NightTeam 最近的时间轴更新 NightTeam 最近的时间轴更新 | NightTeamV2EX 第 441637 号会员，加入于 2019-09-17 15:37:53 +08:00 |
| Javascript 混淆与逆向必读之 AST 节点类型名词基础 1 Javascript NightTeam 2020 年 7 月 12 日 |
| 开源一个网页智能解析算法库 6 分享创造 NightTeam 2021 年 9 月 4 日 最后回复来自 gancl | 6 |
| 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法 7 分享创造 NightTeam 2020 年 7 月 30 日 最后回复来自 tenwx | 156 |
NightTeam 最近回复了
2020 年 7 月 23 日 回复了 NightTeam 创建的主题 分享创造 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法 |
@luren123 #135 #136 不要把自己的场景强行套到别人的场景上，这个做法是很可笑的。因为这样做之后，无论什么东西你都只能得出“不具有实战价值”的结论，就像拿刀叉来吃米饭、拿试管来喝水、拿扫把来拖地一样。
2020 年 7 月 23 日 回复了 NightTeam 创建的主题 分享创造 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法 |
@yeziqing #134 每个需要获取 ID 的机子会去找发号器取 ID，发号器是中心化的所以就是严格顺序的。
2020 年 7 月 23 日 回复了 NightTeam 创建的主题 分享创造 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法 |
@cassyfar #133 自己骂自己可真有意思，您最初在#52 所发表的言论：“纸上谈兵。给我感觉是一群没做过工程的在那玩花活。各种 buzzword，但是一看设计啼笑皆非吧。”，可是刚好适用于您所谓的“偏激的喷子”描述的呢。
2020 年 7 月 7 日 回复了 NightTeam 创建的主题 分享创造 开源一个网页智能解析算法库 |
Gerapy 开发交流群满 200 人了，要进群的话直接加微信 CQCcqc 吧。
2020 年 7 月 6 日 回复了 NightTeam 创建的主题 分享创造 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法 |
自己测试找到问题了，错在“不可猜测性”，我找时间改改。和部分评论指出的问题一致，原因也相差不多。
2020 年 7 月 6 日 回复了 NightTeam 创建的主题 分享创造 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法 |
卧槽，老哥强的一笔
----------------
回复 125 楼 @tikazyq
有一些原创的东西放出来发在社区里讨论，本来是好事情，但很多人冥顽不化、固步自封、敝帚自珍，见不得一些新事物，以为自己了解的才是最好的。其实，当你用开放的心态来面对新事物，会进步得更多。
例如，之前我发了个用 Redis 套壳做 RPC，被很多人吐槽说为什么不用 gRPC 、这方案很奇葩之类的。我一笑了之。不料后来这方案成了我 6k star 开源项目的核心技术之一，而且非常稳定。
所以啊，当你没有深入了解一门新技术的时候，就要克制自己，多自我批判一下是不是自己的想法太单一了。
----------------
回复 125 楼 @tikazyq
有一些原创的东西放出来发在社区里讨论，本来是好事情，但很多人冥顽不化、固步自封、敝帚自珍，见不得一些新事物，以为自己了解的才是最好的。其实，当你用开放的心态来面对新事物，会进步得更多。
例如，之前我发了个用 Redis 套壳做 RPC，被很多人吐槽说为什么不用 gRPC 、这方案很奇葩之类的。我一笑了之。不料后来这方案成了我 6k star 开源项目的核心技术之一，而且非常稳定。
所以啊，当你没有深入了解一门新技术的时候，就要克制自己，多自我批判一下是不是自己的想法太单一了。
2020 年 7 月 4 日 回复了 NightTeam 创建的主题 分享创造 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法 |
2020 年 7 月 4 日 回复了 NightTeam 创建的主题 分享创造 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法 |
整体中肯，是个好评论。我看大部分矛头都直指“作者思路错误、设计垃圾”，从来没有人看到文章里对另外几个实现方式的描述和欣赏。
我写篇文章不是要证明我一定对或者谁一定错，大家指出点就可以了，其他人评论里人身攻击要不得。
1 、要说获取那当然机器上直接读取比通过网络传输来的快。
2 、Snowflake 做好冗余和负载是可以提供很高效服务的，前提是时间对齐。
----------------------
回复 102 楼 @quericy
个人感觉更关键在于，楼主的这套方案在分布式系统实际部署中将更加缺乏说服力：
1，性能瓶颈。举个简单的例子，异地双机房部署的场景下，"薄雾"引入的 redis 单点如何确保对端机房服务的性能表现？ Snowflake 只需要做到机器时间对齐，"薄雾"跨机房的网络开销和抖动均会大大拖慢发号性能，网络 IO 的损耗可不是和时间戳获取可不是一个量级的。
2，可用性。redis 所在机房断网时，异地机房是否还可对外提供服务？ Snowflake 的 AP 特性可以在确保时间正确的前提下提供服务，"薄雾"目前的方案依赖 CP 在上述场景下是无法满足可用性的。
我写篇文章不是要证明我一定对或者谁一定错，大家指出点就可以了，其他人评论里人身攻击要不得。
1 、要说获取那当然机器上直接读取比通过网络传输来的快。
2 、Snowflake 做好冗余和负载是可以提供很高效服务的，前提是时间对齐。
----------------------
回复 102 楼 @quericy
个人感觉更关键在于，楼主的这套方案在分布式系统实际部署中将更加缺乏说服力：
1，性能瓶颈。举个简单的例子，异地双机房部署的场景下，"薄雾"引入的 redis 单点如何确保对端机房服务的性能表现？ Snowflake 只需要做到机器时间对齐，"薄雾"跨机房的网络开销和抖动均会大大拖慢发号性能，网络 IO 的损耗可不是和时间戳获取可不是一个量级的。
2，可用性。redis 所在机房断网时，异地机房是否还可对外提供服务？ Snowflake 的 AP 特性可以在确保时间正确的前提下提供服务，"薄雾"目前的方案依赖 CP 在上述场景下是无法满足可用性的。
2020 年 7 月 4 日 回复了 NightTeam 创建的主题 分享创造 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法 |
2020 年 7 月 4 日 回复了 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，虽然标题党，但内容没有轻蔑。
针对这个观点，是不是又可以衍生出两个论点：
1 、手动维护机器 ID，如果你要自动分配是不是还得引入 zk 这样的组件？引入是不是还会引发其他问题，增加一些工作量，同时还要确保 id 不会漂移。（ zk 没具体了解过，粗浅认知）
2 、如果末位的数值超过上限，它在位运算的时候就会溢出到高位（当然你不用位运算异或我就没办法了，当我没说），溢出到高位必定导致重复或乱序。
3 、针对第 2 点，我只看过 Golang 的 Snowflake 实现，也就是文中配图的那个实现，如果它的实现出错有问题，那我的第 2 个观点也站不住脚。
4 、当然，可以限制 Snowflake 末位值的长度，限制在 12 bit 内以保证不溢出。那就回到了另一个问题，单位时间的 id 上限。
5 、这只是一个权衡选择，我没有说这个完全可以替代 Snowflake，虽然标题党，但内容没有轻蔑。
Select Language