摘要：github：https://github.com/bjlhx15/framework-middleware.git
自研发
可以看分类中，mysql 主键设计。
自开发版本github：https://github.com/bjlhx15/framework-middleware.git 下的：id-generator
支持DB，配置文件配置，配置文件配置IP等生成工作id
业界经典：雪花算法
百度（uid-generator）
github地址：https://github.com/baidu/uid-generator
uid-generator使用的就是snowflake，只是在生产机器id，也叫做workId时有所不同。
uid-generator中的workId是由uid-generator自动生成的，并且考虑到了应用部署在docker上的情况，在uid-generator中用户可以自己去定义workId的生成策略，默认提供的策略是：应用启动时由数据库分配。说的简单一点就是：应用在启动时会往数据库表(uid-generator需要新增一个WORKER_NODE表)中去插入一条数据，数据插入成功后返回的该数据对应的自增唯一id就是该机器的workId，而数据由host，port组成。
对于uid-generator中的workId，占用了22个bit位，时间占用了28个bit位，序列化占用了13个bit位，需要注意的是，和原始的snowflake不太一样，时间的单位是秒，而不是毫秒，workId也不一样，同一个应用每重启一次就会消费一个workId。
具体可参考https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md
美团（Leaf）
github地址：https://github.com/Meituan-Dianping/Leaf
美团的Leaf也是一个分布式ID生成框架。它非常全面，即支持号段模式，也支持snowflake模式。号段模式这里就不介绍了，和上面的分析类似。
Leaf中的snowflake模式和原始snowflake算法的不同点，也主要在workId的生成，Leaf中workId是基于ZooKeeper的顺序Id来生成的，每个应用在使用Leaf-snowflake时，在启动时都会都在Zookeeper中生成一个顺序Id，相当于一台机器对应一个顺序节点，也就是一个workId。
上面两种都是自动生成workId，以让系统更加稳定以及减少人工成功。
Redis
可以利用Redis中的incr命令来实现原子性的自增与返回
