分布式自增 id 的高阶

需求:

1. 高性能

2. 可扩展

3.高可靠

   mysql多台 步长不同. [3]

3. 相对自增

    步长法. 新增机器前需要变更步长. 通知+主动获取的方式来读取更新的步长.

4. 无抖动稳定性高

   双 buffer

5. 带分表基因

几个著名的方案:

1. 淘宝 id

2. twitter 雪花 snak

  instagram 强耦合分片 id 到 id 中. 最好改成分片基因 [1]

3. flicker 的 replaceinto +缓存双 [2]  +号段

    不过 一个业务一张表. 平台性差.

    号段= id*放大倍数.   步长下沉到持久化层. [3] 该文献中还是利用了 flicker 一业务一表的方式. 可以再改进.

 

4. cas +mysql +双缓存

    可以分机器,步长不同. 可靠性 [3]

    号段= id*放大倍数.   步长下沉到持久化层. [3]

5. cas zk etcd +双缓存.

1. 雪花算法的致命问题是什么

      时间倒退

2. docker 中无法配置硬件 id

3.同一秒并发太多.

解决方案:

    2. work 值每次重启的时候增加. %2^xxx

   1.  如果时间倒退那么就增加 worker值.[ phil 自创 ]

            或者 记录上一次时间,时间倒退直接抛错. 传统解决方案,百度也是.

   3. 同一秒,超过最需序号,等待

  

上诉方案引发新的问题. worker 值同一秒启动过多?

特别是 docker 自动编排后, 很尴尬.

参考: 订单号/唯一序列号生成方案（中篇）

百度开源的分布式 id 生成器. 说到了一个伪共享问题.利用 padding补到64位解决了.缓存连续分配的问题.

解答 什么是伪共享,如何测试,如何避免(百度 id 中有说明): http://ifeve.com/falsesharing/ 本文中我将解释Java对象的内存布局以及我们该如何填充缓存行以避免伪共享

百度的这个问题是,用完即弃的 workerId生成规则. 其实 workerId 可以循环使用. 因为秒数是不停的累加的. 只要保证一秒内,不频繁重启就好了. 集群100台,每台重启十次. 也需要1024位.

[1] 分布式系统中唯一 ID 的生成方法 https://mp.weixin.qq.com/s/l3Nrm_fqaFohQ_i4-DYXfA 内含"先简单介绍一下 instagram 的分布式存储方案:"

[2] Leaf——美团点评分布式ID生成系统 https://tech.meituan.com/MT_Leaf.html

[3]干货 | 分布式架构系统生成全局唯一序列号的一个思路https://mp.weixin.qq.com/s/nzIHKa8O75vgu7OqkFivWw