标签：场景   分布式ID   信息安全   整数   系统   延迟   批量   能力   查询   

分布式唯一ID

一、逻辑要求

1. 全局唯一：相同业务和不同业务id都要保证不重复，以满足分布式部署、弹性伸缩、数据治理、追溯等要求。

2. 趋势递增：需要对BTree数据结构友好，保证查询性能。

3. 单调递增：在相同业务内保证后生成的id一定比先生成的大，满足事务版本号、IM实时消息、排序等要求。

4. 信息安全：增加猜测难度，防止恶意爬取和猜测，通过猜测获取订单量、篡改记录等安全问题。

5. 包含时间特征：方便数据定位。

二、性能要求

高可用：对整个系统来说属于核心功能，必须满足99.999%的可用性。

低延迟：响应要快，满足极速要求。

高QPS：能应对高并发，和批量生成要求。

三、方案

uuid：满足条件1，太长对索引不友好，无序对索引不友好会导致BTree节点分裂问题降低索引性能，不能得出先后顺序。

自增主键 + replace-into：建立专门的sequence表，向各服务输出id，主键自增、模块key设唯一索引，能保证模块内id的唯一且自增，但是面对低延迟高并发能力不强。小分布式系统采用，集群部署mysql时需要分段处理，部署麻烦，安全性不高 。

Redis：利用Redis的单线程天生原子性，increase by，满足性能要求，要集群分段才能满足高可用，但是节点故障后会错乱，维护成本较高，安全性不高。

snowflake算法：

1. 在时间上有序且单调递增。
2. 生成64位的long型整数，转换为String后最大长度为19，对索引友好。
3. 分布式系统内不会发生id碰撞（使用datacenterId+workerId区分），效率极高。
4. 一般场景直接使用hutool的IdUtil就可生成，特殊要求可以使用百度、美团的封装。

分布式ID生成

标签：场景   分布式ID   信息安全   整数   系统   延迟   批量   能力   查询   

原文地址：https://www.cnblogs.com/JaxYoun/p/12887858.html