加速“5G+工业互联网”融合发展

nowflake的优点：

• 主键在单个节点上是按序列递增的，能够按照时间趋势进行递增。
• 主键的生成不依赖于数据库，可以由应用程序生成。
• 在分布式集群内不会产生重复id。
• 可以根据业务需求对bit位进行调整。

snowflake的缺点：

• 对于时间依赖较高，如果时间回拨，则会产生主键重复情况。
• 当集群规模较大时，workid配置会增加一定成本。

美团的Leaf-snowflake，使用zk解决了snowflake依赖于时钟，时间回拨产生重复主键问题;百度的UidGenerator，支持自定义时间戳、workerId、序列号等。

5. Redis模式

利用Redis原子操作INCR和INCRBY来实现，使用Redis集群提高并发量，与步长模式类似，只不过将id生成器由传统数据库换成效率更高的Redis数据库。但是当Redis重启或者宕机，记录主键值会丢失，所以利用Redis进行主键生成时需要对当前主键值进行持久化。Redis支持RDB和AOF两种持久化机制。RDB模式下，可能会丢失部分未打镜像的数据，根据快照恢复后会产生部分重复ID，故RDB不适合实施持久化Redis数据场景。AOF以独立日志记录每次写命令，重启时执行日志中的命令进行数据恢复，不会出现ID重复现象，但是会由于备份命令过多，导致Redis恢复数据时间较长。

以上介绍了五种数据库主键的生成策略，大家可以根据具体业务场景和系统实际情况选择一款最适合自己的主键策略，提升数据库性能，保证在高并发情况下系统运行稳定性。

 

号段模式将主键缓存在应用服务端，从而减少对数据库的访问频率;在数据库数据库不可用时，应用服务仍然可以持续运行一段时间直到当前号段用完;但是在应用服务重启时有可能丢失部分id，导致id增长不连续。

基于号段模式有一些成熟方案，且经过实践验证：美团的Leaf-segment对号段发放方式进行了双buffer缓存及高可用容灾优化。采用双buffer模式，在当前号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段，不会在应用服务器向数据库请求id时，因为id号段没有取回来，导致线程阻塞。

滴滴的TinyId参照了美团Leaf的实现方式，并对其做了扩展，增加了多db支持和tinyid-client。

4. snowflake模式(雪花算法)

Twitter实现的分布式ID生成算法。结构如下：0-00000000000000000000000000000000000000000-00000-00000-000000000000

• 1 bit：保留位，为符号位，全部为0，表示生成的id都是正数。
• 41bit：时间戳，单位为毫秒，41位可以表示69年的时间。
• 10bit：机器id，10bit里面5位代表机房id，5位代表机器id，可以表示32个机房，每个机房里面可以用32台机器。
• 12bit：12位序列号，按顺序递增，记录每个节点1毫秒内产生的id，每毫秒可以产生4096个id。

 

（编辑：淮南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!