分布式ID， 咱们可能都听过分布式系统，分布式，分布式ID可能比拟少，因为业务，方向以及系统维护的方面登程，当初的互联网中的我的项目，少数都须要一个全局且惟一，有增量趋势的标识。目前用的可能是MySQL的自增主键，UUID，工夫戳等，然而对于日益增长的音讯零碎，点评，领取等具体操作，都须要一个稳固，全局惟一，且有显著自增趋势的ID作为惟一标识。
## 一个分布式全局ID的硬性要求
其中信息安全，可能有的小伙伴不太理解，你每次申请获取的ID（查问操作），这个如果是递增，咱们就能直观的判断出有信息，多少人，这是第多少个等，这属于敏感信息泄露的领域， 平安还是很重要的；
规定咱们确定之后，咱们就要求生成这个ID零碎的要求，
之前是对于生成单个一个ID的要求，
## 对ID系统生成的可用性要求
因为是存在于分布式系统的，那也就是咱们比拟相熟的，
高可用：发动一个获取分布式ID的申请时，必须保障服务器在99.999%的时候给我创立胜利
低提早： 获取分布式ID,服务器响应疾速，不能有高提早，会有误差
高并发： 一秒钟能够获取10万左右的ID,而且要胜利，服务器要扛得住
### 情景再现：
面试中，对于面试者做过的我的项目，面试官个别会采纳聊集群，QPS等状况验证，我的项目的真实性， 其中分布式ID就属于具体实现了，个别会问：
你们我的项目是，散布式微服务，集群化部署，电商的这个零碎中对于订单，领取等全局ID是如何生成的？
雪花算法 snowFlake；
## 当初零碎罕用的ID生成形式：
数据库自增，UUID ，工夫戳；Redis集群
### (1) 数据库自增（mysql自增）
其中数据库自增，对于单体零碎，后盾零碎用的比拟多，因为并发小，应用人数也少，适宜于小零碎，QPS个别几十到一百左右的，
毛病：
对于数据敏感的场景不宜应用， 且支撑不了分布式场景，自增之后还是会还原为原来的数值### (2) UUID
UUID用的是比拟广泛的一个ID, 因为全局惟一，然而它存在很多的问题
UUID的毛病：
无序，且无奈预测生成程序，无奈无效的出现递增趋势
存储，字段很长，消耗数据库资源，对于特点环境存在一些问题，
长处：只剩下全局惟一了
### （3）工夫戳
个别能够应用工夫戳加具体的业务ID 来规定，然而用的也比拟少
（4）基于Redis集群生成策略
因为Redis个性是基于单线程，所以用它生成ID操作是原子性的，
集群化能够实现，
通过设施集群的增长步长，起始值，就能够
比方Redis集群有五台机器， 能够初始化为每台Redis的值 1，2，3，4，5；步长是5；
各个Redis生成的Id为：
A:1,6,11,16,21,...
B:2,7,12,17.22,...
C:3,8,13,18,23,...
D:4,9,14,19,24,...
E:5,10,15,20,25,...
尽管能够实现，然而配置Redis集群后， 要实现数据失落怎么办，key的生效工夫等等，
不是不能做，是杀鸡焉用牛刀，对的；
而后就到了咱们明天的主题：
(5)Twitter开源的snowflake;
Snowflake（雪花） 是一项服务，用于为 Twitter 内的对象（推文，间接音讯，用户，汇合，列表等）生成惟一的 ID。这些 IDs 是惟一的 64 位无符号整数，它们基于工夫，而不是程序的。残缺的 ID 由工夫戳，工作机器编号和序列号组成。当在 API 中应用 JSON 数据格式时，请务必始终应用 id_str 字段而不是 id，这一点很重要。这是因为解决JSON 的 Javascript 和其余语言计算大整数的形式造成的。如果你遇到 id 和 id_str 仿佛不匹配的状况，这是因为你的环境曾经解析了 id 整数，并在解决的过程中仔细分析了这个数字。
Twitter的分布式雪花算法SnowFlake,经测试snowflake每秒可能产生26万个自增可排序的ID1、twitter的SnowFlake生成ID可能依照工夫有序生成2、SnowFlake算法生成id的后果是一个64bit大小的整数，为一个Long型（转换成字符串后长度最多19).3、分布式系统内不会产生ID碰撞（由datacenter和workerld作辨别）并且效率较高。
分布式系统中，有一些须要应用全局惟一ID的场景，生成ID的根本要求
1.在分布式的环境下必须全局且惟一。
比照
2.个别都须要枯燥递增，因为个别惟一ID都会存到数据库，而Intodb的个性就是将内容存储在主键索引树上的叶子节点，而且是从左往右，递增的，所以思考到数据库性能，个别生成的id也最好是枯燥递增。为了避免ID抵触能够应用36位的UUID,然而UUID有一些毛病，首先他绝对比拟长，另外UUID-般是无序的
snowflake是中能够用69年是否成立？
雪花算法能够高度惟一和可用性工夫长：
作比拟， 41位的1二进制数字，对于十进制来说，是多少呢；
十进制的数字是：2199023255551
https://tool.lu/hexconvert/ 进制转换的工具箱
我做了个demo来证实:
其中次要设置的是 10位的工作过程位；-
个别分为数据中心和机器位
生成snowFlake的ID
咱们以springboot的我的项目来构建这个snowFlake的ID生成，
依赖：
<!-- hutool对于sonwFlake的应用 --> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-captcha</artifactId> <version>5.6.0</version> </dependency>这里咱们示意的是Java代码库中，hutool的类库，调用曾经封装好的IdUtil就好
package com.generate;import cn.hutool.core.lang.Snowflake;import cn.hutool.core.net.NetUtil;import cn.hutool.core.util.IdUtil;import lombok.extern.slf4j.Slf4j;import org.springframework.stereotype.Component;import javax.annotation.PostConstruct;/** * 生成全局ID * 雪花算法Tiwwer */@Component@Slf4jpublic class SnowFlakeUtil { //次要配置工作位十位，其中5位是机器位（节点或者是具体哪台机器），5位数数据中心 private Long workerID = 0L; private Long datecenter = 1L; private Snowflake snowflake = IdUtil.createSnowflake(workerID, datecenter); @PostConstruct private void init() { try { //以后机器的IP workerID = NetUtil.ipv4ToLong(NetUtil.getLocalhostStr()); log.info("以后机器的workerID{}", workerID); } catch (Exception e) { log.warn("获取机器ID失败", e); workerID = Long.valueOf(NetUtil.getLocalhost().hashCode()); log.info("以后机器workID", workerID); } } //简略版本 public synchronized Long createSnowFlakeID() { //生成的ID加锁synchronized return snowflake.nextId(); } //全局版本的 public synchronized long showFlakeID(long workId, long datacenterID) { Snowflake snowflake = IdUtil.createSnowflake(workerID, datecenter); return snowflake.nextId(); } public static void main(String[] args) { System.out.println(new SnowFlakeUtil().createSnowFlakeID());// 1401136955063926784 }}这里是简略的一个版本，与实在我的项目中有差别，差别次要是体现在参数配置中，
尽管雪花算法能够生成，惟一且自增的ID ,然而它也存在问题，是对于工夫戳的；
总结：
长处：
1.不依赖与第三方零碎（MySQL，Redis等），稳定性，生成ID的性能十分高
2.毫秒数在高位，自增序列在低位，整个ID 都是有趋势递增的；
毛病：
依赖于机器时钟，也就是对表工夫，如果机器回拨，会导致反复ID生成；
这种状况个别会产生在分布式环境中，每台机器上的时钟不可能齐全同步，有时候会呈现不是全局递增的状况
然而对于中小公司，此毛病能够疏忽， 个别会要求趋势递增，并不会严格要求递增；
snowFlake的优化
对于时钟回拨的状况，国内的大厂也修复了这个雪花算法的问题，比方
百度开源的Uid Generator
Leaf--美团点评分布式生成ID
两者都是在雪花算法的根底上，优化和改良；
实用于
对于一般公司，200人高低的，体制次要对于研发人员，都能够应用snowFlake, 配置具体ID生成，规定其中位数的默认值，
尤其是对于时钟回拨的，（工夫始终在走），重点在配置，抉择，解决异样，就能够实现
寄语
今日的分享就到这里了，学海无涯难行洲，唯有保持方可成；
我是卢卡，咱们下期见