共计 1990 个字符，预计需要花费 5 分钟才能阅读完成。
一、背景与挑战
这几年随着转转二手业务的疾速倒退，订单零碎的根底性能问题也愈发重大，作为零碎运行的基石，订单库压力不容小觑。
面临的问题：
大促期间 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 以其良好的架构设计、高度灵便、可插拔和可扩大的能力简化了数据分片的开发难度，使研发团队只需关注业务自身，进而实现了数据架构的灵便扩大。
附，最终技术计划目录：
