一致性

作者：芬达 “芬达的数据库学习笔记" 公众号作者，国内最沉闷 mysql ocp 考试探讨群群主，群号：120242978 。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 高能正告，因作者能力无限，文章的剖析过程没有基于 MySQL 源码，而是依据一些业界大佬的文章和官网文档整顿和思考得出的论断，如果感觉说得有情理，请点个赞，如果感觉胡言乱语请留言。本文的受众是至多曾经入门 MySQL 的 DBA。前言1. 咱们简略地温习一下半同步的原理： MySQL5.7 默认参数下咱们开启了半同步，在一个事务提交（commit） 的过程时，在 MySQL 层的 write binlog 步骤后，Master 节点须要收到至多一个 Slave 节点回复的 ACK （示意收到了binlog ）后，能力持续下一个事务； 如果在肯定工夫内（Timeout）内没有收到 ACK ，则切换为异步复制模式。 这能保证数据不失落的高可用需要，因为他能保障从库确认到这个事务后，再告诉主库提交事务。这种模式下，至多一个从库的日志数据和主库保障同步，从而保障主库挂了后，数据不失落，因为最新数据的是从库。 2. 我先说一下我的半同步保证数据一致性的相干设置 sync_binlog=1innodb_flush_log_at_trx_commit=1...(等等)好了，不列出来了，我保障我半同步设置了最靠谱设置，不会因为参数设置谬误而失落数据。 3. 我再解释一下术语: lossless semi-sync replication 、无损半同步、加强半同步，都是一回事，说的是 MySQL5.7 参数rpl_semi_sync_master_wait_point=AFTER_SYNC设置下的半同步，他是默认值，解决高可用切换后的幻读问题。MySQL5.6 没有这个参数设置，这个版本在高可用切换后有概率呈现幻读，产生数据失落，那就是数据不统一。如没有特地指出，本文的"半同步" 均指的是无损半同步。 4. 而后还有一点要留神的，kill -9 主库 mysqld 和 被动 shutdown 主库 mysqld 的行为引发高可用切换是不一样，后者行为有概率会导致幻读，也就是数据失落，具体起因看这两篇文章具体理解。 《如何正确地敞开 MySQL 数据库？99%的 DBA 都是错的！》 《技术分享 | 聊聊 MySQL 关机的故事》》 5. 我确保我测试时，半同步复制没有降级为异步复制。 ...

 在高并发的业务场景下，数据库大多数状况都是用户并发拜访最单薄的环节。所以，就须要应用redis做一个缓冲操作，让申请先拜访到redis，而不是间接拜访Mysql等数据库。这样能够大大缓解数据库的压力。具体业务流程如下：         读取缓存步骤个别没有什么问题，然而一旦波及到数据更新：数据库和缓存更新，就容易呈现缓存和数据库间的数据一致性问题。不论是先写数据库，再删除缓存；还是先删除缓存，再写库，都有可能呈现数据不统一的状况。举个例子：         1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。         2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会呈现数据不统一状况。         因为写和读是并发的，没法保障程序,就会呈现缓存和数据库的数据不统一的问题。如何解决？这里给出两个解决方案，先易后难，联合业务和技术代价抉择应用。 一、 延时双删策略        在写库前后都进行redis.del(key)操作，并且设定正当的超时工夫。具体步骤是：         1）先删除缓存         2）再写数据库         3）休眠500毫秒（依据具体的业务工夫来定）         4）再次删除缓存。         那么，这个500毫秒怎么确定的，具体该休眠多久呢？         须要评估本人的我的项目的读数据业务逻辑的耗时。这么做的目标，就是确保读申请完结，写申请能够删除读申请造成的缓存脏数据。         当然，这种策略还要思考 redis 和数据库主从同步的耗时。最初的写数据的休眠工夫：则在读数据业务逻辑的耗时的根底上，加上几百ms即可。比方：休眠1秒。 二、设置缓存的过期工夫        从实践上来说，给缓存设置过期工夫，是保障最终一致性的解决方案。所有的写操作以数据库为准，只有达到缓存过期工夫，则前面的读申请天然会从数据库中读取新值而后回填缓存         联合双删策略+缓存超时设置，这样最差的状况就是在超时工夫内数据存在不统一，而且又减少了写申请的耗时。 三、如何写完数据库后，再次删除缓存胜利？        上述的计划有一个毛病，那就是操作完数据库后，因为种种原因删除缓存失败，这时，可能就会呈现数据不统一的状况。这里，咱们须要提供一个保障重试的计划。 1、计划一具体流程        （1）更新数据库数据；          （2）缓存因为种种问题删除失败；         （3）将须要删除的key发送至音讯队列；         （4）本人生产音讯，取得须要删除的key；         （5）持续重试删除操作，直到胜利。         然而，该计划有一个毛病，对业务线代码造成大量的侵入。于是有了计划二，在计划二中，启动一个订阅程序去订阅数据库的binlog，取得须要操作的数据。在应用程序中，另起一段程序，取得这个订阅程序传来的信息，进行删除缓存操作。  2、计划二具体流程        （1）更新数据库数据；         （2）数据库会将操作信息写入binlog日志当中；         （3）订阅程序提取出所须要的数据以及key；          （4）另起一段非业务代码，取得该信息；         （5）尝试删除缓存操作，发现删除失败；          （6）将这些信息发送至音讯队列；         （7）从新从音讯队列中取得该数据，重试操作。

