分布式系统-“大型”网站架构设计.ppt

■[Step5]技术点—分库 网站架构演变及其技术脉络 读写分离（简单有效，前面已介绍） 垂直分区 良好的松耦合的模块化设计是垂直分库的前提 ■[Step5]技术点—分库 网站架构演变及其技术脉络 水平分区（Shard） 分片Key识别（划分检索依据）是关键 是否还有其它招？用NoSql数据库部分替换关系数据库 ■[Step5]技术点—分库 网站架构演变及其技术脉络 水平分区（Shard） ■[Step5]技术点—分库 网站架构演变及其技术脉络 shard改变数据库设计 尽量避免join 数据冗余/反范式 shard before comment(id,blog_id,content) shard after comment(id,blog_id,content,user_id) ■[Step6]多个数据中心，向分布式存储和计算的架构体系迈进 网站架构演变及其技术脉络 优点：多数据中心，带来更高质量区域服务体验；分布式存储及计算架构有效解决pb级数据量存储、检索及计算性能问题 缺点：架构复杂、数据同步、一致性及系统维护、技能要求等成本十分高 技术点：分布式文件系统、Map/Reduce、Key-Value存储 ■[Step6]技术点—向分布式存储计算解决方案[DFS、Map/Reduce、Key-Value DB] DFS分布式文件系统，如：Lustre\HDFS\GFS\TFS\FreeNas等 Map/Reduce算法（计算框架），基本上现有NoSQL数据库中都支持此算法。 Key-Value DB，也作为NoSQL解决方案，如：BigTable\Tair\Hbase\ HyperTable等 提供完整解决方案： Google(GFS|Map/Reduce|BigTable) Apache Hadoop(HDFS|Map/Reduce|HBase) 大型网站架构的目标与挑战 网站架构演变及其技术脉络 架构设计理论与原则 讨论及总结 ■关于数据一致性—ACID vs BASE ACID（ Atomicity 、 Consistency 、 Isolation 、 Durability ）是关系型数据库的最基本原则，遵循ACID原则强调一致性，对成本要求很高，对性能影响很大。 问题：ACID原则适用于互联网应用吗？可用性似乎比一致性重要些 BASE（ Basically Available 、 Soft state 、 Eventually consistent ）策略 BASE策略与ACID不同，其基本思想就是通过牺牲强一致性，以获得更好的可用性或可靠性 基本可用 数据能够保证80%一致性就够了，剩下20%就不要过于纠结了。可参考二八定律 软状态 在不过分追求数据一致性（强一致性）前提下可考虑软状态策略，例如把数据缓存（State）在客户端一段时间，过后若没有新请求的话，就清除此缓存（Soft） 最终一致性 在某一段短时间内允许数据不一致，但经过一段较长时间，等所有节点上数据的拷贝都整合在一起的时候，数据会最终达到完全一致 架构设计理论与原则 ■关于分布式系统—CAP理论 一致性 分布式系统中，数据一般会存储在不同节点，一致性就是要保证对数据操作的原子性 可用性 确保客户访问数据时可得到响应。不强调各个节点上数据要保持一致性。 分区容忍性 数据分区存储后，即使部分分区组件不可用，其施加的操作也能够完成 CAP理论指出：一个分布式系统不可能同时满足一致性、可用性 和分区容忍性这三项需求，最多只能同时满足其中两个。 架构设计理论与原则 ■无共享架构（Share Nothing Architecture） 架构设计理论与原则 ■ED-SOA架构 ED-SOA，事件驱动，面向服务架构 SOA是系统组件化、模块化构建性理论；ED是系统组件之间同步通信，采取事件机制异步化，提高响应速度 基于ED-SOA构建松耦合系统可以显著改善网站可伸缩性 ■架构进化与退化--奥卡姆剃刀原理 进化—寻找最适合的；退化—简化不必要的 简单就好，慎防过渡设计 架构设计理论与原则 ■考量成本，先硬后软原则 架构设计理论与原则 ■[Step4]技术点—高可用性HA 网站架构演变及其技术脉络 使用双机热备 故障时切换至备份机 工具(Linux-HA) heartbeat ■[Step4]技术点—数据库读写分离及DAL(数据访问层) 网站架构演变及其技术脉络 ■读写分离逻辑分批 ■负载均衡 ■失效转移（failover） ■数据库分区透明支持 ■两大实现模式：独立Proxy服务器；单独API库文件 各个数据库厂商都有自己复制方案 常见通用方案：ETL、GoldenGate TJS… ■[Step4]技术点—DAL(数据访问层) 网站