分布式一致性

一. 数据切分 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 数据库分布式核心内容无非就是数据切分（Sharding） ，以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。 数据切分根据其切分类型，可以分为两种方式： 垂直（纵向）切分和水平（横向）切分 1、垂直（纵向）切分 垂直切分常见有垂直分库和垂直分表两种。 垂直分库 就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图： 垂直分表 是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销

『浅入深出』MySQL 中事务的实现 在关系型数据库中，事务的重要性不言而喻，只要对数据库稍有了解的人都知道事务具有 ACID 四个基本属性，而我们不知道的可能就是数据库是如何实现这四个属性的；在这篇文章中，我们将对事务的实现进行分析，尝试理解数据库是如何实现事务的，当然我们也会在文章中简单对 MySQL 中对 ACID 的实现进行简单的介绍。 事务其实就是并发控制的基本单位；相信我们都知道，事务是一个序列操作，其中的操作要么都执行，要么都不执行，它是一个不可分割的工作单位；数据库事务的 ACID 四大特性是事务的基础，了解了 ACID 是如何实现的，我们也就清除了事务的实现，接下来我们将依次介绍数据库是如何实现这四个特性的。 原子性 在学习事务时，经常有人会告诉你，事务就是一系列的操作，要么全部都执行，要都不执行，这其实就是对事务原子性的刻画；虽然事务具有原子性，但是原子性并不是只与事务有关系，它的身影在很多地方都会出现。 由于操作并不具有原子性，并且可以再分为多个操作，当这些操作出现错误或抛出异常时，整个操作就可能不会继续执行下去，而已经进行的操作造成的副作用就可能造成数据更新的丢失或者错误。 事务其实和一个操作没有什么太大的区别，它是一系列的数据库操作（可以理解为 SQL）的集合，如果事务不具备原子性，那么就没办法保证同一个事务中的所有操作都被执行或者未被执行了

一致性级别划分 关于分布式系统一致性级别的划分，有些文章划分为 强一致性，顺序一致性以及弱一致性 。 最终一致性属于弱一致性，最终一致性根据更新数据后各进程访问到数据的时间和方式的不同划分为： 因果一致性、 “读己之所写（read-your-writes）”一致性、 会话（Session）一致性、 单调（Monotonic）读一致性、 单调写一致性 另一种，根据一致性的强弱程度不同，直接划分为 强一致性、单调一致性、会话一致性、最终一致性和弱一致性 。 最终一致性和顺序一致性的区别 最终一致性和顺序一致性的差别非常大。 顺序一致性是更强的一致性模型，最终一致性模型是非常弱的一致性模型。可以这么说，满足顺序一致性的系统一定满足最终一致性，但满足最终一致性的系统不一定满足顺序一致性。比如，zookeeper是顺序一致性，zookeeper也满足最终一致性；cassandra是最终一致性，但cassandra不满足顺序一致性。 ZK一致性级别分析 博文 《线性一致性(Linearizability)是并发控制的基础》 中提到【在分布式领域中，我们也会说线性一致性，例如Zookeeper是线性一致性的，再比如分布式领域著名的CAP定理中的C，也是指线性一致性。】 作者的意思是他在文章中提到的【Zookeeper是线性一致性的】是为了举例说明线性一致性也会用来描述分布式系统

一致性算法—Paxos、Raft、ZAB 2019年04月21日 20:35:09 bulingma 阅读数 64 更多 分类专栏： 分布式概念 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/bulingma/article/details/89438851 写在前面 1、分布式系统对fault tolerence的一般解决方案是state machine replication（状态机复制）。 2、分布式一致性算法的一种更准确的说法应该是：state machine replication的共识（consensus）算法。 3、pasox其实是一个共识算法。系统的最终一致性，不仅需要达成共识，还会取决于client的行为。 4、分布式系统中有多个节点就会存在节点间通信的问题，存在着两种节点通讯模型：共享内存（Shared memory）、消息传递（Messages passing），以下谈到的算法都是基于消息传递的通讯模型的。它的假设前提是，在分布式系统中进程之间的通信会出现丢失、延迟、重复等现象，但不会出现传错的现象。以下的算法就是为了保证在这样的系统中进程间基于消息传递就某个值达成一致。 一、一致性概述 当前工业实际应用中的一致性模型分类 1.1、弱一致性

