架构-4.高可用架构之存储高可用

架构-1:高性能架构之读写分离和分表分库
架构-2:高性能架构之NoSQL和缓存
架构-3:高性能架构之单机高性能和负载均衡
架构-4:高可用架构之存储高可用
架构-5:高可用架构之Paxos和Raft
架构-6:高可用架构之一致性哈希算法和数据分片
架构-7.高可用架构之接口级故障

架构的复杂度来源-高可用

高可用是指系统不会轻易的挂掉，这里的“高”是指不可能达到100%的可用性，或者说100%的可用性成本非常高，所以一般用4个九5个九表达高可用，其实就是指99.99%的可用性，99.999的可用性。
相对于高性能，高可用要复杂得多。因为高性能只需要考虑性能。而高可用必须得考虑可用性，一致性和分区容忍性

CAP和Base

CAP原则，CAP分别指C（一致性），A（可用性），P（分区容忍性）。这三个要素最多只能实现两点，不可能三者兼顾。平衡这三者得关系，就是其复杂度来源。

• 可用性：非故障的节点在合理的时间内返回合理的请求（非错误或超时）
• 一致性：从客户端的角度，读操作都能够返回最新的写操作。
• 分区容忍性：但网络出现分区时，系统能够继续履行职责。
  所谓分区是指，当服务器集群因为网络的原因，导致分成了多个隔离的区域，如一主三备的服务器集群，分成了独立的两个服务集群，这个时候会出现两个主机（其中两个备机的区其中一个升级为主机），这个时候对于客户端来是迷惑的，最终可能导致两个主机的状态不一致。这种状态备称为脑裂。

脑裂原指人的一种脑损伤疾病：
如果人的左右脑因为损伤导致不能互相通信，那么一个人的脑袋可能会对身体发出两个截然相反的命令。比如左腿向前走，右腿向后走。

Base可以说是对CAP的一种妥协，CAP是理想状态下的设定，CAP要求强一致性，强可用性，但是网络是有延迟的，所以一定存在不一致，且部分业务条件并不需要强一致性，经过一段时间达到一致性也是可以的。

• 基本可用：Base不要求100%的可用性，因为成本太高了。甚至只要保证主业务可用就可以了。甚至特殊情况下，对于非核心业务，都可以放弃
• 软状态：允许出现中间状态，比如转账的过程中，用户的钱已经被冻结，但是收钱的用户还未收到钱。
• 最终一致性：经过一段时间后，系统的状态最终达到一致：如最终收钱的用户收到钱，

双机架构

• 主备
  主备是指一台主机负责读写操作，一台备用机。备用机不使用，如果是数据节点，只负责备份数据，当主机异常时，切换到备用机以避免功能不可用。
• 主从
  主从指主机负责写功能，而从机负责读功能。这样即使主机挂了，读功能也可以正常使用，通过切换写功能到从机，也可以实现主备的功能。

双机切换常用架构

双机架构的复杂度来自于发生故障时，切换到备/从机。关键的问题在于，如何确认主机的状态。

• 互联式：主备进行状态传递，如使用网络。这种方式实现简单，但是如果主机没有挂，只是主备之间的连接丢失了，那么可能会出现两台主机而导致数据不一致。
  

• 中介式：主备的状态上传到中介服务器，由中介服务器来进行判断，当需要升级备机为主机时，同时会发送主机降级为备机的命令，防止出现多台主机。缺点是，中介必须保证高可用，这陷入了一个无限递归陷阱。
  

• 模拟式：备机模拟成客户端访问主机，当不能访问时，说明客户端也不能访问，这个时候升级成主机，就不会出现多个主机的问题。这种方式实现也简单，但是传递的状态信息就没有使用专门的状态传递那么多。
  

• 主主复制：指两台都是主机，都可以进行读写。两台主机之间进行双向复制。好处是，不需要切换，客户端也不需要区分服务端角色。缺点是，并不是所有的数据都可以进行双向复制，比如用户自增的ID，库存等。
  

数据集群

数据集群要比双机架构要更复杂，但是可用性也更高。相对于双机架构，数据集群则是由更多台机器组成。一般是一主多从或者一主多备。

数据集中集群

数据集中集群是指所有的服务器的数据都是一样的。关键的问题在于，主机故障后，如何决定新的主机。决策主机的算法有Paxos（ZooKeeper的zab算法就是改算法的一种实现）和Raft算法（Redis的哨兵实现）。
参考另外一篇文章《架构-5.高可用架构之Paxos和Raft》

另外一个问题就是，如何把数据复制给备用机。如果所有的备机都直接从主机复制，会导致主机的读压力比较大。也可以使用链式的方式，即备机1复制主机，备机2复制备机1，以此类推。但是这样会导致可用性降低，复制的通道延长了，如果中间的备机挂了，会导致后面的备机无法同步数据。

数据分散集群

数据分散集群是指把不同的数据均匀的分布在集群中的不同机器，比如redis的集群可以把数据分布在redis集群中的机器中。优点是，扩大了容量，像redis这种完全靠内存的服务，单机内存无论如何都是支持不了的。另外的一个优点就是提高了可用性，每台服务器除了保存自己的数据，还会保存一部分其他服务器的备份。这样即使某台服务器挂了，整体还是可用，还可以通过备份恢复数据。
需要考虑的问题是：

• 均衡性：如何把数据均衡分布在集群中，不能出现某台机器拥有大部分的数据。
• 容错性：某台服务器故障之后，如何将其数据分配给其他服务器
• 可伸缩性：当集群容量不足时，能否便捷的加入新的机器，并保证扩容后的均衡性
  一般可使用一致性哈希算法来实现，而redis则是使用数据分片的方式实现。
  参考另外一篇文章《架构-6.高可用架构之一致性哈希算法和数据分片》

数据分区

数据集群考虑的是机器级别的损坏，而数据分区考虑的是容灾，比如地震，火灾等情况导致机房全部被毁。一般会考虑同城灾备和异地多活结构。同城灾备可以防止机房级别的灾难，比如火灾，由于同城，距离较近，可以搭建高速网络实现备份。但是同城灾备无法防止大型的灾难，比如地震等。而异地多活则是考虑在多个城市（距离远）进行备份。由于距离远，延迟高，基本上只能用作备份，比如谷歌备份数据，是直接将保存数据的硬盘送到备份地，而不是通过网络备份，因为大数据量下网络的速度还比不上车的速度。

不同的备份方式

• 集中式
  

• 互备式
  

• 独立式