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

以下文章来源于转转技术 ，作者张强

一、背景与挑战

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

面临的问题：

●  大促期间 DB 压力大，单库查询 qps 上万占用大量数据库资源，写性能大大降低；

●  数据与日剧增，单库中包含非常多数据量过数亿的大表，占用空间接近服务器的容量上限；

●  数据量太大，数据备份和恢复需要耗费很长时间，极端情况下丢失数据的风险越高。

二、为什么选 ShardingSphere

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

●  优化大事务，缩小事务范围，甚至消除事务

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

●  订单数据添加缓存

缓存这块最重要同时最麻烦的地方是保证数据的一致性，订单信息涉及结算抽佣等，数据的不实时或不一致会造成严重事故。

严格保证缓存数据的一致性，代码实现比较复杂同时会降低系统的并发，因此缓存方案实现这块我们做了一定的妥协：

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

●  复杂查询走 ES、主从分离、一些大表进行冷热数据分离等

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

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

ShardingSphere 优势如下:

●  提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、容器、云原生等各种多样化的应用场景；

●  分片策略灵活，支持多种分片方式；

●  集成方便、业务侵入程度低；

●  文档丰富、社区活跃。

ShardingSphere 提出 DB Plus 的理念，采用可插拔的架构设计，模块相互独立，可以单独使用，亦可以灵活组合使用。目前 ShardingSphere 由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。

3 款产品特性对比如下：

通过上图对比，结合订单高并发特性，本次数据分片中间件选择了 ShardingSphere-JDBC。

ShardingSphere-JDBC 定位为轻量级 Java 框架，在 JDBC 层提供的额外服务。它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

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

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

三、项目落地中的关键点

●  分片 key 的选择

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

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

    ◆  可以使分到各个库表的数据尽可能均匀；

    ◆  无论是以订单 id、还是以买家 id 作为查询条件，都可以快速定位到具体分片位置；

    ◆  同一买家的数据能分布到相同的库表，方便买家维度的聚合查询。

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

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

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

四、效果&收益

●  解决了单库容量上限问题;

●  数据分片后单库表的数据量大大减少，单表数据量由原来的近亿降为百万级别，总体性能大大提高;

●  降低了因单库、单表数据过大极端情况数据丢失风险，减轻运维压力。

以下是两次大促期间，下单服务接口调用量与接口耗时对比。

改造前：

改造后：

五、总结感悟

任何公司的“分库分表项目”说白了，都不是一个考验点子思路的常见项目，更多的反而是对一个人、一个团队干活的细致程度、上下游部门的沟通协作、工程化的操作实施以及抗压能力的综合考验。

同时业务的不断发展，又促使系统数据架构需要跟着不断升级，ShardingSphere 以其良好的架构设计、高度灵活、可插拔和可扩展的能力简化了数据分片的开发难度，使研发团队只需关注业务本身，进而实现了数据架构的灵活扩展。

附，最终技术方案目录：

作者简介
张强，转转交易中台研发工程师

本文转载自公众号ShardingSphere官微