背景和目标
需要一个唯一数据标示
ID类型可以使字符串或者整型。 这两类选择对方案影响较大
ID生产性能， 决定服务瓶颈
ID生产容灾解决， 如果ID是你的系统十分重要的数据，那么容灾较为重要
可行的解决方案
- 大数， 参考一般电商系统订单ID
- uniq字符串 ， 可参考UUID、MongoObjectID等
- MySQL 主键
- redis incr
参考
snowflake
https://developer.twitter.com/en/docs/basics/twitter-ids.html
https://blog.twitter.com/engineering/en_us/a/2010/announcing-snowflake.html
优点
- 长整型处理性能相对较高
- 生产性能高
- 生成分布式容错
弊端
- 时间有限，取决于设计的其实时间戳， 目前可使用年限有限， 取决于分配的位数和起始时间戳
- 机器时间回拨，会导致循环hang一段时间，直到比上次生产ID值大
- 每一毫秒2^12次， 单节点QPS过大，也会导致hang住一段时间
- workID，个数有限，可以做成rpc， 产生了rpc调用时耗
可参考其他实现
侧重不一样，导致实现有难易
- MQ messageid 例如kafka
- RPC requestID。 例如dubbo 只需要保证某次连接上唯一
- TCP/IP 序列id
版权声明：本文为博主原创文章，未经允许不得转载。