分布式一致性

1 、背景 Redis的出现确实大大地提高系统大并发能力支撑的可能性，转眼间Redis的最新版本已经是3.X版本了，但我们的系统依然继续跑着2.8，并很好地支撑着我们当前每天5亿访问量的应用系统。想当年Redis的单点单线程特性无法满足我们日益壮大的系统，只能硬着头皮把Redis“集群化”负载。且这套“集群化”方案良好地运行至今。虽难度不高，胜在简单和实用。无论简单还是很简单，记录这种经历是一件非常有趣的事情。 2 、问题 系统访问量日益倍增，当前的Redis单点服务确实客观存在连续可用性以及支撑瓶颈风险，这种主/备模式在服务故障突发的情况下就会被动停止服务进行Redis节点切换。针对单点问题，我们结合自身的业务应用场景对Redis“集群化”提出几个主要目标： 1、避免单点情况，确保服务高可用； 2、紧可能把数据分布式存储，降低故障影响范围，满足服务灵活伸缩； 3、控制“集群化”的复杂度，从而控制边际成本； 3 、过程 以上目标1和2就是所谓的分布式集群方案，把大问题分而治之。但最难把控的是目标3的“简化”实现。基于当时开源社区的那几种Redis集群方案，对于我们“简化”的要求来说相对略显臃肿。所以还是决定结合自身的业务应用等因素打造一个“合适”的Redis集群。 初始，我们凭借自己对分布式集群的认识勾结合应用场景勾勒出一个我们觉得足够“简化”的设计图，然后在这个“简化

1.1. 分布式系统基础知识 一个 tomcat 打天下的时代，不能说完全淘汰了，在一个管理系统，小型项目中还经常使用，这并不过分，出于成本的考虑，这反而值得提倡。 1.1.1. 分布式系统是什么 分布式系统：一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统 这是分布式系统，在不同的硬件，不同的软件，不同的网络，不同的计算机上，仅仅通过消息来进行通讯与协调 这是他的特点，更细致的看这些特点又可以有：分布性、对等性、并发性、缺乏全局时钟、 故障随时会发生。 1.1.1.1. 分布性 既然是分布式系统，最显著的特点肯定就是分布性，从简单来看，如果我们做的是个电商项目，整个项目会分成不同的功能，专业点就不同的微服务，比如用户微服务，产品微服务，订单微服务，这些服务部署在不同的 tomcat 中，不同的服务器中，甚至不同的集群中，整个架构都是分布在不同的地方的，在空间上是随意的，而且随时会增加，删除服务器节点，这是第一个特性 1.1.1.2. 对等性 对等性是分布式设计的一个目标，还是以电商网站为例，来说明下什么是对等性，要完成一个分布式的系统架构，肯定不是简单的把一个大的单一系统拆分成一个个微服务，然后部署在不同的服务器集群就够了，其中拆分完成的每一个微服务都有可能发现问题，而导致整个电商网站出现功能的丢失。 比如订单服务，为了防止订单服务出现问题

微服务–分布式事务的实现方法及替代方案 这两天正在研究微服务架构中分布式事务的处理方案, 做一个小小的总结, 作为备忘. 如有错误, 欢迎指正! 概念澄清 事务补偿机制 : 在事务链中的任何一个正向事务操作, 都必须存在一个完全符合回滚规则的可逆事务. CAP理论 : CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统. 幂等性 : 简单的说, 业务操作支持重试 , 不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID. BASE (Basically avaliable, soft state, eventually consistent): 是分布式事务实现的一种理论标准. 柔性事务 vs. 刚性事务 刚性事务是指严格遵循ACID原则的事务, 例如单机环境下的数据库事务. 柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 两阶段提交(2PC), TCC补偿型提交, 基于消息的异步确保型, 最大努力通知型. 通常对本地事务采用刚性事务, 分布式事务使用柔性事务. 先上结论, 再分别介绍分布式事务的各种实现方式. 如果业务场景需要强一致性, 那么尽量避免将它们放在不同服务中,

