首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  NightTeam  ›  全部回复第 1 页 / 共 2 页
回复总数  34
1  2  
❮ ❯
2020-07-23 10:50:11 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
@luren123 #135 #136 不要把自己的场景强行套到别人的场景上，这个做法是很可笑的。因为这样做之后，无论什么东西你都只能得出“不具有实战价值”的结论，就像拿刀叉来吃米饭、拿试管来喝水、拿扫把来拖地一样。
2020-07-23 10:45:39 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
@yeziqing #134 每个需要获取 ID 的机子会去找发号器取 ID，发号器是中心化的所以就是严格顺序的。
2020-07-23 10:40:36 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
@cassyfar #133 自己骂自己可真有意思，您最初在#52 所发表的言论：“纸上谈兵。给我感觉是一群没做过工程的在那玩花活。各种 buzzword，但是一看设计啼笑皆非吧。”，可是刚好适用于您所谓的“偏激的喷子”描述的呢。
2020-07-07 16:44:08 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 开源一个网页智能解析算法库
Gerapy 开发交流群满 200 人了，要进群的话直接加微信 CQCcqc 吧。
2020-07-06 22:18:33 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
自己测试找到问题了，错在“不可猜测性”，我找时间改改。和部分评论指出的问题一致，原因也相差不多。
2020-07-06 16:56:17 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
卧槽，老哥强的一笔
----------------
回复 125 楼 @tikazyq

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

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

所以啊，当你没有深入了解一门新技术的时候，就要克制自己，多自我批判一下是不是自己的想法太单一了。
2020-07-04 18:54:38 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
你这么说，拿号的顺序就不重要了，无可辩驳。
--------------------
回复 101 楼 @rwx
毫秒内的严格递增到底有什么实际意义？就算你能递增的拿号，你能保证递增的使用吗？
2020-07-04 18:52:18 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
整体中肯，是个好评论。我看大部分矛头都直指“作者思路错误、设计垃圾”，从来没有人看到文章里对另外几个实现方式的描述和欣赏。

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

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

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

2，可用性。redis 所在机房断网时，异地机房是否还可对外提供服务？ Snowflake 的 AP 特性可以在确保时间正确的前提下提供服务，"薄雾"目前的方案依赖 CP 在上述场景下是无法满足可用性的。
2020-07-04 18:39:36 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
下次看完全文再喷哈，闭着眼睛喷是你的习惯吗？
------------
回复 99 楼 @louislivi
用了 Redis 就会建立 TCP 连接，这效率能比 Snowflake 高？
2020-07-04 14:47:53 +08:00
回复了 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，虽然标题党，但内容没有轻蔑。
2020-07-04 14:17:32 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
不用集中发号，而是每个机器一份 snowflake，你看看它那分段设计，你就知道同一时间生成的 ID 必定是重复的，没有例外。
--------------
回复 64 楼 @renyijiu
哪里表明 snowflake 多机无法保证顺序？
2020-07-04 12:50:46 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
在目前领域内 KV 基本都是 3 个 9 的情况下，确实是可以切换到其他存储的，这个设计的预存预取就是为了忽略存储性能影响，以便可以切换存储的。

Snowflake 的机器 ID 并不是为了解决重复问题的，时间戳+序列号才是。单机情况下是没有问题，那多机且每台机器都一份 jar 的话，你如何确保同一时间生成的 ID 不重复？且递增？序列号不共享，它自行按照自己的序号来生成，同一时间不同机器生成的 ID 必定是重复且不递增的。和语言无关。

我这里虚心请教一下，提高可用性的话，除了将 KV 换成其他存储，你还能想到其他办法吗？


----------------------------
回复 41 楼 @iyaozhen

我感觉是你没有大规模用过
我说的 redis 不稳定是 redis 这一套链路不稳定，故障的原因很多，单一性不稳定。3 个 9 不是很高，我上层业务要 4 个 9 怎么办？至少得双存储

“你提到的每个实例模块都引入 jar 包的方式（我不懂 Java，不好乱评价）还能保证各个节点生成的 ID 不重复，那真是太厉害了”
不懂 java 没关系呀，就是类似 go import 一个包
你自己也说了“中下位占 10 bit，值为工作机器的 ID，值的上限为 1024” 每个机器 id 不一样 生成的肯定能保证不重复呀

