我猜你可能没有仔细看全文，角度刁钻是好事但也限制了你看到的内容。生成的随机数碰撞了又如何？它并不会影响中位数的递增，自然也不会影响整体递增。

薄雾的分段，中位是负责保持递增的、中下位和末位两段是为了提高猜测难度的。snowflake 的末位是单位时间的序列号，它是受到影响的，大哥你可不可以把整个思路看完再找角度讨论。[手动捂脸]🤦‍♂️
------------
回复 51 、52 楼 @ryd994
要保证没有碰撞只有维护某个状态或者维护某种单调递增性。你测试没遇到不代表它不可能发生。
你没有遇到碰撞不排除是占了伪随机数算法的便宜。
我就问你两个独立生成的随机数可不可能有碰撞？这是一个数学问题。

我更倾向于认为是你的实现的性能太低，是时间戳而不是随机数保证了不重复

snowflakes 设计时就指出了依赖时间戳保证唯一性的问题：如果在小于时间戳精度的时间内快速反复生成 ID，就有可能发生碰撞。机器 ID 就是为了规避这个情况。因为单机下维护一致性容易多了。
你倒好，把机器 ID 去掉了。在大规模使用时几乎可以保证会发生碰撞。

正是考虑了 snowflake 会受到时间回拨影响才设计的薄雾
----------------
回复 35 楼 @JoshOY
时钟回拨问题是否有考虑？

要是看上下文和应用场景的话，你就会看到列出的需求是什么。
snowflake 是很香，薄雾并不是为了取代它，而是满足相似的需求。单机 snowflake 会有单位时间发号上限且无法给多个客户端使用，多机（多个客户端，每个端一份 snowflake ？）又没办法保证顺序，全局发号中心都是通过网络传输 ID 的，不通过网络难道光用爱传递吗？

在这样的需求场景下，snowflake 它正是不香，所以才有了 UIDGenerator 和 Leaf-Snowflake
--------------
回复 34 楼 @acerlawson
为啥会快呢…

你拿到号的性能瓶颈是网络 IO，比时间戳慢得多。
持久化的瓶颈是磁盘 IO/Redis，人家不需要这东西。

就算只论发号不考虑拿号，人家怎么就比你慢了？高性能环境下，你自己只能单机 vertical scale 。人家可以线性的 horizontal scale，还没有网络和磁盘的负担。

snowflake 他不香吗？

真随机数知识盲区，看到大家说到熵，有空去补充一下。Redis SLA 三个 9 ？
----------------
回复 32 楼 @ManjusakaL

1. 真随机数不是抬杠，各个语言的随机数机制的确不一样，他说的没错，如果要保证严格随机，是需要引入硬件熵源，我们之前用过温度传感器来做随机数种子。对于部分语言，随机数种子固定的情况下，ID 可猜
2. Redis 就是不稳定啊，单节点 Redis SLA 实际上没有 MySQL 等传统数据库来的高，常见的利用 Redis 的场合是对数据有一定容忍度的场合，比如缓存等，但是你这个设计中 Redis 的确是一个短板

欢迎大家来交流和探讨，大家从不同的角度来看待这个场景与需求，看看思路的交锋能不能碰出新的创意。一些明显灌水的评论和明显抬杠的评论我就不回复了哈。

没让你学到东西真是遗憾，书的好坏主观因素很大，这里我没有什么可以解释的。
------------------
回复 24 楼 @biu7
噢文章作者韦世东？看到这个我就要吐嘈一下他的那本《 Python 3 反爬虫原理与绕过实战》。第二章大量抄官方文档，其他章节极其擅长长话短说与短话长说：花了大量文字来叙述基础环境安装过程，而对于关键部分技术一笔带过。虽说我买这本书也没抱着能学点什么新东西的心态，但是此书质量之低还是惊到我了。

可以画流程图的应用挺多的，例如 processon 、WPS 自带的流程图功能、draw.io ，我用的是后面这个，没有文件数限制且图标多

