跨机房环境下常见的唯一键处理方式

当业务发展到一定程度，出现了跨机房的时候，我们往往会面临历史原因中一些唯一键的处理，有些是自增键，有些是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地址进行哈希确保跨机房的不一致

如果是用户修改，有两种方式

先问询生效

发起修改方声明占用，同时去其他机房单向查询有没有使用
缺点是跨机房访问导致给用户返回时间比较长，容易影响用户体验

直接生效

可能会因为同步的延迟导致两边出现唯一键冲突，此时需要比较时间戳，回滚较后修改并告知用户，体验比较差。这个更多是从产品形态进行一些考虑