分布式ID生成器PHP+Swoole实现介绍

标签：问题   存储   表示   ...   高效   传输协议   固定   php   机器   

1.发号器介绍

什么是发号器？

全局唯一ID生成器，主要用于分库分表唯一ID，分布式系统数据的唯一标识。

是否需要发号器？

1）是否需要全局唯一。

分布式系统应该不受单点递增ID限制，中心式的会涉及到锁的问题，而锁意味着成本和性能的下降。

2）时间相关。

时间是天然唯一递增的，不过每秒或每毫秒生成一个唯一ID明显不够，这时候就需要引入SequenceID，使得发号器能在秒或毫秒时间内继续递增，如果引入服务器实例编号、业务编号，多维依赖能使ID值在同一秒或毫秒内生成的更多。

如果要做到精确有序，需要对SequenceID进行并发控制，性能上肯定会打折。所以在秒或毫秒级别上不再保证顺序是系统应该要考虑是否能接受的地方。

3）可反解，解开的是什么？

ID反解能得到这条信息是什么时候生成的，由什么业务生成的，在哪台服务器上生成，这相当于身份证，身份证就是一个典型的分布式ID生成器。比如：

4）可制造（伪造一个过去的一条业务记录）。

比如在存储失败时，可能需要临时导出请求供后续处理，而后续处理时已经离开了当时的时间点，顺序跟其他系统错开了。我们需要制造出这样的ID 以便系统好像一直正常运行一样，可制造的 ID让你可以控制生产日期。为什么不用UUID？字符串型查询效率低；无序；太长了...

2.业界已知的ID设计

1）SnowFlake

推特的分布式自增ID算法。41bit留给毫秒时间，10bit给MachineID，也就是机器要预先配置，剩下12位留给Sequence。

这里的时间戳保存的是当前时间与固定过去时间得一个差值，不是当前时间。这样的好处是能使用更长时间，而且不受年份限制，只取决于从什么时候开始用的，2^41 / 1000360024*365=69年。

如果保存的是当前时间戳，最多只能使用到2039年。2^41=2199023255552=2039/9/7 23:47:35

理论上单机速度：2^12*1000 = 4 096 000/s

2）微博

微博使用了秒级的时间，用了30bit，Sequence 用了15位，理论上可以搞定2^15=3.2w/s的速度。

用4bit来区分IDC，也就是可以支持16个 IDC。剩下的有2bit 用来区分业务，由于当前发号服务是机房中心式的，1bit 来区分热备。30+15+4+2+1=52

服务端使用memcache协议。

3.设计细节

2+41+4+10+7 = 64

• 固定位01, 0表示符号位，1统一长度19位
• 4位服务器编号可支持开启16个集群实例
• 10位业务编号支持1024个业务分类
• 理论上单机速度2^7*1000 = 128 000/s

运行流程图

为什么要用到swoole？

• 1）使用Redis传输协议，作为内部数据交互比http更高效。
• 2）swoole_table共享内存变量，解决多进程间的数据共享和同步问题。
• 3）swoole_atomic多进程间的数据同步加锁。

分布式ID生成器PHP+Swoole实现介绍

标签：问题   存储   表示   ...   高效   传输协议   固定   php   机器   

原文地址：https://www.cnblogs.com/gouyg/p/IDIdentifier-for-php-swoole.html