“数据不能丢，服务不能停”，可以说这句话道出了用户对数据库的核心能力的要求。然而，传统的商业数据库必须依赖高可靠的硬件才能实现数据可靠性和服务可用性。OceanBase作为一款成熟的企业级分布式数据库，基于普通PC服务器，就能够做到传统高端硬件环境下的数据可靠性和服务可用性，而且还能做得更好！跟我们一起看看OceanBase的技术秘诀吧！ Part1 前言 说到数据可靠性和服务可用性，在数据库领域真是老生常谈的话题，可以说从数据库诞生之日起就如影随形。如果要用一句话来概括数据库对数据可靠性和服务可用性的要求，可以借用OceanBase数据库创始人阳振坤老师的一句话：“数据不能丢，服务不能停”。可以说，这句话也道出了用户对数据库的一个核心能力要求：除了功能完善、使用方便之外，还要绝对安全、足够健壮。可以说，为了满足这两个看似简单的要求，在数据库领域诞生了大量的技术和论文，也让无数人绞尽了脑汁。 在传统的商业数据库产品（如Oracle、DB2）中，虽然也有一些行之有效的软件技术（如Redo Log、主从热备技术等）用来提高数据可靠性和服务可用性，但整体来说对硬件的稳定性有很强的依赖。而传统的企业级服务器（如IBM 的Mainframe、AS400、Power等）和EMC、IBM等厂商的高端存储产品，能够很好的保证硬件的稳定性，因此也就成为了Oracle为代表的传统数据库产品的理想平台

1.使用缓存的场景 缓存是提高系统读性能的常用技术，尤其对于读多写少的应用场景，使用缓存可以极大的提高系统的性能 例子：查询用户的存款： select money from user where uid = YYY; 为了优化该查询功能，我们可以在缓存中建立uid->money的键值对。 减少数据库的查询压力。 2. 读操作流程 目前数据库和缓存中都有存储数据，当读取数据的时候，流程如下。 1）先读取缓存是否存在数据(uid->money)。如果缓存中有数据返回结果。 2）如果缓存中没有数据，则从数据库中读取数据。 介绍一个概念： 缓存命中率：缓存命中数/总缓存访问数。 3. 写操作流程 在介绍写操作流程之前，先讨论两个问题 问题一：淘汰缓存还是更新缓存？ 淘汰缓存：数据只会写入数据库，不会写入缓存，只会把数据淘汰掉。 更新缓存：数据不但写入数据库，还会写入缓存。 问题二：先写缓存还是先写数据库？ 由于对缓存的更新和数据库的更新无法保证事务性操作。一定涉及到哪个先做，哪个后做的问题，我们的原则是采取对业务影响小的策略。下面是四种不同的组合策略 由此可见第四种策略的影响最小，只会造成一次查询缓存miss而已。那么当查询缓存miss的时候，我们该怎么办？很简单，查询数据库，然后将数据库的内容更新到缓存中。可能有人会问第四种策略，如果一上来淘汰缓存就失败了怎么办，当然是直接返回即可

在分布式存储领域，为了增加系统的高可用性，经常将同一份数据存储多个副本，常见的做法的三备份。但是此做法也引来了数据一致性的问题。为了解决数据一致性的问题，业界常用的有CAP、ACID、BASE等理论模型。 CAP原则 CAP是对强一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance） 的一种简称。 强一致性：即在分布式系统中同一数据多副本的情况下，对数据的更新操作体现出的效果与只有单份数据是一样的。 可用性：客户端在任何时刻对分布式系统的读写操作都应保证在限定延时内完成。 分区容忍性：即使分区机器间无法进行网络通信仍能继续工作。 CAP原则最初由Eric Brewer于1999年提出，他同时证明：对于一个大型分布式系统，CAP三者不可兼得。即要么AP，要么CP，要么AC，不存在CAP。 ACID原则 在关系型数据库领域经常采纳ACID原则，即原子性（Atomicity）、一致性（Consistency）、事务独立性（Isolation）、持久性（Durability） 原子性：指一个事务要么全部执行，要么完全不执行，不允许一个事务执行一半就停止。 一致性：事务的开始和结束时，硬始终满足一致性约束条件。 事务独立性：如果有多个事务同时执行，彼此之间不需要知晓对方的存在。不允许出现两个事务交错、间隔执行部分任务的情形

