共计 2909 个字符,预计需要花费 8 分钟才能阅读完成。
Apache ShardingSphere 助力当当 3.5 亿用户量级顾客零碎重构,由 PHP+SQL Server 技术栈无缝转型为 Java+ShardingSphere+MySQL,性能、可用性及维护性均失去显著晋升,是 ShardingSphere 异构迁徙最佳实际。
1 顾客零碎背景
当当顾客零碎次要负责账户的注册、登录、隐衷数据保护等性能,历史技术栈为 PHP+SQL Server,是规范的集中式架构,如下图。
重构我的项目启动前,顾客零碎的数个业务模块存在多个辣手的业务问题和技术挑战,如逻辑扩散、吞吐量低及运维老本低等问题。为改善顾客的购物体验,当当技术团队决定对业务逻辑和底层数据架构进行优化,实现顾客零碎多场景下的可用性、扩展性及综合晋升等多个指标。在重构过程也实现了泛滥技术创新,如跨数据源双写、读写拆散、智能网关及灰度公布等技术。
从需要设计、分库分表布局、逻辑优化、压测再到齐全上线等多个环节,当当技术团队用半年的工夫实现了基于 3.5 亿 + 用户的零碎重构。
应用 Java 语言重构十余个模块,通过 ShardingSphere+ MySQL 构建分布式数据库解决方案,顺利完成异构数据库在线迁徙,案例亮点如下。
- 应用 Java 语言重构 PHP 业务代码;
- 应用 ShardingSphere+MySQL 替换 SQL Server;
- 在线实现 3.5 亿用户数据残缺迁徙;
- 通过数据双写计划实现无缝上线。
2 痛点 & 挑战
业务痛点
在业务层面,顾客零碎局部模块的注册和登录逻辑扩散在各端,保护老本较高,且过后的技术架构对于性能的晋升和高可用性存在着很大的局限性。
- 不易保护 :多平台注册和登录逻辑较为扩散,业务保护简单;
- 性能受限 :PHP+SQL Server 集中式技术架构,吞吐量有余;
- 可用性 & 安全性差 :
- SQL Server 主备状态变动后,订阅库会生效,重新配置须要窗口工夫;
- SQL Server 运行在 Windows Server 上,病毒影响导致安全性差,且打补丁后降级启动工夫长(>30min)。
挑战
- 数据完整性
顾客零碎领有 3.5 亿 + 用户数据,在数据迁徙过程中,需保证数据从 SQL Server 迁徙到 MySQL 后的一致性及完整性;
- API 通明
API 对调用方放弃通明,确保调用方无改变,最小化变更界面;
- 无缝切换
须要满足业务零碎无缝切换,切换过程对业务无影响;
- 工夫紧迫
“618”和“11.11”促销流动前后会封网,因而需在两大促流动间、无限窗口的工夫内实现切换,并紧接着面对“11.11”的验证。
3 解决方案
整体规划
为了改善顾客零碎的可维护性、可用性及性能,研发团队从新梳理顾客零碎的架构。
在应用层,对立各端的性能逻辑,晋升业务可维护性。在数据库层,将集中式架构调整为分布式数据库架构,晋升性能及可用性,即 ShardingSphere+MySQL 构建的开源分布式解决方案。
- 应用层:随当当整体技术栈的变迁,业务开发语言由 PHP 转为 Java;
- 中间件:应用成熟的开源数据库中间件 ShardingSphere 实现分库分表;
- 数据库:应用多套 MySQL 集群代替 SQL Server 数据库。
在整体架构设计上,引入了分布式主键生成策略、分片治理、数据迁徙校验以及灰度公布等多个计划。
分布式主键生成策略
数据库架构由集中式转型为基于中间件的分布式架构,分布式主键生成策略是首先须要思考解决问题。在零碎重构中,抉择建设两台以上的数据库 ID 生成服务器,每台服务器都有一张记录各表以后 ID 的 Sequence 表,Sequence 中 ID 增长的步长是服务器的数量。起始值顺次错开,这样相当于把 ID 的生成散列到了每台服务器节点上。
分片(ShardingSphere)
在顾客零碎重构中,通过 Apache ShardingSphere 实现数据库 Sharding,同时也启用了读写拆散性能。
因为顾客零碎在高并发、低延时的要求,接入端抉择了 ShardingSphere-JDBC,它定位为轻量级 Java 框架,在 Java 的 JDBC 层提供的额定服务。它应用客户端直连数据库,以 jar 包模式提供服务,无需额定部署和依赖,可了解为增强版的 JDBC 驱动,齐全兼容 JDBC 和各种 ORM 框架。
- Sharding
ShardingSphere 反对十分全面的分片算法,包含取模、哈希、范畴、工夫及自定义等算法,顾客系采纳取模分片算法对大表进行拆分。
- 读写拆散
除了 Sharding,同时还启用 ShardingSphere 读写拆散性能,充分利用 MHA 集群资源,晋升零碎吞吐能力。
双写 & 数据同步
数据同步贯通了整个重构我的项目,数据迁徙的完整性及数据一致性是重构的要害。
该案例基于 Elastic-Job 同步历史数据,以周期的形式将 SQL Server 的历史数据同步到 MySQL 中。
对于数据库切换方面,在切换过程中会采纳备份计划,进行数据库的双写,保障切换前后的数据一致性,过程如下。
第 1 步:实现双写机制
断掉链路 1,买通链路 2、3、4,买通链路 9、10。
第 2 步:切换登录服务
断掉链路 9,10,买通链路 7,断掉链路 5。
第 3 步:切换读服务
买通链路 8,断掉链路 6。
第 4 步:勾销双写机制
断掉链路 2,实现切换。
在数据校验方面,通过业务侧和数据库侧两个方面进行验证,均周期性进行查看,在不同时间段采纳不同的频率,抽样或全量检查数据的完整性,在数据库侧也会进行 COUNT/SUM 的验证。
顾客零碎重构应用了基于 apollo 的灰度公布形式,在新登录形式的解决上,通过配置项逐渐放开、小范畴陆续割接,确保上线成功率。重构后的零碎架构如下图。
4 用户收益
通过重构,当当顾客零碎响应速度显著晋升,同时也升高了日常运维老本,ShardingSphere 提供的分布式解决方案功不可没。该计划实用于各种高流量的互联网平台服务,也实用于电商平台以及其余以数据处理为主的零碎。
- 性能晋升,响应速度晋升 20% 以上;
- 可用性加强,ShardingSphere+MySQL 的计划实现 RTO<30s;
- 易于保护,业务逻辑以及数据库的可维护性显著晋升;
- 无缝迁徙,6 个月内在线实现各模块割接,窗口工夫为零。
5 总结
在“ShardingSphere 助力当当 WMS:订单效率晋升 30%、节约老本上千万”案例之后,这是第二篇 ShardingSphere 在当当的实际案例。
Apache ShardingSphere 为业务零碎提供了强力的撑持。简略与极致,是 ShardingSphere 突出的两个个性,让业务逻辑更简略,让性能更极致。
Apache ShardingSphere 社区已在开源畛域耕耘了 7 年的工夫。短暂的保持,使社区更加成熟,已呈凋谢和多元化的势态。咱们诚心欢送有开源情怀和编码激情的敌人一起参加社区共建,也欢迎您提供优质案例内容分享给社区的敌人们。
如果大家对 Apache ShardingSphere 有任何疑难或倡议,欢送在 GitHub Issue 列表提出,或可返回中文社区交换探讨。
GitHub Issue:https://github.com/apache/sha…
奉献指南:https://shardingsphere.apache…
中文社区:https://community.sphere-ex.com/