分布式系统设计模式

dongfeiwww

贡献于2014-06-05

字数:0 关键词: 分布式/云计算/大数据

分布式系统设计模式 汪源 内容介绍 • ⺫标 - 介绍⼀些分布式系统设计思路或经验,⾮严格意义的设计模式 - 不求全⾯,但求最实⽤ • 提纲 - 可伸缩设计模式 - ⾼可靠可⽤设计模式 - 低成本设计模式 可伸缩设计模式 伸缩模式 (1) scale-upscale-down scale-in scale-out 垂直伸缩 ⽔平伸缩 读写分离 write read write read 复制 伸缩模式 (2) • 垂直伸缩 - 易于实现 - 传统观念:不好 (规格有限,淘汰损失 ) - 基于 IaaS云计算:不错 丰富的硬件规格 (1-64ECU/64x,1-64GMEM/64x,5G-1T 存储 /200x) 资源共享⽆浪费 优先进⾏垂直伸缩,简化系统实现与实施 • ⽔平伸缩 - 伸缩性最佳 - 难以实现与运维 • 读写分离 - 实现难度中等 - 只适合读多写少的应⽤ 交叉扩容 0 50.00 100.00 150.00 200.00 节点规格 节点数量 系统容量 优势:只需要进⾏ 1分为 N的⽔平扩容 ⽔平分区 • 哈希分区 - 推荐 :易于规划,易于实现,均衡性⼀般很好 - 避免过于 trivial的哈希函数(如取模),以免引起分布不均衡 教训: DDB(按时间戳分配全局 ID导致分布不均衡) • 范围分区 - ⼀般不推荐:难以规划,均衡性容易出问题 - 时间分区⽐较常⽤ • 组合分区 • ⾃定义分区 - 例: DDB通过⽤户⾃定义 .jar包计算纪录的分区号 ⼀致性哈希 朴素哈希分区 1 2 3 4 5 6 新增节点 3 分区策略 : HASH%N 缺陷:节点数变化导致数据完全重分布 ⼀致性哈希分区 节点 1(0~49)节点 2(50~99) 节点 1(0~49) 节点 3(75~99) 节点 2(50~74) 0 50 0 50优点:节点数变化只导致少量数据重分布 缺点:只分流⼀个节点的负载,容易不均衡 虚拟节点⼀致性哈希 节点 1(0~24,25~49) 节点 2(50~74,75~99) 0 50  ⼀个物理节点负责多个虚拟节点,增加节点时从来⾃于多个 物理节点的虚拟节点都分流⼀部分负载 2575 节点 1(0~24,25~33) 节点 2(67~74,75~99) 0 50 2575 67 34 节点 3(34~49,50~66) 固定分区路由表 - 事先规划固定数量⾜够多 的分区 (相当于虚拟节 点 ),之后只调整分区到物 理节点的映射关系 (即只会 迁移整个分区⽽不分裂分 区 ) - 简洁实⽤ - 分区数量规划原则 > 10x 最⼤物理节点数 因⼦数多 (60, 3600) 60 = 60 * 1 = 30 * 2 = 20 * 3 = 15 * 4 = 12 * 5 = 10 * 6 = 6 * 10 = 5 * 12 = 4 * 15 ⺴易 DDB 数据迁移 (1) • DDB数据迁移算法历程 - 第⼀代:通过分布式事务进⾏细粒度迁移,迁移中的分区要合并源和 ⺫的结果 性能极差,⼤量死锁,完全不可⽤ - 第⼆代:禁⽌待迁移分区的访问 性能不错,但影响可⽤性 - 第三代:基于 MySQL复制实现⼀分为⼆扩容 在线迁移,不影响可⽤性,性能不错,但伸缩模式受限 - 第四代:基于 MySQL交叉复制实现多对多伸缩 在线,性能不错,伸缩模式灵活,但操作复杂 数据迁移 (2) • 基于复制的⾼性能在线数据迁移 - 分区数据隔离(推荐) 在⺫的节点建⽴待迁移分区数据的复制,等待复制同步后,修改路由信息 - 分区数据融合 在⺫的节点建⽴源节点的复制, 等待复制同步后,修改路由信息,⽽后清理不需要的分区数 据 • 路由表版本号 - 同步修改缓存于所有客户端的路由表困难怎么办? 为路由表设置递增的版本号,迁移时增加源节点的路由表版本号 客户端请求源节点,发现路由表版本不匹配,同步路由表后正确路由⾄⺫的节点 ⽆迁移扩容 • PB级以上存储需要采⽤⽆迁移扩容 • 元数据库 - 对象级元数据记录存储位置,元数据与数据分离。数据扩容⽆需迁移,元数据扩容仍需迁移但 数据量⼩ - 案例:⺴易 NOS,元数据使⽤⺴易 DDB,数据使⽤⺴易 SDFS - 凡是没有元数据的海量存储都是耍流氓 • 分区预留 - 案例:⺴易 DFS/SDFS ⽂件访问键由系统分配 ⽽不是应⽤程序指定,因此 访问键中可以包含分区号 事先规划好 65536个分区,但不⽴即启⽤ 增加⼀个物理节点时,启⽤⼀批分区分配给该物理节点 系统⽣成⽂件的访问键时,使⽤新分配的分区号 - 适⽤范围 访问键由系统分配且可包含分区号 负载在初始分配完成后基本不变 ⾼可靠可⽤设计模式 可靠 /可⽤性数据 • 软件 /OS故障: >10% • 硬盘故障: 8%(参考 Google报告 ) • 内存 /⺴卡等故障: 1% • 交换机故障: <1% 可靠性计算 :复本 • 多复本系统综合可靠性 (近似 ): P = pr×tr-1/dr-1 - p:单个设备的故障率 - d:故障率周期 - t:故障恢复时间 - r:复本数 • 增加复本数对提⾼可靠性最有效 • 复本数⼀定时 关键在于加快恢复速度 可靠性计算 :组合 • 组合系统的综合可靠性: P=1-(1- p)n≈np(np⋘1) - p:单个设备的故障率 - n:组合包含的设备数,即组合规模 • 扩⼤组合规模伤害系统可靠性 ,故障率 随组合规模线性增⻓ - 不建议做很多块磁盘组合的 RAID 0或 RAID 1+0 可靠性三原则 • 增加复本 • 加快恢复 • 避免组合 复本分布与规模效应 d d’ ⋮ d d1 d2 d3 d4 d100 ⼀对⼀复制 磁盘容量 : 900GB 恢复带宽 : 20MB/s 恢复时间 : 45000s 可靠性 : 99.999% ⼀对多复制 磁盘容量 : 900GB 恢复带宽 : 2000MB/s 恢复时间 : 450s 可靠性 : 99.99999% • 分布式⼀对多复制以进⾏ 并⾏快速恢复是提⾼数据 可靠性的良策; • 在⼀定规模范围内 (如 <200节点 ),恢复并⾏度 只取决于集群规模。恢复 时间与集群规模成反⽐; • 云计算的数据可靠性规模 效应。 集群可靠性 • PB级本机 RAID 1可靠 性可以接受 • 10PB级分布 式 2复本可靠 性可以接受 有效容量 集群规模 磁盘数 数据恢复 速度 (MB/ s) 年丢数据 概率 本机 raid 1 本机 raid 1 分布式 2复本 分布式 2复本 1PB 50 500*2 20 1.01% 10PB 500 5000*2 20 9.65% 1PB 50 500*2 20*20 0.05% 10PB 500 5000*2 20*200 0.5% 案例 : 云硬盘 (1) C1 C1’ C2 C2’ Cn Cn’ md-raid md-raid md-raid device-mapper volume 1 ⋯ ⋯云硬盘 物理硬盘 • ⼀个云硬盘划分为多个 chunk • 每个 chunk含两个复本 • 每个物理硬盘存储来⾃于多个云 硬盘的 chunk 案例 : 云硬盘 (2) • chunk⼤⼩多⼤最好 ? - ⼩ chunk,恢复时间短 - ⼤ chunk,受影响的云硬盘数量少 (组合规模⼩ ) • 结论:增加 chunk⼤⼩时, 可靠性稍有下降,但幅度较 ⼩,设计时可忽略chunk⼤⼩ (GB) 坏盘概率 多复本读写 • 读⼀写全 (WARO, write-all-read-one) • Quorum读写 • 热备 读⼀写全 • 机制 - 使⽤两阶段提交保证终 态⼀致 复本故障时⽤另⼀复本同步 - 加锁以保证更新期间读 取到⼀致数据 若不⽤多版本将导致更新期间 不可读 • 分析 - 需要⾼可靠系统存储协 调者⽇志 - 可⽤性差 客户 协调者 复本 1 复本 2 1、写请求 2.1、写请求 2.2、写请求 3.1、加锁 4.1、写 3.2、加锁 4.2、写 5.1、 ACK 5.2、 ACK 6、写 PREPARE⽇志 7.2、 COMMIT 7.1、 COMMIT 8.1、放锁 8.2、放锁 9.1、 ACK 9.2、 ACK 10、清 PREPARE⽇志 11、 ACK Quorum读写 • 基本规则 - 复本数 N,写 W个复本,读 R个复本 - 保证 W+R>N • 基本规则可保证最终⼀致, ⽆法 保证强⼀致 - ⽆法区分更新成功还是失败 • 强⼀致规则 - 前⼀个更新成功后才可以执⾏后⼀个更新(不易实现) - ⼀直读取到版本号最⾼复本的 W个复本,若最终少于 W 个则判定更新失败 • 评价 - ⾄少需要 3复本,读效率低 v2 v2 v2 v1 v1 v1 v1 v2 v1 v1 热备 • 故障处理 - SLAVE故障,中断复制,暂时退 化为单复本,⽽后重建 SLAVE SLAVE复活,从断点继续复制 - MASTER故障,暂时退化为单复 本,提升 SLAVE为新 MASTER, ⽽后重建新 SLAVE MASTER复活,成为新的 SLAVE • 评价 - 牺牲暂时的可靠性,换取写效 率与可⽤性 - SLAVE不可承担⼀致性读 客户 MASTER SLAVE 1、写请求 3、写请求 5、 ACK 2、加锁,写,不提交 6、提交 7、 ACK 4、写并提交 单主与租约 (1) • 故障检测不可能性 - ⽆法判断服务故障还是检测者与服务器之间⺴络故障 • 案例:⺴络故障导致双主 - 初始状态,所有客户端连接到 MASTER - MASTER与控制中⼼间⺴络故障,控制中⼼认为 MASTER已故障(其实还活着),启⽤ 新 MASTER’ - 部分客户端仍连接到 MASTER,部分连接到 MASTER’ 客户 1 客户 2 MASTER MASTER’ 控制中⼼ 单主与租约 (2) • 机制 - 服务节点持续向控制中⼼申请短时间租约 (Lease,⼀般 10s) - 控制中⼼在已派发的租约过期之前,不启⽤新服务节点 - 服务节点租约过期时若还⽆法从控制中⼼申请到新租约,⾃⼰中断客 户连接 (⾃杀 ) • 评价 - 易于实现 - 依赖于⾼可⽤控制中⼼服务(通常⽤ ZooKeeper) 可⽤性受⼀定影响,但由于⼤⾯积⺴络故障罕⻅,可⽤性⼀般能满⾜需求 低成本模式 常⻅问题 • 怎么降低存储成本? • 应该⽤什么存储介质? • 要不要加缓存?缓存要多⼤? • 性能不⾜时,加内存还是磁盘? IOPS/GB准则 • 最优单⼀存储介质只 取决于 - 应⽤ IOPS/GB特征 - 各类介质的每 GB成本 - 各类介质能提供的 IOPS/GB性能 • 使⽤某存储介质时的 每 GB成本 - 若应⽤ IOPS/GB<介质 IOPS/GB = 介质每 GB成本 - 若应⽤ IOPS/GB>介质 IOPS/GB = (应⽤ IOPS/GB / 介质 IOPS/GB) * 介质每 GB成 本 介质 $/GB 介质 IOPS/ GB 适⽤应⽤ IOPS/GB SATA SAS SSD 内存 0.1 0.05 0~0.3 0.6 0.33 0.3~0.825 1.5 10 0.825~100 15 >10000 >100 多级存储与缓存 (1) • 案例 1: 设存储分 10%热数据 (IOPS/GB = 0.5)和 90% 冷数据 (IOPS/GB=0.06),综合 IOPS/GB=0.104 - 使⽤单⼀存储 SATA:每 GB成本 =0.104/0.05*0.1=0.208 - 使⽤⼆级存储,热数据⽤ SAS,冷数据⽤ SATA:每 GB成本 =0.1*(0.5/0.33)*0.6+0.9*(0.06/0.05)*0.1=0.199 - 使⽤ SATA存储,但⽤ SSD缓存热数据:每 GB成本 =0.1*(0.5/0.3)*0.6+1*((0.9*0.06)/ 0.05)*0.1=0.199 • 案例 2:设存储分 10%热数据 (IOPS/GB = 0.5)和 90%冷 数据 (IOPS/GB=0.03),综合 IOPS/GB=0.077 - 使⽤单⼀存储 SATA:每 GB成本 =0.077/0.05*0.1=0.154 - 使⽤⼆级存储,热数据⽤ SAS,冷数据⽤ SATA:每 GB成本 =0.1*(0.5/0.33)*0.6+0.9*0.1=0.181 - 使⽤ SATA存储,但⽤ SSD缓存热数据:每 GB成本 =0.1*(0.5/0.33)*0.6+1*0.1=0.191 多级存储与缓存 (2) • 采⽤多级存储或热点数据缓存是否⼀定能降低系统 成本? - 缓存过剩 (或热点数据存储容量过⼤ )时反⽽增加系统成本 (案例 2) - 缓存严重不⾜时,虽然能降低系统成本,但达不到最理想的效益 • 缓存容量经验法则 (近似 ) - 冷数据访问 IOPS/GB<介质 IOPS/GB:缓存过剩 - 冷数据访问 IOPS/GB>介质 IOPS/GB:缓存不⾜ - 冷数据访问 IOPS/GB=介质 IOPS/GB:缓存合适 • 热点数据较少时,缓存与分级存储成本接近,⽽缓 存更易于实施,⼯程实现往往实现缓存⽽⾮分级存 储 常⻅问题解答 • 怎么降低存储成本? - 通⽤⽅法是选⽤合适的存储介质,且可区分热点与⾮热点数据,使⽤缓存或多 级存储 • 应该⽤什么存储介质? - 统计应⽤访问 IOPS/GB特征,结合各介质没 GB成本和 IOPS/GB能⼒计算 • 要不要加缓存?缓存要多⼤? - ⽐较访问 IOPS/GB与冷数据介质 IOPS/GB,调整缓存容量使⼆者接近 • 性能不⾜时,加内存还是磁盘? - 同上经验法则 其它成本优化⽅法 • 压缩 - 除了 zlib,可以尝试 lzo、 snappy等计算效率更⾼的压缩算法 • 去重 - 对象级 md5去重:相册 /邮箱⼤附件去重率 20-30% - 分块去重:最好基于内容(搜索哈希值符合某⼀特征的内容⽚段作为边界)⽽不是固定分块 相册实验结果对象级去重与内容分块去重效果差别很⼩ • 纠删码 - n块内容编码为 n+k块,只要读取任意 n块即可解码 - 理论上可以⽤很⼩的存储代价实现⾮常⾼的数据可靠性(如 10+2配置, 20%开销,可靠性等效于 3复本), 但恢复时的带宽消耗⾮常⾼,分布式环境难实⽤(希望万兆⺴络普及) - 极度放⼤随机读写 IOPS,从⽽影响性价⽐ • 升级硬件 - ⽼旧低性能服务器机架托管成本很⾼ - ⼀般推荐 4-5年替换 升级周期计算 • 计算公式 - 设: P=初始价格 ;T=托管价 格 ;Y=折旧年限 ;g=年性能增 ⻓率 • 典型数据 - P=1 - T=0.1 - g=0.6 折旧年限 TCO 进阶阅读 《分布式基础》学习计划 @⺴易云课堂 http://study.163.com/plan/planIntroduction.htm?id=272067#/planDetail Q/A?

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享文档获得金币 ] 0 人已下载

下载文档

相关文档