1、一致性常见问题 这些问题离我们并不遥远,数据分散在多处会导致数据不一致，必须尽可能地解决此问题，才能保证良好的用户体验，最终的期望是任何人、任何时间、任何地点、任何接入方式、任何服务，数据都是一致的 2、一致性模式1)、顺序一致性(Sequencial Consistency）每个线程内部的指令都是按照程序规定的顺序执行的(单个线程的视角)。线程执行的交错顺序可以是做任意的，但是所有线程所看见的整体程序总体执行顺序都是一样的(整体程序的视角) 2)、弱一致性-因果一致性(Casual Consistency)如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制 3)、弱一致性-入口一致性(Entry Consistency)入口一致性要求每个普通的共享数据都要与某种同步变量如锁(lock)或屏障(barrier)相关联 进程2在没有获取”y”数据的访问锁时，读取的值将为NIL(In the following figures, since Process2 does not hold the access right (= synchronous variable) to the data item “y”, the reading result becomes NIL) 4、弱一致性-最终一致性(Eventual consistency) 5)、弱一致性-以客户为中心的一致性（Client-centric consistency model)包括以下四种体现 （1)、单调读一致性(Monotonic reading)如果一个进程从系统中读取出一个数据项X的某个值后，该进程对于X后续访问都不应该返回更旧的值(If a process reads data item x, any subsequent reads on x by that process will either reply with the same value or reply with a newer value) ...

