今天跟大家简单介绍下分布式唯一键浅析
背景：
随着微服务概念的兴起，我们系统拆分的越来越模块化，系统变多了，调用链路页变长了，那么问题就出来了，一次用户的请求过来，我如何能够在分布式的系统中跟踪这次调用的路径 或者一次调用如何能够生成一个全局的唯一ID
举例说明一下：
以我们系统为例：我们现在唯一键生成有两种方式（1）、使用sequenceUtil生成（2）、生成UUID
首先说使用sequenceUtil生成的，目前我们订单的唯一键的生成方式是这样，首先要保证存在表sequence_value，这个表里只有两个字段，id、name；每次请求到sequenceUtil 生成唯一主键，都会在本机中存一个map，该map中key是表名，value中包含 唯一键开始值、唯一键跨度值、唯一键当前值，最大值
当我们应用调用sequence得到唯一键时，若是应用中没有这个key，需要先往表中插入一条唯一键数据，id值为0，然后更新为200 ，然后这个机器能够使用的主键的范围就是从0到200，当200个主键用完之后再继续累加。
好处：使用预展的方式，我们每次生成id都知道该id具体值的内容
坏处：由于每个机器之间有200的跨度，出现问题的几率页不大， 但是可能会出现两个机器都使用完，同时发起请求，由于在sql中存在CAS校验，有可能无法变更id的值，导致主键id生成失败
第二种方式：String uuid = UUID.randomUUID().toString(), 这种方式可以生成一个长度为32位的全局唯一识别码，目前我们的结算页请求地址中的requestId就是这种方式生成的，以及我们再tp_order中的accessGuid也是这种方式生成的。
我们可以看到他可以保证全局唯一，而且代码简单，性能也很好，但是不足在于长度较长，而且它在作为数据库索引存储时，由于数据库的索引大都是B+树的方式，当无序的数插入时，可能会导致因为把新记录插入到合适的位置而移动大量的数据，从而降低了写入性能。
第三种方式：snowFlake算法，也是十分著名的分布式ID生成的算法，是一种划分命名空间来生成ID的一种算法，结算是一个long型的ID。其核心是把64-bit分别划分为多段。 这个算法现在不维护， 但是git项目还在，大家可以下载玩一下
(图片来自：https://crazyfzw.github.io/2018/07/21/unique-id-generate/)
- 1位标识符：始终是0，由于long基本类型在Java中是带符号的，最高位是符号位，正数是0，负数是1，所以id一般是正数，最高位是0。
- 41位时间戳：41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截 )得到的值，这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的。
- 10位机器标识码：可以部署在1024个节点，如果机器分机房（IDC）部署，这10位可以由 5位机房ID + 5位机器ID 组成。
- 12位序列：毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号
优点：
- 时间戳在高位，自增序列在低位，整个ID是趋势递增的，按照时间有序递增。
- 可以根据bit位不同划分不同业务
缺点：
- 依赖机器的时钟，如果服务器时钟回拨，会导致重复ID生成。
- 在分布式环境上，每个服务器的时钟不可能完全同步，有时会出现不是全局递增的情况。
分布式生成唯一键就说到这里，我们再来稍微提一嘴各个公司的分布式追踪系统，分布式追踪系统是基于分布式唯一键生成的基础上，对系统中的调用链路进行跟踪。
京东的：Hydra - 京东开源的基于Dubbo的调用分布跟踪系统
CallGraph 、pfinder
美团的
Leaf-segment
https://tech.meituan.com/2017/04/21/mt-leaf.html
Flickr 在分布式系统中我们可以多部署几台机器，每台机器设置不同的初始值，且步长和机器数相等。比如有两台机器。设置步长step为2，TicketServer1的初始值为1（1，3，5，7，9，11…）、TicketServer2的初始值为2（2，4，6，8，10…）。这是Flickr团队在2010年撰文介绍的一种主键生成策略
微信：https://blog.csdn.net/hellojackjiang2011/article/details/82997656
大家有兴趣可以继续研究这方面的东西。加油！