1.elasticsearch的问题

1.为什么要用？Elasticsearch?

因为未来我们商场的数据会很多，所以使用之前的模糊查询和模糊查询的前置配置会放弃索引，导致商品查询是全表面扫描。在百万级数据库中，效率很低，我们使用它ES做一个全文索引，我们会经常查询商品的某些字段，如商品名称、描述、价格和id我们将这些字段放入我们的索引库可以提高查询速度。

2.elasticsearch 什么是倒排索引？

我们的传统搜索是通过文章逐一找到相应关键词的位置。

通过分词策略，倒排索引形成了词与文章的映射关系表，这是词典映射表

即倒排索引。

通过倒排索引，可以实现 o(1)时间复杂性的效率检索文章大大提高了

检索效率。

学术的解答方式：

倒排索引，相反，一篇文章中包含了哪些单词，它从单词开始，记录了哪些单词

由词典和倒排表两部分组成。

3、elasticsearch 是如何实现 master 选举的

4.详细描述Elasticsearch索引文档的过程。

协调节点默认使用文档ID参与计算(也支持通过routing），为路由提供合适的分片。 shard = hash(document_id) % (num_of_primary_shards) 当分片所在的节点收到协调节点的请求时，请求将写入Memory Buffer，然后定期(默认为每1秒)写入Filesystem Cache，这个从Momery Buffer到Filesystem Cache这个过程叫做refresh；当然，在某些情况下，存在Momery Buffer和Filesystem Cache数据可能会丢失，ES是通过translog保证数据可靠性的机制。事实上，实现机制是在收到请求后写入的translog中，当Filesystem cache当数据写入磁盘时，它将被删除，这个过程被称为flush；在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync创建新的提交点，刷新磁盘和旧的内容translog删除并开始一个新的translog。 flush定时触发(默认30分钟)或translog变得太大(默认为512M）时；

5.详细描述Elasticsearch搜索的过程

搜索被执行成两个阶段，我们称之为 Query Then Fetch；在初始查询阶段，查询将广播到索引中的每个片段副本（主片或副本片）。每个分片在当地搜索并构建匹配文档的大小 from size 优先队列。PS：搜索时会查询Filesystem Cache是的，但些数据仍然存在Memory Buffer，所以搜索是近实时的。每个分片返回各自的优先队列所有文档的 ID 和排序值对于协调节点，它将这些值合并到自己的优先队列中，以产生全局排序后的结果列表。接下来就是在回收阶段，协调节点确定哪些文档需要回收，并向相关分片提交多个文件 GET 请求。加载并加载每个片段。丰富文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。补充：Query Then Fetch文档相关性评分时，搜索类型是指本分片的数据，因此当文档数量较少时，可能不准确，DFS Query Then Fetch增加预查询处理，查询Term和Document frequency，这个分数比较准确，但是性能会变差。

6.Elasticsearch的搭建

查询速度快，分词

elasticsearch比solr好的地方持续更新

数据存在于分片上，分片均匀分布在所有节点上

加粗边框的主分片负分片不粗

kinana一张图胜过千万行日志

logstash导入数据

spring

2.Minor GC和Full GC总结触发条件

在 Java 堆分为两个不同的区域：新一代 ( Young )、老年代 ( Old)。新生代 ( Young ) 又分为三个区域：Eden、S0、S1。这种划分的目的是为了使 JVM 能更好地管理堆内存中的对象，包括内存的分配和回收。

1.年轻代

年轻一代的初级回收分为三个区域，一个新生代 , 2个大小相同的复活代, 应用程序只能使用新一代和复活一代，初级垃圾回收发生时，gc挂起程序, 然后将新生代和复活代中的存活对象复制到另外一个非活动的复活代中,然后一次性清除新生代和复活代，将原来的非复活代标记成为活动复活代。将指定次数回收后仍存在的对象移动到老年人，初级回收后，得到空的新一代。

HotSpot复制算法流程如下：

?1. 当Eden当区域满时，第一次触发Minor gc,将还活着的对象复制到Survivor From区；当Eden区再次触发Minor gc会扫描Eden区和From这两个区域的垃圾回收直接复制到两个区域。To区域,并将Eden和From区域清空。

?2. 当后续Eden又发生Minor gc会对的Eden和To垃圾回收区域，生存对象复制到From区域,并将Eden和To区域清空。

?3. 有些对象会在From和To在区域内复制复制15次(由JVM参数MaxTenuringThreshold这个参数默认为15)，最终如果还活着，就存入老年。

当对象在 Eden 出生后，经过一次 Minor GC 在那之后，如果对象仍然存活，并且可以是另一个 Survivor 如果该区域被容纳，则使用复制算法将这些仍然存活的对象复制到另一个区域 Survivor 在区域内，然后清理使用过的区域 Eden 以及 Survivor 区域，并将这些对象的年龄设定为1，以后对象在 Survivor 每隔一次 Minor GC，对象的年龄 1.当对象的年龄达到一定值时 ( 默认是 15 岁，可通过参数 -XX:MaxTenuringThreshold 来设定 )，这些对象将成为老年人。但对于一些较大的对象来说，这并不一定 ( 即需要分配较大的连续内存空间 ) 直接进入老年。

2.老年代

Full GC 是发生在老年代的垃圾收集动作，所采用的是标记-清除算法(或标记-整理算法)。

当老年人装不下的时候，就会扔出去OOM。

3.永久代永久代是Hotspot虚拟机的独特概念是实现方法区和其他方法区JVM没有这样的东西Java 8.永久代被完全移除，取而代之的是另一个与堆不相连的本地内存-元空间。或永久Perm Gen”包含了JVM所需的应用元数据描述了应用中使用的类别和方法。请注意，永久代不是Java堆内存的一部分。永久存储JVM操作中使用的类别。永久代也包括Java SE库的类别和方法。永久代的对象在full GC垃圾收集。

Java 中的堆也是 GC 垃圾收集的主要区域。GC 分为两种：Minor GC、Full GC ( 或称为 Major GC )。

从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC；
对老年代GC称为Major GC；
而Full GC是对整个堆来说的；

在最近几个版本的JDK里默认包括了对永生带即方法区的回收（JDK8中无永生带了），出现Full GC的时候经常伴随至少一次的Minor GC,但非绝对的。Major GC的速度一般会比Minor GC慢10倍以上。下边看看有那种情况触发JVM进行Full GC及应对策略。

Minor GC触发条件：当Eden区满时，触发Minor GC。

Full GC触发条件：

（1）System.gc()方法的调用

（2）老年代空间不足

旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误： java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

（3）方法区空间不足

JVM规范中运行时数据区域中的方法区，在HotSpot虚拟机中又被习惯称为永生代或者永生区，Permanet Generation中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息： java.lang.OutOfMemoryError: PermGen space 为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

4.你是通过什么方式实现JVM优化的？

　　1》调整新生代、s0、s1比例以及调整新生代老年代的大小，目的是减少GC次数

　　2》不要显示的调用system.GC()

　　3》对象不用的时候显式的置为null

　　4》尽量减少局部变量的使用

　　5》尽量使用基本数据类型而不使用封装类

　　6》尽量少使用静态变量，因为静态变量属于类的变量，是全局变量，会一直占用资源

　　7》尽量分散的创建对象，不要一次性创建多个对象。

3.Zookeeper的选举机制

一、什么是Zookeeper

ZooKeeper是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

它的核心是：文件系统 + 通知机制

二、重要特点

一个领导者(Leader)，多个跟随者(Follower)组成的集群
集群中只要有半数以上节点存活，Zookeeper集群就能正常服务
全局数据一致性，每个server保存一份相同的副本，client无论链接哪个server，得到的数据都是一致的
更新请求顺序执行，来自同一个client的请求按顺序执行
数据更新原子性，一次数据更新要么成功要么失败
实时性，在一定时间范围内，client能读到最新数据

三、数据结构

Zookeeper数据模型的结构与Unix文件系统很类似，整体上可看作是一棵树，每个节点称作一个ZNode。每个ZNode默认能存储1MB数据，每个ZNode都可以通过其路径唯一标识。

四、应用场景(※)

分布式锁
服务注册和发现
- 利用Znode和Watcher，可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式RPC框架Dubbo。
共享配置和状态信息
- Redis的分布式解决方案Codis（豌豆荚），就利用了Zookeeper来存放数据路由表和 codis-proxy 节点的元信息。同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。

五、选举机制(※)

5.1 半数机制（paxos协议）

集群中半数以上机器存活，集群可用，所以Zookeeper适合安装奇数台服务器

5.2 内部选举

在分布式系统中选主最直接的方法是直接选定集群的一个节点为leader，其它的节点为follower，这样引入的一个问题是如果leader节点挂掉，整个集群就挂掉了。需要有一种算法自动选主，如果leader节点挂掉，则从follower节点中选出一个主节点。

1. 选举阶段 Leader election

最大ZXID也就是节点本地的最新事务编号，包含epoch和计数两部分。epoch是纪元的意思，相当于Raft算法选主时候的term，标识当前leader周期，每次选举一个新的Leader服务器后，会生成一个新的epoch

所有节点处于Looking状态，各自依次发起投票，投票包含自己的服务器ID和最新事务ID（ZXID）。
如果发现别人的ZXID比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的ZXID所属节点。
每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。

2. 发现阶段 Discovery

为了防止某些意外情况，比如因网络原因在上一阶段产生多个Leader的情况。
Leader集思广益，接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。
各个Follower收到全新的epoch后，返回ACK给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。

3. 同步阶段 Synchronization

Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。

选举流程简述

目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
服务器5启动，后面的逻辑同服务器4成为小弟。

六、ZNode 内构

6.1 节点类型

持久persistent：client 和 server 断开连接后，创建的节点不删除

短暂ephemeral：client 和 server 断开连接后，创建的节点自己删除

另外分有序和无序。创建有序节点时，会自动将节点名增加序列号

$ create -s /test/no1 "no1"
Created /test/no10000000000

6.2 内部结构

data: ZNode存储的数据信息，每个节点数据最大不超过1MB
ACL(Access Control List): 记录访问权限，哪些人或哪些IP可访问本节点
child: 当前节点的子节点
stat: 各种元数据，比如事务ID、版本号、时间戳、大小等
- czxid- 引起这个 znode 创建的 zxid，创建节点的事务的 zxid
- ctime - znode 被创建的毫秒数
- mzxid - znode 最后更新的 zxid
- mtime - znode 最后修改的毫秒数
- pZxid-znode 最后更新的子节点 zxid
- cversion - znode 子节点变化号，znode 子节点修改次数 7)dataversion - znode 数据变化号
- aclVersion - znode 访问控制列表的变化号
- ephemeralOwner- 如果是临时节点，这个是znode拥有者的 session id。如果不是临时节点则是 0
- dataLength- znode 的数据长度
- numChildren - znode 子节点数量

5.Redis主从复制原理学习总结

和Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。

全量同步 Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下： - 从服务器连接主服务器，发送SYNC命令； - 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； - 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； - 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； - 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； - 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

完成上面几个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求。

增量同步 Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。 Redis主从同步策略主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。需要注意：如果多个Slave断线了，需重启时，因为只要Slave启动，就会发送sync请求和主机全量同步，当多个同时出现的时候，可能会导致Master IO剧增宕机。

主从复制的一些特点： 1）采用异步复制； 2）一个主redis可以含有多个从redis； 3）每个从redis可以接收来自其他从redis服务器的连接； 4）主从复制对于主redis服务器来说是非阻塞的，这意味着当从服务器在进行主从复制同步过程中，主redis仍然可以处理外界的访问请求； 5）主从复制对于从redis服务器来说也是非阻塞的，这意味着，即使从redis在进行主从复制过程中也可以接受外界的查询请求，只不过这时候从redis返回的是以前老的数据，如果你不想这样，那么在启动redis时，可以在配置文件中进行设置，那么从redis在复制同步过程中来自外界的查询请求都会返回错误给客户端；（虽然说主从复制过程中对于从redis是非阻塞的，但是当从redis从主redis同步过来最新的数据后还需要将新数据加载到内存中，在加载到内存的过程中是阻塞的，在这段时间内的请求将会被阻，但是即使对于大数据集，加载到内存的时间也是比较多的）； 6）主从复制提高了redis服务的扩展性，避免单个redis服务器的读写访问压力过大的问题，同时也可以给为数据备份及冗余提供一种解决方案； 7）为了编码主redis服务器写磁盘压力带来的开销，可以配置让主redis不在将数据持久化到磁盘，而是通过连接让一个配置的从redis服务器及时的将相关数据持久化到磁盘，不过这样会存在一个问题，就是主redis服务器一旦重启，因为主redis服务器数据为空，这时候通过主从同步可能导致从redis服务器上的数据也被清空；

6.Nacos对比Zookeeper、Eureka之间的区别

CAP定律

1）CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

Zookeeper和Consul保证的是CP，而Eureka则是AP，Nacos不仅支持CP也支持AP。

Nacos与Zookeeper，Eureka区别

相同点：三者都可以实现分布式注册中心框架

不同点： Zookeeper采用CP保证数据的一致性的问题，原理采用(ZAP原子广播协议)，当我们ZK领导者因为某种情况下部分节点出现了故障，会自动重新实现选举新的领导角色，整个选举的过程中为了保证数据一致性的问题，客户端暂时无法使用我们的Zookeeper，那么这以为着整个微服务无法实现通讯。注意：可运行的节点必须满足过半机制，整个zk采用使用。

Eureka采用AP设计思想实现分布式注册中心，完全去中心化、每个节点都是相等，采用你中有我、我中有你相互注册设计思想，只要最后有一台Eureka节点存在整个微服务就可以实现通讯。中心化：必须围绕一个领导角色作为核心，选举为领导和跟随者角色去中心化：每个角色都是均等

Nacos从1.0版本选择Ap和CP混合形式实现注册中心，默认情况下采用Ap，CP则采用Raft协议实现保持数据的一致性。如果选择为Ap模式，注册服务的实例仅支持临时模式，在网络分区的的情况允许注册服务实例选择CP模式可以支持注册服务的实例为持久模式，在网络分区的产生了抖动情况下不允许注册服务实例。

什么情况下选择cp和ap呢

必须要求读取接口的地址保证强一致性的问题，可以采用cp模式，一般情况下采用ap就可以了

常见分布式一致性算法：

ZAP协议（底层就是基于Paxos实现），核心底层基于2PC两阶段提交协议实现。
Nacos中集群保证一致性算法采ratf协议模式，采用心跳机制实现选举的。

Zap整个底层实现原理

Zookeeper基于ZAP协议实现保持每个节点的数据同步，中心化思想集群模式，分为领导和跟随者的角色

在程序中如何成为某个节点能力比较强：对每个节点配置一个myid或者serverid, 数据越大表示能力越强整个集群中为了保持数据的一致性的问题，必须满足大多数情况 >n/2+1 可运行的节点环境才可以使用 ZAP的协议实现原理是通过比较myid谁最大，谁就是可能领导角色，只要满足过半的机制就可以成为领导角色，后来启动的节点不会参与选举。
如何保持数据的一致性的问题所有的写的请求统一交给我们的领导角色实现，领导角色写完数据之后，领导角色再将数据同步给每个节点注意：数据之间同步采用2pc两阶段提交协议
选举过程：先去比较zxid谁最大谁就是领导角色如果zxid相等的情况下，myid谁最大谁就为领导角色;

Ratf整个底层实现原理：

在Raft协议中分为的角色

1.状态：分为三种跟随者、竞选者、领导

2.大多数： >n/2+1

3.任期：每次选举一个新的领导角色任期都会增加。

默认情况下选举的过程：

默认的情况下每个节点都是为跟随者角色
每个节点随机生成一个选举的超时时间大概分为100-300ms，在这个超时时间内必须要等待。
超时时间过后，当前节点的状态由跟随者变为竞选者角色，会给其他的节点发出选举的投票的通知，只要该竞选者有超过半数以上即可选为领导角色。

核心的设计原理其实就是靠的谁超时时间最短谁就有非常大的概率为领导角色。

故障的重新实现选举：

如果我们跟随者节点不能够及时的收到领导角色消息，那么这时候跟随者就会将当前自己的状态由跟随者变为竞选者角色，会给其他的节点发出选举的投票的通知，只要该竞选者有超过半数以上即可选为领导角色。

疑问：是否可能会产生两个同时的竞选者呢，同时实现拉票呢？

注意当我们的集群节点总数，如果是奇数情况下就算遇到了该问题也不用担心。

当我们的节点是为偶数的情况下，可能会存在该问题，如果两个竞选者获取的票数相等的情况下，开始重置竞选的超时时间，一直到谁的票数最多谁就为领导。

如何实现日志的复制

所有的写的请求都是统一的交给我们的领导角色完成，写入该对应的日志，标记该日志为被提交状态。
为了提交该日志，领导角色就会将该日志以心跳的形式发送给其他的跟随者节点，只要超过跟随者节点写入该日志，则直接通知其他的跟随者节点同步该数据，这个过程称做为日志复制的过程。

6.dubbo 负载均衡策略

Random LoadBalance

随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

轮询，按公约后的权重设置轮询比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

配置

服务端服务级别

<dubbo:service interface="..." loadbalance="roundrobin" />

客户端服务级别

<dubbo:reference interface="..." loadbalance="roundrobin" />

服务端方法级别

<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>

客户端方法级别

<dubbo:reference interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>

7.分布式事务解决方案

InnoDB实现原理

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

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

而事务的ACID是通过InnoDB日志和锁来保证。事务的隔离性是通过数据库锁的机制实现的，持久性通过redo log（重做日志）来实现，原子性和一致性通过Undo log来实现。UndoLog的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为UndoLog）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。和Undo Log相反，RedoLog记录的是新数据的备份。在事务提交前，只要将RedoLog持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是RedoLog已经持久化。系统可以根据RedoLog的内容，将所有数据恢复到最新的状态。

分布式事务

什么是分布式事务

分布式事务产生的原因

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

service多个节点

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

这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。

resource多个节点

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

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来说适合一些:

强隔离性，严格一致性要求的活动业务。
执行时间较短的业务

本地消息表

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

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

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

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

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

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

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

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

MQ事务

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

基本流程如下: 第一阶段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

面试套路问题总结5