1. 分布式服务接口的幂等性如何设计？
  2. 分布式系统的接口调用如何保证顺序性
  3. 说说zookeeper一般都有哪些使用场景？
  4. 说说你们的分布式session方案是啥？怎么做的
  5. 常见的分布式锁有哪些解决方案
  6. zk和redis的区别，各自有哪些优缺点
  7. mysql如何做分布式锁？
  8. 你了解业界哪些大公司的分布式锁框架
  9. 请讲一下你对cap理论的理解
  10. 请讲一下你对base理论的理解
  11. 请讲一下base理论的三要素
  12. 分布式与集群分别是什么
  13. 分布式事务了解吗
  14. 请说一下对两阶段提交协议的理解
  15. 将讲一下对TCC协议的理解


分布式服务接口的幂等性如何设计？

所谓幂等性，就是说一个接口，多次发起同一个请求，这个接口需要保证结果是准确的。比如不能多次扣款、不能多插入一条数据，不能将统计值多加了1，这就是幂等性。
其实保证幂等性主要是三点：

  1. 对于每个请求必须有一个唯一的标识，举个例子：订单支付请求，肯定需要包含订单ID，一个订单ID最多支付一次。
  2. 每次处理完整请求之后，必须有一个记录标识这个请求处理过了，比如说常见的方案是在mysql中记录个状态，比如支付之前记录一条这个订单的支付流水，而且支付流水采用order id作为唯一键（unique key）。只有成功插入这个支付流水，才可以执行实际的支付扣款。
  3. 每次接受请求需要进行判断之前是否处理过逻辑，比如说，如果有一个订单已经支付了，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，如果order id已经存在了，唯一键约束生效，报错插入不进去。这样就不需要再次扣款了。

    分布式系统的接口调用如何保证顺序性

    可以接入MQ，如果是系统A使用多线程处理的话，可以使用内存队列，来保证顺序性，如果要100%的顺序性，可以使用分布式锁，但会影响系统的并发性。

    说说zookeeper一般都有哪些使用场景？

  • 分布式协调：这个其实就是zk很经典的一个用法，简单来说，就好比系统A发送请求到mq，然后B消费了之后处理。那系统A如何知道B系统的处理结果？用zk就可以实现分布式系统之间的协调工作，一旦B系统处理完了就修改zk那个节点的值，A立马就可以收到通知
  • 分布式锁：对某一个数据连续发出两个修改操作，两台机器同时收到请求，但是只能一台机器先执行另一台机器再执行，那么此时就可以使用zk分布式锁，一个机器接收到了请求之后先获取zk上的一把分布式锁，就是可以去创建一个znode，接着执行操作，然后另一个机器尝试去创建znode时发现创建不了，因为别人先创建了，那就只能等到另一个机器完成后自己再执行。
  • 配置信息管理：zk可以用作很多系统的配置信息的管理，比如kafka、storm等很多分布式系统都会选用zk来做一些元数据，配置信息的管理，包括dubbo注册中心也支持zk。

  • HA高可用性：这个应该是很常见的，比如hdfs、yarn等很多大数据系统，都选择基于zk来开发HA高可用机制，就是一个重要进程一般会主备两个，主进程挂了立马通过zk感知切换到备份进程

    说说你们的分布式session方案是啥？怎么做的*

    常见的分布式锁有哪些解决方案

  • redis的分布式锁，很多大公司都会基于redis做拓展开发

  • 基于zookeeper

  • 基于数据库，比如mysql

    zk和redis的区别，各自有哪些优缺点

  • redis：

    • redis只保证最终一致性，副本间的数据复制是异步进行（set是写，get是读，redis集群一般是读写分离架构，存在主从同步延迟的情况），主从切换之后可能有部分数据没有复制过去，可能会丢失锁的情况，故强一致性要求的业务不推荐使用redis，更推荐zk。
    • redis集群各方法的响应时间均为最低。随着并发量和业务数量的提升，其响应时间会有明显上升（公有集群影响因素偏大），但是极限qps可以达到最大且基本无异常

  • zookeeper：

    • 使用zk集群，锁原理是使用zookeeper的临时节点，临时节点的生命周期在client与集群的session结束时结束。因此如果某个client节点存在问题，与zookeeper集群断开连接，session超时 同样会导致锁被错误的释放（导致被其他线程错误的持有），因此zookeeper也无法保证完全一致。
    • zookeeper具有较好的稳定性，响应时间抖动很小，没有出现异常。但是随着并发量和业务数量的提升其响应时间和qps会明显下降。

      mysql如何做分布式锁？

  • 方法一：

    • 利用mysql的锁表，创建一张表，设置一个UNIQUE KEY，这个KEY就是要锁的KEY，所以同一个KEY在mysql表里只能插入一次，这样对锁的竞争就交给了数据库，处理同一个KEY数据库保证了只有一个节点能插入成功，其他节点都会插入失败。
    • db分布式锁的实现：通过主键id的唯一性进行加锁，说白了就是加锁的形式向一张表中插入一条数据，该条数据的id就是一把分布式锁，例如当一次请求插入了一条id为1的数据，其他想要进行插入数据的并发请求必须等第一次请求执行完成后删除了这条id为1的数据才能继续插入，实现了分布式锁的功能

  • 方法二：

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

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

  • Google：Chubby

    • Chubby是一套分布式协调系统，内部使用Paxos协调Master与Replicas。Chubby lock service被应用在GFS，BigTable等项目中，其首要设计目标是高可靠性，而不是高性能。
    • Chubby被作为粗粒度锁使用，例如被用于选举。持有锁的时间跨度一般为小时或天，而不是秒级
    • Chubby对外提供类似于文件系统的API，在Chubby创建文件路径即加锁操作。Chubby使用Delay和SequenceNumber来优化锁机制。Delay保证客户端异常释放锁时，Chubby仍认为客户端一直持有锁。SequenceNumber指锁的持有者向Chubby客户端请求一个序号（包括几个属性），然后之后在需要使用锁的时候将该序号一并发给Chubby服务器，服务端检查序号的合法性，包括number是否有效等。
  • 京东：SharkLock
    • SharkLock是基于redis实现的分布式锁。锁的排他性由SETNX原语实现，使用timeout与续租机制实现锁的强制释放。
  • 蚂蚁金服：SOFAJRaft-RheadKV分布式锁
    • RheaKV是基于SOFAJRaft和RocksDB实现的嵌入式、分布式、高可用、强一致的KV存储类库
    • RheaKV对外提供lock接口，为了优化数据的读写，按不同的数据存储类型，提供不同的锁特性。RheaKV提供watchdog调度器来控制锁的自动续租机制，避免锁在任务完成前提前释放，和锁永不释放造成死锁。

  • Netflix：Curator

    • Curator是Zookeeper的客户端封装，其分布式锁的实现完全由Zookeeper完成。
    • 在Zookpeer创建EPHEMERAL_SEQUENTIAL节点视为加锁，节点的EPHEMERAL特性保持了锁持有者与Zookeeper断开时强制释放锁；节点的SEQUENTIAL特性避免了加锁较多时的惊群效应。

      请讲一下你对cap理论的理解

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

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

  • Availability（可用性） 指系统提供的服务必须一直处于可用的状态，每次请求都能够获取到非错的相应（不保证获取的数据为最新数据）。
  • Partition tolerance（分区容错性） 分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

