数据库一致性

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

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

分布式理论（一） 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 算法就是干这事情。 所以今天要讲的这些的前提一定是分布式，解决的问题全部都是在分布式环境下

一、前言 只有InnoDB引擎支持事务，下边的内容均以InnoDB引擎为默认条件 二、常见的并发问题 1、脏读 一个事务读取了另一个事务未提交的数据 2、不可重复读 一个事务对同一数据的读取结果前后不一致。两次读取中间被其他事务修改了 3、幻读 幻读是指事务读取某个范围的数据时，因为其他事务的操作导致前后两次读取的结果不一致。幻读和不可重复读的区别在于,不可重复读是针对确定的某一行数据而言,而幻读是针对不确定的多行数据。因而幻读通常出现在带有查询条件的范围查询中 三、事务隔离级别 1、读未提交(READ UNCOMMITTED) 可能产生脏读、不可重复读、幻读 2、读已提交(READ COMMITTED) 避免了脏读，可能产生不可重复读、幻读 3、可重复读(REPEATABLE READ)（mysql默认隔离级别） 避免了脏读，不可重复读。通过区间锁技术避免了幻读 4、串行化(SERIALIZABLE) 串行化可以避免所有可能出现的并发异常,但是会极大的降低系统的并发处理能力 四、数据库日志有哪些？ 1、undo日志 undo日志用于存放数据修改被修改前的值 UNDO LOG中分为两种类型，一种是 INSERT_UNDO（INSERT操作），记录插入的唯一键值； 一种是 UPDATE_UNDO（包含UPDATE及DELETE操作），记录修改的唯一键值以及old column记录。

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

一.事务 定义：所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。 准备工作：为了说明事务的ACID原理，我们使用银行账户及资金管理的案例进行分析。 // 创建数据库 create table account( idint primary key not null, namevarchar(40), moneydouble ); // 有两个人开户并存钱 insert into account values(1,'A',1000); insert into account values(2,'B',1000); 二.ACID ​ ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）.这是可靠数据库所应具备的几个特性.下面针对这几个特性进行逐个讲解. 三.原子性 原子性是指事务是一个不可再分割的工作单位，事务中的操作要么都发生，要么都不发生。 ​ 1.案例 ​ A给B转帐100元钱 ​ ​ 2.分析 在事务中的扣款和加款两条语句，要么都执行，要么就都不执行。否则如果只执行了扣款语句，就提交了，此时如果突然断电，A账号已经发生了扣款，B账号却没收到加款，在生活中就会引起纠纷。

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 环境中，消息队列的插入过程独立于数据库更新操作

一个系统可能包含很多模块，如数据库、前端、缓存、搜索、消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用的实现可能更加复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的高可用方案时，在容灾之外，还要同时考虑方案中数据一致性问题。 本文将通过介绍一些业界主流的数据库高可用架构、每种方案的特性和优缺点，以及数据库高可用架构的自动化运维实现，讲讲数据库高可用容灾方案设计与实现，希望抛砖引玉，和大家一起讨论。 一、高可用数据库概述 什么是高可用数据库？ 高可用数据库是由一系列数据库构成的总体系统，在任何时刻，至少有一个节点可以接受用户的请求并提供数据库服务。大多数数据库架构中，有一个主节点处理主要请求，还有若干备用节点用于容灾切换，当主节点不能提供服务时，备用节点成为主节点继续提供服务，用以保证整个系统的可用和稳定。 高可用数据库有很多优点： 第一，方便读写分离。数据库请求当中，一般读操作的请求次数远大于写操作，高可用数据库可以通过将写操作放在主数据库节点上进行，将读操作分担到若干从库上，来提升读操作吞吐量，进而提升读写效率； 第二，变更不停服。当整个高可用数据库架构或者主节点升级时，可以让高可用数据库先进行主库切换，让备用节点替换原主节点提供数据库服务，当主节点升级完毕后，再将主从库服务切换回来