阿里巴巴国际站架构分析和镜像解决方案
- 1. 阿里巴巴网站技术介绍 网站镜像和同步技术
- 2. 纲要 一、前 言 二、网站部署的三个阶段 三、新的挑战 四、总结
- 3. 阿里巴巴（ Alibaba.com ）是一个服务于全球企业的（ B2B ）电子商务平台。用户遍布中国以及世界各地，为了更好的为这上千万的用户提供网络服务，我们建立了多个站点去为用户提供应用 . 总体而言 , 我们的站点发展经历了以下三个阶段： 单站点 双站点 多站点 前 言
- 4. 纲 要 一、前 言 二、网站部署的三个阶段 三、新的挑战 四、阶段性总结
- 5. 网站部署的三个阶段
- 6. 应用都是 无状态 的 状态数据都保存在以下的设备中 数据库 存储 第一阶段 - 单站点
- 7. 状态数据都保存在数据库和存储，由数据库和存储提供分布式以及 HA 的解决方案。 应用都是无状态的（尽量用 Cookie 解决 session 的问题），非常便于扩展。 描述 缺 点 部分地区用户 的 使用 体验不佳 系统性能和扩展性不好 第一阶段 - 单站点
- 8. 可用性的要求 单个 IDC 发生故障 , 例行维护 , 系统升级 都会影响所有的用户，进而降低网站的可用时间。 用户体验的问题 网站是为全球用户提供服务的，物理距离产生的网络延时是不可避免的。 10000 公里 = 延时 30 毫秒 电子商务网站的内容通常都是动态的， CDN 只能解决大多数静态资源的问题 ( 图片 ,css,js…) 。 驱动力 第二阶段 - 双站点
- 9. DNS 负载均衡 (IDC 之间的负载均衡 ) 数据同步解决方案 应用拆分＆镜像 需要解决的问题 第二阶段 - 双站点
- 10. DNS 负载均衡 第二阶段 - 双站点
- 11. 数据同步 1.0- 方案 选型 第二阶段 - 双站点 数据库提供的方式 专业工具 , 例如 shareplex 自主开发 同步效率 中 高 中 双向同步 不支持 支持 支持 关联的文件同步 不支持 不支持 支持 异构数据库 不支持 不支持 支持 冲突检测逻辑 不支持 不支持 支持
- 12. 基于 AOP 方式的 SQL 拦截 根据变更的数据找到关联的文件 . 异步的进行 SQL 以及文件的复制 . 数据同步 1.0- 实现 第二阶段 - 双站点
- 13. 第二阶段 - 双站点 数据同步 1.0- 缺点 数据同步 1.0- 优点
- 14. CAP 原理 写应用 : 符合 Consistency&Availability 读应用 : 符合 Partition tolerance&Availability, 结论 : 读应用更容易实现跨 IDC 的部署 问题 数据同步会 放大 数据不一致 & 数据不完整的情况 . 这会增加镜像站点应用的复杂性 . 应用拆分 - 分析 第二阶段 - 双站点
- 15. 应用拆分 - 注意事项 第二阶段 - 双站点 被镜像的读应用需要从设计上避免数据完整性的问题 . 设计业务流程的时候需要避免跨 IDC 的 Web Flow.
- 16. 应用拆分示意图 第二阶段 - 双站点
- 17. 部署结果 第二阶段 - 双站点
- 18. 解决了大多数读应用和少量写应用的用户体验问题 . 实现了读应用的跨站点的 HA. 提高了读应用以及网站的整体可用性 . 读应用的数据源尽量迁移到了 Search engine 和 cache 上为其性能和可扩展性带来了很大的收益 . 收益 第二阶段 - 双站点
- 19. 不完全的镜像 同步的延迟 到导致应用之间数据不一致的问题，尤其在不同 IDC 之间存在应用的依赖时，这个问题会被放大。 数据的双向同步带来了一些不能解决的 数据冲突 ，需要在设计的时候进行规避。 缺 陷 第二阶段 - 双站点
- 20. 应用规模的日益复杂 同步数据量的增大 数据同步 1.0 的缺点逐渐凸显 . 数据冲突的问题 不能拦截所有的数据变更 开始酝酿升级 后 记 第二阶段 - 双站点
- 21. 起因 第三阶段 - 多站点 Disaster…
- 22. 目 标 第三阶段 - 多站点
- 23. 多个 IDC 之间的数据同步 数据同步的吞吐量以及数据一致性的问题 . 写应用的镜像 & 数据拆分 挑 战 第三阶段 - 多站点
- 24. 变更数据的急剧增长导致同步的效率成为瓶颈 . 结果： 站点之间的数据延迟不断加大 应用之间的数据不一致的情况逐渐加剧 数据同步现状 第三阶段 - 多站点
- 25. 数据同步的瓶颈并不在于网络 数据同步的瓶颈最终受制于为了满足数据一致性而对写入操作进行的排序 数据同步瓶颈分析 第三阶段 - 多站点
- 26. 在数据库层面记录数据变更 基于 Base 原则 消息驱动 并行所有可以并行的内容 . 有选择的侵入业务 简单的处理冲突的逻辑 Merge 操作 数据同步 2.0 设计原则 第三阶段 - 多站点
- 27. 写应用的镜像方案选择 第三阶段 - 多站点 HA 方式 Master-Slave Master-Master 业务数据冲突 √ 实现成本 √ 维护成本 ? 硬件成本 √ 可用性 √ 数据丢失情况 √ 吞吐量 √ 用户体验 √
- 28. Sharding. 去中心化 , 缩小中心 Write Sticky: 解决跨站点的 Web Flow 的问题 事后补偿 异步 写应用的镜像解决方案 第三阶段 - 多站点
- 29. 提高对数据不一致窗口的容忍程度． 数据库记录中的文件路径的问题 . 降低多点更新数据的冲突可能性 引用计数的问题 应用的注意事项 & 案例 第三阶段 - 多站点
- 30. IDC 之间的数据不能遵循 ACID, 只遵循 Base 的原则 . 下面两个问题是提高用户体验的关键 . 提高同步性能，缩小数据不一致性窗口 尽量保证目的端数据库的数据完整性 . 单个 IDC 内部的数据一致性优于跨 IDC 的数据环境 . 所以。尽量把单个用户的操作行为限制在单个 IDC 中 . 总结 第三阶段 - 多站点
- 31. 纲 要 一、前 言 二、网站部署的三个阶段 三、新的挑战 四、阶段性总结
- 32. 集中的持久化技术已经不足以支撑应用的写入的吞吐量，其他的持久化技术开始引入 分布式数据库 其他分布式持久化方案的引入 :KV-Engine, DFS.. 分布式事务 . 一、应用架构发展的需要 新的挑战
- 33. 新的挑战
- 34. 数据复制的节点增加 . 硬件成本随之增大 一些特殊应用对同步实时性的要求提高 . 随着分布式持久化技术的引入 . 单个 IDC 的数据持久化能力 得到极大的提升 . 但数据同步技术因为受制于数据一致性 的问题 , 逐渐成为了瓶颈 . 设备数量的增长对自动化管理提出了新的要求 . 多站点的发布 , 自动化测试以及应用监控 . 跨站点的动态负载均衡 问题 新的挑战
- 35. 数据同步方案的优化 有效地控制数据备份的数量 . 在合适的场景下使用反向代理技术 . 水平拆分优于垂直拆分 . 应用监控平台 自动化发布和部署的平台 . 解决方案 新的挑战
- 36. 优化数据变更的采集方式 根据数据的类型设定不同的通道和策略 . 解决各种分布式数据源的数据一致性的问题 .( 分布式事务的场景 ) 纪录和尝试解决数据冲突的问题 . 数据同步 3.0 新的挑战
- 37. 适用范围 数据总量比较大 , 访问相对集中的静态资源 ; 例如图片信息 . 访问量比较小的一些动态应用 . 效果 降低同步数据量 降低存储设备的投入 减少因为同步延迟而造成的数据不一致 . 反向代理 新的挑战
- 38. 纲 要 一、前 言 二、网站部署的三个阶段 三、新的挑战 四、阶段性总结
- 39. 镜像的关键是数据同步的问题 . 根据 D&Q 的原则 . 将中心最小化 . 采用异步或者事后补偿的机制降低中心应用对其他应用的可用性的影响 . 单个 IDC 的核心数据保证可以保证强一致性 , 多个 IDC 的核心业务数据只保证最终一致性 . 在业务上解决数据冲突的问题并容忍一定程度的不一致 . 采用数据 Sharding 技术 , 水平拆分优于垂直拆分 . 总结
- 40. Q & A