1.一致性协议1.1两阶段提交2PC：本身是一致强一致性算法，所以很适合用作数据库的分布式事务。其实数据库的经常用到的TCC本身就是一种2PC。 数据库事务：回顾下数据库的事务，对一条数据的修改操作首先写undo日志，记录的数据原来的样子，接下来执行事务修改操作，把数据写到redo日志里面，万一捅娄子，事务失败了，可从undo里面回复数据。 数据库通过undo与redo能保证数据的强一致性，要解决分布式事务的前提就是当个节点是支持事务的。在这个前提下,2PC将整个分布式事务分两节点： 1.第一阶段：为准备节点，事务的请求都发送给一个个资源，资源可以是数据库，也可以是其他支持事务的框架(比如zookeeper)，他们会分别执行自己的事务，写日志到undo与redo，但不提交事务。2.第二阶段：当事务管理器收到了所以资源的反馈，事务都执行没报错后，事务管理器再发送commit指令让资源把事务提交，一旦发现任何一个资源在准备阶段没有执行成功，事务管理器会发送rollback，让所有的资源都回滚。强一致性是指：保证每个资源都成功,整个分布式事务才成功. 缺点： 1.同步阻塞.----------所有的节点都在等待其他节点的响应，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。2.单点问题.----------如果协调者在提交(commit)阶段出现问题，那么整个流程将无法运转。更重要的是，其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作.3.数据不一致.-------若协调者即事务管理器未发送完所有commit请求自身崩溃，则导致一部分参与者未收到commit请求，导致数据不一致.4.容错性不好.----任何一个节点失败都会导致整个事务失败.1.2.三阶段提交 three-phase commit (3PC) 第一阶段：协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。第二阶段：如果所有服务都ok，可以接收事务请求，这一阶段就可以执行事务了，这时候也是每个资源都回写redo与undo日志，事务执行成功，返回ack（yes）,否则返回no第三阶段：这阶段和前面说的2阶段提交大同小异，这个时候协调者发现所有提交者事务提交者事务都正常执行后，给所有资源发送commit指令。与2PC区别：第二阶段才写undo和redo事务日志第三阶段协调者出现异常或网络超时参与者也会commit 三阶段3PC优点：相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，比如由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。 但回顾整个过程，不管是2pc,还是3pc，同步阻塞，单点故障，容错机制不完善这些问题都没本质上得到解决，尤其是前面说得数据一致性问题，反而更糟糕了。 所有数据库的分布式事务一般都是二阶段提交，而者三阶段的思想更多的被借鉴扩散成其他的算法 1.3.Paxos算法 paxos算法分为两个阶段，有2个角色，提议者和接受者。 关键是：1.少数服从多数2.角色轮换避免单点故障具体流程也没搞清楚~~先知道核心思想即可 2 zookeeper集群2.1 zookeeper集群特点 顺序一致性 ：客户端的更新顺序与它们被发送的顺序相一致。原子性： 更新操作要么成功要么失败，没有第三种结果。单一视图： 无论客户端连接到哪一个服务器，客户端将看到相同的 ZooKeeper 视图。可靠性： 一旦一个更新操作被应用，那么在客户端再次更新它之前，它的值将不会改变。实时性： 连接上一个服务端数据修改，所以其他的服务端都会实时的跟新，不算完全的实时，有一点延时的角色轮换避免单点故障： 当leader出现问题的时候，会选举从follower中选举一个新的leader集群中的角色 Leader： 集群工作机制中的核心 事务请求的唯一调度和处理者，保证集群事务处理的顺序性， 集群内部个服务器的调度者(管理follower,数据同步)Follower： 集群工作机制中的跟随者处理非事务请求，转发事务请求给Leader, 参与事务请求proposal投票， 参与leader选举投票Observer： 观察者 3.30以上版本提供，和follower功能相同，但不参与任何形式投票 处理非事务请求，转发事务请求给Leader 提高集群非事务处理能力2.1 zookeeper集群搭建1.安装JDK，zookeeper。 2.配置环境变量vi /etc/profile export JAVA_HOME=/usr/local/jdk1.8.0_211export ZOOKEEPER_HOME=/usr/local/zookeeperexport CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jarexport PATH=$JAVA_HOME/bin:$ZOOKEEPER_HOME/bin:$PATH 刷新profile文件source /etc/profile 关闭防火墙(命令视不同系统情况而定) 3.修改zk配置文件 mv zoo_sample.cfg zoo.cfg 修改conf: vi zoo.cfg 修改两处（1） dataDir=/usr/local/zookeeper/data（注意同时在zookeeper创建data目录） dataDirLog=/usr/local/zookeeper/log 日志目录，并创建目录（2）最后面添加server.0=192.168.64.128:2888:3888(2888是集群内机器通讯端口,3888是选举leader使用)server.1=192.168.64.129:2888:3888server.2=192.168.64.130:2888:3888 注意：server.0,server.1中，0和1就是服务器标识4.创建服务器标识 在dataDir路径下data目录下创建myid文件，内容即为0/1/2，即上述配置的。 5.复制 /usr/local/zookeeper下所有文件到另外2个服务器上面，只修改myid的服务器标识即可。 ...

Raft作为Paxos的简化版本，在工程领域有着更加广泛的应用。本文转载的几篇文章对Raft的工作原理、实现方式进行了详细的介绍。分布式系统的Raft算法总结：目前几乎所有语言都已经有支持Raft算法的库包，具体可参考：raftconsensus.github.io英文动画演示RaftCAP原理和BASE思想分布式Paxos算法分布式事务 => 分布式系统事务一致性解决方案