25 | 高可用存储架构：双机架构

政府信息网站使用主备或者主从架构就可以了。信息都是人工录入，可以补录。数据本来对实时性要求不高，所以出了故障人工修复也来得及。所以主备就够了，如果为了照顾形象可以用主从，保证主机故障后仍然可以查，不能新发

政府信息公开网站的特点： 1、用户量和QPS不会很大 2、其次读/写都非常少，读相较于写多 3、可忍受一定时间范围的不可用 主主架构因其固有的双向复杂性，很少在实际中使用；再加上此场景并不适合用主主架，故排除使用它。 根据第3个特点就可以排除使用双机互换架构。 对于主备架构来说，主机正常时，备机不提供读写服务，比较浪费。 综合来看，选择主从的存储架构。

单机就可以了，搞那么复杂

复制延迟和复制中断的数据不一致的解决方案好像没看到

中介式相对于互联式来说有如下优势:一是状态决策更加准确。举个例子，在互联模式下如果连接中断则无法判断对方的状态，切也不是，不切也不是；而在中介模式下一方连接中断（无论是主机和中介中断还是备机与中介中断）仍然能够做出决策，就连接来说多了一条冗余判断的方式，毕竟两个连接同时中断的概率更小。如果用上节课介绍的FMEA方法逐个分析的话，会发现中介模式可以解决更多的故障模式。二是将状态决策的逻辑解耦，主备只需要上报状态不需要承担状态的决策，状态决策的逻辑全部由中介来负责，并且可以灵活定制决策逻辑。         模拟式相对于互联式来说走一下不足:一是提供的判决依据不够；二是信息不正确，模拟读写操作可能已经完成了但是由于网络拥塞的原因不能及时返回。而互联式有独立的状态通道可以保证传输优先级。         一个政府信息公开网站的信息存储系统，从场景上来看分为管理员发布信息和人们查看信息，这些信息基本上都是严肃的官方的非临时信息，因此主主模式不合适；同时这些信息基本上都是读多写少，平时更新频率不高，因此考虑主备或主从。从业务要求上看整体的TPS和实验要求不高，因此考虑主备即可，同时即使主集群宕机了能够在半天内恢复问题不大（毕竟这些网站不是经常使用的），这也就不需要做状态检测了。因此综合来说选择主备无状态检测的方案。

数据持久化信息我可能会选择主备模式，备机主做数据备份不提供读写操作。 添加一个redis缓存全量信息数据，做一个哨兵模式，实现故障切换，提高网站的可用性 应用上再使用个Ehcache堆外缓存，主要把热点信息放到应用里提升性能. 这样做相对主从模式，读并发压力过大时，扩容更容易

老师，主备负责方案，主挂了的时候，系统就会有一段时间不可用了吧？怎么样人工把备机改成主机呢，应用是不是还要修改数据ip的配置呢，具体怎么操作能不能详细说一下？

双机切换架构里面的中介模式是由db连接到中介，而后中介告诉它应该是主还是备，这种模式下要求db能够根据中介的返回结果实时的修改自己的模式，同时当客户端请求类型和当前模式不匹配时返回调用失败。对于mongo db原生支持还是可以，如果是原生不支持的db，是不是改为客户端直接链接中介，根据请求类型获取对应的db ip可用性更好些，如同zookeeper？又或者mongo db采用客户端直接链接中介是否也可以？因为中介模式本身对中介的高可用要求也比较高。

关于主主互相复制相关的有没有进一步讲解。

老师我是这么理解的，数据库主从实现读写分离保证了数据库的高性能，但是没有保证数据库的高可用，主机崩掉后，数据库不在提供写服务，而从库只能进行读操作，拒绝写服务。所以需要在主从之间加入主从切换的规则，当主机崩掉后，从机可以进行自主升为主机，从而保证高可用，这种机制就可以保证数据库的高性能和高可用，但是感觉这种复杂度太高了，真的会使用这种架构吗？