-------------
回复 15 楼 @rainmint

想问下这流程图是用啥软件画的

文中提到了中下位和末位是为了防止通过 ID 猜测日订单量。Snowflake 对标的是 Mist 薄雾算法，Medis 对应的是类似美团 Leaf 那样的服务，Snowflake 如果要做成高可用服务，也是需要结合存储和冗余多机的。
-----------------
回复 14 楼 @catror
简单概括，中位 redis 自增+低位随机数，就是不知道你把低位分两部分算随机数的意义是啥。
方案也不是不行，但是相比 snowflake，redis 和你的 medis 极大的增加了系统的复杂度和维护难度。

这里跟上面的回答观点一致，不会出现碰撞，遂不用规避
--------------
回复 13 楼 @sunny352787

用随机数后面就不用看了，碰撞概率太高，给 UUID 算个 CRC 碰撞概率还低点

1 、维护分布式全局递增函数，同时满足高性能和高可用一点都不困难，困难的是一致性和高可用，业内至今没有办法解决。
2 、Snowflake 的碰撞问题是因为中位用了时间戳，薄雾算法没有用时间戳，所以不会收到单位时间的限制，也不会产生碰撞问题。另外不用担心高流量下的唯一性，Jmeter 5000w 数据测试过了。
3 、真随机数的代码注释是人类主观的注释，是一种泛泛称呼，你要是抬杠的话，我没有什么可以解释的。
4 、获取时间在文中描述的测试代码场景下是比常数耗费时间的，如果能优化那更好。补充一点，在法律领域会采用“一般人”观点，所以我这里描述的获取时间戳耗费性能是相对于常数和随机数的耗费，是一般人观点。
5 、client-server-redis 这样的流程中，必定要经过 server 这一层，预存预取消除的是后面的 Redis 性能影响。后面的那个实测建议原理相同。


------------------------
回复 10 楼 @ryd994

内容太多我就不复制了

如果不关注上下文，单单看标题就给出角度如此刁钻的评价，我建议你去建筑场所抬杠

-------------
回复 7 楼 @xupefei

587 倍性能？写篇论文发顶会吧，没人敢拒。

全局唯一 ID 就是统一的发号中心，你提到的每个实例模块都引入 jar 包的方式（我不懂 Java，不好乱评价）还能保证各个节点生成的 ID 不重复，那真是太厉害了。但是在我看来，无论是统一还是分散的生成渠道，时间依旧是 Snowflake 的缺点，这是要解决的。

另外，提到 Redis 不靠谱、容易出问题，我猜你平时不用 Redis ？

----------
回复 5 、6 楼 @iyaozhen
Snowflake 的好处是这个 jar 包 每个实例模块都可以引入，还能保证各个节点生成的 id 不重复。
你这个是相当于发号中心了。

你这个严重依赖 redis 很不靠谱，实际使用中 redis 容易出问题。

文中单调递增的描述是“下一个 ID 一定大于上一个 ID”，Medis 和 Mist 的设计使生成的 ID 完全符合单调递增特性。你可能没注意看，587 倍性能并不是随机数取代时间戳生成函数，而是常数取代时间戳生成函数。在实测当中它确实提高了性能，这是 benchmark 测试结果，并不是我凭空想象的。就着性能这个话题，如果不追求性能，要分布式何用？另外，高可用是全局唯一 ID 发号服务的底线，无论分布式还是单机，都需要通过冗余手段保证高可用，同时提供服务能力的机器越多，出问题的几率就越大。

另外一个角度看性能问题，如果 1 台机器的性能能抵 5 台机器的性能，是不是可以从设计方面降低实现和维护成本呢？

-----------
回复 2 楼 @aec4d
符合单调递增特性？用随机数替代了取时间函数就声称 587 倍性能。而且这类东东可能设计考虑根本不是性能问题，天天就想搞个大新闻