干货来了，分库分表的实战案例分享
问题现状
某系统， 订单单表早就已经突破200G ，由于查询维度较多，即使加了 两个从库，优化索引 等优化手段也无济于事。因为数据库达到瓶颈，应用只能通过 限速、异步队列等对其进行保护， 因此进行分库分表的尝试 。
整体思路
按照商户ID进行分库，用户ID进行分表，同时通过数据同步等方式，把数据同步到一个运营库， 同时满足C端用户、B端商户、客服、运营等的需求。最终，通过 新老系统双写 逐渐从老库过渡到新库，完成业务的切换。
切分策略
1. 查询切分
将ID和库的Mapping关系记录在一个单独的库中，但是这样 引入额外的服务器来维护这个Mapping关系 。
2. 范围切分
按照时间区间或ID区间来切分。但是 针对于某些大商户来说，还是解决不了性能瓶颈的问题 。
3. Hash切分（最终方案）
我们分库分表的方案是16*16的。
商户Id后四位mod 16 分16个库， UserId后四位Mod 16 将每个库分为16个表，共计分为256张表。
线上部署情况为 4个集群 ，每个集群4个库（ 1主3从 ）。
场景一：数据库性能达到瓶颈：扩大数据库的集群数量，从16个数据库变成32个数据库。
场景二：单表容量达到瓶颈：扩大分表的数量，从16切分变成32切分。
唯一ID方案
1. 利用数据库自增ID(单点风险、单机性能瓶颈)
2. 利用数据库集群并设置相应的步长（ 需要单独的数据库集群 ）
3. Twitter Snowflake( 需要独立的集群以及ZK )
4. 采用了带有业务属性的方案：（时间戳+商户ID+用户ID+随机数）
其他问题
数据迁移
第一阶段
第二阶段
第三阶段
总结
七鑫易维信息技术
2024-09-02 广告
