{
    "componentChunkName": "component---src-templates-case-study-detail-ts",
    "path": "/case-studies/34",
    "result": {"pageContext":{"next":{"id":28,"attributes":{"feature":true,"title":"中商惠⺠交易中台架构演进：对 Apache ShardingSphere 的应⽤","content":"> 项目背景\n中商惠民历经⼏次技术迭代，2016 到 2017 年开始 PHP 技术栈转到 Java 技术栈并进⾏微服务化，2018 年开始打造中台。\n2021 年年初完成的交易中台⼀期上线，2022 年 3 ⽉完成⼆期上线。\n\n伴随着业务成长和多样性的变化，要及时响应新需求，同时要避免对现有业务产⽣影响，本着提⾼⼈效，降低成本的原则，中商惠民推出了强中台发展战略。对系统⽽⾔，要降低系统之间的耦合度，增加可扩展性，提取业务共性的同时要保证低延迟。在 2021 年之初完成了对之前订单管理系统（OMS）的重构，推出了以订单的交易过程为核⼼的交易中台项⽬，分为以下四个核⼼模块：订单状态流转系统，订单管理系统，订单履约系统，订单费⽤计算系统。同时，基于业务分层，又拆分为订单查询系统，报表系统，订单管理后台等。\n\n在系统的重构过程中避免技术需求对业务需求产⽣阻碍，上线过程分为两个阶段：应⽤系统拆分和数据拆分。\n\n## 业务挑战\n数据表拆分之后，需要解决数据散列和查询问题。作为⼀家中⼩型企业，⾃研⼀套分库分表的中间件成本过⾼，初期还会⾯临各种踩坑的风险，\n\n## 拆分原则\n以 3 年作为⼀个迭代周期，拆分数量=（（每⽉新增的数据量* 36）+ 历史数据量）/单表数据量上限\n根据我们维护阿⾥云 RDS MySQL 的经验来看，基于在使⽤ Innodb 引擎下，进⾏ DDL 操作时，⼩于 500 万数据量，执⾏时间⼤概⼏⼗秒；⼤于 500 万，⼩于 1000 万数据量，执⾏时间⼤概 500 秒左右；⼤于 1000 万数据量，⼩于 5000 万左右，执⾏时间⼤概 1000 多秒；⼤于 5000 万以上数据量，执⾏时间在 2000 秒以上。\n单表分配上限可以取决于单表操作对业务带来的影响，当然也有⼀些⽅案可以解决 DDL 操作锁表的问题，例如双表同步，切换表名的⽅式可以将影响降低为秒级。\n库表的拆分数量最好是 2 的 N 次⽅，有利于后期做⽔平扩容。\n\n## 解决方案\nShardingSphere 提供了⼀种解决思路。它提出了连接模式（Connection Mode）的概念，将其划分为内存限制模式（MEMORY_STRICTLY）和连接限制模式（CONNECTION_STRICTLY）这两种类型。\n\n### 内存限制模式\n\n使⽤此模式的前提是，ShardingSphere 对⼀次操作所耗费的数据库连接数量不做限制。如果实际执⾏的 SQL 需要对某数据库实例中的 200 张表做操作，则对每张表创建⼀个新的数据库连接，并通过多线程的⽅式并发处理，以达成执⾏效率最⼤化。并且在 SQL 满⾜条件情况下，优先选择流式归并，以防⽌出现内存溢出或避免频繁垃圾回收情况。\n### 连接限制模式\n\n使⽤此模式的前提是，ShardingSphere 严格控制对⼀次操作所耗费的数据库连接数量。如果实际执⾏的 SQL 需要对某数据库实例中的 200 张表做操作，那么只会创建唯⼀的数据库连接，并对其 200 张表串⾏处理。如果⼀次操作中的分⽚散落在不同的数据库，仍然采⽤多线程处理对不同库的操作，但每个库的每次操作仍然只创建⼀个唯⼀的数据库连接。这样即可以防⽌对⼀次请求对数据库连接占⽤过多所带来的问题。该模式始终选择内存归并。\n\n内存限制模式适⽤于 OLAP 操作，可以通过放宽对数据库连接的限制提升系统吞吐量；连接限制模式适⽤于 OLTP 操作，OLTP 通常带有分⽚键，会路由到单⼀的分⽚，因此严格控制数据库连接，以保证在线系统数据库资源能够被更多的应⽤所使⽤，是明智的选择。\n\n我们发现在内存限制模式下，过程中会因为 MySQL 的 innodb 引擎的 cache buffer 加载策略导致操作变为 io 密集型，导致 SQL ⼤量超时，解决此问题的办法就是在不变更数据库资源的情况下我们程序多⼀层处理，如果发现没有分⽚键的时候，先在外置索引中确认⼀下分⽚键，再通过分⽚键来进⾏数据库检索。\n\n## 选择 Apache ShardingSphere 的理由\n\n1. Apache ShardingSphere 功能符合预期，可以解决⽬前的问题并且有丰富的扩展性；\n2. Apache ShardingSphere 社区活跃度⾼，遇到问题会有专⼈及时响应；\n3. 公司采⽤ SpringCloud 技术栈，集成⽅便，成本低；\n4. 性能表现符合预期，完全可以⽀撑现有业务。\n\n## 用户收益\n\n- 性能提升\n通过架构重构，有效控制单表数据量，⼤幅缩减慢 SQL，效率提升近 50%。\n\n- 节省研发资源，降低成本\n引⼊成熟的 Apache ShardingSphere ⽆需重新开发分表组件，降低了研发和踩坑的成本，研发同学只需要集中精⼒处理业务问题。\n\n- 丰富的扩展性\nApache ShardingSphere 对于数据加密、分布式事务和影⼦库等⽅⾯都具备良好的扩展性。","date":"2022-11-01","author":"SphereEx ","excerpt":"通过架构重构，有效控制单表数据量，⼤幅缩减慢 SQL，下降将近 50%","metaDescription":null,"createdAt":"2022-11-03T06:03:40.665Z","updatedAt":"2022-11-16T09:39:37.310Z","publishedAt":"2022-11-03T06:03:44.426Z","locale":"zh","caseStudiesType":{"data":null},"cover":{"data":{"id":423,"attributes":{"name":"WechatIMG1962.png","alternativeText":"WechatIMG1962.png","caption":"WechatIMG1962.png","width":1790,"height":758,"formats":{"thumbnail":{"name":"thumbnail_WechatIMG1962.png","hash":"thumbnail_Wechat_IMG_1962_95b9c6004e","ext":".png","mime":"image/png","width":245,"height":104,"size":41.69,"path":null,"url":"https://sphereex-media-1305704183.cos.ap-beijing.myqcloud.com/thumbnail_Wechat_IMG_1962_95b9c6004e.png"},"large":{"name":"large_WechatIMG1962.png","hash":"large_Wechat_IMG_1962_95b9c6004e","ext":".png","mime":"image/png","width":1000,"height":423,"size":461.64,"path":null,"url":"https://sphereex-media-1305704183.cos.ap-beijing.myqcloud.com/large_Wechat_IMG_1962_95b9c6004e.png"},"medium":{"name":"medium_WechatIMG1962.png","hash":"medium_Wechat_IMG_1962_95b9c6004e","ext":".png","mime":"image/png","width":750,"height":318,"size":283.18,"path":null,"url":"https://sphereex-media-1305704183.cos.ap-beijing.myqcloud.com/medium_Wechat_IMG_1962_95b9c6004e.png"},"small":{"name":"small_WechatIMG1962.png","hash":"small_Wechat_IMG_1962_95b9c6004e","ext":".png","mime":"image/png","width":500,"height":212,"size":140.24,"path":null,"url":"https://sphereex-media-1305704183.cos.ap-beijing.myqcloud.com/small_Wechat_IMG_1962_95b9c6004e.png"}},"hash":"Wechat_IMG_1962_95b9c6004e","ext":".png","mime":"image/png","size":966.17,"url":"https://sphereex-media-1305704183.cos.ap-beijing.myqcloud.com/Wechat_IMG_1962_95b9c6004e.png","previewUrl":null,"provider":"strapi-provider-upload-s3-compat","provider_metadata":null,"createdAt":"2022-11-03T06:01:48.589Z","updatedAt":"2022-11-03T06:01:48.589Z"}}},"metaLogo":{"data":null},"localizations":{"data":[]}}},"prev":{"id":48,"attributes":{"feature":false,"title":"某银行的数据库网关实践","content":" ## 业务挑战\n该银行部分系统采用了 DNS + MySQL 主从的高可用架构，如风控系统。当数据库主节点发生故障时，需通过人工介入切换域名的方式进行重新映射，来完成整体 failover，RTO 为分钟级。\n为进一步改善业务体验，同时满足未来业务发展需要，需要在对业务无入侵前提下，达成如下目标：\n1. 提升业务系统的「可靠性」；\n2. 提高业务系统的「可维护性」；\n3. 增强业务系统的「安全性」；\n4. 增加系统架构的「可扩展性」。\n\n## 设计思路\n为了在现有技术栈的基础上实现可靠性、可维护性、安全性和可扩展性的提升目标，在设计思路上考虑引入数据库网关。通过引入数据库网关，可以为用户提供一个统一的访问接口，充当数据库系统和应用程序之间的桥梁。这样一来，应用程序与数据库之间的交互变得更加简化，同时为架构、研发和运维团队提供了其所关注的能力。\n### 1. 统一接入\n目前行内所使用数据库种类较多，通过数据库网关对分散的数据源进行整合，为用户提供统一的数据库视图和接口，无须再关注底层存储细节。\n### 2. 可用性探测\n可用性探测能力能够主动监测和检测底层数据库系统的可用性，并及时采取相应措施以确保系统的连续可用性。\n### 3. 安全合规\n金融行业对数据的安全性和合规性要求非常高。借助数据库网关为业务系统提供更强大的安全管控能力，如访问控制、数据加密和审计日志等，以确保敏感数据的保护和合规性要求的满足，遵守相关法规和监管要求。\n### 4. 高性能与可伸缩性\n对于金融场景海量数据处理和高并发请求，数据库网关可以提供高性能和可伸缩性的能力，通过读写分离、负载均衡及弹性伸缩等技术，确保业务快速响应及保持良好的扩展性，为用户提供高效的交易处理和良好的体验。\n### 5. 数据分析和业务洞察\n金融机构需定期对大量的数据进行分析，以获取业务洞察、风险评估和决策支持。数据库网关的联邦查询能力可以支持跨系统异构数据的实时访问和查询，通过复杂数据的分析了解客户行为、市场趋势和风险状况，从而优化业务策略和创新产品。\n综上，对于该系统优化升级需求，引入数据库网关是一个升级平滑、投入小且收益高的方案。\n\n## 解决方案\nSphereEx 数据库网关支持多种类型数据库，它面向应用程序和用户提供数据库网关功能，如读写分离、负载均衡、高可用探测、数据库防火墙、访问控制和安全审计等能力，支持如 Oracle、MySQL、PostgreSQL、openGauss、人大金仓及其他国产化数据库。\n在风控系统中，网关的高可用探测能力实现了数据库节点状态感知、确认故障及上线从库全流程切换处理，过程中无需人工介入，达成提升业务系统可靠性的目标。\n![20231016-144927.jpeg](https://sphereex-media-1305704183.cos.ap-beijing.myqcloud.com/20231016_144927_53ea986f5c.jpeg)\n\n下面是关于故障探测、重试及切换过程的描述。\n1. 监测连接状态：数据库网关能够周期性地探测与底层数据库系统之间的连接状态。通过心跳的验证，网关可以验证与数据库的连接是否正常，确保数据库系统处于可用状态。\n2. 故障检测与重试：当数据库网关在请求数据库时遇到连接异常或错误时，它能够执行故障恢复机制。网关可以自动进行错误处理，例如进行重试操作，恢复数据库连接，尽量避免中断用户的请求。\n3. 确认故障与切换：当数据库网关发现底层数据库系统出现故障或不可用的情况时，它具备自动切换到备用数据库的能力。网关会及时检测到故障，并迅速切换到备用数据库，从而保障系统的连续可用性。\n4. 报警与日志记录：数据库网关可以生成详细的日志记录，包括连接状态、故障信息、切换过程以及其他相关的事件，结合日志内容可通过运维平台发送警报通知，及时获取异常及恢复情况。\n\n总的来说，通过网关可用性探测能力，能够实现对底层数据库系统的主动监测和故障处理，提高系统的可用性和稳定性。这样可以确保系统在面对数据库故障或异常情况时能够快速切换和恢复，并提供可靠的服务给用户。\n\n\n此外，对于系统下一阶段的扩展性要求，SphereEx 数据库网关预留了较好的扩展空间。\n- 读写分离：智能路由读写流量，提升系统整体吞吐量、提升资源利用率，主从延迟感知能力保证数据一致性；\n- 数据库防火墙：通过 SQL 匹配的方式识别并完成风险 SQL 拦截，避免误操作，最大程度降低业务系统风险；\n- 访问控制：精确控制授予每个用户的库级、表级、列级的操作权限，可对接第三方 LDAP；\n- 数据库审计：记录所有执行过的 SQL 语句，便于企业进行 SQL 安全审计操作。\n\n## 客户收益\n通过 SphereEx 数据库网关解决方案，该银行客户面向架构、研发和 DBA 构建起了面向数据库的功能生态，将异构数据库的全局能力统一纳管，应对灵活多变的应用场景。\n1. RTO 由分钟级降至秒级；\n2. 符合金融级业务可用性要求；\n3. 全流程自动化 failover，无需人工介入；\n4. 预留扩展插槽，如读写分离、安全管控等能力。\n\n\n\n\n","date":"2023-08-14","author":"代野","excerpt":null,"metaDescription":null,"createdAt":"2023-10-16T06:50:07.037Z","updatedAt":"2023-10-16T06:50:36.811Z","publishedAt":"2023-10-16T06:50:08.773Z","locale":"zh","caseStudiesType":{"data":null},"cover":{"data":null},"metaLogo":{"data":null},"localizations":{"data":[]}}},"article":{"id":34,"attributes":{"feature":true,"title":"F6 汽车科技基于 Apache ShardingSphere 的核心业务分库分表实践","content":"## 业务背景\nF6 汽车科技，是一家专注于汽车后市场信息化建设的互联网平台公司，为维修企业开发智慧管理平台。各个维修企业（后文简称商户）之间的数据是相互隔离的，不同商户之间的数据理论上可以存储在不同库不同表。随着公司业务发展迅速，有些表的数据量增长迅速，单表总的数据量达到千万甚至亿的级别，系统越来越难以满足业务的高速发展。另外随着业务发展公司也在对系统进行拆分，按照不同域不同业务拆分成许多微服务，随之也就垂直拆分成了不同的业务库。  \n \n## 业务挑战\n关系型数据库由于单机存储容量、连接数、处理能力都有限，容易成为系统瓶颈。从性能上看，当单表的数据量达到千万以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。另外单库的连接数有限，如果数据库查询的 QPS 过高，那么就需要通过分库来分担单个数据库的连接压力。从可用性上看，单个数据库如果发生意外，很可能会丢失所有数据，影响所有业务，分库可以隔离故障，减少业务的影响范围。\n \n## 总体方案\n结合公司实际情况我们选择了 ShardingSphere 实现 Sharding。按照公司现有业务逻辑，因此采用商户 ID 作为分片键（ShardingKey），保证一个商户的工单数据，分配在同一个库同一个单表中，避免了多表查询关联的性能损耗，后期分片到多个库时，可以避免跨库事务及跨库 JOIN。\n商户 ID 数据库中的类型为 BIGINT(20)，为了保证后续分库扩容的需求，采用基因法，选取商户 ID 最后两位作为分库基因，按照双倍扩容的规则，可以最大扩展到 64 个库中。剩余位数的值用于分表，分片到 32 个分表中。\n\n规则如下（10545055917999668983 为某商户 ID）：\n\n```\n105450559179996689    83\n分表基因值 % 32    分库基因值 % 1\n```\n\n最后两位 83 用于分库，暂时数据只分片到 f6xxx 一个库中，因此余数为 0，后期数据量增加，扩展至多个库。剩余数值 105450559179996689 用于分表，首次分为 32 个单表，取模余数对应具体的分表下标，为 0~31。\n\n![screenshot-20230321-153539.png](https://sphereex-media-1305704183.cos.ap-beijing.myqcloud.com/screenshot_20230321_153539_94108c0802.png)\n按照公司系统现状及开发功能能快速迭代分步上线的背景，因此我们制定了先分表再拆库的方案，考虑到分库分表改动影响比较大，因此需要灰度上线，一旦有问题需要快速回滚，不能影响正常业务。具体实施步骤如下：\n### 分表\n（1）工程从 JDBC 切到 Sharding-JDBC 数据源连接方式\n（2）写库业务解耦和代码迁移\n（3）历史数据和增量数据同步\n（4）切分表\n### 分库\n（1）读库业务迁移\n（2）数据迁移\n（3）切读库\n（4）切写库\n\n## 选择 Apache ShardingSphere 的理由\n- 社区活跃，目前已经升级至 5.0 版本，仍处于快速迭代中；\n- 成功应用案例多，京东、当当等大公司广泛应用；\n- 使用简单，Sharding-JDBC 快速集成项目，不需要部署额外服务；\n- 兼容性好，路由至单数据节点，SQL 100% 支持；\n- 性能优异，损耗低，官网有测试结果；\n\n\n","date":"2023-01-02","author":"SphereEx ","excerpt":"汽车互联网平台领域技术实践        ","metaDescription":null,"createdAt":"2023-03-21T07:36:34.241Z","updatedAt":"2024-01-03T09:57:02.591Z","publishedAt":"2023-03-21T07:36:35.817Z","locale":"zh","caseStudiesType":{"data":null},"cover":{"data":null},"metaLogo":{"data":null},"localizations":{"data":[]}}}}},
    "staticQueryHashes": []}