阿里网站技术介绍.pptVIP

集中的持久化技术已经不足以支撑应用的写入的吞吐量，其他的持久化技术开始引入 分布式数据库 其他分布式持久化方案的引入:KV-Engine, DFS.. 分布式事务. 一、应用架构发展的需要 新的挑战 新的挑战 数据复制的节点增加. 硬件成本随之增大 一些特殊应用对同步实时性的要求提高. 随着分布式持久化技术的引入.单个IDC的数据持久化能力 得到极大的提升.但数据同步技术因为受制于数据一致性 的问题 ,逐渐成为了瓶颈. 设备数量的增长对自动化管理提出了新的要求. 多站点的发布,自动化测试以及应用监控. 跨站点的动态负载均衡 问题 新的挑战 数据同步方案的优化 有效地控制数据备份的数量. 在合适的场景下使用反向代理技术. 水平拆分优于垂直拆分. 应用监控平台 自动化发布和部署的平台. 解决方案 新的挑战 优化数据变更的采集方式 根据数据的类型设定不同的通道和策略. 解决各种分布式数据源的数据一致性的问题.(分布式事务的场景) 纪录和尝试解决数据冲突的问题. 数据同步3.0 新的挑战 适用范围 数据总量比较大,访问相对集中的静态资源;例如图片信息. 访问量比较小的一些动态应用. 效果 降低同步数据量 降低存储设备的投入 减少因为同步延迟而造成的数据不一致. 反向代理 新的挑战 纲 要 一、前 言 二、网站部署的三个阶段 三、新的挑战 四、阶段性总结 镜像的关键是数据同步的问题. 根据DQ的原则.将中心最小化.采用异步或者事后补偿的机制降低中心应用对其他应用的可用性的影响. 单个IDC的核心数据保证可以保证强一致性,多个IDC的核心业务数据只保证最终一致性. 在业务上解决数据冲突的问题并容忍一定程度的不一致. 采用数据Sharding技术,水平拆分优于垂直拆分. 总结 Q A * 阿里巴巴网站技术介绍 网站镜像和同步技术? ?? 纲要 一、前 言 二、网站部署的三个阶段 三、新的挑战 四、总结 阿里巴巴（A）是一个服务于全球企业的（B2B）电子商务平台。用户遍布中国以及世界各地，为了更好的为这上千万的用户提供网络服务，我们建立了多个站点去为用户提供应用. 总体而言,我们的站点发展经历了以下三个阶段： 单站点 双站点 多站点 前 言 纲 要 一、前 言 二、网站部署的三个阶段 三、新的挑战 四、阶段性总结 网站部署的三个阶段 应用都是无状态的 状态数据都保存在以下的设备中 数据库 存储 第一阶段-单站点 状态数据都保存在数据库和存储，由数据库和存储提供分布式以及HA的解决方案。 应用都是无状态的（尽量用Cookie解决session的问题），非常便于扩展。 描述 缺 点　 部分地区用户的使用体验不佳 系统性能和扩展性不好 第一阶段-单站点 可用性的要求 单个IDC发生故障,例行维护,系统升级都会影响所有的用户，进而降低网站的可用时间。 用户体验的问题 网站是为全球用户提供服务的，物理距离产生的网络延时是不可避免的。 10000公里 = 延时30毫秒 电子商务网站的内容通常都是动态的，CDN只能解决大多数静态资源的问题(图片,css,js…)。 驱动力 第二阶段-双站点 DNS负载均衡(IDC之间的负载均衡) 数据同步解决方案 应用拆分＆镜像 需要解决的问题 第二阶段-双站点 DNS负载均衡 第二阶段-双站点 数据同步1.0-方案选型 数据库提供的方式 专业工具,例如shareplex 自主开发 同步效率 中 高 中 双向同步 不支持 支持 支持 关联的文件同步 不支持 不支持 支持 异构数据库 不支持 不支持 支持 冲突检测逻辑 不支持 不支持 支持 第二阶段-双站点 数据同步1.0-实现 基于AOP方式的SQL拦截 根据变更的数据找到关联的文件. 异步的进行SQL以及文件的复制. 第二阶段-双站点 第二阶段-双站点 数据同步1.0-缺点 数据同步1.0-优点 CAP原理 写应用:符合ConsistencyAvailability 读应用:符合Partition toleranceAvailability, 结论:读应用更容易实现跨IDC的部署 问题 数据同步会放大数据不一致数据不完整的情况 .这会增加镜像站点应用的复杂性. 应用拆分-分析 第二阶段-双站点 应用拆分-注意事项 第二阶段-双站点 被镜像的读应用需要从设计上避免数据完整性的问题. 设计业务流程的时候需要避免跨IDC的Web Flow. 应用拆分示意图 第二阶段-双站点 部署结果 第二阶段-双站点 解决了大多数读应用和少量写应用的用户体验问题. 实现了读应用的跨站点的HA.提高了读应用以及网站的整体可用性. 读应用的数据源尽量迁移到了Search e