架构师训练营第六周学习总结

关注
发布于: 2020 年 07 月 15 日
本周的学习结束了, 和上周的内容一样, 这周的知识密度也比较大。和上周操作系统层面知识的缺失，这周则完整地体会了分布式存储系统层面的架构知识和设计方案。
重点内容总结分布式数据库MySQL传统的关系型数据库是通过复制来做到性能伸缩和高可用的。拿 MySQL 关系型数据库举例:
MySQL 主从复制
使用 MySQL 只从复制的架构方案之后, 来自于应用的写请求由主数据库服务器执行。 主服务器接收到写请求之后主要有如下的流程发生：
主服务器上面的任何修改都会通过自己的 I/O tread(I/O 线程)保存在二进制日志 Binary log 里面。
从服务器上面也启动一个 I/O thread，通过配置好的用户名和密码, 连接到主服务器上面请求读取二进制日志，然后把读取到的二进制日志写到本地的一个Realy log（中继日志）里面。
从服务器上面同时开启一个 SQL thread 定时检查 Realy log (这个文件也是二进制的)，如果发现有更新立即把更新的内容在本机的数据库上面执行一遍。
每个从服务器都会收到主服务器二进制日志的全部内容的副本, 由于每个从服务器都分别记录了自己当前处理二进制日志中的位置，因此可以断开从服务器的连接，重新连接然后恢复继续处理。
MySQL 一主多从
一主多从的架构下, 数据库主服务器和从服务器之间的数据复制原理和 MySQL 主从数据复制的原理一致。
MySQL 一主多从复制有如下的优点:
分摊负载: 主服务器接收来自于客户端的写请求, 从服务器接收来自于客户端的读请求
专机专用: 可以在不同的从服务器上进行不同功能范围内的读操作, 比如说报表数据统计和业务数据读取的功能使用不同的从数据库
便于冷备: 在从服务器上做数据备份，这样不影响主服务器的正常运行
高可用: 数据存在多个镜像和数据冗余，可以防止单一主机的数据丢失，提高数据的安全性
MySQL 主主复制
两台 MySQL 之间互为彼此的从库，同时又是主库。这种方案，既做到了访问量的压力分流，同时也解决了 "单点故障" 问题。任何一台故障，都还有另外一套可供使用的服务。
MySQL 主主复制通过下面的示意图进行失效恢复:
﻿
MySQL 复制的注意事项:
主主复制的两个数据库不能并发写入, 主主复制一般作为灾备方案, 对外提供服务的只有其中的一个主服务器
复制只是增加了数据的读并发处理能力, 没有增加写并发能力和存储能力
更新表结构会导致巨大的同步延迟
MySQL 数据分片
MySQL 通过数据分片提升写并发能力和数据的存储能力, 它把数据分割为一个小片或者一块，然后存储到不同的节点上。数据分片一般会对数据增长的非常庞大的数据进行分片。
数据的分片的实现方式有如下几种:
应用程序硬编码
这种分片的实现方式最大的特点就是实现简单, 缺点也比较明显: 分片的规则耦合在代码中; 分片所在的服务器规模增加或者分片规则更改时, 分片规则的更改复杂。
分片映射表
分片规则映射表解决了应用分片规则硬编码方法中分片的规则耦合在代码中和分片规则更改复杂性的问题，但是也不是一个完善的方案，它也有如下的缺点：引入了映射表本身的高可用问题；映射表可能成为分片数据读写性能的瓶颈。
使用分布式数据库中间件
使用数据库中间件访问数据分片，是目前分布式系统实现数据库分片存储和访问的主流方式。
使用分布式数据库中间件做数据迁移
在系统规划的时候就做好数据分片数量的规划, 在增加数据库实例的时候, 将数据分片迁移至新的数据库实例后配置数据库中间件按照新的分片存放规则访问数据分片。
CAP 定理一致性 (Consistency): 每次读取数据的时候都应该是最近写入的数据或者返回一个错误, 而不是过期数据
可用性 (Availability): 每次请求都应该得到一个响应, 而不是返回一个错误或者失去响应, 不过这个响应不需要保证数据是最近写入的, 也就是说系统需要一直都是可以正常使用的, 不会引起调用者的异常, 但是并不保证响应的数据是最新的
分区容忍性 (Partition tolerance): 即使因为网络原因, 部分服务器节点之间消息丢失或者延迟了, 系统依然是可以操作的。
分布式一致性协议分布式一致性协议主要解决如下问题:
由于网络故障或者集群节点之间的通信链路有问题，导致原本的一个集群被物理分割成为两个甚至多个小的、独立运作的集群，这些小集群各自会选举出自己的主节点，并同时对外提供服务。网络分区恢复后，这些小集群再度合并为一个集群，就出现了多个活动的主节点。
分布式一致性算法: Paxos
﻿
总结本周的重点在分布式一致性协议, 课后还需要结合老师分享的例子和讲解的分布式组件的架构进行理解。
﻿