时钟回拨是个问题，但你的做法只是用 redis 来代替本地时间，这个可靠性是降了几个数量级的
2020-07-04 12:45:05 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
是的，我看这算是为数不多的中肯评论。我看很多人就是为了标题而喷的，来的时候就带着有色眼镜和高期望，结果看到一个很简单且不高明的设计就开始了。

我没有恶意，只是表达自己的观点和看法，也吸收大家给的建议和看法。这次来 V2EX 我觉得讨论氛围很好，大家都很愿意表达自己的看法，排除一部分为喷而喷和灌水的，我觉得一部分人看了文章并且给出了看法和意见，这我就满足了。
--------------
回复 46 楼 @oneisall8955
我的理解是通过增加中位长度，并且一定的手段如 redis 获取自增值，来规避雪花基于时间会回拨导致重复或不单调自增的弊端，达到随机和单调。本质上和雪花算法是一样的，只是获取雪花基于机器时间存在弊端，你采取的依赖 redis 自增，使得单调递增控制在自己手里。好处显而易见，弊端大家也懂，依赖外部服务，增加网络 IO 时间（存在 buffer 发号且 client 和 Server 都在内网其实 IO 时间可以忽略吧），有舍有得。另外，大家没必要互相喷吧，作者提供一个思路而已。可能文中写的很自信，这里看不惯别人不谦虚吧。（吐槽下文末请大家小心是什么鬼，辣眼睛）
2020-07-04 12:41:34 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
先讲道理，分布式环境下以我粗浅的学识还没见过高明的算法（我看到的算法和协议都是为了场景和需求权衡折中，例如 Raft 、NWR 、Paxos ），我已经说明了我学识浅，后面的人就不用抓着这里喷了哈。

用位和分段组合的方式稍稍比你提出这个好一些，但是本质上确是 id + rand 的结构，没错。
-------------------
@RemRain

大家也不用嘲讽楼主，这个算法看着不高明，确实能解决问题

我这早年有一个项目干过类似的事，也是不想让用户看出自增 id，不过我们的算法更简单粗暴，是这样设计的：

id += rand.Intn(100000)

楼主可以考虑换成这个算法，和你的效果完全一致，但是更好理解
2020-07-04 12:37:27 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
讲道理，snowflake 在单机上确实没有什么大问题，就算单机对号的需求不会突破单位时间的上限，但是时间回拨你不考虑？
机器越多，出现的回拨整体概率是不是也就越大？

你把 snowflake 的长度增大，可以解决单位时间上限问题，那回拨你永远不考虑了吗？拿到重复的 ID 怎么办？拿到不递增的 ID 怎么办？

按需求场景来说，如果你的需求对 ID 重复和递增情况无所谓，那你的描述确实是可以的。
------------------
回复 71 楼 @fwee
老实说 LZ 文章前半段介绍部分写的不错，后面的算法就是我这个分布式外行也能看出来 snowflake 的价值就是（除时钟外）无状态，你把人家优点给改没了。

我也发明个算法，用 128bits 来表示 id，把 snowflake 每个段增大一倍，估计性能吊打你这个不知道多少倍，容我三个月想个好名字
2020-07-04 12:33:43 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
是的，它的猜测上限就是 256 * 256，我并没有指望通过两段小随机数屏蔽所有人，如果你盯着这个角度，那确实相当刁钻（你猜测完随机数，是不是还得猜测前面的中位？）。
既然你提到 MD5，那我来提个问题：
1 、MD5 并不是不能破解，业内也有人破解
2 、可以自己生成数和 MD5 值进行对比，也能得到结果（和上面的枚举破解方法相同）
3 、你的意思是要追求很高的隐匿性？那我觉得就不能 64 bit 了，可能会 128，然后为了安全性再做很多的尝试和权衡
--------------------
回复 68 楼 @RemRain
我看明白了，这算法本质就是给自增 id 拼个随机数后缀，什么高位低位的，只是设置随机数长度是 16 位：

比如我的 id 是 0x33，最终结果可能就是 0x330A0B 。表面上猜不出下一个 id 了，实际由于随机数长度只有 16 位，最多枚举 65536 次就能猜中

这个算法存在单点问题，两台机器如果不借助外存，生成的 id 有很高的碰撞概率。如果已经借助外存获取自增 id 了，直接 md5(id) 不香吗
2020-07-04 12:28:32 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
首先说明，标题起不好根本没有机会跟大家交流讨论。再有，snowflake 确实是时间戳，这里用随机数和常数作为测试，是有问题吗？

