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

没头脑遇到不高兴

于 2024-03-02 14:03:47 发布

阅读量1k

点赞数 14

分类专栏：分库分表文章标签： ShardingJDBC 分库分表数据双写数据迁移分库分表灰度切流验证分库分表新老数据核对校验分布式ID 分库分表实战方案设计

本文链接：https://blog.csdn.net/u012988901/article/details/136398388

版权

分库分表专栏收录该内容

3 篇文章 0 订阅

订阅专栏

项目背景

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

积分账户表：每个用户在一个品牌下有一个积分账户记录，记录了用户的积分余额，数据量在千万级
积分明细表：用户每次积分发放、积分扣减、积分退款、积分过期都会产生一条积分明细，积分明细的数据量很大在亿级别

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

一、为什么要选择分表

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

历史数据归档不行吗

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

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

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

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

分库分表有很多问题

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

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

分布式ID问题
分片键选择问题
分库分表算法问题
容量不够了扩容问题
分布式事物问题
统计查询分析问题
数据迁移问题
灰度验证问题
数据校验问题
................

二、分库分表组件

分库分表组件选择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？

我自己的理解如下：

设置为2的次幂，是程序员的习惯；
好处是求余运算，可以用 num & (128-1)，按位与运算求余数比除法速度快。

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

四、分布式事务？

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

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

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

五、分布式ID

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

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

六、总体计划

简要描述一下整个流程：

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

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

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