{
    "componentChunkName": "component---src-templates-case-study-detail-ts",
    "path": "/case-studies/48",
    "result": {"pageContext":{"next":{"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":[]}}},"prev":{"id":49,"attributes":{"feature":false,"title":"某央企｜打造新一代云上数据底座，助力业务推广","content":"## 业务挑战\n根据客户总公司上云整体目标，为推动下一阶段相关业务板块全面推广使用奠定良好基础，需完成项目管理系统上云升级改造工作。\n项目管理系统所使用的技术栈为 Java + MySQL，为满足未来更多项目的云上高效管理，结合当前系统架构，围绕业务、研发及运维三个维度进行了梳理，本次上云升级改造工作需同时达成如下目标。\n1. 提升系统扩展能力\n2. 提高系统资源利用率\n3. 减少查询流程响应时间\n\n## 解决方案\n面向业务构建数据通用接入层，通过 “DBPlusEngine + RDS + 云平台” 打造云上数据底座，提供轻量化分布式数据库解决方案。\n在沿用 MySQL 技术栈基础之上提供分布式计算和存储能力，客户端（Driver）访问模式为业务提供低延时响应支持，服务端（Proxy）访问模式为运维提供便捷维护入口。\n数据分片及分布式事务的支持使应用程序无需修改；全局高可用、多数据库支持及一体化运维能力减轻运维工作。\n\n![20231016-145048.jpeg](https://sphereex-media-1305704183.cos.ap-beijing.myqcloud.com/20231016_145048_86ccdc01f7.jpeg)\n\n## 客户收益\n- 平滑迁移上线：保持了原有业务逻辑与数据库使用模式，人员、生态及工具均可复用；\n- 避免厂商绑定：为自主创新落地提供必要支撑平台，多数据库支持可避免被指定厂商绑定；\n- 提升扩展能力：计算及存储扩展灵活，新一代数据底座为业务快速增长提供良好扩展能力；\n- 提升系统效能：显著提高云上资源利用率，压力负载均衡，同时业务请求响应时间缩短近 90%。\n\n## 客户感言\n“SphereEx 数据库增强平台具有良好的扩展能力，最重要的是对业务没有入侵。对于不希望改变技术栈，同时有分布式改造升级诉求的业务场景，这样的方案是一个合适的选择。”\n","date":"2023-09-27","author":"代野","excerpt":null,"metaDescription":null,"createdAt":"2023-10-16T06:53:13.035Z","updatedAt":"2023-10-16T06:53:14.701Z","publishedAt":"2023-10-16T06:53:14.698Z","locale":"zh","caseStudiesType":{"data":null},"cover":{"data":null},"metaLogo":{"data":null},"localizations":{"data":[]}}},"article":{"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":[]}}}}},
    "staticQueryHashes": []}