高可用
存储高可用
问题：主要是副本冗余实现高可用
- 数据如何复制
- 各个节点的职责是什么
- 如何应对复制延迟
- 如何应对复制中断
主备复制
详细设计
- 1.主机存储数据，通过复制渠道复制给备机
- 2.正常情况下，所有的请求直接发给主机，备机只做数据的备份不提供任何的读写
- 3.主机出现故障的情况下，所有的请求不会发送到备机，整个系统处于中断状态，不可读写数据，但数据并没有全部丢失，备机还存在数据备份
- 4.主机恢复后，读写继续访问主机，主机数据继续复制给备机
- 5.如果主机不可修复，可通过人工备机升为主机，但是为了保持主备，需要新增机器
- 6.主机不可恢复情况下，可能存在数据只到主机还未复制到备机的情况，此种数据就需要人工修复，业务也需要考虑改情况
- 7.复制可能存在延迟，但是备机不提服务，所以不会影响系统，但是若存在大量数据未同步，突然主机不可修复，会损失大量数据，所以不可掉以轻心，需要添加监控，若存在延迟过大需要人工介入
优点
- 客户端无感知，只需要回复后进行重新连接
- 只需要数据同步，不需要进行机器的状态判断和倒换
缺点
- 备机只提供备份，不提供读写，造成成本浪费
- 故障后需要人工干预，无法自动恢复
主从复制
详细设计
- 1.主机存储数据，通过复制渠道复制给备机
- 2.写操作发给主机，读操作则根据业务进行发给主机还是从机
- 3.主机故障的情况下，客户端不可写入数据，读操作可以发给从机是不影响读数据。适用于读操作较多的场景如新闻网站
- 4.如果主机恢复后，写操作还继续访问主机，主机数据绩溪复制到从机
- 5.如果主机不可修复，可通过人工从机升为主机，为了保持主从需要添加新主机
- 6.主机不可恢复情况下，可能存在数据只到主机还未复制到备机的情况，此种数据就需要人工修复，业务也需要考虑改情况
- 7.主从之间可能存在同步延迟，导致读取主从数据不一致问题，若是需要强一致性，则需要直接读取主机
优点
- 主机出现故障时读操作不会受到影响
- 从机提供读，发挥了硬件的性能
缺点
- 客户端需要感知主从，不同的命令发送到不同的机器
主备倒换和主从倒换
主从/主备的共性问题
- 主机故障不能写操作
- 如果主机无法恢复则需要人工参与
考虑的关键点
- 状态判断
- 状态传递渠道：相互连接还是三方仲裁
- 状态检测的内容：机器能够正常提供服务
- 倒换决策
- 倒换时机：什么时候倒换，是主机停机 3s 还是其他参数
- 倒换策略：主机恢复后还是主机还是恢复后变为从/备机
- 自动程度：全自动还是半自动（人工确认）
- 数据冲突
- 同步中主机出现故障导致主机和从/备机数据不一致问题怎么处理
常见架构
- 互联式：主备/主从相互连接
- 问题：需要主、备、客户端左右做修改；连接通道出现问题就会出现多主或多从问题，若是多种连接通道就会浪费资源
- 中介式：引入中介方，MongDB 就是这种模式
- 优点：实现简单，只需要中介读取主从节点，然后根据状态进行确定各方是否主备情况
- 缺点：为了保证中介方高可用就会引入新的问题
- 开源中介 ZooKeeper
- 模拟式：从节点模拟客户端访问主节点
- 优点：实现更简单省去连接通道和状态管理
- 缺点：基于有限状态做决定，可能出现偏差
主主复制
详细设计
- 1.两台主机都存储数据，通过复制通道将数据复制到另外一台主机
- 2.正常情况下，客户端可以将读写操作发送给任意一台主机
- 3.一台主机故障情况下，客户端只需要把读写操作发送给另一个主机
- 4.如果故障主机恢复，客户端继续访问两台主机，两台主机之间互相复制对方数据
- 5.如果故障主机不能恢复则需要人工添加一台新的主机
- 6.存在某个主机写入数据后还未同步至另一台主机，该主机崩溃导致的书记丢失，需要考虑此风险
- 7.存在同步延迟，可能写入了A，在B上读取不到刚刚写入的数据
优点
- 两台都是主机，不存在倒换概念
- 客户端无需分辨不同角色的主机，随便将读写操作发送给哪台主机都行
缺点
- 部分数据不能双向复制，例如库存，A-1 和B-2双向复制会导致数据错误
数据集群
集中集群：每个节点的数据都是完整的一份
- 需要考虑的
- 主机如何将数据复制给备机
- 备机如何检测主机状态
- 主机故障后，如何决定新的主机
分散集群：每台服务器都会负责存储一部分数据，为了提升硬件利用率，每台服务器又会备份一部分数据
- 需要考虑的
- 均衡性
- 容错性
- 可伸缩性
分布式算法
分布式一致性算法
- Paxos算法
- Raft算法
- ZAB算法
数据分区
数据量，数据量越大分区规则越复杂
分区规则
复制规则
- 集中式：数据统一复制到总的备份中心
- 互备式，节点之间相互备份
- 优缺点
- 设计比较复杂
- 扩展麻烦
- 成本低，可以直接利用已有的设备
- 优缺点
- 独立式：每个节点有自己的备份节点
- 设计简单，各分区互不影响
- 扩展容器，新增分区只需要搭建自己的备份中心即可
- 成本高
计算高可用
设计关键点
- 哪些服务器可以执行任务
- 任务如何重新执行
主备
详细设计
-
- 主机执行所有的计算任务
- 2.当主机故障时，任务分配其不会自动将任务发送给备机，此时系统不可用状态
- 3.如果主机能够恢复，任务分配器继续将任务发送给主机
- 4.如果主机不能恢复，则人工将备机升级为主机，需要添加新主机做备机
细分
- 冷备：备机启动状态，但是未启动业务系统，当备机升级为主机时，启动业务系统
- 温备：业务系统已经启动，但是不对外服务，当备机升级为主机时，让它正式提供服务
主从
详细设计
-
- 一般情况下，主机执行部分任务，备机执行部分任务
-
- 当主机出现故障时，任务分配器不会自动的将原来发给主机的任务发给从机，而是继续发送给主机，不管这些任务执行是否成功
- 3.如果主机能够恢复，任务分配器继续将任务发送给主机
- 4.如果主机不能恢复，则人工把原来的从机升为主机，然后添加新的主机为从机
优点
- 主从架构的从机也执行任务，发挥了硬件的性能
缺点
- 主从架构需要对任务进行分类，任务分配器会更复杂一些
根据节点角色分类
- 解决的问题：从或主备，人工效率低，容器出错，不能及时处理故障
- 对称集群(负载均衡集群)：所有节点的角色一致
- 详细设计
- 1.正常情况下，任务采取某种策略（轮询、权重、资源）等方法，将任务分配到集群中的不同服务器
- 2.当某台服务器出现故障，任务不再将任务分配给该机器，转而分配给其他的服务器
- 3.当故障的服务器恢复后，任务将再次分配给该机器
- 详细设计
- 非对称集群：分角色master-slave
- 详细设计
-
- 集群会通过某种方式区分服务器的不同角色，例如 Paxos 算法选举或者简单的 id 最小的为 master
- 2.任务分配器将不同的任务分配给不同的角色
-
- 复杂度的体现
- 1.任务分配的策略更加复杂
- 2.角色分配更加复杂
- 详细设计
业务高可用
异地多活
两个标准
-
- 正常情况下用户访问不管哪一地点的业务系统，都能够得到正确的业务服务
- 2.某地异常的情况下， 用户访问到另一地点的业务系统，也能够得到正确的业务服务
两个代价
- 1.系统的复杂度会发生质的变化
- 2.成本会上升
架构
- 同城异区：相比设计和实现的降低了复杂度和成本，但是同城天灾时出现都不可用的概率增大
- 跨城异地：相比同城天灾影响的概率降低，但是由于存在网络延迟等问题，相关成本大大增加
- 跨国异地：成本最大
使用场景
- 为不同的地区提供服务
- 只读类做多活
技巧
- 同城异区：网络延迟较低可以不用考虑设计
- 跨城异地：主要网络延迟导致的数据不一致问题，架构是需要考虑
- 跨国异地：为不同的地区提供服务和只读所以对系统的设计并不多
- 技巧一：保证核心业务的异地多活
- 技巧二：核心数据最终一致性
- 减少异地多活的距离，搭建高速网络
- 尽量减少数据同步，只同步核心数据
- 保证数据最终一致性，不保证实时一致性
- 技巧三：采用多种数据同步手段
- 消息队列方式
- 二次读取
- 存储系统同步方式
- 回源读取方式：优先访问上次请求的主机
- 重新生成数据方式
- 技巧四：只保证绝大部分用户的异地多活
设计步骤
- 1.业务分级
- 访问量大的业务
- 核心业务
- 产生大量收入的业务
- 2.数据分类
- 数据量
- 唯一性
- 实时性
- 可丢失性
- 可恢复性
- 3.数据同步
- 存储系统同步方式
- 消息队列方式
- 重新生成数据方式
- 4.异常处理
- 目的
- 避免少量数据导致整体业务不可用
- 问题恢复后，对异常数据进行修复
- 对用户安抚，进行补偿
- 措施
- 多通道同步
- 一般采用两个通道，再多成本较高
- 通道尽量隔离，如使用同一个网络，若出现网络问题则都不可用
- 需要数据覆盖，无论走哪一通道最后结果一致
- 同步和访问结合
- 接口访问和数据同步不要走同一个网络
- 数据有路由规则，可以通过数据确定需要访问哪个去补偿
- 优先本地数据，其次远程调用，可以节省大量的调用
- 日志记录
- 服务器上保存日志
- 本地独立系统保存日志
- 日志异地保存
- 用户补偿
- 多通道同步
- 目的
接口级的故障应对方案
降级：减少功能
- 系统后门降级：通过参数设置变量控制降级
- 存在安全问题
- 主机多的情况需要操作多次，效率低
- 独立降级系统：解决系统后门降级的问题，把所有的降级抽取为一个服务进行管理
熔断：外部依赖的系统存在故障时，要熔断防止影响该系统
限流：防止用户访问过于频繁，通过限流降低短时间内访问次数
- 基于请求限流
- 基于资源限流