在数据库主键设计上,比较常见的方法是采用自增ID(1开始,每次加1)和生成GUID。生成GUID的方式虽然简单,但是由于采用的是无意义的字符串,推测会在数据量增大时造成访问过慢,在基础互联网的系统设计中都不推荐采用。自增ID的方法虽然比较适合大数据量的场景,当时由于自增ID是按照顺序增加的,数据记录都是可以根据ID号进行推测出来,对于一些数据敏感的场景,不建议采用
最近在一篇文章中看到P2P网站处理订单流水号的思路还不错。该平台设计时希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。Twitter 的 Snowflake 算法解决了这种需求。在流水号服务中采用了这种算法。
snowflake算法的好处有两点:一是纯数字,二是整体上来说是按时间顺序的。
Scala版详见开源项目https://github.com/twitter/snowflake
Python版详见开源项目https://github.com/erans/pysnowflake
C#版详见开源项目https://github.com/ccollie/snowflake-net
Twitter分布式自增ID算法snowflake原理解析
以JAVA为例 Twitter分布式自增ID算法snowflake,生成的是Long类型的id,一个Long类型占8个字节,每个字节占8比特,也就是说一个Long类型占64个比特(0和1). 那么一个 ...
Twitter分布式自增ID算法snowflake原理解析(Long类型)
Twitter分布式自增ID算法snowflake,生成的是Long类型的id,一个Long类型占8个字节,每个字节占8比特,也就是说一个Long类型占6