分布式一致性

最近在研究分布式系统的一些理论概念，例如关于分布式系统一致性的讨论，看了一些文章我有一些不解。大多数对分布式系统一致性的划分是将其分为三类：强一致性，顺序一致性以及弱一致性。强一致性（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 result

1 一致性 1.1 简述 一致性，是指对每个节点一个数据的更新，整个集群都知道更新，并且是一致的 假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性： 全认同 : 所有N个节点都认同一个结果 值合法 : 该结果必须由N个节点中的过半节点提出 可结束 : 决议过程在一定时间内结束，不会无休止地进行下去 1.2 面临着的问题 消息传递异步无序 : 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序 节点宕机 : 节点持续宕机，不会恢复 节点宕机恢复 : 节点宕机一段时间后恢复，在分布式系统中最常见 网络分化 : 网络链路出现问题，将N个节点隔离成多个部分 拜占庭将军问题 : 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息 假设现实场景中也存在这样的问题： 周五 我：晚上下班吃鸡 周六凌晨 xc：好的 // 消息延迟 我：... --------------------------------- 我：晚上下班吃鸡 xc：No (两小时后) xc：No problem！ // 宕机节点恢复 我：… --------------------------------- 我：晚上下班吃鸡 … // 节点宕机 --------------------------------- 我：晚上下班吃鸡 cx:好，我们去大保健！ //

Zookeeper是什么 ZooKeeper是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Leader选举、分布式锁和分布式队列等功能。 Zookeeper保证了如下分布式一致性特性： 顺序一致性 原子性 单一视图 可靠性 实时性（最终一致性） 客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理。对于写请求，会统一由Leader接收并处理，广播给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。 有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。 分布式系统的CAP原则是什么？ZK实现的是AP还是CP？ CAP原则又称CAP定理

摘要：对于所有的分布式系统，我想事务一致性问题是极其非常重要的问题，因为它直接影响到系统的可用性。本文以下所述所要解决的问题是：对于入HBase和Solr的过程，如何保证HBase中写入的数据与Solr中写入的数据完全一致。 关键词：HBase, Solr, 分布式, 事务, 系统架构, 大数据 作者：王安琪（博客： http://www.cnblogs.com/wgp13x/ ） 一、关于分布式系统事务一致性问题 Java 中有三种可以的事务模型，分别称作本地事务模型（Local Transaction Model），编程式事务模型（Programmatic Transaction Model），和声明式事务模型（Declarative Transaction Model)。事务要求包含原子性（Atomicity），一致性（Consistency），独立性（Isolation），和持久性（Durability）。 《大型网站系统与Java中间件实践》一书中分享了一些解决分步式系统一致性问题的方案构思与实践，如在第六章中谈到的消息中间件。下表展现了解决一致性方案与传统方式的对比。 传统方式是，我做完了，发你消息。解决一致性的方案的意思就是，我先发你消息，我做完了再跟你确认我做完了。这是改进后的有事务的消息中间件。 因为在非XA 环境中，消息队列的插入过程独立于数据库更新操作

异地多活在近年越来越多大型互联网公司采用的方案，几乎也是大型应用发展到一定阶段的必然选择，综合比较一下各个互联网公司的方案，会发现有很多共性的东西，也有很多差异化的东西，这是最有意思的地方 什么是异地多活 异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活，是指这些机房在日常的业务中也需要走流量，做业务支撑。冷备份的主要问题是成本高，不跑业务，当主机房出问题的时候，也不一定能成功把业务接管过来。 CAP原则 分布式架构设计无论怎样都绕不开CAP原则，C一致性 A可用性 P分区容错性，分区容错性是必不可少的，没有分区容错性就相当于退化成了单机系统，所以实际上架构设计是在一致性和可用性一个天平上的两端做衡量。为什么强一致性和高可用性是不能同时满足？假如需要满足强一致性，就需要写入一条数据的时候，扩散到分布式系统里面的每一台机器，每一台机器都回复ACK确认后再给客户端确认，这就是强一致性。如果集群任何一台机器故障了，都回滚数据，对客户端返回失败，因此影响了可用性。如果只满足高可用性，任何一台机器写入成功都返回成功，那么有可能中途因为网络抖动或者其他原因造成了数据不同步，部分客户端独到的仍然是旧数据，因此，无法满足强一致性。 异地多活的挑战 延迟

