分布式事务

微服务的开发框架也比较多：
比较著名的有Dubbo,SpringCloud,thrift,grpc等

 

再有人问你分布式事务，把这篇扔给他

再有人问你分布式事务，把这篇扔给他

咖啡拿铁 纯洁的微笑 今天

前言

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。

事务的具体定义

事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。

数据库本地事务

ACID

说到数据库事务就不得不说，数据库事务中的四大特性，ACID:

• A:原子性(Atomicity)

一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

就像你买东西要么交钱收货一起都执行，要么要是发不出货，就退钱。

• C:一致性(Consistency)

事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。

• I:隔离性(Isolation)

指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。

打个比方，你买东西这个事情，是不影响其他人的。

• D:持久性(Durability)

指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

打个比方，你买东西的时候需要记录在账本上，即使老板忘记了那也有据可查。

InnoDB实现原理

InnoDB是mysql的一个存储引擎，大部分人对mysql都比较熟悉，这里简单介绍一下数据库事务实现的一些基本原理，在本地事务中，服务和资源在事务的包裹下可以看做是一体的:

我们的本地事务由资源管理器进行管理: 

 

而事务的 ACID 是通过 InnoDB 日志和锁来保证。事务的隔离性是通过数据库锁的机制实现的，持久性通过 Redo Log（重做日志）来实现，原子性和一致性通过 Undo Log 来实现。

Undo Log 的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为 Undo Log）。然后进行数据的修改。

如果出现了错误或者用户执行了 Rollback 语句，系统可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。

和 Undo Log 相反，Redo Log 记录的是新数据的备份。在事务提交前，只要将 Redo Log 持久化即可，不需要将数据持久化。

当系统崩溃时，虽然数据没有持久化，但是 Redo Log 已经持久化。系统可以根据 Redo Log 的内容，将所有数据恢复到最新的状态。对具体实现过程有兴趣的同学可以去自行搜索扩展。

 

分布式事务

什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

分布式事务产生的原因

从上面本地事务来看，我们可以看为两块，一个是service产生多个节点，另一个是resource产生多个节点。

service多个节点

随着互联网快速发展，微服务，SOA等服务架构模式正在被大规模的使用，举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护  这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。

resource多个节点

同样的，互联网发展得太快了，我们的Mysql一般来说装千万级的数据就得进行分库分表，对于一个支付宝的转账业务来说，你给的朋友转钱，有可能你的数据库是在北京，而你的朋友的钱是存在上海，所以我们依然无法保证他们能同时成功。 

分布式事务的基础

从上面来看分布式事务是随着互联网高速发展应运而生的，这是一个必然的我们之前说过数据库的ACID四大特性，已经无法满足我们分布式事务，这个时候又有一些新的大佬提出一些新的理论:

CAP

CAP定理，又被叫作布鲁尔定理。对于设计分布式系统来说(不仅仅是分布式事务)的架构师来说，CAP就是你的入门理论。

• C (一致性):对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致。

