卧槽，老哥强的一笔
----------------
回复 125 楼 @tikazyq

有一些原创的东西放出来发在社区里讨论，本来是好事情，但很多人冥顽不化、固步自封、敝帚自珍，见不得一些新事物，以为自己了解的才是最好的。其实，当你用开放的心态来面对新事物，会进步得更多。

例如，之前我发了个用 Redis 套壳做 RPC，被很多人吐槽说为什么不用 gRPC 、这方案很奇葩之类的。我一笑了之。不料后来这方案成了我 6k star 开源项目的核心技术之一，而且非常稳定。

所以啊，当你没有深入了解一门新技术的时候，就要克制自己，多自我批判一下是不是自己的想法太单一了。

Jul 4, 2020

Replied to a topic by NightTeam › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法

你这么说，拿号的顺序就不重要了，无可辩驳。
--------------------
回复 101 楼 @rwx
毫秒内的严格递增到底有什么实际意义？就算你能递增的拿号，你能保证递增的使用吗？

Jul 4, 2020

Replied to a topic by NightTeam › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法

整体中肯，是个好评论。我看大部分矛头都直指“作者思路错误、设计垃圾”，从来没有人看到文章里对另外几个实现方式的描述和欣赏。

我写篇文章不是要证明我一定对或者谁一定错，大家指出点就可以了，其他人评论里人身攻击要不得。

1 、要说获取那当然机器上直接读取比通过网络传输来的快。
2 、Snowflake 做好冗余和负载是可以提供很高效服务的，前提是时间对齐。
----------------------
回复 102 楼 @quericy

个人感觉更关键在于，楼主的这套方案在分布式系统实际部署中将更加缺乏说服力：
1，性能瓶颈。举个简单的例子，异地双机房部署的场景下，"薄雾"引入的 redis 单点如何确保对端机房服务的性能表现？ Snowflake 只需要做到机器时间对齐，"薄雾"跨机房的网络开销和抖动均会大大拖慢发号性能，网络 IO 的损耗可不是和时间戳获取可不是一个量级的。

2，可用性。redis 所在机房断网时，异地机房是否还可对外提供服务？ Snowflake 的 AP 特性可以在确保时间正确的前提下提供服务，"薄雾"目前的方案依赖 CP 在上述场景下是无法满足可用性的。

Jul 4, 2020

Replied to a topic by NightTeam › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法

下次看完全文再喷哈，闭着眼睛喷是你的习惯吗？
------------
回复 99 楼 @louislivi
用了 Redis 就会建立 TCP 连接，这效率能比 Snowflake 高？

Jul 4, 2020

Replied to a topic by NightTeam › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法

哎，怎么还是抓住 Snowflake 机器 ID 这个点在反问呢？做个例子它不香吗？假设 A 、B 两台机器的 ID 为 2 和 1，A 的机器 ID 比 B 的大，你们的意思是 A 上面的 Snowflake 值一定大过 B 的值，因为机器 ID 在高位？？？

针对这个观点，是不是又可以衍生出两个论点：

1 、手动维护机器 ID，如果你要自动分配是不是还得引入 zk 这样的组件？引入是不是还会引发其他问题，增加一些工作量，同时还要确保 id 不会漂移。（ zk 没具体了解过，粗浅认知）
2 、如果末位的数值超过上限，它在位运算的时候就会溢出到高位（当然你不用位运算异或我就没办法了，当我没说），溢出到高位必定导致重复或乱序。
3 、针对第 2 点，我只看过 Golang 的 Snowflake 实现，也就是文中配图的那个实现，如果它的实现出错有问题，那我的第 2 个观点也站不住脚。
4 、当然，可以限制 Snowflake 末位值的长度，限制在 12 bit 内以保证不溢出。那就回到了另一个问题，单位时间的 id 上限。
5 、这只是一个权衡选择，我没有说这个完全可以替代 Snowflake，虽然标题党，但内容没有轻蔑。

» More replies by NightTeam