分布式面试题

分布式

1.CAP定理

cap定理

​ Consistency 一致性：访问分布式系统中任意节点，总能返回一致的结果

​ Available 可用性：分布式系统总能向客户端返回响应

​ Partition tolerance 分区容忍：当分布式系统节点通信发生了消息丢失或消息延迟，仍然允许系统运行

​ CAP 定理：最多3选2，无法兼得，通常CP 或 AP

不一致产生

​ 1.client 向 node1 写入 新值 v1

​ 2.写入成功 node1更新成了v1

​ 3.node1在没有变更到node2时，客户端就返回了应答

​ 4.client 发起对node2的读操作

​ 5.返回了旧值v0（不一致的结果）

保证一致性

保CP失A

保AP失C

一致性级别

​ CP 和 AP 之间需要做权衡，其实跟据需求不同，也可以将一致性分为几个级别，在这些级别里做一个权衡。

​ 强一致性：系统写入什么，读出来的也会是什么，但实现起来对性能影响较大。

​ 例如：火车站售票，有就是有，没有就是没有，不能出现不一致的情况

​ 典型算法：ZAB，RAFT,Paxos

​ 弱一致性：系统写入成功后，不承诺立刻可以读到写入的值，也不承诺具体多久后数据能达到一致，还可以细分为：

​ 会话一致性，同一个客户端会话中保持一致，其他会话不能保证

​ 用户一致性，同一个用户可以保证，其他用户不能保证

​ 例如：网上购物，在商品详情页还有许多库存，下单的瞬间才被提示"库存量不足"，实际上商品详情页展示的库存并不是最新的数 据，只是在某个流程上才会做准确的检查

​

​ 最终一致性：是弱一致性的特例，保证在一定时间内，能够达到一个一致的状态

​ 例如：转账，转账完成后，会有一个提示，您的转账会在24小时内到账，一般用户也是可以接受的，但最终必须是一致的

​ 典型协议：Gossip

2.Paxos 算法

3.Raft 算法

4.Gossip 协议

5.分布式通用设计

如何检测节点还活着

​ 通过心跳。

​ 向节点周期性发送节点请求，如果能收到心跳回应，表示该节点还活着

​ 但如果收不到心跳回应，却不能证明该节点死了，可能由于网络抖动、回应延时等原因没能及时收到回应，有如下解决思路：

​ 1.如 Redis哨兵模式中，如果 sentinel 向 master 发送 ping 而没有收到 pong ，只能判定主观下线，必须采纳它 sentinel 意见，达 到多数派后才能判定客观下线，进入主备切换流程

​ 2.将周期心跳检测升级为累计心跳检测机制，即记录统计该节点的历史响应时间，如果超过警戒，则发起有限次的重试作为进一步判 定

如何实现高可用

应用层高可用

​ 关键是做到：无状态，即所有节点地位平等，去session化。利用负载均衡将请求发送到任意一台节点进行处理，如果有某个节点宕机 机，把该节点从服务列表删掉，不会影响业务运行

服务层高可用

​ 同样要做到无状态，此外还需要考虑

​ 1.核心服务与非核心服务隔离部署，分级管理，便于非核心服务降级

​ 2.对于即时性没有要求的服务可以考虑采用异步调用优化

​ 3.合理设置超时时间，在超时后应当有相应的处理策略，如：重试，转移，降级等

数据层高可用

​ 需要有数据备份机制和故障转移机制

​ 缓存服务是否需要高可用，两种观点：

​ 1.缓存服务不可用会让数据库失去保护，因此需要保证缓存服务高可用

​ 2.缓存服务不是数据存储服务，缓存宕机应该通过其他手段解决，如扩大缓存规模，一个服务器的宕机只会影响局部

全局ID生成

​ 1.数据库id表

​ Oracle 数据库，直接使用序列作为id

​ MySQL 数据库，采用自增主键作为id，如果想避免单点故障，用多台 MySQL 使用不同的起始值和步长来设置 auto_increment

​ 缺点：数据库并发不高，属于集中式解决方案

​ 2.Redis

​ 使用 incr 生成id，由于redis 单线程特性，保证它不会重复

​ 仍然属于集中式解决方案，有网络消耗

3.UUID 有多种实现机制，典型的 UUID 会包含时间信息，MAC 地址信息，随机数

​ 优点：属于本地解决方案，无网络消耗

​ 缺点：MAC 提供了唯一保证，但也会带来安全隐患，最遭的是它是字符串形式，占用空间大，查询效率低，无法保证趋势递增

负载均衡策略

​ 负载均衡：即使用多台服务器共同分担计算任务，把网络请求和计算按某种算法均摊到每台服务器上

​ 可用使用硬件实现（如F5），也可用使用软件来实现（如 nginx，dubbo，ribbon等诸多软件有自己的负载均衡）

​ 常见的负载均衡算法有

​ 轮询，轮流（nginx,ribbon）

​ 加权轮询，在轮询的基础上考虑权重，权重高的分到请求越多 （nginx，dubbo）

​ 最少连接，指谁的活跃连接数越少，就把请求分发给谁，因为活跃多意为着响应慢 （nginx，dubbo）

​ 最少响应时间，指谁的响应快，且活跃连接数越少，就把请求发给谁（nginx，ribbon）

​ 随机，随便发给谁（nginx，dubbo，ribbon）

​ hash，例如跟据 ip 的hash值分配请求，ip 相同的请求会由同一台处理器处理

​ 一致性 hash，比hash好处在于添加，移除节点对请求分发较小

数据分片策略

所谓分片就是指数据量较大时，对数据进行水平切分，让数据分布在多个节点上。

​ 1.hash

​ 按照key的hash指将数据映射到不同的节点上

​ 优点：实现简单，数据分布均匀

​ 缺点1：如果直接hash 与 节点数取模，节点变动时会造成数据大规模迁移，可以使用一致性hash改进

​ 缺点2：查询某类热点数据时，由于被hash分散到不同的节点上，造成查询效率不高

​ 2.range

​ 可以将key按照range划分放到不同节点上，让某一范围内的数据放到某个节点上

​ 优点一：按range查询性能更高

​ 优点二：如果配合动态range 分片，可以将较小的分片合并，将热点数据分散，有很多有用的功能

​ 3.静态调度与动态调度

​ 静态意为着数据分片后分布固定，即使移动也需要人工介入

​ 动态意为着通过管理器基于调度算法在各节点之间自由移动数据