一、目录：

8、 MySQL 如何做 分布式锁 ？

9、你了解业界哪些 大公司的分布式锁框架 ？

10、请讲一下你对 CAP 理论的理解

11、请讲一下你对 BASE 理论的理解

12、 分布式与集群 的区别是什么？

13、请讲一下 BASE 理论的 三要素

14、请说一下对 两阶段提交协议 的理解

15、请讲一下对 TCC 协议 的理解

二、详情解读：

8、MySQL 如何做分布式锁？

方法一：

利用 Mysql 的锁表，创建一张表，设置一个 UNIQUE KEY 这个 KEY 就是要锁的 KEY ，所以同一个 KEY 在 mysql 表里只能插入一次了，这样对锁的竞争就交给了数据库，处理同一个 KEY 数据库保证了只有一个节点能插入成功，其他节点都会插入失败。

DB 分布式锁的实现 ：通过主键 id 的唯一性进行加锁，说白了就是加锁的形式是向一张表中插入一条数据，该条数据的 id 就是一把分布式锁，例如当一次请求插入了一条 id 为 1 的数据，其他想要进行插入数据的并发请求必须等第一次请求执行完成后删除这条 id 为 1 的数据才能继续插入，实现了分布式锁的功能。

方法二：

使用 流水号+时间戳 做幂等操作，可以看作是一个不会释放的锁。

9、你了解业界哪些大公司的分布式锁框架？

• Google:Chubby

Chubb y 是一套分布式协调系统 ，内部使用 Paxos 协调 Master 与 Replicas 。

Chubby lock service 被应用在 GFS, BigTable 等项目中，其首要设计目标是高可靠性，而不是高性能。

Chubby 被作为粗粒度锁使用，例如被用于选主。持有锁的时间跨度一般为小时或天，而不是秒级。

Chubby 对外提供类似于文件系统的 API ，在 Chubby 创建文件路径即加锁操作。 Chubby 使用 Delay 和 SequenceNumber 来优化锁机制。

Delay 保证客户端异常释放锁时， Chubby 仍认为该客户端一直持有锁。 Sequence number 指锁的持有者向 Chubby 服务端请求一个序号（包括几个属性），然后之后在需要使用锁的时候将该序号一并发给 Chubby 服务器，服务端检查序号的合法性，包括 number 是否有效等。

• 京东 SharkLock

SharkLock 是基于 Redis 实现的分布式锁。锁的排他性由 SETNX 原语实现，使用 timeout 与续租机制实现锁的强制释放。

• 蚂蚁金服 SOFAJRaft-RheaKV 分布式锁

RheaKV 是基于 SOFAJRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库。

RheaKV 对外提供 lock 接口，为了优化数据的读写，按不同的存储类型，提供不同的锁特性。 RheaKV 提供 wathcdog 调度器来控制锁的自动续租机制，避免锁在任务完成前提前释放，和锁永不释放造成死锁。

• Netflix: Curator

Curator 是 ZooKeeper 的客户端封装，其分布式锁的实现完全由 ZooKeeper 完成。

在 ZooKeeper 创建 EPHEMERAL_SEQUENTIAL 节点视为加锁，节点的 EPHEMERAL 特性保证了锁持有者与 ZooKeeper 断开时强制释放锁；节点的 SEQUENTIAL 特性避免了加锁较多时的惊群效应。

10、请讲一下你对 CAP 理论的理解

在理论计算机科学中， CAP 定理（ CAP theorem ），又被称作 布鲁尔定理 （ Brewer’s theorem ），它指出对于一个分布式计算系统来说，不可能 同时满足 以下三点：

• Consistency （一致性） 指数据在多个副本之间能够保持一致的特性 （严格的一致性）

• Availability （可用性） 指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应 （不保证获取的数据为最新数据）

• Partition tolerance （分区容错性） 分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障

Spring Cloud 在 CAP 法则上主要满足的是 A 和 P 法则， Dubbo 和 Zookeeper 在 CAP 法则主要满足的是 C 和 P 法则。

CAP 仅适用于原子读写的 NOSQL 场景中，并不适合数据库系统。现在的分布式系统具有更多特性比如扩展性、可用性等等，在进行系统设计和开发时，我们不应该仅仅局限在 CAP 问题上。

现实生活中，大部分人解释这一定律时，常常简单地表述为：“ 一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到 ”。实际上这是一个非常具有误导性质的说法，而且在 CAP 理论诞生 12 年之后， CAP 之父也在 2012 年重写了之前的论文。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1 。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（ Partition tolerance ）我们是必须要实现的。

11、请讲一下你对 BASE 理论的理解

BASE 理论由 eBay 架构师 Dan Pritchett 提出，在 2008 年上被分表为论文，并且 eBay 给出了他们在实践中总结的基于 BASE 理论的一套新的 分布式事务解决方案 。

BASE 是 Basically Available （基本可用） 、 Soft-state （软状态） 和 Eventually Consistent （最终一致性） 三个短语的缩写。 BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

BASE 理论的核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

针对数据库领域， BASE 思想的主要实现是对业务数据进行拆分，让不同的数据分布在不同的机器上，以提升系统的可用性，当前主要有以下两种做法：

• 按功能划分数据库
• 分片（如开源的Mycat、Amoeba等）。

12、分布式与集群的区别是什么？

分布式：一个业务分拆成多个子业务，部署在不同的服务器上

集群：同一个业务，部署在多个服务器上。比如之前做电商网站搭的 redis 集群以及 solr 集群都是属于将 redis 服务器提供的缓存服务以及 solr 服务器提供的搜索服务部署在多个服务器上以提高系统性能、并发量解决海量存储问题。

13、请讲一下 BASE 理论的三要素

基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。

比如：

• 响应时间上的损失 ：正常情况下，一个在线搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

• 系统功能上的损失 ：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性

强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

14、请说一下对两阶段提交协议的理解

分布式系统的一个难点是 如何保证架构下多个节点在进行事务性操作的时候保持一致性 。为实现这个目的， 二阶段提交算法 的成立基于以下假设：

• 该分布式系统中，存在一个节点作为协调者( Coordinator )，其他节点作为参与者( Cohorts )。且 节点之间可以进行网络通信 。

• 所有节点都采用 预写式日志 ，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。

• 所有节点不会永久性损坏，即使损坏后仍然可以恢复。

第一阶段（投票阶段）

• 协调者节点向所有参与者节点询问是否可以执行提交操作( vote )，并开始等待各参与者节点的响应。

• 参与者节点执行询问发起为止的所有事务操作，并将 Undo 信息和 Redo 信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）

• 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。

第二阶段（提交执行阶段）

当协调者节点从所有参与者节点获得的相应消息都为”同意”：

• 协调者节点向所有参与者节点发出”正式提交( commit )”的请求。

• 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。

• 参与者节点向协调者节点发送”完成”消息。

• 协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。

如果任一参与者节点在第一阶段返回的响应消息为”中止”：

• 协调者节点向所有参与者节点发出”回滚操作( rollback )”的请求。

• 参与者节点利用之前写入的 Undo 信息执行回滚，并释放在整个事务期间内占用的资源。

• 参与者节点向协调者节点发送”回滚完成”消息。

• 协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。

15、请讲一下对 TCC 协议的理解

Try Confirm Cancel

• Try ：尝试待执行的业务 ，这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源。

• Confirm ：执行业务，这个过程真正开始执行业务，由于 Try 阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。

• Cancel ：取消执行的业务，若业务执行失败，则进入 Cancel 阶段，它会释放所有占用的业务资源，并回滚 Confirm 阶段执行的操作。

更多编程干货，请关注我