中文
首页/案例/Apache ShardingSphere 在转转亿级交易系统落地实践

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

业务的不断发展,促使系统数据架构的不断升级
2022/11/03by 张强,转转交易中台研发工程师

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

一、背景与挑战

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

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

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

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

二、为什么选ShardingSphere

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

  • 优化大事务,缩小事务范围,甚至消除事务

图片]

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

  • 订单数据添加缓存

[图片]

缓存这块最重要同时最麻烦的地方是保证数据的一致性,订单信息涉及结算抽佣等,数据的不实时或不一致会造成严重事故。   严格保证缓存数据的一致性,代码实现比较复杂同时会降低系统的并发,因此缓存方案实现这块我们做了一定的妥协:1. 允许数据缓存失败情况下请求直接查库;2. 给缓存key添加版本号,通过读最新版本号的数据确保数据的实时性。

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

[图片]

通过上述几个方面的优化DB压力虽有所下降,但面对大促等一些高并发场景时仍显得力不从心。为了从根本上解决订单库的性能问题,我们决定对订单库进行数据分片(分库分表)改造,使得未来3-5年内不需要担心订单容量问题。 数据分片组件选型这块,我们从效率、稳定性、学习成本和时间多个方面对比,最终选择了ShardingSphere。 [图片]

ShardingSphere优势如下:

  • 提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景;
  • 分片策略灵活,支持多种分片方式;
  • 集成方便、业务侵入程度低;
  • 文档丰富、社区活跃。ShardingShpere提出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以其良好的架构设计、高度灵活、可插拔和可扩展的能力简化了数据分片的开发难度,使研发团队只需关注业务本身,进而实现了数据架构的灵活扩展。

分享文章
wechat qrcode

扫码关注
微信公众号

中商惠⺠交易中台架构演进:对 Apache ShardingSphere 的应⽤
基于 ShardingSphere 的得物数据库中间件平台“彩虹桥”演进之路

推荐阅读

某零售电商|一键在线拆分数亿大表

某央企|打造新一代云上数据底座,助力业务推广

某银行的数据库网关实践

F6 汽车科技基于 Apache ShardingSphere 的核心业务分库分表实践

汽车互联网平台领域技术实践

中商惠⺠交易中台架构演进:对 Apache ShardingSphere 的应⽤

通过架构重构,有效控制单表数据量,⼤幅缩减慢 SQL,下降将近 50%
即刻免费体验新一代数据库增强引擎
400-900-2818 GitHub
合作伙伴:中国信通院重庆大学ShardingSphere
Privacy PolicyTerms Of UseDisclaimerCookie PolicyDo Not Sell My Personal Information
wechat qrcode

扫码关注
微信公众号