通用全局唯一ID生成器
前言
全局唯一生成器在很多场景下需要,例如,sharding时。
下面介绍几种方法来解决这个问题。
双db方案
flickr开发团队在2010年撰文介绍了flickr使用的一种主键生成测策略,同时表示该方案在flickr上的实际运行效果也非常令人满意。
其主要的想法 是
双DB
DB分别生成奇、偶的ID
ID生成是事务的
此种方案的优缺点:
优点:速度快,稳定性高,一致性高,没有单点问题。
缺点:需要部署两个db,ID生成不连续
redis+lua方案
采用redis+lua的id generato算法,可以非常方便的实现一个ID生成服务。
若在redis-client里采用预取技术,可以保证ID的连续性。如果redis-client实例经常会重启,更甚者,可以将使用的ID dump成文件,方便重启时不必浪费ID。
优缺点是:
优点:速度极快,ID连续性较高
缺点:单点问题,存在不一致问题。如果主redis挂机,备redis切换成主redis。这个过程可能ID会有不一致。
增强版
模仿第一种方案,采用双redis方案,各台redis来生成奇偶ID。稳定性和单点问题可以大部分解决掉。
ID生成服务化
ID服务以服务化RPC开放出来
采用预取ID技术保证大部分时间内ID的连续性
mysql采用mysqlproxy方案
优缺点:
优点:稳定性高,一致性。ID连续性较高。比较适合服务化。
缺点:可能存在id不连续,但比 双DB方案 要好。
mysql是单点。
总结
除了第一种方案外,第二、第三种方案均存在着单点DB的问题。
第二种方案部署最简单,一台redis可以搞定一切。如果害怕单点问题,也可以采用增强版方案。
鉴于大型企业mysql运维技术的稳定性,第一、第三方案均属于较大型企业的选择方案,部署起来比较复杂。