分布式常见面试题

001什么是CAP理论？

CAP原理指的是，在分布式系统中这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数Web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。 
一致性（Consistency）：数据在多个副本之间是否能够保持一致的特性。（当一个系统在一致状态下更新后，应保持系统中所有数据仍处于一致的状态）。 
可用性（Availability）：系统提供的服务必须一直处于可用状态，对每一个操作的请求必须在有限时间内返回结果。 
分区容错性（Tolerance of network Partition）：分布式系统在遇到网络分区故障时，仍然需要保证对外提供一致性和可用性的服务，除非整个网络都发生故障。

002CAP理论中为什么只能同时满足两个？

例如，服务器中原本存储的value=0，当客户端A修改value=1时，为了保证数据的一致性，要写到3个服务器中，当服务器C故障时，数据无法写入服务器C，则导致了此时服务器A、B和C的value是不一致的。这时候要保证分区容错性，即当服务器C故障时，仍然能保持良好的一致性和可用性服务，则Consistency和Availability不能同时满足。为什么呢？ 如果满足了一致性，则客户端A的写操作value=1不能成功，这时服务器中所有value=0。如果满足可用性，即所有客户端都可以提交操作并得到返回的结果，则此时允许客户端A写入服务器A和B，客户端C将得到未修改之前的value=0结果。

003什么是BASE理论？

1)Basically Available（基本可用）分布式系统在出现不可预知故障的时候，允许损失部分可用性 
2)Soft state（软状态）软状态也称为弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。 
2)Eventually consistent（最终一致性）最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

004CAP 与 ACID 关系？

ACID 是传统数据库常用的设计理念，追求强一致性模型。BASE 支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。 ACID 和 BASE 代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此 ACID 和 BASE 又会结合使用。

005什么是接口幂等？

接口的幂等性实际上就是接口可重复调用，在调用方多次调用的情况下，接口最终得到的结果是一致的。有些接口可以天然的实现幂等性，比如查询接口，对于查询来说，你查询一次和两次，对于系统来说，没有任何影响，查出的结果也是一样。除了查询功能具有天然的幂等性之外，增加、更新、删除都要保证幂等性。

006如何来保证幂等性呢？

1)全局唯一ID：全局唯一ID就是根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存储系统中，比如数据库、redis等。如果存在则表示该方法已经执行。 从工程的角度来说，使用全局ID做幂等可以作为一个业务的基础的微服务存在，在很多的微服务中都会用到这样的服务，在每个微服务中都完成这样的功能，会存在工作量重复。另外打造一个高可靠的幂等服务还需要考虑很多问题，比如一台机器虽然把全局ID先写入了存储，但是在写入之后挂了，这就需要引入全局ID的超时机制。 使用全局唯一ID是一个通用方案，可以支持插入、更新、删除业务操作。但是这个方案看起来很美但是实现起来比较麻烦，下面的方案适用于特定的场景，但是实现起来比较简单。 
2)去重表:这种方法适用于在业务中有唯一标的插入场景中，比如在以上的支付场景中，如果一个订单只会支付一次，所以订单ID可以作为唯一标识。这时，我们就可以建一张去重表，并且把唯一标识作为唯一索引，在我们实现时，把创建支付单据和写入去去重表，放在一个事务中，如果重复创建，数据库会抛出唯一约束异常，操作就会回滚。 
3)插入或更新:这种方法插入并且有唯一索引的情况，比如我们要关联商品品类，其中商品的ID和品类的ID可以构成唯一索引，并且在数据表中也增加了唯一索引。这时就可以使用InsertOrUpdate操作。在mysql数据库中如下： 

insert into goods_category (goods_id,category_id,create_time,update_time) 
       values(#{goodsId},#{categoryId},now(),now()) 
       on DUPLICATE KEY UPDATE
       update_time=now()

4)多版本控制:这种方法适合在更新的场景中，比如我们要更新商品的名字，这时我们就可以在更新的接口中增加一个版本号，来做幂等 

boolean updateGoodsName(int id,String newName,int version);

在实现时可以如下 

update goods set name=#{newName},version=#{version} where id=#{id} and version<${version}

5)状态机控制:这种方法适合在有状态机流转的情况下，比如就会订单的创建和付款，订单的付款肯定是在之前，这时我们可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来做幂等。比如订单的创建为0，付款成功为100，付款失败为99 。
在做状态机更新时，我们就这可以这样控制 

update `order` set status=#{status} where id=#{id} and status<#{status}

007什么是分布式事务?

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。一个大的操作由 N 多的小的操作共同完成。而这些小的操作又分布在不同的服务上。针对于这些操作，要么全部成功执行，要么全部不执行。

008分布式id生成方案有哪些？

1.UUID：时间戳+时钟序列(计数器)+唯一的IEEE机器识别码(比如网卡的MAC地址) 。
缺点：对数据库不友好，因为随机不连续。
2.数据库自增：对于数据库集群模型，要设置不同的数据库起始值不同，但是步长(自增几)相同。 
3.Leaf-segment：(美团大众点评的)采用每次获取一个ID区间的方式。比如一次和数据库的交互，就请求到100个id，数据来了直接用。避免每次添加数据都请求一个id，增加了数据库的压力。 也是对数据库自增策略的一个优化。
4.雪花算法：其核心思想是：41位时间戳+10位机器id+12位序列号+符号位(0)。结果是一个长度为64bit的long型的ID。  
优点：12位序列号是说每个节点在每毫秒可以产生4096 个ID，并且是递增的。 这样适合于Mysql的聚集索引，索引的连续性也好。 
缺点：依赖于时间戳，时间戳是根据机器的时间得到的。比如linux中，如果人为的进行时钟回拨，就可能造成id重复。

009分布式架构下，Session 共享有什么方案?

● 使用jwt
● 使用cookie (有安全风险)
● 服务器之间进行session同步：保证每个服务器都有session信息，消耗比较大。
● ip绑定策略：比如使用Ngnix进行源地址哈希法的负载均衡，让每一个ip固定访问一个服务器， 但是这种就失去分布式的作用。
● 使用redis存储：是业界最广泛的。 可实现不同服务，不同平台(网页/app)，甚至不同语言的session共享。