当业务发展到一定程度,出现了跨机房的时候,我们往往会面临历史原因中一些唯一键的处理,有些是自增键,有些是C端设置的,本问探讨下怎么解决这个问题
数字键
常见于db的自增主键或用户生成时的随机id
对于自增主键这种毫无业务含义的字段,通常采用id生成器进行替换,一般团队都会有通用的id生成器,方法一般也是基于比较主流的id生成算法,可以参考id生成器
对于用户生成时的随机id,一般就具有了一些业务id,比如该id可以用于应用中的搜索添加好友等(比如QQ号),这种情况下,id生成器这种会生成长id的工具就不能满足相应需求了。
此时可以使用步长遗留的方式。例如当前有100w存量用户,从1000001开始出现双机房,那个id就可以利用
A机房:id 1000001, 1000003, 1000005
B机房:id 1000002, 1000004, 1000006
可以在redis里存一个key,持续地进行自增以确认数据不会重复。
如此A机房id永远不会和b机房冲撞
一般也会预留更多空间,比如步长变为10,这样最多可以支持10机房
非数字键
这种一般是用于用户C端设置或者系统生成的,比如微信号。
如果是系统随机生成,也可以类似于id生成器,结合时间戳和机器mac地址进行哈希确保跨机房的不一致
如果是用户修改,有两种方式
先问询生效
发起修改方声明占用,同时去其他机房单向查询有没有使用
缺点是跨机房访问导致给用户返回时间比较长,容易影响用户体验
直接生效
可能会因为同步的延迟导致两边出现唯一键冲突,此时需要比较时间戳,回滚较后修改并告知用户,体验比较差。这个更多是从产品形态进行一些考虑