【实战总结】分库路由字段与业务字段绑定落库

问题背景

我们一般分库分表的路由字段是用户的账户ID（userId），有些业务场景外部不以此做业务，而是以业务请求ID等进行业务交互

所以我们内部系统通过userId来串联业务关系，但是与外部交互要使用到bizId等这些代表业务唯一性的字段，这两个字段不同路由可能会打到不同的库是没办法做数据库事务处理的

出现这些场景时的一个需要解决的问题是，按照userId路由字段落库了，但是外部服务交互只有bizId没有userId，导致无法通过bizId反查userId路由到内部的业务数据。

查询数据中心的同步数据，只要字段做了ES索引配置，就是支持全量搜索的，这种方案最简单，但不是最优的，原因是数据中心数据都配置了TTL，有些不能支持永久查询，而且数据中心的查询性能不能满足生产级调用可能会产生性能瓶颈

通过绑定分库分表路由字段与外部业务交互字段进行逻辑绑定，这样就可以在同外部业务交互时通过内部业务的分库分表的业务字段反查库表了

如图所示，

Step 1：业务请求发起时，按照路由字段（userId）落库，同时发出一条包含路由字段（userId）与业务字段（bizId）MQ消息，异步处理再按照业务字段（bizId）进行落库，一般这就是完整的处理流程了。

Step 2：99.9%的时间Step 1都是OK的，异常情况是MQ发不出去或者丢失或异常了，这时候可以增加Worker来扫描绑定状态进行补偿，异步落库的业务字段MQ是支持幂等重试的，是最终一致的

Step 3：由于上述绑定过程不是准实时的，99.9%的时间外部是感知不到是非同步业务的，外部调用失败可以重试处理