ETCD在CAP法则上主要满足CP法则，即强一致性和分区容错性。

请讲一下你对base理论的理解

BASE理论由ebay架构师Dan Pritchett提出，在2008年上被分表为论文，并且ebay给出了他们在实践中总结的基于Base理论的一套新的分布式事务解决方案。
base是 Basically Available（基本可用）、Soft-state（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。BASE理论是对CAp中一致性和可用性权衡的结果，其来源对大规模互联网系统分布式实践的总结，是基于CAP逐步演化而来的，它大大降低了我们对系统的要求。base理论的核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或不一致时，仍然需要保持系统整体“主要可用”
针对数据库领域，base思想的主要实现是对业务数据进行拆分，让不同的数据分布在不同的机器上，以提升系统的可用性，当前主要有以下两种做法：

  • 按功能划分数据库

  • 分片（如开源的mycat、amoeba等）

    请讲一下base理论的三要素

  • 基本可用

    • 基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性。但是，这不等价于系统不可用
    • 比如：
      • 响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒内返回给用户相应的查询结果，但由于出现了故障，查询结果的响应时间增加1~2秒
      • 系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利的完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
  • 软状态
    • 软状态指允许系统中的数据存在中间状态，即认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

  • 最终一致性

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

      分布式与集群分别是什么

      分布式：一个业务拆分多个子业务，部署在不同的服务器上
      集群：同一个业务，部署在多个服务器上。来提高系统性能、并发量等问题

      分布式事务了解吗

  • XA方案/两阶段提交方案

    • 第一阶段：询问
    • 第二阶段：执行

  • TCC方案

    • TCC的全过程是：Try、Confirm、Cancel
      • try：各个服务的资源做检测以及对资源进行锁定或预留
      • confirm：各个服务中执行实际的操作
      • cancel：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经成功的业务逻辑的回滚操作。
    • 这个阶段是用到了补偿的概念，分为了三个阶段
    • 本地信息表
    • 可靠消息最终一致性方案
    • 最大努力通知方案

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

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

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

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

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

    第一阶段：投票阶段

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

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

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

    第二节点：提交执行阶段

    当协调者节点向所有参与者节点获取的响应信息都为“同意”

  • 协调者节点向所有参与者节点发出“正式提交（commit）”的请求

  • 参与者节点正式完成操作，并释放整个事务期间内占用的资源
  • 参与者节点向协调者节点发送“完成”消息
  • 协调者节点受到所有参与者节点反馈的“完成”信息后，完成事务

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

  • 协调者节点向所有参与者节点发出“回滚（rollback）”的请求
  • 参与者节点利用之前写入的undo信息执行回滚，并释放整个事务期间内占用的资源
  • 参与者节点向协调者节点发送“回滚完成”消息

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

    将讲一下对TCC协议的理解

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

  • confirm：执行业务，这个过程真正开始执行业务，由于try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到try阶段预留的业务资源
  • cancel：取消执行的业务，若业务执行失败，则进入cancel阶段，它会释放所有占用的业务资源，并回滚confirm阶段执行的操作