首先映入脑海的一定是uuid
代码语言：javascript复制>>> import uuid
>>> print(uuid.uuid1())
d13a0096-abca-11ea-8997-acbc32785ec1客观地说，如果一定要用uuid生成订单号这类东西也能凑合用，但是它有着罄竹难书的“罪行”：肉眼可见，它是无序的；长度是64位数字字母随机组合的字符串，占用空间巨大；完全不具备业务属性，也就是说使用uuid你完全无法推算出它到底是干嘛的；因为无序，所以趋势递增就更不用指望了；所以用uuid生成订单号就是自杀行为，适合它的是类似生成token令牌的场景。
那么我们就要说起业界鼎鼎有名的SnowFlake(雪花算法)发号器了。 Twitter-Snowflake算法产生的背景相当简单，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的id，这些id还需要一些大致的顺序，让twitter可以通过一定的索引来进行检索，而在Twitter庞大的分布式系统中不同机器产生的id必须又必须不同。
它的好处显而易见，不仅全局唯一，并且有序按时间递增，同时占用空间少，生成的id仅仅是19位的整形数字，正好契合mysql的bigint数据类型，简直完美。
为啥它叫做Snowflake(雪花)算法？因为每个人都知道没有两片一样的雪花，这一事实源于晶体在天空中形成的方式。雪是一团冰晶，在大气中形成，并在它们下落时保持其形状。雪花形成于大气冷到能阻止它们融化变成雨或雨夹雪的时候。尽管云中的温度和湿度是不均匀的，但是在雪花大小的范围内，这些变量大约都是常数，这就是雪花的生长通常是对称的原因。另一方面，塔夫茨大学（Tufts University）化学家玛丽·简·舒尔茨（Mary Jane Shultz）指出：每片雪花都受到风，日光和其他变量变化的影响。她解释说，由于每个雪晶都到云层紊乱的影响，它们的形式都略有不同。
而Snowflake的逻辑也非常简单，雪花算法生成64位的二进制正整数，然后转换成10进制的数。64位二进制数由如下部分组成：
1位标识符：始终是0
41位时间戳：41位时间戳不是存储当前时间的时间戳，而是存储时间截的差值（当前时间截 - 开始时间截 )得到的值，这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的 10位机器标识码：可以部署在1024个节点，如果机器分机房（IDC）部署，这10位可以由 5位机房ID 5位机器ID 组成 12位序列：毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号
看到时间戳，就可以联想到它的缺陷，也就是它依赖机器的时钟，如果服务器时钟回拨，可能会导致重复ID生成。
这里我们用Python3.0来生成SnowFlake生成的唯一id
首先安装库
代码语言：javascript复制pip3 install pysnowflake安装完成后，就可以在本地命令行启动snowflake服务
代码语言：javascript复制snowflake_start_server --worker=1这里的worker就是当前节点的标识，此时编写代码就可以打印出当前客户端使用的snowflake的服务信息
代码语言：javascript复制import snowflake.client
print(snowflake.client.get_stats())
{'dc': 0, 'worker': 1, 'timestamp': 1591871273195, 'last_timestamp': 550281600000, 'sequence': 0, 'sequence_overload': 0, 'errors': 0}当然了，如果一台服务器上起了很多节点服务，也可以指定相关的节点进行装载
代码语言：javascript复制host = '127.0.0.1'
port = 30001
snowflake.client.setup(host, port)随后我们究竟可以根据该服务生成唯一id了
代码语言：javascript复制import snowflake.client
print(snowflake.client.get_guid())
4368750411956359169可以看到这些id很明显带有递增的连续性，有的人会问了，假设我搭建了上千个节点的分布式系统，此时接口接到参数id,我怎么判断该id的订单信息存储在那个节点中呢？
其实很容易就可以判断，从SnowFlake的算法结构入手，本身就是二进制转换十进制的整形，现在我们反着进行解析即可，这里以这个19位的id为例子：4368750411956359169
首先将其转换为二进制
代码语言：javascript复制print(bin(4368750411956359169))
0b11110010100000111010110101101001100001000000000001000000000001可以看到上文所述的第一位是标识符，此后是41位的时间戳，紧接着10位的节点标识码，最后12位的递增序列，从后面数12位是：000000000001，再数5位是：00001 这5位就是某个节点的存储标识，但是它目前是二进制，我们再将它转换为十进制
代码语言：javascript复制print(int('00001',2))
1可以看到，转换结果显示该id存储在节点1的数据库中，如此就具备了相当强的业务属性，通过反推逻辑我们可以快速准确的定位到数据的具体存储位置从而进行查询。
结语：
其实关于分布式唯一id的解决方案，也不仅仅只有uuid或者snowflake，像redis的incr原子性操作自增，亦或者Mongodb极具特色的_objectid的生成方式，专为分布式而设计的ID生成方案。都是可以参考的解决方案，但是方案总归是方案，总有其自身的特点和缺陷，这就需要根据实际应用场景而具体问题进行具体分析了。