[手动滑稽] 大家如果盯着 587 不放，忽略了设计的背景需求和应用场景，那就太可惜了
-----------------------
回复 49 楼 @Deepseafish
原来 587 倍是这么来的，把自己算法中的随机数换成常数，然后和再和自己使用随机数的算法比较。这个标题起的实在是高。
2020-07-04 12:25:48 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
我们来看看时间回拨问题，这里提到 sleep，如果它回拨了 5 秒是不是要 sleep 5 秒？如果它回拨了 20 秒甚至更长时间呢？其他要拿号的客户端就会受到很大的影响。

snowflake 的分布式问题，无论你怎么分布，毫秒的上限现在是固定的，如果并发数高是不是就用不了它了？本地，每个机器一个 snowflake 你如何保证末位的序列号不重叠？拿这就到了递增问题和唯一问题这里来了。

要不然你以为干嘛非得搞个发号中心负责发号？

单点故障可以通过机器冗余来解决，业内都是这么做的，你能找到其他办法那就更好了
-----------------------------
回复 42 楼 @optional
snowflake 的分布式可以是同机房的分布式，也可以是异地甚至全球的分布式。而且是无网络依赖了，本地就可以生成。 时间问题可以用 GPS 授时（低成本）和原子钟（高成本），至于回拨其实很简单用一个变量记录最后生成事件，回拨就 sleep 就好，因为回拨是个低频的事情，所以偶尔的低性能也能接受。
但是你用 id 服务器后，基本就只能限制在一定范围了，而且还有单点故障。
2020-07-04 12:19:25 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
首先阐明一个观点，两个随机数的安全性自然不高，严格按照安全领域的“一般人学说”来说猜测难度确实低。但你不知道位数分段和随机数的情况下，你写个程序来猜？这个随机是为了挡住部分人，不是所有人（复杂如 RSA 也没有挡住所有人）。

另外看到你列觉了时间戳变化和自增 id 的变化，那按照你的观点把中位挑出来做减法，这样来看的话时间戳和自增有区别吗？你都挑出中位来了，那挑出中位和末位一起计算也不是问题了，同一个难度。

------------------
回复 56 楼 @jinliming2
那么我问个问题，你这个算法怎么保证信息安全？因为你中间使用的是自增 id，所以我只需要把中间那个自增 id 取出来，然后每天减一下，就能知道你一天生成了多少 id ？
中间用时间戳好理解，数值变化一天固定就是变一天的时间戳。但自增 id ？
2020-07-04 12:11:39 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
就需求论事，如果上升到千万 QPS 又要保证 3 个 9 或者更高的 SLA，那高素质团队自研确实才是出路。你们的业务要求系统稳定和高可用，才会有后面的 3 年 30 人自研存储。脱离需求而喷，还夹带 3 年 30 人千万 QPS 这么准确的数据，你莫不是为了喷而来的？

换一个角度说，在目前大部分 KV 都是 3 个 9 以下的情况下，你认为怎么做才更合适？实际上 Redis 只是实现的样例之一，可以把存储换成 MySQL，因为用了预存预取所以换什么存储都不会影响原有效率但是确实可以提高 SLA 。

你从程序设计或者架构的角度给大家讲解一下，如果是你来做，你根据上面描述的需求你会怎么设计？
----------------
回复 52 楼 @cassyfar
纸上谈兵。给我感觉是一群没做过工程的在那玩花活。各种 buzzword，但是一看设计啼笑皆非吧。

自增算法在多分布情况下怎么解决一致性？别告诉我你要用一台机器撑起百万，千万 QPS 吧。
解决一致性我能想到实际的就是锁，但是多线程性能降低不厉害？
另外存储的运维不严重？性能依赖不过分？我以前的公司做千万 QPS 的 auth，要依赖数据库。工业界没有数据库能达到期望的 availability，只有自己花了 3 年，30 人团队开发了一个。你用一个 reddis，我真的打扰了。
最后的最后，你可能不知道工业界系统设计原则之一，keep it simple 。这不是炫技。
1  2  
❮ ❯
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   999 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 67ms · UTC 21:14 · PVG 05:14 · LAX 13:14 · JFK 16:14
Developed with CodeLauncher
♥ Do have faith in what you're doing.