Apache ShardingSphere在转转亿级交易系统落地实践

淡淡的烟草味﹌ 2023-10-03 22:48 2阅读 0赞

### 一、背景与挑战 ###

这几年随着转转二手业务的快速发展，订单系统的基础性能问题也愈发严重，作为系统运转的基石，订单库压力不容小觑。 面临的问题：

*  大促期间DB压力大，单库查询qps上万占用大量数据库资源，写性能大大降低；
 *  数据与日剧增，单库中包含非常多数据量过数亿的大表，占用空间接近服务器的容量上限；
 *  数据量太大，数据备份和恢复需要耗费很长时间，极端情况下丢失数据的风险越高。

### 二、为什么选ShardingSphere ###

迫于上述所说的DB压力问题，起初我们做了一些缓解措施，其中包括:

*  优化大事务，缩小事务范围，甚至消除事务
    
    ![format_png][]

通过调整原有业务逻辑顺序将核心的生单步骤放置在最后 ，仅在订单主表保持事务，主表操作异常时其他订单相关的表允许有脏数据产生。

*  订单数据添加缓存
    
    ![format_png 1][]
    
    缓存这块最重要同时最麻烦的地方是保证数据的一致性，订单信息涉及结算抽佣等，数据的不实时或不一致会造成严重事故。
    
    严格保证缓存数据的一致性，代码实现比较复杂同时会降低系统的并发，因此缓存方案实现这块我们做了一定的妥协：

1.  允许数据缓存失败情况下请求直接查库;
2.  给缓存key添加版本号，通过读最新版本号的数据确保数据的实时性。

*  复杂查询走ES、主从分离、一些大表进行冷热数据分离等
    
    ![format_png 2][]

通过上述几个方面的优化DB压力虽有所下降，但面对大促等一些高并发场景时仍显得力不从心。为了从根本上解决订单库的性能问题，我们决定对订单库进行数据分片（分库分表）改造，使得未来3-5年内不需要担心订单容量问题。

数据分片组件选型这块，我们从效率、稳定性、学习成本和时间多个方面对比，最终选择了ShardingSphere。

![format_png 3][]

ShardingSphere优势如下:

提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景； 分片策略灵活，支持多种分片方式； 集成方便、业务侵入程度低； 文档丰富、社区活跃。 ShardingShpere提出DB Plus的理念，采用可插拔的架构设计，模块相互独立，可以单独使用，亦可以灵活组合使用。目前ShardingSphere 由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。 3款产品特性对比如下：

![format_png 4][]

通过上图对比，结合订单高并发特性，本次数据分片中间件选择了ShardingSphere-JDBC。   ShardingSphere-JDBC定位为轻量级 Java 框架，在JDBC层提供的额外服务。它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

![format_png 5][]

随着5.x版本的发布，ShardingSphere还提供了许多新特性：

1.  全新 distsql 用于加载及展示 shardingsphere配置信息
2.  支持跨不同数据库实例的分片 join sql 查询
3.  增加数据网关能力，支持异构数据库存储
4.  支持在线动态创建及修改用户权限
5.  新增自动化探针模块

### 三、项目落地中的关键点 ###

*  **分片key的选择**

当前订单id的生成，采用了时间戳+用户标识码+机器码+递增序列的方式，其中用户标识码取自买家id的第9~16位，该码是用户id生成时的真随机位，很适合作为分片key。

*  选择该用户标识码作为分片key有如下优势：

1.  可以使分到各个库表的数据尽可能均匀；
2.  无论是以订单id、还是以买家id作为查询条件，都可以快速定位到具体分片位置；
3.  同一买家的数据能分布到相同的库表，方便买家维度的聚合查询。

![format_png 6][]

具体分片策略上：我们采用了16库16表，用户标识码取模分库，用户标识码高四位取模分表。

*  **新老库数据迁移**

1.  迁移必须是在线的，不考虑停机迁移，迁移的过程中还会有数据的写入；
2.  数据应该是完整的，C端体验是无感知的，迁移之后需要保证新库和旧库的数据是严格一致的；
3.  迁移过程中需要做到可以回滚，一旦迁移过程中出现问题，可以立即回滚到源库，不会对系统可用性造成影响。

数据迁移步骤如下：双写->迁移历史数据->校验->老库下线。

### 四、效果&收益 ###

*  解决了单库容量上限问题;
 *  数据分片后单库表的数据量大大减少，单表数据量由原来的近亿降为百万级别，总体性能大大提高;
 *  降低了因单库、单表数据过大极端情况数据丢失风险，减轻运维压力。 以下是两次大促期间，下单服务接口调用量与接口耗时对比。

改造前：

![format_png 7][]

改造后：

![format_png 8][]

### 五、总结感悟 ###

任何公司的“分库分表项目”说白了，都不是一个考验点子思路的常见项目，更多的反而是对一个人、一个团队干活的细致程度、上下游部门的沟通协作、工程化的操作实施以及抗压能力的综合考验。 同时业务的不断发展，又促使系统数据架构需要跟着不断升级，ShardingSphere以其良好的架构设计、高度灵活、可插拔和可扩展的能力简化了数据分片的开发难度，使研发团队只需关注业务本身，进而实现了数据架构的灵活扩展。

附，最终技术方案目录：

![format_png 9][]

[format_png]: https://img-blog.csdnimg.cn/img_convert/ac8e0e2eca75d5c49024d859a0d38ba6.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/a15a10ecbabd39c0f1fcb247f84fbd55.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/af765ecb020002a0ce1002f6bc134375.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/3ad0eeb6e024717ce5a448abd2c7c508.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/dc6be2600a80248ecb5417bf0bc81bb9.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/8a3536cf57ec098c0606bbf2c44aecb7.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/d51bfb8e3b27856bd17c507b3f83f626.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/500da40df68d2627f45abd03cd329218.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/10b3f8c66bb1d500134d3c6c4e9db0e7.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/61d76c05fbcc27e84fba63cc4b092c2c.webp?x-oss-process=image/format,png