一、布景与应战
这几年跟着转转二手事务的快速发展，订单体系的基础功用问题也益发严峻，作为体系工作的柱石，订单库压力不容小觑。 面对的问题：
- 大促期间DB压力大，单库查询qps上万占用大量数据库资源，写功用大大下降；
- 数据与日剧增，单库中包含非常多数据量过数亿的大表，占用空间接近服务器的容量上限；
- 数据量太大，数据备份和恢复需要耗费很长时刻，极点情况下丢掉数据的风险越高。
二、为什么选ShardingSphere
迫于上述所说的DB压力问题，起初咱们做了一些缓解办法，其中包含:
- 优化大事务，缩小事务范围，甚至消除事务
经过调整原有事务逻辑次序将中心的生单步骤放置在终究 ，仅在订单主表坚持事务，主表操作异常时其他订单相关的表允许有脏数据发生。
-
订单数据增加缓存
缓存这块最重要一起最麻烦的当地是保证数据的共同性，订单信息触及结算抽佣等，数据的不实时或不共同会形成严峻事故。
严厉保证缓存数据的共同性，代码完成比较杂乱一起会下降体系的并发，因此缓存计划完成这块咱们做了必定的退让：
- 允许数据缓存失利情况下请求直接查库;
- 给缓存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还供给了许多新特性：
- 全新 distsql 用于加载及展示 shardingsphere装备信息
- 支撑跨不同数据库实例的分片 join sql 查询
- 增加数据网关才能，支撑异构数据库存储
- 支撑在线动态创立及修正用户权限
- 新增自动化探针模块
三、项目落地中的关键点
- 分片key的挑选
当前订单id的生成，选用了时刻戳+用户标识码+机器码+递增序列的方法，其中用户标识码取自买家id的第9~16位，该码是用户id生成时的真随机位，很适合作为分片key。
- 挑选该用户标识码作为分片key有如下优势：
- 能够使分到各个库表的数据尽可能均匀；
- 无论是以订单id、还是以买家id作为查询条件，都能够快速定位到详细分片位置；
- 同一买家的数据能散布到相同的库表，便利买家维度的聚合查询。
详细分片战略上：咱们选用了16库16表，用户标识码取模分库，用户标识码高四位取模分表。
- 新老库数据搬迁
- 搬迁必须是在线的，不考虑停机搬迁，搬迁的过程中还会有数据的写入；
- 数据应该是完好的，C端体会是无感知的，搬迁之后需要保证新库和旧库的数据是严厉共同的；
- 搬迁过程中需要做到能够回滚，一旦搬迁过程中出现问题，能够立即回滚到源库，不会对体系可用性形成影响。
数据搬迁步骤如下：双写->搬迁历史数据->校验->老库下线。
四、作用&收益
- 处理了单库容量上限问题;
- 数据分片后单库表的数据量大大削减，单表数据量由原来的近亿降为百万级别，总体功用大大提高;
- 下降了因单库、单表数据过大极点情况数据丢掉风险，减轻运维压力。 以下是两次大促期间，下单服务接口调用量与接口耗时比照。
改造前：
改造后：
五、总结感悟
任何公司的“分库分表项目”说白了，都不是一个考验点子思路的常见项目，更多的反而是对一个人、一个团队干活的细致程度、上下游部分的沟通协作、工程化的操作施行以及抗压才能的归纳考验。 一起事务的不断发展，又促使体系数据架构需要跟着不断升级，ShardingSphere以其杰出的架构设计、高度灵敏、可插拔和可扩展的才能简化了数据分片的开发难度，使研制团队只需重视事务自身，从而完成了数据架构的灵敏扩展。
附，终究技能计划目录：
作者简介
张强，转转交易中台研制工程师
转转研制中心及业界小伙伴们的技能学习沟通平台，定时共享一线的实战经验及业界前沿的技能论题。`
重视公众号「转转技能」（归纳性）、「大转转FE」（专心于FE）、「转转QA」（专心于QA），更多干货实践，欢迎沟通共享~`