摘要： 前言目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总... 前言 目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总结了几个点，更多的应用系统在编码的时候，更加关注数据的一致性，这样系统才是健壮的。 基础理论相关 说起事务，目前的几个理论，ACID事务特性，CAP分布式理论，以及BASE等，ACID在数据库事务中体现，CAP和BASE则是分布式事务的理论，结合业务系统，例如订单管理，例如仓储管理等，可以借鉴这些理论，从而解决问题。 ACID 特性 A（原子性）事务的原子操作单元，对数据的修改，要么全部执行，要么全部不执行； C（一致性）在事务开始和完成时，数据必须保持一致状态，相关的数据规则必须应用于事务的修改，以保证数据的完整性，事务结束时，所有的内部数据结构必须正确； I（隔离性

分布式CAP理论 来自wiki: 在 理论计算机科学 中， CAP定理 （CAP theorem），又被称作 布鲁尔定理 （Brewer's theorem），它指出对于一个 分布式计算系统 来说，不可能同时满足以下三点：[ 1] [ 2] 一致性（ C onsistency） （等同于所有节点访问同一份最新的数据副本） 可用性 （ A vailability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据） 分区容错性 （ P artition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择[ 3] 。） 根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项[ 4] 。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。 来自 : 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后

1、背景 在解决分布式系统中负载均衡的问题时候可以使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡的作用。 但是普通的余数hash（hash(比如用户id)%服务器机器数）算法伸缩性很差，当新增或者下线服务器机器时候，用户id与服务器的映射关系会大量失效。一致性hash则利用hash环对其进行了改进。 2、 为了能直观的理解一致性hash原理，这里结合一个简单的例子来讲解，假设有4台服务器，地址为ip1,ip2,ip3,ip4。 一致性hash是首先计算四个ip地址对应的hash值 hash(ip1),hash(ip2),hash(ip3),hash(ip3)，计算出来的hash值是0~最大正整数直接的一个值，这四个值在一致性hash环上呈现如下图： hash环上顺时针从整数0开始，一直到最大正整数，我们根据四个ip计算的hash值肯定会落到这个hash环上的某一个点，至此我们把服务器的四个ip映射到了一致性hash环 当用户在客户端进行请求时候，首先根据hash(用户id)计算路由规则（hash值），然后看hash值落到了hash环的那个地方，根据hash值在hash环上的位置顺时针找距离最近的ip作为路由ip. 如上图可知user1,user2的请求会落到服务器ip2进行处理

一、CAP是什么 CAP是理解分布式系统的基础，它其实是三个英文单词Consistency,Availability,Partition tolerance的缩写，这三个英文单词也就是CAP的三大组成部分。 提出这个指标的人指出：这三个指标不能同时做到。这就是著名的CAP定理。 下面我们来说说这三个指标，注意不考虑单服务器的情况。 1.Consistency，一致性 一致性意味着当用户发起写操作后，所有的读操作都必须返回该值。这就要求用户在向A服务器发起写操作成功后，A服务器必须向与它相关联的B服务器发送一条消息，要求B服务器也完成相同的写操作。这样后面的用户发起读操作时，无论读取的是哪个服务器的信息，得到的数据都是一样的，这就是一致性。 2.Availability，可用性 即有求必应，服务器收到请求，就必须在有限的时间内返回结果给用户。 3.Partition tolerance，分区容错 即分布式系统在遇到任何网络分区故障的时候，仍然能够保证提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。 二、主要矛盾 对于一个分布式系统架构而言，分区容错性是一个最基本的要求，而如果不满足分区容错性，那实际上意味着如果分布式系统某个分区出故障了，整个系统都会停掉，这和分布式架构的设计理念不符。所以其实CAP原理的主要矛盾在于一致性和可用性。 那为什么一致性和可用性无法同时成立呢