第九章 一致性与共识 分布式系统最重要的的抽象之一是共识(consensus)：让所有的节点对某件事达成一致。 最终一致性(eventual consistency)只提供较弱的保证，需要探索更高的一致性保证(stronger consistency)。 摘要： start by looking at one of the strongest consistency models in common use,linearizability(线性一致性)。 then examine the issue of ordering events(事件顺序) in a distributed system,particularly around causality(因果关系) and total ordering(全局顺序). explore how to atomically commit a distributed transaction Linearizability 非线性一致性案例： 全序 全序(total order)指允许任意两个元素进行比较，如自然数集就是全序的。 而数学集合不是全序的，如{a,b}与{b,c}不能比较大小，称为偏序。 线性一致性的系统中，操作是全序的；如果两个事件有因果关系，则它们有序，如果是并发的，则它们的顺序无法比较。这意味着因果关系定义了一个偏序。

缓存一致性问题 一.场景 二.问题 三.定义 四.分析 1.顺序异常分析 1.1 先A后B 1.2 先B后A 1.3小结 2.方案分析 2.1先A后B 2.2先B后A 1.3小结 1.4方案改进 五.总结 一.场景 项目中为了对dao(data access object)层数据做缓存，设计了一层das(data access service)，在das上采用了aop的方式作统一缓存处理。这里做的是缓存删除操作。 二.问题 数据库和缓存的一致性问题。 三.定义 A: 删除缓存 B: 提交数据库事务 C: 读取缓存（如果缓存数据为空，会从数据库读取旧数据） A-B: A和B同步 A–B: A和B异步 四.分析 1.顺序异常分析 1.1 先A后B 注意：删除缓存的操作在数据库事务中执行的情况也属于先A后B （１）A失败了，B不会执行，不影响一致性。 （２）A成功了，B失败了。因为是删除缓存操作（读请求会从数据库读取旧数据），所以不影响一致性。 （３）先A，后B，存在时间间隙，如果在这段间隙中有其它读请求C，那么就会出现数据不一致。 1.2 先B后A （１）B失败，A不会执行，不影响一致性。 （２）B成功，A失败，会出现数据不一致。 1.3小结 从上面分析可以发现，两种顺序的执行都会存在导致数据不一致的问题。 2.方案分析 2.1先A后B 解决问题（3） （1）阻塞加锁的方式， A-B

单机MySQL的美好时代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 在那个时候，更多的都是静态网页，动态交互类型的网站不多 初期架构 | center DAL，（Data Access Layer）。其功能主要是负责数据库的访问。简单地说就是实现对数据表的Select（查询）、Insert（插入）、Update（更新）、Delete（删除）等操作。 上述架构下，我们来看看数据存储的瓶颈是什么？ 1、数据量的总大小 一个机器放不下时。（表要占空间，表的索引要占空间） 2、数据的索引（B+ Tree树）一个机器的内存放不下时库 3、访问量(读写混合)一个实例不能承受，（读写一个库） 真正意义上的库应该是主从复制，读写分离，而mysql等数据库只能自己从自己的库中读与写，也就是自己和自己玩。 如果满足了上述1 or 3个，则需要进化.. Memcached(缓存,java上还有一个ehcache)+MySQL+垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力， 优化数据库的结构和索引 。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付 又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。 有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性 ACID： A：原子性(Atomicity)，一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么发不出货，就退钱。 C：一致性(Consistency)，事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。 如果事务成功地完成，那么系统中所有变化将正确地应用

微服务系统 事务 事务的原则 事务：是一种可靠，一致的方式，访问和操作数据库中数据的程序单元 原则特性： 原子性， 一致性 ，隔离性：事务之间互不干扰，持久性： 没提交事务之前，系统挂了，数据还是之前的数据，并没有被改变 mysql 查询事务的隔离级别 SELECT @@GLOBAL.tx_isolation,@@tx_isolation; 默认是 REPEATABLE-READ 可重复读 什么是 可重复读？ 比如 开启一个 事务，这个事务只读某一个表的 某条 的取数据。 但是这时候并没有提交 ， 但是 这时候另一个事务 修改了 该条数据，并提交了事务。 此时 之前的 的那个为 提交的事务，再次查询数据，这时候的数据是 未改变之前的数据，并不会因为 其他事务修改了数据提交了事务， 而显示出来 修改的值。 mysql 可重复读 修复 因为mysql 的事务隔离级别是 可重复读，另一个事务a 在执行更新数据，但是未提交， 这时候 一个事务 读取到 值之后， 另一个事务a更新了数据， 那么这时候 之前读取的值就不对了，怎么解决呢？ 1， 要么改 数据隔离级别是 序列化的, 可以修改当前 连接 session的 事务隔离级别 2. 使用 FOR UPDATE 这时候 比如 SELECT * FROM T_USER FOR UPDATE 此时 如果该表有未 提交事务，将等待 事务提交完成