时间流导程最新分析和总结.pptx

汇报人：时间流导程反?方意?见：造轮?子 = 战略错误Its important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.— Joel Spolsky, 2001NetscapeBorland Quattro Pro正?方意?见：再造轮?子 = 学习+?革新案例：重写Lotus Notes 公式引擎案例：重写Lotus Notes 公式引擎改写前? 超过10年的代码库上百积压bugs? ?大量优化? 资深?工程师：“没?人能动这套代码”Damien Katz: 多年UI经验，?无C++经验改写后? 全新C++代码库0 bug? 提速300%? 全新数据复制组件CouchDB造轮?子的唯?一原因核?心竞争?力Google: 基础架构Uber: DispatchNetflix: ?高质廉价的影视作品Undifferentiated Heavy Lifting?无关紧要的重活常?见?工程师?黑话?第三?方设计太复杂?第三?方代码太丑陋?第三?方系统太不稳定都不是理由?降低基建开销200%?系统可?用时间从3个9提升到4个9?没有系统能够?支持公司的战略功能Auto ScalingAuto Scaling vsPredictive Auto Scaling造轮?子的正确姿势像科学研究?一样遍历?文献遍历?文献 = 熟悉已知系统熟悉历史沿?革熟悉历史沿?革 = 了解技术发展中的取舍案例：Elasticsearch案例：Elasticsearch??自?己的Leader Election算法案例：Elasticsearch??自?己的Leader Election算法??自?己的集群管理算法 (zen discovery)案例：Elasticsearch??自?己的Leader Election算法??自?己的集群管理算法 (zen discover)?Call-me-maybe Test: 50% 数据丢失案例：Facebook Zeus应?用场景- 服务发现应?用场景- 服务发现- 动态配置管理应?用场景- 服务发现- 动态配置管理- ?自动分?片(shard)管理应?用场景- 服务发现- 动态配置管理- ?自动分?片(shard)管理- 分布式锁和分布协调跨区集群.需求-- ?西岸：两个数据中?心。- 东岸：三个数据中?心跨区集群.需求-- ?西岸：两个数据中?心。- 东岸：三个数据中?心?至少百万客户端-跨区集群.需求-- ?西岸：两个数据中?心。- 东岸：三个数据中?心?至少百万客户端DoS 保护：流畅处理?大量客户端同时 上线--跨区集群.需求-- ?西岸：两个数据中?心。- 东岸：三个数据中?心?至少百万客户端DoS 保护：流畅处理?大量客户端同时上线 100%上线 - 任何时候可读---怎么?入?手？遍历?文献 = 考察现有系统Google ChubbyApache ZookeeperApache ZookeeperZookeeper远?非完美Zookeeper远?非完美?写?入吞吐量太低Zookeeper远?非完美?写?入吞吐量太低?保证写?入顺序导致写?入延迟Zookeeper远?非完美?写?入吞吐量太低?保证写?入顺序导致写?入延迟?客户端短时?大量接?入导致服务器当掉Zookeeper远?非完美?写?入吞吐量太低?保证写?入顺序导致写?入延迟?客户端短时?大量接?入导致服务器当掉?不能承受上亿监控节点Zookeeper远?非完美?写?入吞吐量太低?保证写?入顺序导致写?入延迟?客户端短时?大量接?入导致服务器当掉?不能承受上亿监控节点?Leader节点挂掉造成?长时间服务中断解决?方案?确认性能瓶颈- Leader节点的锁争?用- Java wait-notify 耗时太?长解决?方案?确认性能瓶颈- Leader节点的锁争?用- Java wait-notify 耗时太?长?采纳精简数据结构- 位图表?示监控节点 - 250GB to 300MB解决?方案?确认性能瓶颈- Leader节点的锁争?用- Java wait-notify 耗时太?长?采纳精简数据结构- 位图表?示监控节点 - 250GB to 300MB?常?用优化?手段- 流?水线- 客户端缓存- 适当放松协议限制从“?小”开始从“?小”开始 = 快速迭代从“?小”开始 = 累进改动从“?小”开始 = 最多考虑10倍增?长案例：Netflix AtlasNetflix Atlas?Ne