• A (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是返回40。

• P (分区容错性):当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。

熟悉CAP的人都知道，三者不能共有，如果感兴趣可以搜索CAP的证明，在分布式系统中，网络无法100%可靠，分区其实是一个必然现象，如果我们选择了CA而放弃了P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是A又不允许，所以分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。

对于CP来说，放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致。

对于AP来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的BASE也是根据AP来扩展。

顺便一提，CAP理论中是忽略网络延迟，也就是当事务提交时，从节点A复制到节点B，但是在现实中这个是明显不可能的，所以总会有一定的时间是不一致。同时CAP中选择两个，比如你选择了CP，并不是叫你放弃A。因为P出现的概率实在是太小了，大部分的时间你仍然需要保证CA。就算分区出现了你也要为后来的A做准备，比如通过一些日志的手段，是其他机器回复至可用。

BASE

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩展

1. 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。

2. 软状态:允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。

3. 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。

BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

分布式事务解决方案

有了上面的理论基础后，这里介绍开始介绍几种常见的分布式事务的解决方案。

是否真的要分布式事务

在说方案之前，首先你一定要明确你是否真的需要分布式事务？

上面说过出现分布式事务的两个原因，其中有个原因是因为微服务过多。我见过太多团队一个人维护几个微服务，太多团队过度设计，搞得所有人疲劳不堪，而微服务过多就会引出分布式事务，这个时候我不会建议你去采用下面任何一种方案，而是请把需要事务的微服务聚合成一个单机服务，使用数据库的本地事务。因为不论任何一种方案都会增加你系统的复杂度，这样的成本实在是太高了，千万不要因为追求某些设计，而引入不必要的成本和复杂度。

如果你确定需要引入分布式事务可以看看下面几种常见的方案。

2PC

说到2PC就不得不聊数据库分布式事务中的 XA Transactions。 在XA协议中分为两阶段:

第一阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.

第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据。

优点： 尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于MySQL是从5.5开始支持。

缺点:

• 单点问题:事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。

• 同步阻塞:在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。

• 数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。

总的来说，XA协议比较简单，成本较低，但是其单点问题，以及不能支持高并发(由于同步阻塞)依然是其最大的弱点。

TCC

关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。 TCC事务机制相比于上面介绍的XA，解决了其几个缺点: 1.解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器也变成多点，引入集群。 2.同步阻塞:引入超时，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。 3.数据一致性，有了补偿机制之后，由业务活动管理器控制一致性 对于TCC的解释:

•  

  Try阶段：尝试执行,完成所有业务检查（一致性）,预留必须业务资源（准隔离性）

   

•  

  Confirm阶段：确认执行真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm操作满足幂等性。要求具备幂等设计，Confirm失败后需要进行重试。

   

•  

  Cancel阶段：取消执行，释放Try阶段预留的业务资源 Cancel操作满足幂等性Cancel阶段的异常和Confirm阶段异常处理方案基本上一致。

   

举个简单的例子如果你用100元买了一瓶水， Try阶段:你需要向你的钱包检查是否够100元并锁住这100元，水也是一样的。

如果有一个失败，则进行cancel(释放这100元和这一瓶水)，如果cancel失败不论什么失败都进行重试cancel，所以需要保持幂等。

如果都成功，则进行confirm,确认这100元扣，和这一瓶水被卖，如果confirm失败无论什么失败则重试(会依靠活动日志进行重试)

对于TCC来说适合一些:

• 强隔离性，严格一致性要求的活动业务。

• 执行时间较短的业务

实现参考:ByteTCC:https://github.com/liuyangming/ByteTCC/

本地消息表

本地消息表这个方案最初是ebay提出的 ebay的完整方案https://queue.acm.org/detail.cfm?id=1394128。

此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。 

对于本地消息队列来说核心是把大事务转变为小事务。还是举上面用100元去买一瓶水的例子。

1.当你扣钱的时候，你需要在你扣钱的服务器上新增加一个本地消息表，你需要把你扣钱和写入减去水的库存到本地消息表放入同一个事务(依靠数据库本地事务保证一致性。

2.这个时候有个定时任务去轮询这个本地事务表，把没有发送的消息，扔给商品库存服务器，叫他减去水的库存，到达商品服务器之后这个时候得先写入这个服务器的事务表，然后进行扣减，扣减成功后，更新事务表中的状态。

3.商品服务器通过定时任务扫描消息表或者直接通知扣钱服务器，扣钱服务器本地消息表进行状态更新。

4.针对一些异常情况，定时扫描未成功处理的消息，进行重新发送，在商品服务器接到消息之后，首先判断是否是重复的，如果已经接收，在判断是否执行，如果执行在马上又进行通知事务，如果未执行，需要重新执行需要由业务保证幂等，也就是不会多扣一瓶水。

本地消息队列是BASE理论，是最终一致模型，适用于对一致性要求不高的。实现这个模型时需要注意重试的幂等。

MQ事务

在RocketMQ中实现了分布式事务，实际上其实是对本地消息表的一个封装，将本地消息表移动到了MQ内部，下面简单介绍一下MQ事务，如果想对其详细了解可以参考: https://www.jianshu.com/p/453c6e7ff81c。  

 

基本流程如下:

第一阶段Prepared消息，会拿到消息的地址。

第二阶段执行本地事务。

第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。消息接受者就能使用这个消息。

如果确认消息失败，在RocketMq Broker中提供了定时扫描没有更新状态的消息，如果有消息没有得到确认，会向消息发送者发送消息，来判断是否提交，在rocketmq中是以listener的形式给发送者，用来处理。 

 

如果消费超时，则需要一直重试，消息接收端需要保证幂等。如果消息消费失败，这个就需要人工进行处理，因为这个概率较低，如果为了这种小概率时间而设计这个复杂的流程反而得不偿失

Saga事务

Saga是30年前一篇数据库伦理提到的一个概念。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。 Saga的组成：

每个Saga由一系列sub-transaction Ti 组成 每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果,这里的每个T，都是一个本地事务。 可以看到，和TCC相比，Saga没有“预留 try”动作，它的Ti就是直接提交到库。

Saga的执行顺序有两种：

T1, T2, T3, ..., Tn

T1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < n Saga定义了两种恢复策略：

向后恢复，即上面提到的第二种执行顺序，其中j是发生错误的sub-transaction，这种做法的效果是撤销掉之前所有成功的sub-transation，使得整个Saga的执行结果撤销。 向前恢复，适用于必须要成功的场景，执行顺序是类似于这样的：T1, T2, ..., Tj(失败), Tj(重试),..., Tn，其中j是发生错误的sub-transaction。该情况下不需要Ci。

这里要注意的是，在saga模式中不能保证隔离性，因为没有锁住资源，其他事务依然可以覆盖或者影响当前事务。

还是拿100元买一瓶水的例子来说，这里定义

T1=扣100元 T2=给用户加一瓶水 T3=减库存一瓶水

C1=加100元 C2=给用户减一瓶水 C3=给库存加一瓶水

我们一次进行T1,T2，T3如果发生问题，就执行发生问题的C操作的反向。 上面说到的隔离性的问题会出现在，如果执行到T3这个时候需要执行回滚，但是这个用户已经把水喝了(另外一个事务)，回滚的时候就会发现，无法给用户减一瓶水了。这就是事务之间没有隔离性的问题

可以看见saga模式没有隔离性的影响还是较大，可以参照华为的解决方案:从业务层面入手加入一 Session 以及锁的机制来保证能够串行化操作资源。也可以在业务层面通过预先冻结资金的方式隔离这部分资源， 最后在业务操作的过程中可以通过及时读取当前状态的方式获取到最新的更新。

具体实例:可以参考华为的servicecomb

最后

还是那句话，能不用分布式事务就不用，如果非得使用的话，结合自己的业务分析，看看自己的业务比较适合哪一种，是在乎强一致，还是最终一致即可。最后在总结一些问题,大家可以下来自己从文章找寻答案:

1. ACID和CAP的 CA是一样的吗？

2. 分布式事务常用的解决方案的优缺点是什么？适用于什么场景？

3. 分布式事务出现的原因？用来解决什么痛点？

如果上面问题有什么疑问的话可以关注公众号，来和我一起讨论吧。

 

===========================================================================================================================================================================================================================================================================

 

一张图让你看懂InnoDB

 

熟悉MySQL的人，都知道InnoDB存储引擎，如大家所知，Redo Log是innodb的核心事务日志之一，innodb写入Redo Log后就会提交事务，而非写入到Datafile。之后innodb再异步地将新事务的数据异步地写入Datafile，真正存储起来。

那么innodb引擎有了redo log和buffer pool以后，为什么能够在提升性能的同时，还能保证不丢数据呢? Buffer Pool, Redo Log以及Datafile之间的具体关系是什么呢。

另外Innodb还有一大堆概念，Dirty Page, LRU, LSN，Checkpoint等等，这些概念在Innodb里是什么运作的呢？

下面通过一张图来告诉大家

Buffer Pool, Redo Log以及Datafile的关系

图1 Innodb的原理

大家可以把innodb的事务写入过程看成写作一篇文章的过程。Innodb的写入过程其实和我们写作的过程是非常类似的。

试想，领导让我们写一篇文章，发表在论坛上。然后我们想到了一个绝佳的点子，并决定要放到文章里，可是手上还有其他事情，一时半会儿写不完，又担心过后忘了，领导还等着我们答复，此时我们会怎么做呢？我们一定会先大概构思个提纲，并把提纲和一些关键细节记录到本子上，作为草稿，然后立刻告诉领导自己要写什么东西，让其确认。最后等晚上有时间了，再根据草稿去斟词酌句，编写正稿。

在这个过程中，我们用到的几个关键的东西：

我们的大脑，用来临时暂时记住我们的点子

草稿，我们需要草稿来保证不会把点子和关键的细节给忘了

正稿，这是我们最终要输出的东西

有了这几个东西，我们不仅能确保我们不会错过一篇漂亮的文章，还能快速告诉领导自己一定可以搞定这件事情。

Innodb实际上也用到了这几个关键的东西：

Buffer Pool：就是我们的大脑

事务日志：就是我们的草稿

Datafile：就是我们的正稿

只要按照之前写文章的过程，来进行整个事务的写入操作，不仅能保证不丢失数据，而且能够快速响应。

一次写入操作是一次事务，innodb首先把事务数据写入到Buffer Pool和事务日志中，也就是在大脑中记忆下来，并写下草稿。然后就可以提交事务，响应客户端了。之后innodb在“有时间的时候”，异步地把这次写入的数据从Buffer Pool，或者事务日志中正式地写入到Datafile中，形成“正稿”。

其中，innodb为了保证事务日志这个“草稿”一定能无损地还原成正稿，还不能占用太多空间，事务日志需要有以下特点：

事务日志中一定保存了要写入的所有数据内容

事务日志只会把新事务追加在日志最后，而不会去修改之前的内容

一旦事务数据被写到datafile，事务日志中的“草稿”就可以删除了

通过上面3个特点我们可以看出，在形成“正稿”之前，“草稿”是不会被删除的；同时，“草稿”的空间是可以被循环利用的；最后，只要“草稿”在，我们一定能写出“正稿”。

这里还需要说明的，是Recovery流程。也就是如果在形成“正稿”前，数据库Crash了，我们需要重启整个进程，服务器，甚至只能把数据复制到另外一台服务器来进行恢复。这个时候，事务日志这个“草稿”就发挥了它最大的作用——数据恢复。这也和我们在工作生活中常出现的问题——把事情忘了——非常类似。

Buffer Pool本质就是存储于内存中的一个数据结构，内存和人的大脑一样，是“健忘”的。数据库Crash时，Buffer Pool中的数据极大可能“灰飞烟灭”了。因此，事务日志就如我们贴心的“记事本”，它把我们的记忆，保存为“草稿”，当我们忘了的时候，就可以翻开，把记忆重新回想起来。

图2 恢复的逻辑

LSN和Checkpoint

上面介绍了一次写入事务的情况，而数据库在使用过程中，事务都是连续不断，根据上面所述innodb逻辑，写“草稿”和写“正稿”速度和进度绝大部分情况下是不一样的。

再继续上面“写作文章”例子，如果我们的文章很长，一天写不完，而白天都有其他工作，我们只能记录草稿，只有晚上回去才能继续写正稿。那么我们就面临一个问题：我们昨天写到哪了。

最常见的办法就是，每天晚上去对照一下草稿的内容和正稿的内容，以此来判断写到哪了，但这比较花时间，因为正稿中可能包含了很多华丽的语句，我们需要思考一下才能对比上内容。

另外一个更简单的办法，就是每天晚上写完正稿后，我们在草稿上做个标记，标记下最后一条被写为正稿的内容，这样第二天晚上，我们就可以从这个标记的后面一条开始，继续写我们的正稿，而不需要去对比内容。

显然第二个方法效率更高，而且没有什么额外的风险。因此innodb就使用了这个办法。LSN是草稿上每一条记录的编号，我们每天晚上标记下最后一条写到正稿的记录编号，这个标记的编号，就是Checkpoint。Innodb根据这个checkpoint，就可以很快知道上次回放到哪里，同时也可以把这个编号之前的草稿，全部删掉了。

 

===========================================================================================================================================================================================================================================================================

Dirty Page, LRU, LSN，Checkpoint

关于checkpoint

Ⅰ、Checkpoint

1.1 checkpoint的作用

• 缩短数据库的恢复时间
• 缓冲池不够用时,将脏页刷到磁盘
• 重做日志不可用时,刷新脏页

1.2 展开分析

page被缓存在bp中,page在bp中和disk中不是时刻保持一致的(page修改一下就刷一次盘是不现实的,是通过checkpoint来玩的)

万一宕机,重启的时候disk上那个page需要恢复到原来bp中page的那个版本

那问题是,两个page版本不一致咋整？没事,我们做到最终一致就行

那我们就说一下这个最终一致是个怎样的过程,通过一个例子来说明：

Step1：
一个page读到bp中时,它的lsn（这个鬼东西待会儿仔细说,先理解为一个flag）是100,然后这个page被modify了,它的lsn变成了130,当对应的事务提交后,修改日志会被记录到redo里面,此时redo和全局的lsn就相应的变成了130
Step2：
另外一个page之前进bp的时候lsn是50,前面那个page被modify之后,它也被修改,它的lsn变成了140,它这个140的lsn也写到了redo里,全局lsn变成140
Step3：
关键的一步,假设此时lsn为130的page被刷到disk上了（什么时候刷也是个学问,这里不说）,而lsn为140的那个page还没被刷,磁盘上保存的还是老版本,突然宕机了。
Step4：
这时候restart数据库,就会从磁盘上cp的位置(130)开始读redo log,一直回放到140,这样没被刷到磁盘的那个page就恢复到宕机之前的状态了。

划重点：

①这个130,140其实就是字节数,也就是说你对这个页修改产生了10个字节的日志,那么lsn就加10

②page原来读进bp的lsn甭管,只管它改变了多少字节就行,所以这个lsn的变化肯定是一个单调递增的过程,其实lsn就是日志写了多少字节(之前没理解好,以为各个page的lsn是自己玩自己的)

Ⅱ、LSN(log sequence number)——日志序列号

lsn是用来保存checkpoint的,保存现在刷新到磁盘的位置在哪里

这个130,140其实就是字节数,也就是说你对这个页修改产生了10个字节的日志,那么lsn就加10,lsn没有上限,8字节

2.1 lsn存在什么地方？

• 每个page有一个LSN,page更新一下LSN就会更新一下,记录在page header中
• 整个MySQL实例也有一个LSN(这就是checkpoint),记录在第一个重做日志的前2k的块里(就给它用,不会被覆盖)
• redo log里有一个LSN

全局lsn位置之前的内容已经刷磁盘上,只要恢复它后面的日志,数据就恢复了

2.2 查看lsn和整个checkpoint流程梳理

看page中的lsn,page中其实是保存两个lsn的,如下：

(root@172.16.0.10) [(none)]>  desc information_schema.INNODB_BUFFER_PAGE_LRU;
+---------------------+---------------------+------+-----+---------+-------+
| Field               | Type                | Null | Key | Default | Extra |
+---------------------+---------------------+------+-----+---------+-------+
| POOL_ID             | bigint(21) unsigned | NO   |     | 0       |       |
| LRU_POSITION        | bigint(21) unsigned | NO   |     | 0       |       |
| SPACE               | bigint(21) unsigned | NO   |     | 0       |       |
| PAGE_NUMBER         | bigint(21) unsigned | NO   |     | 0       |       |
| PAGE_TYPE           | varchar(64)         | YES  |     | NULL    |       |
| FLUSH_TYPE          | bigint(21) unsigned | NO   |     | 0       |       |
| FIX_COUNT           | bigint(21) unsigned | NO   |     | 0       |       |
| IS_HASHED           | varchar(3)          | YES  |     | NULL    |       |
| NEWEST_MODIFICATION | bigint(21) unsigned | NO   |     | 0       |       |
| OLDEST_MODIFICATION | bigint(21) unsigned | NO   |     | 0       |       |
| ACCESS_TIME         | bigint(21) unsigned | NO   |     | 0       |       |
| TABLE_NAME          | varchar(1024)       | YES  |     | NULL    |       |
| INDEX_NAME          | varchar(1024)       | YES  |     | NULL    |       |
| NUMBER_RECORDS      | bigint(21) unsigned | NO   |     | 0       |       |
| DATA_SIZE           | bigint(21) unsigned | NO   |     | 0       |       |
| COMPRESSED_SIZE     | bigint(21) unsigned | NO   |     | 0       |       |
| COMPRESSED          | varchar(3)          | YES  |     | NULL    |       |
| IO_FIX              | varchar(64)         | YES  |     | NULL    |       |
| IS_OLD              | varchar(3)          | YES  |     | NULL    |       |
| FREE_PAGE_CLOCK     | bigint(21) unsigned | NO   |     | 0       |       |
+---------------------+---------------------+------+-----+---------+-------+
20 rows in set (0.00 sec)

newest_modification 页最新更新完后的lsn
oldest_modification 页第一次更新完后的lsn
page刷到磁盘的时候,全局的check_point保存的是oldest(只保存第一次修改时的lsn),而page中的lsn保存的是newest

(root@172.16.0.10) [(none)]> show engine innodb status\G
...
---
LOG
---
Log sequence number 15151135824   当前内存中最新的LSN
Log flushed up to   15151135824   redo刷到磁盘的LSN
Pages flushed up to 15151135824   最后一个刷到磁盘上的页的最新的LSN（NEWEST_MODIFICATION）
Last checkpoint at  15151135815   最后一个刷到磁盘上的页的第一次被修改时的LSN（OLDEST_MODIFICATION）
...

Log sequence number和Log flushed up这两个LSN可能会不同,运行过程中后者可能会小于 前者,因为redo日志也是先在内存中更新,再刷到磁盘的

最后一个小于前面三个,为什么？

脏页会被指向flush list这个就不多赘述了

flush list是根据lsn进行组织的,而且还是用一个page第一次放进来的lsn进行组织的,也就是说这个page再次发生更新,它的位置是不会移动的

分析一波：

bp的LRU列表中,一个page,假设LSN进来的时候是100,当前全局LSN也是100,如果这个page变化了,产生了20字节的日志,这时候page的lsn变成120,并且通过指针指向flush list中去了,但是这个page立马又被更新产生20字节日志,此时page的lsn为140,而此时在flush list中的lsn还是120(这里意思就是page里面保存了两种lsn,一个是第一次修改页的,一个是最后一次修改页的)

当这个lsn为120的page被刷到disk上,那么disk上的cp就是120了,但是上面的三个值都是140,是不是很好理解呢,那就是说,每个page只更新一次,那这四个值就相等了呗,23333！

为什么这么设计？

为了恢复的时候,保证redo回放的过程的连续性,不会出错

page A第一次修改后lsn是120,记录到全局lsn,后面还有个page B被更新,lsn变为140,此时,page A再更新,lsn变为160了。这时候发生宕机,page A被刷到磁盘,page B没刷过去,如果flush list里面记录160的话,发生故障重启时lsn为140的page B怎么恢复？是不是被跳过去了

那从120开始恢复,那个页已经是160了,为什么还要恢复？

数据库会检测,如果page的lsn大于实例的lsn,就不会恢复这个page,跨过去,只将page B从120恢复到140

tips：

①checkpoint不需要实时刷新到磁盘,不是一个页更新了就要更新磁盘上的cp,磁盘上的cp前置一点是没有关系的,大不了多scan一点redo log,读到不回放就是了,而是由master_thread控制,差不多每秒钟更新一次

②回滚问题

回滚不是通过redo来回滚的,所有的page前滚到一个位置(恢复完),这些page对应的事务还是活跃的,还没提交,之后这些事务都会通过undo log来undo回滚,但undo是通过redo来恢复的

比如一个页120-160已经恢复过去了,但是这个事务需要回滚,却又已经刷到磁盘了,没关系,通过undo log往回滚一下就好了

事务活跃列表存放在undo段中,只要事务没提交就在里面,提交后移动到undo的history中,这个历史列表是用来做purge的,这里面的undo会被慢慢回收

Ⅲ、checkpoint 分类

• Sharp Checkpoint
  将所有的赃页都刷新回磁盘,刷新时系统hang住,InnoDB关闭时使用
  相关参数：innodb_fast_shutdown={1|0}
• Fuzzy Checkpoint
  将部分脏页刷新回磁盘,对系统影响较小
  innodb_io_capacity来控制,最小限制为100,表示一次最多刷新脏页的能力,与IOPS相关
  SSD可以设置在4000-8000,SAS最多设置在800多（IOPS在1000左右）

Ⅳ、什么时候刷dirty page

• 以前在master thread线程中(从flush_list中进行刷新)

  现在都在page_cleaner_thread线程中(每一秒,每十秒)

• FLUSH_LRU_LIST 刷新

  5.5以前需要保证在LRU_LIST尾部要有100个空闲页（可替换的页）,即刷新一部分数据 ,保证有100个空闲页。

  由innodb_lru_scan_depth参数来控制,并不只是刷最后一个页,默认探测尾部1024个页（默认）,1024个页中所有脏页会一起刷掉,该参数是应用到每个Buffer Pool,总数即为该值乘以Buffer Pool的个数,总量超过innodb_io_capacity是不合理的,即此参数不得超过innodb_io_capacity/innodb_buffer_pool_instances,ssd的话,可以适当把这个扫描深度调深一点

• Async/Sync Flush Checkpoint
  重做日志重用

• Dirty Page too much
  赃页比例超过bp总量的一定比例,本来是通过page_cleaner_thread来刷,但是脏页太多了,就会强行刷,由innodb_max_dirty_pages_pct参数控制

tips：

①页只会从flush_list中刷新这个观点是不对的,只有page_cleaner_thread定期问flush_list要脏页,一个一个刷,刷到innodb_io_capacity的比例值

②LRU list中既存在干净的页也存在脏页,假设最后一个页,是脏的,另一个线程需要一个页,free list已经空了,lru会把这个页淘汰给这个线程去使用,这时候也需要刷新这个脏页,默认一下探测1024个page,把脏页刷掉

 

====================================================================================================================================================================================================================================================================================================================================================================

 

gRPC基础：C++

http://doc.oschina.net/grpc?t=57966

 

本教程提供了C++程序员如何使用gRPC的指南。

通过学习教程中例子，你可以学会如何：

• 在一个 .proto 文件内定义服务.
• 用 protocol buffer 编译器生成服务器和客户端代码.
• 使用 gRPC 的 C++ API 为你的服务实现一个简单的客户端和服务器.

假设你已经阅读了概览并且熟悉protocol buffers. 注意，教程中的例子使用的是 protocol buffers 语言的 proto3 版本，它目前只是 alpha 版：可以在proto3 语言指南和 protocol buffers 的 Github 仓库的版本注释发现更多关于新版本的内容.

这算不上是一个在 C++ 中使用 gRPC 的综合指南：以后会有更多的参考文档.

为什么使用 gRPC?

我们的例子是一个简单的路由映射的应用，它允许客户端获取路由特性的信息，生成路由的总结，以及交互路由信息，如服务器和其他客户端的流量更新。

有了 gRPC， 我们可以一次性的在一个 .proto 文件中定义服务并使用任何支持它的语言去实现客户端和服务器，反过来，它们可以在各种环境中，从Google的服务器到你自己的平板电脑- gRPC 帮你解决了不同语言间通信的复杂性以及环境的不同.使用 protocol buffers 还能获得其他好处，包括高效的序列号，简单的 IDL 以及容易进行接口更新。

例子代码和设置

教程的代码在这里 grpc/grpc/examples/cpp/route_guide. 要下载例子，通过运行下面的命令去克隆grpc代码库：

$ git clone https://github.com/grpc/grpc.git

改变当前的目录到examples/cpp/route_guide：

$ cd examples/cpp/route_guide

你还需要安装生成服务器和客户端的接口代码相关工具-如果你还没有安装的话，查看下面的设置指南 C++快速开始指南。

定义服务

我们的第一步(可以从概览中得知)是使用 protocol buffers去定义 gRPC service 和方法 request 以及 response 的类型。你可以在examples/protos/route_guide.proto看到完整的 .proto 文件。

要定义一个服务，你必须在你的 .proto 文件中指定 service：

service RouteGuide {
   ...
}

然后在你的服务中定义 rpc 方法，指定请求的和响应类型。gRPC允 许你定义4种类型的 service 方法，在 RouteGuide 服务中都有使用：

• 一个 简单 RPC ， 客户端使用存根发送请求到服务器并等待响应返回，就像平常的函数调用一样。

   // Obtains the feature at a given position.
   rpc GetFeature(Point) returns (Feature) {}

• 一个 服务器端流式 RPC ， 客户端发送请求到服务器，拿到一个流去读取返回的消息序列。 客户端读取返回的流，直到里面没有任何消息。从例子中可以看出，通过在 响应 类型前插入 stream 关键字，可以指定一个服务器端的流方法。

  // Obtains the Features available within the given Rectangle.  Results are
  // streamed rather than returned at once (e.g. in a response message with a
  // repeated field), as the rectangle may cover a large area and contain a
  // huge number of features.
  rpc ListFeatures(Rectangle) returns (stream Feature) {}

• 一个 客户端流式 RPC ， 客户端写入一个消息序列并将其发送到服务器，同样也是使用流。一旦客户端完成写入消息，它等待服务器完成读取返回它的响应。通过在 请求 类型前指定 stream 关键字来指定一个客户端的流方法。

  // Accepts a stream of Points on a route being traversed, returning a
  // RouteSummary when traversal is completed.
  rpc RecordRoute(stream Point) returns (RouteSummary) {}

• 一个 双向流式 RPC 是双方使用读写流去发送一个消息序列。两个流独立操作，因此客户端和服务器可以以任意喜欢的顺序读写：比如， 服务器可以在写入响应前等待接收所有的客户端消息，或者可以交替的读取和写入消息，或者其他读写的组合。 每个流中的消息顺序被预留。你可以通过在请求和响应前加 stream 关键字去制定方法的类型。

  // Accepts a stream of RouteNotes sent while a route is being traversed,
  // while receiving other RouteNotes (e.g. from other users).
  rpc RouteChat(stream RouteNote) returns (stream RouteNote) {}

我们的 .proto 文件也包含了所有请求的 protocol buffer 消息类型定义以及在服务方法中使用的响应类型-比如，下面的Point消息类型：

// Points are represented as latitude-longitude pairs in the E7 representation
// (degrees multiplied by 10**7 and rounded to the nearest integer).
// Latitudes should be in the range +/- 90 degrees and longitude should be in
// the range +/- 180 degrees (inclusive).
message Point {
  int32 latitude = 1;
  int32 longitude = 2;
}

生成客户端和服务器端代码

接下来我们需要从 .proto 的服务定义中生成 gRPC 客户端和服务器端的接口。我们通过 protocol buffer 的编译器 protoc 以及一个特殊的 gRPC C++ 插件来完成。

简单起见，我们提供一个 makefile 帮您用合适的插件，输入，输出去运行 protoc(如果你想自己去运行，确保你已经安装了 protoc，并且请遵循下面的 gRPC 代码安装指南)来操作：

$ make route_guide.grpc.pb.cc route_guide.pb.cc

实际上运行的是：

$ protoc -I ../../protos --grpc_out=. --plugin=protoc-gen-grpc=`which grpc_cpp_plugin` ../../protos/route_guide.proto
$ protoc -I ../../protos --cpp_out=. ../../protos/route_guide.proto

运行这个命令可以在当前目录中生成下面的文件：

• route_guide.pb.h， 声明生成的消息类的头文件
• route_guide.pb.cc， 包含消息类的实现
• route_guide.grpc.pb.h， 声明你生成的服务类的头文件
• route_guide.grpc.pb.cc， 包含服务类的实现

这些包括：

• 所有的填充，序列化和获取我们请求和响应消息类型的 protocol buffer 代码
• 名为 RouteGuide 的类，包含
  • 为了客户端去调用定义在 RouteGuide 服务的远程接口类型(或者 存根 )
  • 让服务器去实现的两个抽象接口，同时包括定义在 RouteGuide 中的方法。

创建服务器

首先来看看我们如何创建一个 RouteGuide 服务器。如果你只对创建 gRPC 客户端感兴趣，你可以跳过这个部分，直接到创建客户端 (当然你也可能发现它也很有意思)。

让 RouteGuide 服务工作有两个部分：

• 实现我们服务定义的生成的服务接口：做我们的服务的实际的“工作”。
• 运行一个 gRPC 服务器，监听来自客户端的请求并返回服务的响应。

你可以从examples/cpp/route_guide/route_guide_server.cc看到我们的 RouteGuide 服务器的实现代码。现在让我们近距离研究它是如何工作的。

实现RouteGuide

我们可以看出，服务器有一个实现了生成的 RouteGuide::Service 接口的 RouteGuideImpl 类：

class RouteGuideImpl final : public RouteGuide::Service {
...
}

在这个场景下，我们正在实现 同步 版本的RouteGuide，它提供了 gRPC 服务器缺省的行为。同时，也有可能去实现一个异步的接口 RouteGuide::AsyncService，它允许你进一步定制服务器线程的行为，虽然在本教程中我们并不关注这点。

RouteGuideImpl 实现了所有的服务方法。让我们先来看看最简单的类型 GetFeature，它从客户端拿到一个 Point 然后将对应的特性返回给数据库中的 Feature。

  Status GetFeature(ServerContext* context, const Point* point,
                    Feature* feature) override {
    feature->set_name(GetFeatureName(*point, feature_list_));
    feature->mutable_location()——>CopyFrom(*point);
    return Status::OK;
  }

这个方法为 RPC 传递了一个上下文对象，包含了客户端的 Point protocol buffer 请求以及一个填充响应信息的Feature protocol buffer。在这个方法中，我们用适当的信息填充 Feature，然后返回OK的状态，告诉 gRPC 我们已经处理完 RPC，并且 Feature 可以返回给客户端。

现在让我们看看更加复杂点的情况——流式RPC。 ListFeatures 是一个服务器端的流式 RPC，因此我们需要给客户端返回多个 Feature。

  Status ListFeatures(ServerContext* context, const Rectangle* rectangle,
                      ServerWriter<Feature>* writer) override {
    auto lo = rectangle->lo();
    auto hi = rectangle->hi();
    long left = std::min(lo.longitude(), hi.longitude());
    long right = std::max(lo.longitude(), hi.longitude());
    long top = std::max(lo.latitude(), hi.latitude());
    long bottom = std::min(lo.latitude(), hi.latitude());
    for (const Feature& f : feature_list_) {
      if (f.location().longitude() >= left &&
          f.location().longitude() <= right &&
          f.location().latitude() >= bottom &&
          f.location().latitude() <= top) {
        writer->Write(f);
      }
    }
    return Status::OK;
  }

如你所见，这次我们拿到了一个请求对象(客户端期望在 Rectangle 中找到的 Feature)以及一个特殊的 ServerWriter 对象，而不是在我们的方法参数中获取简单的请求和响应对象。在方法中，根据返回的需要填充足够多的 Feature 对象，用 ServerWriter 的 Write() 方法写入。最后，和我们简单的 RPC 例子相同，我们返回Status::OK去告知gRPC我们已经完成了响应的写入。

如果你看过客户端流方法RecordRoute，你会发现它很类似，除了这次我们拿到的是一个ServerReader而不是请求对象和单一的响应。我们使用 ServerReader 的 Read() 方法去重复的往请求对象(在这个场景下是一个 Point)读取客户端的请求直到没有更多的消息：在每次调用后，服务器需要检查 Read() 的返回值。如果返回值为 true，流仍然存在，它就可以继续读取；如果返回值为 false，则表明消息流已经停止。

while (stream->Read(&point)) {
  ...//process client input
}

最后，让我们看看双向流RPCRouteChat()。

  Status RouteChat(ServerContext* context,
                   ServerReaderWriter<RouteNote, RouteNote>* stream) override {
    std::vector<RouteNote> received_notes;
    RouteNote note;
    while (stream->Read(&note)) {
      for (const RouteNote& n : received_notes) {
        if (n.location().latitude() == note.location().latitude() &&
            n.location().longitude() == note.location().longitude()) {
          stream->Write(n);
        }
      }
      received_notes.push_back(note);
    }

    return Status::OK;
  }

这次我们得到的 ServerReaderWriter 对象可以用来读 和 写消息。这里读写的语法和我们客户端流以及服务器流方法是一样的。虽然每一端获取对方信息的顺序和写入的顺序一致，客户端和服务器都可以以任意顺序读写——流的操作是完全独立的。

启动服务器

一旦我们实现了所有的方法，我们还需要启动一个gRPC服务器，这样客户端才可以使用服务。下面这段代码展示了在我们RouteGuide服务中实现的过程：

void RunServer(const std::string& db_path) {
  std::string server_address("0.0.0.0:50051");
  RouteGuideImpl service(db_path);

  ServerBuilder builder;
  builder.AddListeningPort(server_address, grpc::InsecureServerCredentials());
  builder.RegisterService(&service);
  std::unique_ptr<Server> server(builder.BuildAndStart());
  std::cout << "Server listening on " << server_address << std::endl;
  server->Wait();
}

如你所见，我们通过使用ServerBuilder去构建和启动服务器。为了做到这点，我们需要：

1. 创建我们的服务实现类 RouteGuideImpl 的一个实例。
2. 创建工厂类 ServerBuilder 的一个实例。
3. 在生成器的 AddListeningPort() 方法中指定客户端请求时监听的地址和端口。
4. 用生成器注册我们的服务实现。
5. 调用生成器的 BuildAndStart() 方法为我们的服务创建和启动一个RPC服务器。
6. 调用服务器的 Wait() 方法实现阻塞等待，直到进程被杀死或者 Shutdown() 被调用。

<a name="client"></a>

创建客户端

在这部分，我们将尝试为RouteGuide服务创建一个C++的客户端。你可以从examples/cpp/route_guide/route_guide_client.cc看到我们完整的客户端例子代码.

创建一个存根

为了能调用服务的方法，我们得先创建一个 存根。

首先需要为我们的存根创建一个gRPC channel，指定我们想连接的服务器地址和端口，以及 channel 相关的参数——在本例中我们使用了缺省的 ChannelArguments 并且没有使用SSL：

grpc::CreateChannel("localhost:50051", grpc::InsecureCredentials(), ChannelArguments());

现在我们可以利用channel，使用从.proto中生成的RouteGuide类提供的NewStub方法去创建存根。

 public:
  RouteGuideClient(std::shared_ptr<ChannelInterface> channel,
                   const std::string& db)
      : stub_(RouteGuide::NewStub(channel)) {
    ...
  }

调用服务的方法

现在我们来看看如何调用服务的方法。注意，在本教程中调用的方法，都是 阻塞/同步 的版本：这意味着 RPC 调用会等待服务器响应，要么返回响应，要么引起一个异常。

简单RPC

调用简单 RPC GetFeature 几乎是和调用一个本地方法一样直观。

  Point point;
  Feature feature;
  point = MakePoint(409146138, -746188906);
  GetOneFeature(point, &feature);

...

  bool GetOneFeature(const Point& point, Feature* feature) {
    ClientContext context;
    Status status = stub_->GetFeature(&context, point, feature);
    ...
  }

如你所见，我们创建并且填充了一个请求的 protocol buffer 对象（例子中为 Point），同时为了服务器填写创建了一个响应 protocol buffer 对象。为了调用我们还创建了一个 ClientContext 对象——你可以随意的设置该对象上的配置的值，比如期限，虽然现在我们会使用缺省的设置。注意，你不能在不同的调用间重复使用这个对象。最后，我们在存根上调用这个方法，将其传给上下文，请求以及响应。如果方法的返回是OK，那么我们就可以从服务器从我们的响应对象中读取响应信息。

      std:：cout << "Found feature called " << feature->name()  << " at "
                << feature->location().latitude()/kCoordFactor_ << ", "
                << feature->location().longitude()/kCoordFactor_ << std:：endl;

流式RPC

现在来看看我们的流方法。如果你已经读过创建服务器，本节的一些内容看上去很熟悉——流式 RPC 是在客户端和服务器两端以一种类似的方式实现的。下面就是我们称作是服务器端的流方法 ListFeatures，它会返回地理的 Feature：

    std::unique_ptr<ClientReader<Feature> > reader(
        stub_->ListFeatures(&context, rect));
    while (reader->Read(&feature)) {
      std::cout << "Found feature called "
                << feature.name() << " at "
                << feature.location().latitude()/kCoordFactor_ << ", "
                << feature.location().longitude()/kCoordFactor_ << std::endl;
    }
    Status status = reader->Finish();

我们将上下文传给方法并且请求，得到 ClientReader 返回对象，而不是将上下文，请求和响应传给方法。客户端可以使用 ClientReader 去读取服务器的响应。我们使用 ClientReader 的 Read() 反复读取服务器的响应到一个响应 protocol buffer 对象(在这个例子中是一个 Feature)，直到没有更多的消息：客户端需要去检查每次调用完 Read() 方法的返回值。如果返回值为 true，流依然存在并且可以持续读取；如果是 false，说明消息流已经结束。最后，我们在流上调用 Finish() 方法结束调用并获取我们 RPC 的状态。

客户端的流方法 RecordRoute 的使用很相似，除了我们将一个上下文和响应对象传给方法，拿到一个 ClientWriter 返回。

    std::unique_ptr<ClientWriter<Point> > writer(
        stub_->RecordRoute(&context, &stats));
    for (int i = 0; i < kPoints; i++) {
      const Feature& f = feature_list_[feature_distribution(generator)];
      std::cout << "Visiting point "
                << f.location().latitude()/kCoordFactor_ << ", "
                << f.location().longitude()/kCoordFactor_ << std::endl;
      if (!writer->Write(f.location())) {
        // Broken stream.
        break;
      }
      std::this_thread::sleep_for(std::chrono::milliseconds(
          delay_distribution(generator)));
    }
    writer->WritesDone();
    Status status = writer->Finish();
    if (status.IsOk()) {
      std::cout << "Finished trip with " << stats.point_count() << " points\n"
                << "Passed " << stats.feature_count() << " features\n"
                << "Travelled " << stats.distance() << " meters\n"
                << "It took " << stats.elapsed_time() << " seconds"
                << std::endl;
    } else {
      std::cout << "RecordRoute rpc failed." << std::endl;
    }

一旦我们用 Write() 将客户端请求写入到流的动作完成，我们需要在流上调用 WritesDone() 通知 gRPC 我们已经完成写入，然后调用 Finish() 完成调用同时拿到 RPC 的状态。如果状态是 OK，我们最初传给 RecordRoute() 的响应对象会跟着服务器的响应被填充。

最后，让我们看看双向流式 RPC RouteChat()。在这种场景下，我们将上下文传给一个方法，拿到一个可以用来读写消息的ClientReaderWriter的返回。

    std::shared_ptr<ClientReaderWriter<RouteNote, RouteNote> > stream(
        stub_->RouteChat(&context));

这里读写的语法和我们客户端流以及服务器端流方法没有任何区别。虽然每一方都能按照写入时的顺序拿到另一方的消息，客户端和服务器端都可以以任意顺序读写——流操作起来是完全独立的。

来试试吧！

构建客户端和服务器：

$ make

运行服务器，它会监听50051端口：

$ ./route_guide_server

在另外一个终端运行客户端：

$ ./route_guide_client