分布式一致性

##分布式存储中的应用 在分布式存储系统中，将数据分布至多个节点的方式之一是使用哈希算法。假设初始节点数为 N，则传统的对 N 取模的映射方式存在一个问题在于：当节点增删，即 N 值变化时，整个 哈希表 （Hash Table）需要重新映射，这便意味着大部分数据需要在节点之间移动。 因此现在普遍使用的是被称为 一致性哈希 （Consistent Hashing）的一类算法。“一致性” 这个定语的意义在于：当增删节点时，只影响到与变动节点相邻的一个或两个节点，散列表的其他部分与原来保持 一致 。某种程度上可以将其理解为：一致性哈希算法的哈希函数与节点数 N 无关。 其他地方对一致性哈希配图的时候，都会选择一个圆环来解释，但我个人感觉哈希表更加直观： 上图左右分别表示增加一个 “节点 5” 前后的哈希表，哈希函数使用的是 md5 。md5 会根据 key 的值摘要出一个 128 bit 的哈希值（校验和），一般表示为一个 32 位的 16 进制数。这里我们取哈希值第一位的范围来将 key 映射到不同的节点，可以看到在拆分了 “节点 4” 的 md5 首位范围后，只需要将 “节点 4” 原本数据的约一半移动到 “节点 5” 上去就可以了，其他三个节点并未受到影响。 <br /> ##负载均衡改进 但这里其实仍有改进的空间。 问题在于，上面需要将 “节点 4” 的一半数据搬运到 “节点 5

首先，所谓网站的伸缩性，指 不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力 。在整个互联网行业的发展渐进演化中，最重要的技术就是 服务器集群 ，通过不断地向集群中添加服务器来增强整个集群的处理能力。 一、网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 　　（1）纵向分离：将业务处理流程上得不同部分分离部署，实现系统的伸缩性； 　　（2）横向分离：将不同的业务模块分离部署，实现系统的伸缩性； 1.2 单一功通过集群规模实现伸缩 　　使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说，集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同，技术实现也有很大的区别。 　It is said that 当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车 。 二、应用服务器集群的伸缩性设计 2.1 应用服务器那点必须知道的事儿 　　（1）应用服务器应该被设计成 无状态 的，即应用服务器不存储请求上下文信息；构建集群后，每次用户的请求都可以发到集群中任意一台服务器上处理，任何一台服务器的处理结果都是相同的； 　　（2）HTTP本身是一个无状态的连接协议，为了支持客户端与服务器之间的交互，我们就需要通过不同的技术为交互存储状态

1、技术背景 1.1、技术举例：Memcache 1.2、技术瓶颈 memcached服务器端本身不提供分布式cache的一致性，由客户端实现提供。以余数分布式算法为例。 余数分布式算法是根据添加进入缓存时key的hash值通过特定的算法得出余数，然后根据余数映射到关联的缓存服务器，将该key-value数据保存到该服务器 1.2.1、假设有3台缓存服务器以及它们对应的余数值 Node A:0，3，6，9 Node B:1，4，7 Node C:2，5，8 1.2.2、此时添加一台服务器Node D 服务器对应的余数值发生变化，如下 Node A:0，1，2 Node B:3，4 Node C:5，6 Node C:7，8，9 根据上面的变化，发现只有余数值为0，4，5所对应的缓存服务器没有发生改变，也就是说其它余数值对应的缓存服务器发生了改变，即缓存失效，如果大量缓存失效会严重影响系统的性能，也就是缓存动荡。针对这样大片缓存失效的技术瓶颈，于是提出了一致性hash算法。缩小失效缓存范围。 2、一致性Hash算法 2.1、将hash值范围看成一个0～2 32 的圆。 2.2、将服务器节点的hash值映射到该圆上。 2.3、对数据进行缓存时，计算key的hash值，然后找到该值在圆上的位置，顺时针进行查找，将数据保存到第一个查找到的服务器。 2.4、添加一个缓存服务器，如图

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

3 月，跳不动了？>>> 来源：http://www.blogjava.net/hello-yun/archive/2012/04/27/376744.html 在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素： 一致性( C onsistency) 可用性( A vailability) 分区容忍性( P artition tolerance) CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而 对于分布式数据系统，分区容忍性是基本要求 ，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。 当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到 最终一致性 即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，

https://www.cnblogs.com/soundcode/p/5590710.html 编者按：本文由「高可用架构后花园」群讨论整理而成。 有人的地方，就有江湖 有江湖的地方，就有纷争 问题的起源 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。 在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。 强一致 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下，系统 最终 返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 在工程实践上

3 月，跳不动了？>>> 简单的说， Raft 是一种易于理解的一致性算法，其功能相当于Paxos。目前很多提供一致性服务的系统都采用Paxos, 例如Chubby, ZooKeeper, 那么为何还需要 Raft ？自Lamport 1998年提出Paxos以来, 该协议虽逐渐成为主流一致性协议，但也以难以理解而著名，实现起来比较困难。针对 Raft 难以理解的缺陷， Raft 设计的主要目的之一就是容易理解， Raft 将整个算法过程分解为若干个独立的子过程，并且详细描述了每个子过程如何实现，容易理解和实现。我自己也用 Java 实现了 Raft , 代码在 https://github.com/chicm/CmRaft , 本系列文章的最后我将介绍我的实现。 本文主要参考了 In Search of an Understandable Consensus Algorithm (Extended Version) ，也包含了我自己的理解。 那么什么是一致性算法？ 一致性是分布式容错系统的基本功能，例如在分布式共享文件系统中，通常有多台服务器向客户提供文件服务，当客户通过其中一台服务器A向文件系统存储 了一个文件，如何保证能从服务器B获取刚刚保存的文件？其核心问题在于多台机器就某个值达成一致，一旦某个值达成了一致，客户向整个集群的任何一台机器请 求该值时都会得到同一个值

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

99% 的人都能看懂的「补偿」以及最佳实践 也许你对降级已经有了一些认识，这次，我们来聊一聊在保证对外高可用的同时，憋出的“内伤”该如何通过「补偿」机制来自行消化。 「补偿」机制的意义 以电商的购物场景为例： 客户端 ----> 购物车微服务 ----> 订单微服务 ----> 支付微服务。 这种调用链非常普遍。 那么为什么需要考虑补偿机制呢？ 正如之前几篇文章所说，一次跨机器的通信可能会经过 DNS 服务，网卡、交换机、路由器、负载均衡等设备，这些设备都不一定是一直稳定的，在数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。 而在分布式场景中，一个完整的业务又是由多次跨机器通信组成的，所以产生问题的概率成倍数增加。 但是，这些问题并不完全代表真正的系统无法处理请求，所以我们应当尽可能的自动消化掉这些异常。 可能你会问，之前也看到过「补偿」和「事务补偿」或者「重试」，它们之间的关系是什么？ 你其实可以不用太纠结这些名字，从目的来说都是一样的。就是一旦某个操作发生了异常，如何通过内部机制将这个异常产生的「不一致」状态消除掉。 题外话：在笔者看来，不管用什么方式，只要通过额外的方式解决了问题都可以理解为是「补偿」，所以「事务补偿」和「重试」都是「补偿」的子集。前者是一个逆向操作，而后者则是一个正向操作。 只是从结果来看，两者的意义不同。「事务补偿」意味着“放弃”

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能