最近在研究分布式系统的一些理论概念，例如关于分布式系统一致性的讨论，看了一些文章我有一些不解。大多数对分布式系统一致性的划分是将其分为三类：强一致性，顺序一致性以及弱一致性。强一致性（Strict Consistency）也称为：原子一致性（Atomic Consistency）、线性一致性（Linearizable Consistency）。 在谈到Zookeeper的一致性是哪种级别的一致性问题，以及CAP原则中的C是哪一种一致性级别时有些疑惑。 下面是大多数文章中提到的一致性级别 1. 一致性（Consistency） 一致性（Consistency）是指多副本（Replications）问题中的数据一致性。可以分为强一致性、顺序一致性与弱一致性。 1.1 强一致性（Strict Consistency） 也称为： 原子一致性（Atomic Consistency）** 线性一致性（Linearizable Consistency）** 强一致性有两个要求： 任何一次读都能读到某个数据的最近一次写的数据。 系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。 简言之，在任意时刻，所有节点中的数据都是一样的。 例如，对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。 1.2 顺序一致性（Sequential Consistency） the

一致性hash的设计初衷是解决分布式缓存问题，它不仅能起到hash作用，还可以在服务器宕机时，尽量少地迁移数据。因此被广泛用于状态服务的路由功能 # 01分布式系统的路由算法 假设有一个消息推送系统，其简易架构如下 设备接入层不仅要接收设备的登录、下线等状态命令，还要把开发者的消息推送给设备。这个时候设备接入层就需要维护设备的状态信息（当然可以专门拆一个状态服务去维护这些信息，要求这部分必须少有代码更新，具体原因自己去想哦=_=）。这个时候设备接入层的每台server都保留一批设备的状态信息cache，设备应该连接哪台server去获取数据，同时中间层的消息又该发往哪个server去推送呢？这就用到了一致性hash算法。 # 02什么是一致性hash算法 一致性hash由对象、资源、算法和机器组成。它要做的是：对象通过算法判断连哪台机器。在如上系统中：设备id（userID）为对象；其对应的状态数据(cache)为资源；服务器为机器。 在一致性hash算法中，这些资源围成了一个闭环，每台机器又保存着一个资源段，每个资源段对应一批对象/设备；这样如果某台机器挂了，那它对应的资源转移到离它较近的机器x，这台dead server对应的设备连接到机器x就行。 现在假设这四个资源段对应的设备，活跃情况相差较大。比如说资源段1、2对应的设备特别活跃，而资源段3和4几乎没活动。这样机器1

分布式理论（一） CAP 理论 一． CAP 理论前言 CAP 原则又称为 CAP 理论，主要思想是在任何一个分布式系统中都无法同时满足 CAP 。 C （ Consistency ）：表示一致性，所有的节点同一时间看到的是相同的数据。 A （ Avaliablity ）：表示可用性，不管是否成功，确保一个请求都能接收到响应。 P （ Partion Tolerance ）：分区容错性，系统任意分区后，在网络故障时，仍能操作。 如上所述，正如 Gilbert 认为， 一致性 其实就是关系型数据库所讲的 ACID ，一个用户请求要么是成功，要么是失败的，不能有处于一个中间状态；一旦一个事务完成，将来所有事务都必须基于这个完成后的状态；未完成的事务不会互相影响；一旦一个事务完成，就是持戒的。 可用性 其实就是对于一个系统而言，所有的请求都应该 “成功”并且收到“响应”。 分区容错性 其实就是指分布式系统的容错性，一个节点出现了故障，不影响整个集群的正常使用。 二． CAP 理论介绍 如图，在一个网络中， N1 和 N2 即分布式系统中的两个节点，他们都共享数据块 V ，其中有一个值是为 V0 。 l 在满足一致性的时候， A 中的 V0 应该和 B 中的 V0 保持一致的，即 V0=V0 l 在满足可用性的时候，无论请求访问 A 或者是 B 都应该得到响应。 l 在满足分区可用性的时候

