存储类问题处理框架图
故障：机器挂掉
灾难：自然灾害
多活：技术复杂度高、成本高
高可用的关键指标
stag1是正常状态，系统和业务都是正常的
stag2是故障状态，系统和业务都是异常的
stag3是系统恢复正常，但是此时业务异常
stag4是系统和业务都是正常的
RPO的时间内数据应该是丢了。
主备&主从架构
这类架构需要人为进行介入处理
本质：就是通过搭建多台机器来解决这个问题的
要想将备机变为主机或者将从机变为主机需要人为的切换
主备复制是增加一个备机，用来做备份，主从在备份基础上还有一个提升读性能的作用，所以如果读性能没有瓶颈，那么主备也能完成任务了。
根据变化，可以产生如下情况：
主备级联复制
这种场景应用不多，复制能够节省的性能不多，延迟也会比较大
主备主从架构的灾备部署
主备和主从架构可以结合起来形成高可用架构方案
案例学习-Redis
上图redis是主从架构
双机切换架构
这类架构可以实现数据系统自动恢复，不需要认为介入处理，RTO低
双机切换-主备切换
双机切换-主从切换
这两种模式，比较适合内部系统、管理系统，一是数据量少，第二数据丢了可以人为恢复。即使影响到了，也只是影响内部，不会影响到业务系统。
集群选举
集群选举案例-Redis vs MongoDB
sentinel本身就是一个集群
Bully vs Raft vs ZAB vs Paxos
最佳实践-基于ZooKeeper实现
不需要理解paxos，不需要实现paxos，只需要基于Zookeeper就好了。
Zookeeper自己是民主式的，但是基于Zookeeper来做主节点选举就是独裁式的，因为一切都以Zookeeper为准。
本节思维导图
