别再问“分库分表”了，再问就瓦解了！
|
`stub` char(1) NOT NULL default '', PRIMARY KEY (`id`), UNIQUE KEY `stub` (`stub`) ) ENGINE=MyISAM; stub 字段配置为独一索引，统一 stub 值在 sequence 表中只有一笔记录，可以同时为多张表生玉成局 ID。 sequence 表的内容，如下所示： +-------------------+------+ | id | stub | +-------------------+------+ | 72157623227190423 | a | +-------------------+------+ 行使 MyISAM 存储引擎而不是 InnoDB，以获取更高的机能。MyISAM 行使的是表级此外锁，对表的读写是串行的，以是不消担忧在并发时两次读取统一个 ID 值。 当必要全局独一的 64 位 ID 时，执行： REPLACE INTO sequence (stub) VALUES ('a'); SELECT LAST_INSERT_ID(); 这两条语句是 Connection 级此外，select last_insert_id() 必需与 replace into 在统一数据库毗连下才气获得方才插入的新 ID。 行使 replace into 取代 insert into 甜头是停止了表行数过大，不必要其它按期整理。 此方案较为简朴，但弱点也明明：存在单点题目，强依靠 DB，当 DB 非常时，整个体系都不行用。 设置主从可以增进可用性，但当主库挂了，主从切换时，数据同等性在非凡环境下难以担保。其它机能瓶颈限定在单台 MySQL 的读写机能。 flickr 团队行使的一种主键天生存策，与上面的 sequence 表方案相同，但更好的办理了单点和机能瓶颈的题目。 这一方案的整体头脑是：成立 2 个以上的全局 ID 天生的处事器，每个处事器上只陈设一个数据库，每个库有一张 sequence 表用于记录当前全局 ID。 表中 ID 增添的步长是库的数目，起始值依次错开，这样能将 ID 的天生散列到各个数据库上。 如下图所示：
由两个数据库处事器天生 ID，配置差异的 auto_increment 值。第一台 sequence 的起始值为 1，每次步长增添 2，另一台的 sequence 起始值为 2，每次步长增添也是 2。 功效第一台天生的 ID 都是奇数(1, 3, 5, 7 ...)，第二台天生的 ID 都是偶数(2, 4, 6, 8 ...)。 这种方案将天生 ID 的压力匀称漫衍在两台呆板上。同时提供了体系容错，第一台呈现了错误，可以自动切换到第二台呆板上获取 ID。 但有以下几个弱点：体系添加呆板，程度扩展时较伟大;每次获取 ID 都要读写一次 DB，DB 的压力照旧很大，只能靠堆呆板来晋升机能。 可以基于 flickr 的方案继承优化，行使批量的方法低落数据库的写压力，每次获取一段区间的 ID 号段，用完之后再去数据库获取，可以大大减轻数据库的压力。 如下图所示：
照旧行使两台 DB 担保可用性，数据库中只存储当前的最大 ID。ID 天生处事每次批量拉取 6 个 ID，先将 max_id 修改为 5，当应用会见 ID 天生处事时，就不必要会见数据库，从号段缓存中依次派发 0~5 的 ID。 当这些 ID 发完后，再将 max_id 修改为 11，下次就能派发 6~11 的 ID。于是，数据库的压力低落为原本的 1/6。 ③Snowflake 漫衍式自增 ID 算法 Twitter 的 Snowflake 算法办理了漫衍式体系生玉成局 ID 的需求，天生 64 位的 Long 型数字。 构成部门： 第一位未行使。 接下来 41 位是毫秒级时刻，41 位的长度可以暗示 69 年的时刻。 5 位 datacenterId，5 位 workerId。10 位的长度最多支持陈设 1024 个节点。 最后 12 位是毫秒内的计数，12 位的计数次序号支持每个节点每毫秒发生 4096 个 ID 序列。 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
