内容简介:扯扯 ID
原文地址: http://www.yunai.me/Architecture/talk-about-global-id/
:smiling_imp:每 1-2 周更新一篇,欢迎订阅、关注、收藏 公众号
在日常开发中,数据库的id是不可少的。在各个场景下会有不同的选择,本文对互联网上常见的ID算法进行归纳,希望对工程师们有一点点帮助。
1. 数据库自增
- MySQL、Oracle、PGSQL等关系数据库的id主键自增
- Redis、 Memcached 等K/V数据库的incr操作自增
- 需要考虑持久化的问题
- MongoDB自己维护一个id自增集合
- MongoDB的Update操作支持incr操作,因此可以这么做。
- 该方式适用于支持该操作的其他数据库。
2. 类UUID算法
- UUID
- MongoDB的ObjectId
3. SnowFlake
3.1 Twitter-Snowflake
Twitter-Snowflake算法产生的背景相当简单,为了满足Twitter每秒上万条消息的请求,每条消息都必须分配一条唯一的id,这些id还需要一些大致的顺序(方便客户端排序),并且在分布式系统中不同机器产生的id必须不同。
64bits从左往右依次是
- 1bit 保留
- 41bits 时间戳
- 支持69.7年需要的id。2 ^41 /365/24/60/60/1000=69.7
- 10bits work-id
- 支持1024个work
- 12bits sequence-id
- 支持每work每毫秒4096个id
- 支持每work每秒4096000个id
- 若当前毫秒超过4096,则sleep1毫秒,获取下一毫秒的自增
snowflake的意义,不仅仅在于提供了解决方式,更多的是一种基于Long长度实现具有时间相关性的id自增序列。因此,很多公司基于它进行二次改造适应自己的场景
3.2 Instagram SnowFlake
去中性化,基于PGSQL实现
64bits从左至右依次是
- 41bits 时间戳
- 13bits logic-shard-id
- 10bits sequence-id
实现方式
- 根据
share-key
获取对应的PGSQL实例-库 - id使用PGSQL的存储过程
- 13bits =
share-key对应值%logic-share-id
- 10bits =
该Table的auto_increment_id%(2 ^10)
好处
- 去中性化
- 根据id可以获得对应PGSQL实例-库
3.3 Simpleflake
64bits
- 去中性化
- 将work-id的12bits给sequence-id。完全随机,每毫秒有1/(2^22 )出现冲突的情况。数据量大时需要注意。
- 未来可以平滑迁移到Twitter SnowFlake
3.4 Boundary flake
去中性化,基于erlang实现
128bits从左到右依次是
- 64bits 时间戳
- 和毫秒时间戳等长
- 48bits work-id
- 和mac地址等长,使用时要避免相同mac多个进程
- 14bits sequence-id
3.5 自己的想法
参考Instagram SnowFlake的做法
去中心化,基于 redis 实现
64bits从左到右依次是
- 1bit 保留
- 41bits 时间戳
- 12bits 基于logic-shard-id
- 10bits 基于时间戳+logic-shard-id在redis里自增
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
PHP高级开发技术与应用
曹铁群、孙一江、张永学 / 清华大学出版社 / 2002-5-1 / 32.00
作为一本介绍PHP高级开发技术的书籍,本书并不像一般介绍PHP语言的书籍那样讲述大量的语法规则,罗列大量的函数,而是着眼于PHP在Web中的实际应用,特别是PHP对最新技术的支持,比如WAP技术、XML技术等。 本书涉及到的内容主要有:高级环境配置、高级语法和应用、正则表达式、面向对象技术、高级图像技术、用PHPLIB实现模板的处理、用PHPDoc实现文档的自动生成、PHP与组件技术、PH......一起来看看 《PHP高级开发技术与应用》 这本书的介绍吧!