常用分布式解决方案

常用分布式解决方案

基本概念

集中式存储

传统的存储也称为集中式存储， 从概念上可以看出来是具有集中性的，也就是整个存储是集中在一个系统中的，但集中式存储并不是一个单独的设备，是集中在一套系统当中的多个设备。集中式存储 最大的特点是有一个统一的入口，所有数据都要经过统一的入口。

分布式存储

分布式存储最早是由谷歌提出的，其目的是通过廉价的服务器来提供使用与大规模，高并发场景下的 Web 访问问题。它 采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

分布式存储包含的种类繁多，除了传统意义上的分布式文件系统、分布式块存储和分布式对象存储外，还包括分布式数据库和分布式缓存等，但其中架构无外乎于三种:

• 中间控制节点架构

  以 HDFS ( Hadoop Distribution File System )为代表的架构是典型的代表。在这种架构中，一部分节点 NameNode 是存放管理数据(元数据)，另一部分节点 DataNode 存放业务数据，这种类型的服务器负责管理具体数据。这种架构就像公司的层次组织架构， namenode 就如同老板，只管理下属的经理( datanode )，而下属的经理，而经理们来管理节点下本地盘上的数据。

  在该架构中 NameNode 通常是主备部署( Secondary NameNode )，而 DataNode 则是由大量节点构成一个集群。由于元数据的访问频度和访问量相对数据都要小很多，因此 NameNode 通常不会成为性能瓶颈，而 DataNode 集群中的数据可以有副本，既可以保证高可用性，可以分散客户端的请求。因此，通过这种分布式存储架构可以通过横向扩展 datanode 的数量来增加承载能力，也即实现了动态横向扩展的能力。

• 完全无中心架构 – 计算模式

  以 Ceph 为代表的架构是其典型的代表。在该架构中与 HDFS 不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系 计算出来 其写入数据的位置，这样客户端可以直接与存储节点通信，从而避免中心节点的性能瓶颈。

• 完全无中心架构 – 一致性哈希

  以 Ceph 为代表的架构是其典型的代表。在该架构中与 HDFS 不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系 计算出来 其写入数据的位置，这样客户端可以直接与存储节点通信，从而避免中心节点的性能瓶颈。

分布式理论

分布式一致性问题

分布式系统中要解决的一个非常重要的问题就是数据的复制，所谓分布式一致性的问题，就是指在分布式环境中引入数据复制机制后，不同数据节点之间可能会出现的、且无法依靠计算机应用程序自身解决的数据不一致的情况。

简单来说，数据一致性就是指在对一个副本数据进行变更的时候，必须确保也能够更新其它的副本，否则不同副本之间的数据将出现不一致。

• 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入的是什么，读出来的也要是什么，用户体验好，但实现起来往往对系统的性能影响较大；

• 弱一致性：这种一致性级别约束了系统在写入成功后，不保证立即可以读到写入的值，也不保证多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（如秒级别）后，数据能够达到一致状态；

• 最终一致性：最终一致性其实是弱一致性的一个特例，系统会保证在一定时间内，能够达到数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上用的比较多的一致性模型。

CAP 理论

它是一个经典的分布式系统理论。CAP 理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability ）及分区容错性（P：Partition tolerance）这三个基本要求，最多只能同时满足其中两项。

• 一致性：所有节点上的数据时刻保持同步

• 可用性：每个请求都能接收一个响应，无论响应成功或失败

• 分区容错：系统应该持续提供服务，即使系统内部（某个节点分区）有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂、服务器发生网络延迟或死机，导致某些Server与集群中的其他机器失去联系。

BASE 理论

在分布式（数据库分片或分库存在的多个实例上）前提下，CAP理论并不适合数据库事务，因为更新一些错误的数据而导致的失败，无论使用什么高可用方案都是徒劳的，因为数据发生了无法修正的错误 。此外，XA事务虽然保证了数据库在分布式系统下的 ACID （原子性、一致性、隔离性、持久性）特性，但同时也带来了一 些性能方面的代价，对于并发和响应时间要求都比较高的电商平台来说，是很难接受的。

eBay尝试了另外一条完全不同的路，放宽了数据库事务的ACID要求，提出了一套名为BASE的新准则。BASE全称为Basically Available，Soft-state，Eventually Consistent。系统基本可用、软状态、数据最终一致性。

etcd

zookeeper

raft

corosync

quorum {
        provider: corosync_votequorum　　　　　　# 启动了votequorum
        expected_votes: 7　　　　　　　　　　　　　 # 7表示，7个节点，quorum为4。如果设置了nodelist参数，expected_votes无效
        wait_for_all: 1　　　　　　　　　　　　　　 # 值为1表示，当集群启动，集群quorum被挂起，直到所有节点在线并加入集群，这个参数是Corosync 2.0新增的。
        last_man_standing: 1　　　　　　　　　　   # 为1表示，启用LMS特性。默认这个特性是关闭的，即值为0。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　# 这个参数开启后，当集群的处于表决边缘（如expected_votes=7，而当前online nodes=4），处于表决边缘状态超过last_man_standing_window参数指定的时间，
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　# 则重新计算quorum，直到online nodes=2。如果想让online nodes能够等于1,必须启用auto_tie_breaker选项，生产环境不推荐。
        last_man_standing_window: 10000        # 单位为毫秒。在一个或多个主机从集群中丢失后，重新计算quorum
}

c-raft集群开发需处理问题：

1. 需要开发动态更改quorum代码；
2. 需要开发客户端和服务端代码；（如何连接集群和集群如何处理数据）
3. 需要开发集群维护代码；（集群监控、查询集群状态、移除添加节点等）
4. 支持持久化，但当前仅记录变更日志；若要持久化业务，需在开发服务端和客户端时添加相关代码，将业务逻辑写入文件；

corosync集群开发需处理问题：

1. 需要开发客户端和服务端代码；（如何连接集群和集群如何处理数据）
2. 需要开发集群维护代码；（集群监控、查询集群状态、移除添加节点等）
3. 支持持久化，但当前仅记录变更日志；若要持久化业务，需在开发服务端和客户端时添加相关代码；

reference

1. https://juejin.cn/post/6844903630819033095