项目背景 中商惠民历经⼏次技术迭代，2016 到 2017 年开始 PHP 技术栈转到 Java 技术栈并进⾏微服务化，2018 年开始打造中台。 2021 年年初完成的交易中台⼀期上线，2022 年 3 ⽉完成⼆期上线。
伴随着业务成长和多样性的变化，要及时响应新需求，同时要避免对现有业务产⽣影响，本着提⾼⼈效，降低成本的原则，中商惠民推出了强中台发展战略。对系统⽽⾔，要降低系统之间的耦合度，增加可扩展性，提取业务共性的同时要保证低延迟。在 2021 年之初完成了对之前订单管理系统（OMS）的重构，推出了以订单的交易过程为核⼼的交易中台项⽬，分为以下四个核⼼模块：订单状态流转系统，订单管理系统，订单履约系统，订单费⽤计算系统。同时，基于业务分层，又拆分为订单查询系统，报表系统，订单管理后台等。
在系统的重构过程中避免技术需求对业务需求产⽣阻碍，上线过程分为两个阶段：应⽤系统拆分和数据拆分。
业务挑战
数据表拆分之后，需要解决数据散列和查询问题。作为⼀家中⼩型企业，⾃研⼀套分库分表的中间件成本过⾼，初期还会⾯临各种踩坑的风险，
拆分原则
以 3 年作为⼀个迭代周期，拆分数量=（（每⽉新增的数据量* 36）+ 历史数据量）/单表数据量上限 根据我们维护阿⾥云 RDS MySQL 的经验来看，基于在使⽤ Innodb 引擎下，进⾏ DDL 操作时，⼩于 500 万数据量，执⾏时间⼤概⼏⼗秒；⼤于 500 万，⼩于 1000 万数据量，执⾏时间⼤概 500 秒左右；⼤于 1000 万数据量，⼩于 5000 万左右，执⾏时间⼤概 1000 多秒；⼤于 5000 万以上数据量，执⾏时间在 2000 秒以上。 单表分配上限可以取决于单表操作对业务带来的影响，当然也有⼀些⽅案可以解决 DDL 操作锁表的问题，例如双表同步，切换表名的⽅式可以将影响降低为秒级。 库表的拆分数量最好是 2 的 N 次⽅，有利于后期做⽔平扩容。
解决方案
ShardingSphere 提供了⼀种解决思路。它提出了连接模式（Connection Mode）的概念，将其划分为内存限制模式（MEMORY_STRICTLY）和连接限制模式（CONNECTION_STRICTLY）这两种类型。
内存限制模式
使⽤此模式的前提是，ShardingSphere 对⼀次操作所耗费的数据库连接数量不做限制。如果实际执⾏的 SQL 需要对某数据库实例中的 200 张表做操作，则对每张表创建⼀个新的数据库连接，并通过多线程的⽅式并发处理，以达成执⾏效率最⼤化。并且在 SQL 满⾜条件情况下，优先选择流式归并，以防⽌出现内存溢出或避免频繁垃圾回收情况。
连接限制模式
使⽤此模式的前提是，ShardingSphere 严格控制对⼀次操作所耗费的数据库连接数量。如果实际执⾏的 SQL 需要对某数据库实例中的 200 张表做操作，那么只会创建唯⼀的数据库连接，并对其 200 张表串⾏处理。如果⼀次操作中的分⽚散落在不同的数据库，仍然采⽤多线程处理对不同库的操作，但每个库的每次操作仍然只创建⼀个唯⼀的数据库连接。这样即可以防⽌对⼀次请求对数据库连接占⽤过多所带来的问题。该模式始终选择内存归并。
内存限制模式适⽤于 OLAP 操作，可以通过放宽对数据库连接的限制提升系统吞吐量；连接限制模式适⽤于 OLTP 操作，OLTP 通常带有分⽚键，会路由到单⼀的分⽚，因此严格控制数据库连接，以保证在线系统数据库资源能够被更多的应⽤所使⽤，是明智的选择。
我们发现在内存限制模式下，过程中会因为 MySQL 的 innodb 引擎的 cache buffer 加载策略导致操作变为 io 密集型，导致 SQL ⼤量超时，解决此问题的办法就是在不变更数据库资源的情况下我们程序多⼀层处理，如果发现没有分⽚键的时候，先在外置索引中确认⼀下分⽚键，再通过分⽚键来进⾏数据库检索。
选择 Apache ShardingSphere 的理由
- Apache ShardingSphere 功能符合预期，可以解决⽬前的问题并且有丰富的扩展性；
- Apache ShardingSphere 社区活跃度⾼，遇到问题会有专⼈及时响应；
- 公司采⽤ SpringCloud 技术栈，集成⽅便，成本低；
- 性能表现符合预期，完全可以⽀撑现有业务。
用户收益
-
性能提升 通过架构重构，有效控制单表数据量，⼤幅缩减慢 SQL，效率提升近 50%。
-
节省研发资源，降低成本 引⼊成熟的 Apache ShardingSphere ⽆需重新开发分表组件，降低了研发和踩坑的成本，研发同学只需要集中精⼒处理业务问题。
-
丰富的扩展性 Apache ShardingSphere 对于数据加密、分布式事务和影⼦库等⽅⾯都具备良好的扩展性。
