分库分表落地解决方案

随着系统不断的运行，当数据库的数据开始超过千万、上亿时，mysql数据库将承受更大的压力。数据是企业生存的根本，数据库的健康状况将直接决了定企业的竞争力。

解决思路

为了更好的缓解数据库压力，使得系统更高效的运行，落地的解决方案有：1、分库（也叫垂直拆分，即：每个模块对应一个单独的数据库）。2、分表（也叫水平拆分，即：一张表的数据拆分存储到多张表里）。

引入的新问题

1、数据库分离的同时，也引入了分布式事物的问题。2、表的水平拆分的同时，也带来了很多的挑战，比如：分页查询、表数据的后续扩展、数据的存储和检索策略。

落地解决方案

1、分布式事物的解决方案也有很多，比如：TCC、MQ事物消息等。这里提出方案的是事物补偿，且仅有事务补偿没有回滚。具体做的时候需要注意：将执行一个操作所涉及到的所有校验条件全部提到服务编排层的最前面（包括试算）。若所有的校验条件都通过了，则认为后续执行的业务逻辑一定是通过的。如果执行报错，那么，通过消息队列做三次补偿，补偿仍然失败，手工介入处理。

2、RPC调用、事物补偿引入了并发场景下的接口幂等性问题，这里给出三种解决方案是：a.乐观锁，ID和版本号，update version … where version<version+1 判断更新结果。b.悲观锁，每次业务操作之前先从后端拿到唯一的requestId，作为参数再传入，后端增加去重表主键requestId操作。c.消息队列，消除并发，顺序执行，执行的时候判断是否执行重复。

3、分表的同时带来了数据的存储和检索问题，这里给的解决方案是：a.根据业务组ID（全局分配唯一）取模运算，比如：10张表，那么，就是取10的模来决定存储的表编号，并存入路由表。业务组的ID是指一个更大的管理单位，比如：某个商户的ID、企业的ID。b.增加路由表，根据业务组ID查找路由表，找到表编号。c.对于没有业务组关联的信息，例如：用户信息，也是直接采用取模的计算方式。对于一些特殊场景的userId，也可以存储到路由表里，检索的时候，优先检索路由表。这里有两个重要的概念第一个是按照业务组ID为单位操作，第二个是根据路由表来查找表编号。