1.1. 一致性协议概述 前面已经讨论过，在分布式环境下，有很多不确定性因素，故障随时都回发生，也讲了 CAP 理论， BASE 理论 我们希望达到，在分布式环境下能搭建一个高可用的，且数据高一致性的服务，目标是这样，但 CAP 理论告诉我们要达到这样的理想环境是不可能的。这三者最多完全满足 2 个。 在这个前提下， P （分区容错性）是必然要满足的，因为毕竟是分布式，不能把所有的应用全放到一个服务器里面，这样服务器是吃不消的，而且也存在单点故障问题。 所以，只能从一致性和可用性中找平衡。 怎么个平衡法？在这种环境下出现了 BASE 理论： 即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性； BASE 由 Basically Avaliable 基本可用、 Soft state 软状态、 Eventually consistent 最终一致性组成，一句话概括就是：平时系统要求是基本可用，除开成功失败，运行有可容忍的延迟状态，但是，无论如何经过一段时间的延迟后系统最终必须达成数据是一致的。 其实可能发现不管是 CAP 理论，还是 BASE 理论，他们都是理论，这些理论是需要算法来实现的，今天讲的 2PC 、 3PC 、 Paxos 算法， ZAB 算法就是干这事情。 所以今天要讲的这些的前提一定是分布式，解决的问题全部都是在分布式环境下

1.1 模型 节点 在具体的工程项目中，一个节点往往是一个操作系统上的进程。在本文的模型中，认为节点是一个完整的、不可分的整体，如果某个程序进程实际上由若干相对独立部分构成，则在模型中可以将一个进程划分为多个节点。 异常 机器宕机 ：机器宕机是最常见的异常之一。在大型集群中每日宕机发生的概率为千分之一左右，在实践中，一台宕机的机器恢复的时间通常认为是24 小时，一般需要人工介入重启机器。 网络异常 ：消息丢失，两片节点之间彼此完全无法通信，即出现了“网络分化”；消息乱序，有一定的概率不是按照发送时的顺序依次到达目的节点，考虑使用序列号等机制处理网络消息的乱序问题，使得无效的、过期的网络消息不影响系统的正确性；数据错误；不可靠的TCP，TCP 协议为应用层提供了可靠的、面向连接的传输服务，但在分布式系统的协议设计中不能认为所有网络通信都基于TCP 协议则通信就是可靠的。TCP协议只能保证同一个TCP 链接内的网络消息不乱序，TCP 链接之间的网络消息顺序则无法保证。 分布式三态 ：如果某个节点向另一个节点发起RPC(Remote procedure call)调用，即某个节点A 向另一个节点B 发送一个消息，节点B 根据收到的消息内容完成某些操作，并将操作的结果通过另一个消息返回给节点A，那么这个RPC 执行的结果有三种状态：“成功”、“失败”、“超时（未知）”

大纲 Hash取余算法 判定哈希算法好坏的四个定义 一致性Hash算法的两大设计 Hash取余算法 hash( Object.key) %N，hash值随Object.key、N的变化而变化。 如果有节点（集群中节点增减太正常）发生变化，几乎重新分配，意味着所有已经分配好的数据都要迁移到新的节点上。 一致性Hash算法提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义 ： 1、平衡性（Balance）：平衡性是指哈希的结果能够尽可能分布在所有的缓冲(Cache)中去，这样可以使得所有的缓冲空间得到利用。很多哈希算法都能够满足这一条件。 2、单调性（Monotonicity）：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应该能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会映射到旧的缓冲集合中的其他缓冲区。 3、分散性（Spread）：在分布式环境中，终端有可能看不到所有的缓冲，而只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上去，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度