1.亿级积分数据分库分表：总体方案设计

项目背景

以一个积分系统为例，积分系统最核心的有积分账户表和积分明细表：

随着业务的增长、时间的推移，积分明细的数据量越来越多，单表数据量太大，产生很多问题：慢SQL，加字段、索引比较耗时（虽然可以用MySQL8.0的新特性INSTANT算法加字段），统计查询很慢，数据库CPU压力大等

目前积分系统的积分明细数据现存几亿条，每日新增积分明细数据大几十万，并且随着活动的接入还在逐渐递增，慢慢的带来了很多问题，需要进行优化处理。

历史数据归档不行吗

因为系统积分规则规定积分有效期两年，并且积分扣减、退款、过期等操作需要对积分明细溯源，最近两年的积分明细数据也有几个亿，即使将两年前的冷数据归档，也无法解决积分明细单表几亿数据量的问题。

根据积分现有数据量以及日增长量进行评估，未来3-5年内单数据库实例能够满足积分数据的存储，并且积分系统的写入TPS单实例可以支撑，本次积分决定只分表不分库。

什么情况适合用数据归档？

如果能把历史冷数据归档，热数据一两亿左右、读写并发不太高的情况下，利用好数据库索引、数据库配置高一些完全可以不用分表，采用历史数据归档也可以解决很多问题。但是大表还是有一些其他的问题，比如加字段比较耗时。

分库分表有很多问题

网上动不动就说超过2000万数据就要分库分表并不太对，在单表数据一两亿、并发不是很高、利用好数据库索引的情况下，MySQL数据库配置高一点是完全可以扛得住的。

而且能不分库分表就不要分库分表，分库分表会产生很多问题，没有其他优化手段了再进行分库分表。分库分表可能会产生的问题如下：

分库分表组件选择Sharding-JDBC，因为目前该项目文档较为丰富、社区活跃度高、无中心化、性能相较于proxy方式性能更好，对于开发来说使用更为灵活可控。官网地址Apache ShardingSphere

需要拆分的表：point_info（积分明细表）

根据目前的数据量、单日新增的数据量来进行分析，计划分为128张表，未来3-5年内单表数据尽量不要超过2000万，后期分表数据量大了可以进行历史数据归档。

拆分后的表为point_info[0-127]，采用user_id作为分片键，选取user_id后四位取模定位到具体的分表

table后缀 = (user_id后四位) % 128

如果怕user_id的尾数不均匀，可以将hashcode(user_id)%128来计算分表下标

分表数量为啥是128，不是127或者100？

我自己的理解如下：

如果还有其他的好处欢迎指正

因为只进行了分表，没有进行分库，所以没有分布式事务问题。

假如后面进行了分库分表，可以通过将相同用户的积分账户表和积分明细表分到同一个分库中，来避免同一个用户操作账户和明细的分布式事务问题。

shardingsphere里面也有一些分布式事务的支持，比如XA，Seata框架的AT模式等

原来单表时主键采用MySQL自增id，分表之后再使用自增id会导致不同表主键值重复，可以使用雪花算法、美团的Leaf等生成分布式ID，也可以自定义实现。

注意：原生雪花算法有时钟回拨问题、低频场景下生成的id都是偶数的问题，需要进行优化一下，感兴趣的话可以看下我的另一篇博客雪花算法生成分布式ID源码分析及低频场景下全是偶数的解决办法

简要描述一下整个流程：

线上库新的分表创建配置完成，然后按照下面的步骤执行：

改造双写代码预发测试（多种case跑一下，双写开关等校验），没问题发布上线，上线时双写开关默认关闭，可以通过配置中心动态开启，打开双写开关（新表写入失败先忽略，因为更新和删除操作会因为新表数据不存在而失败），记录双写开始时间点A
将老表的积分明细的createTime小于等于双写开始时间点A+5分钟（防止时间不同步导致少迁移数据，预留一些缓冲时间）的数据进行全量迁移到分表
新老数据全量数据校验，查看数据是否一致；同时定时任务每隔一小段时间进行增量校验，增量数据因为读取新老数据存在短暂时间差可能会瞬时不一致，这种数据隔一段时间再次校验，多次校验还不一致的数据进行数据订正（老表数据覆盖到新表数据）
改造代码，添加双读的逻辑上线（读新表的开关默认关闭）
低流量节点(凌晨过后)进行白名单、灰度切流userId%10000，进行验证，逐步流量打开，持续观察
双写开关切到新表，保证只写新表（也可以继续写老表一段时间，或者创建一个新表往老表同步的canal任务，方便回滚），完成数据迁移方案
系统稳定运行一段时间，迁移&双写代码下线，老表进行资源释放

为什么没有采用全量同步+canal增量同步方式，这种方式不是比双写实现更简单吗？怎么进行双写？双写有什么好处？后面会继续写一篇单独介绍。