面试题（5）

81.什么是CAP理论

CAP理论是分布式领域中⾮常重要的⼀个指导理论，C（Consistency）表示强⼀致性，A
（Availability）表示可⽤性，P（Partition Tolerance）表示分区容错性，CAP理论指出在⽬前的硬件 条件下，⼀个分布式系统是必须要保证分区容错性的，⽽在这个前提下，分布式系统要么保证CP，要么 保证AP，⽆法同时保证CAP。
分区容错性表示，⼀个系统虽然是分布式的，但是对外看上去应该是⼀个整体，不能由于分布式系统内 部的某个结点挂点，或⽹络出现了故障，⽽导致系统对外出现异常。所以，对于分布式系统⽽⾔是⼀定 要保证分区容错性的。
强⼀致性表示，⼀个分布式系统中各个结点之间能及时的同步数据，在数据同步过程中，是不能对外提 供服务的，不然就会造成数据不⼀致，所以强⼀致性和可⽤性是不能同时满⾜的。
可⽤性表示，⼀个分布式系统对外要保证可⽤。

82.什么是BASE理论

由于不能同时满⾜CAP，所以出现了BASE理论，BASE理论是AP方案的延伸：

核心思想是即使无法做到强一致，但可以采用适合的方式达到最终一致性

1. BA：Basically Available，表示基本可⽤，表示可以允许⼀定程度的不可⽤，⽐如由于系统故障， 请求时间变⻓，或者由于系统故障导致部分⾮核⼼功能不可⽤，都是允许的
2. S：Soft state：表示分布式系统可以处于⼀种中间状态，⽐如数据正在同步
3. E：Eventually consistent，表示最终⼀致性，不要求分布式系统数据实时达到⼀致，允许在经过⼀段时间后再达到⼀致，在达到⼀致过程中，系统也是可⽤的

83.什么是RPC

RPC，表示远程过程调⽤，对于Java这种⾯试对象语⾔，也可以理解为远程⽅法调⽤，RPC调⽤和 HTTP调⽤是有区别的，RPC表示的是⼀种调⽤远程⽅法的⽅式，可以使⽤HTTP协议、或直接基于TCP 协议来实现RPC，在Java中，我们可以通过直接使⽤某个服务接⼝的代理对象来执⾏⽅法，⽽底层则通 过构造HTTP请求来调⽤远端的⽅法，所以，有⼀种说法是RPC协议是HTTP协议之上的⼀种协议，也是可以理解的。

84.分布式ID是什么？有哪些解决方案？

在开发中，我们通常会需要⼀个唯⼀ID来标识数据，如果是单体架构，我们可以通过数据库的主键，或 直接在内存中维护⼀个⾃增数字来作为ID都是可以的，但对于⼀个分布式系统，就会有可能会出现ID冲突，此时有以下解决⽅案：
1. uuid，这种⽅案复杂度最低，但是会影响存储空间和性能
2. 利⽤单机数据库的⾃增主键，作为分布式ID的⽣成器，复杂度适中，ID⻓度较之uuid更短，但是受 到单机数据库性能的限制，并发量⼤的时候，此⽅案也不是最优⽅案
3. 利⽤redis、zookeeper的特性来⽣成id，⽐如redis的⾃增命令、zookeeper的顺序节点，这种⽅案 和单机数据库(mysql)相⽐，性能有所提⾼，可以适当选⽤
4. 雪花算法，⼀切问题如果能直接⽤算法解决，那就是最合适的，利⽤雪花算法也可以⽣成分布式
ID，底层原理就是通过某台机器在某⼀毫秒内对某⼀个数字⾃增，这种⽅案也能保证分布式架构中
的系统id唯⼀，但是只能保证趋势递增。业界存在tinyid、leaf等开源中间件实现了雪花算法。

85.分布式锁的使用场景是什么？有哪些实现方案？

在单体架构中，多个线程都是属于同⼀个进程的，所以在线程并发执⾏时，遇到资源竞争时，可以利⽤ ReentrantLock、synchronized等技术来作为锁，来控制共享资源的使⽤。
⽽在分布式架构中，多个线程是可能处于不同进程中的，⽽这些线程并发执⾏遇到资源竞争时，利⽤ ReentrantLock、synchronized等技术是没办法来控制多个进程中的线程的，所以需要分布式锁，意思就是，需要⼀个分布式锁⽣成器，分布式系统中的应⽤程序都可以来使⽤这个⽣成器所提供的锁，从⽽达到多个进程中的线程使⽤同⼀把锁。
⽬前主流的分布式锁的实现⽅案有两种：
1. zookeeper：利⽤的是zookeeper的临时节点、顺序节点、watch机制来实现的，zookeeper分布式 锁的特点是⾼⼀致性，因为zookeeper保证的是CP，所以由它实现的分布式锁更可靠，不会出现混 乱
2. redis：利⽤redis的setnx、lua脚本、消费订阅等机制来实现的，redis分布式锁的特点是⾼可⽤， 因为redis保证的是AP，所以由它实现的分布式锁可能不可靠，不稳定（⼀旦redis中的数据出现了不⼀致），可能会出现多个客户端同时加到锁的情况

86.什么是分布式事务？有哪些实现方案？

在分布式系统中，⼀次业务处理可能需要多个应⽤来实现，⽐如⽤户发送⼀次下单请求，就涉及到订单 系统创建订单、库存系统减库存，⽽对于⼀次下单，订单创建与减库存应该是要同时成功或同时失败 的，但在分布式系统中，如果不做处理，就很有可能出现订单创建成功，但是减库存失败，那么解决这 类问题，就需要⽤到分布式事务。常⽤解决⽅案有：
1. 本地消息表：创建订单时，将减库存消息加⼊在本地事务中，⼀起提交到数据库存⼊本地消息表， 然后调⽤库存系统，如果调⽤成功则修改本地消息状态为成功，如果调⽤库存系统失败，则由后台 定时任务从本地消息表中取出未成功的消息，重试调⽤库存系统
2. 消息队列：⽬前RocketMQ中⽀持事务消息，它的⼯作原理是：
        a. ⽣产者订单系统先发送⼀条half消息到Broker，half消息对消费者⽽⾔是不可⻅的
        b. 再创建订单，根据创建订单成功与否，向Broker发送commit或rollback
        c. 并且⽣产者订单系统还可以提供Broker回调接⼝，当Broker发现⼀段时间half消息没有收到任 何操作命令，则会主动调此接⼝来查询订单是否创建成功
        d. ⼀旦half消息commit了，消费者库存系统就会来消费，如果消费成功，则消息销毁，分布式事 务成功结束
        e. 如果消费失败，则根据重试策略进⾏重试，最后还失败则进⼊死信队列，等待进⼀步处理
3. Seata：阿⾥开源的分布式事务框架，⽀持AT、TCC等多种模式，底层都是基于两阶段提交理论来 实现的

87.负载均衡算法有哪些

1、轮询法：将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每⼀台服务器，⽽不关⼼服 务器实际的连接数和当前的系统负载。
2、随机法：通过系统的随机算法，根据后端服务器的列表⼤⼩值来随机选取其中的⼀台服务器进⾏访 问。由概率统计理论可以得知，随着客户端调⽤服务端的次数增多，其实际效果越来越接近于平均分配 调⽤量到后端的每⼀台服务器，也就是轮询的结果。
3、源地址哈希法：源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的⼀个数值， ⽤该数值对服务器列表的⼤⼩进⾏取模运算，得到的结果便是客服端要访问服务器的序号。采⽤源地址哈希法进⾏负载均衡，同⼀IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同⼀台后端 服务器进⾏访问。
4、加权轮询法：不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能⼒ 也不相同。给配置⾼、负载低的机器配置更⾼的权重，让其处理更多的请；⽽配置低、负载⾼的机器， 给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这⼀问题，并将请求顺序且按照权重分配到后端。
5、加权随机法：与加权轮询法⼀样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，⽽⾮顺序。
6、最⼩连接数法：最⼩连接数算法⽐较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的⼀台服务器 来处理当前的请求，尽可能地提⾼后端服务的利⽤效率，将负责合理地分流到每⼀台服务器。

88.分布式架构下，Session 共享有什么方案

1、采⽤⽆状态服务，抛弃session
2、存⼊cookie（有安全⻛险）
3、服务器之间进⾏ Session 同步，这样可以保证每个服务器上都有全部的 Session 信息，不过当服务 器数量⽐较多的时候，同步是会有延迟甚⾄同步失败；
4、 IP 绑定策略
使⽤ Nginx （或其他复杂均衡软硬件）中的 IP 绑定策略，同⼀个 IP 只能在指定的同⼀个机器访问，但是这样做失去了负载均衡的意义，当挂掉⼀台服务器的时候，会影响⼀批⽤户的使⽤，⻛险很⼤；
5、使⽤ Redis 存储
把 Session 放到 Redis 中存储，虽然架构上变得复杂，并且需要多访问⼀次 Redis ，但是这种⽅案带来的好处也是很⼤的：
● 实现了 Session 共享；
● 可以⽔平扩展（增加 Redis 服务器）；
● 服务器重启 Session 不丢失（不过也要注意 Session 在 Redis 中的刷新/失效机制）；
● 不仅可以跨服务器 Session 共享，甚⾄可以跨平台（例如⽹⻚端和 APP 端）。

89.存储拆分后如何解决唯⼀主键问题

● UUID：简单、性能好，没有顺序，没有业务含义，存在泄漏mac地址的⻛险
● 数据库主键：实现简单，单调递增，具有⼀定的业务可读性，强依赖db、存在性能瓶颈，存在暴露业务 信息的⻛险
● redis，mongodb，zk等中间件：增加了系统的复杂度和稳定性
● 雪花算法

90.雪花算法原理

第⼀位符号位固定为0，41位时间戳，10位workId，12位序列号，位数可以有不同实现。
优点：每个毫秒值包含的ID值很多，不够可以变动位数来增加，性能佳（依赖workId的实现）。时间戳 值在⾼位，中间是固定的机器码，⾃增的序列在低位，整个ID是趋势递增的。能够根据业务场景数据库节点布置灵活调整bit位划分，灵活度⾼。
缺点：强依赖于机器时钟，如果时钟回拨，会导致重复的ID⽣成，所以⼀般基于此的算法发现时钟回拨，都会抛异常处理，阻⽌ID⽣成，这可能导致服务不可⽤。

91.Spring Cloud有哪些常用组件，作用是什么？

1. Eureka：注册中⼼
2. Nacos：注册中⼼、配置中⼼
3. Consul：注册中⼼、配置中⼼
4. Spring Cloud Config：配置中⼼
5. Feign/OpenFeign：RPC调⽤
6. Kong：服务⽹关
7. Zuul：服务⽹关
8. Spring Cloud Gateway：服务⽹关
9. Ribbon：负载均衡
10. Spring CLoud Sleuth：链路追踪
11. Zipkin：链路追踪
12. Seata：分布式事务
13. Dubbo：RPC调⽤
14. Sentinel：服务熔断
15. Hystrix：服务熔断

92.如何避免缓存穿透、缓存击穿、缓存雪崩？

缓存雪崩是指缓存同⼀时间⼤⾯积的失效，所以，后⾯的请求都会落到数据库上，造成数据库短时间内承受⼤量请求⽽崩掉。
解决⽅案：
● 缓存数据的过期时间设置随机，防⽌同⼀时间⼤量数据过期现象发⽣。
● 给每⼀个缓存数据增加相应的缓存标记，记录缓存是否失效，如果缓存标记失效，则更新数据缓
存。
● 缓存预热互斥锁
缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受⼤量请求⽽崩掉。
解决⽅案：
● 接⼝层增加校验，如⽤户鉴权校验，id做基础校验，id<=0的直接拦截；
● 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有
效时间可以设置短点，如30秒（设置太⻓会导致正常情况也没法使⽤）。这样可以防⽌攻击⽤户
反复⽤同⼀个id暴⼒攻击
● 采⽤布隆过滤器，将所有可能存在的数据哈希到⼀个⾜够⼤的 bitmap 中，⼀个⼀定不存在的数据 会被这个 bitmap 拦截掉，从⽽避免了对底层存储系统的查询压⼒
缓存击穿是指缓存中没有但数据库中有的数据（⼀般是缓存时间到期），这时由于并发⽤户特别多，同时读缓存没读到数据，⼜同时去数据库去取数据，引起数据库压⼒瞬间增⼤，造成过⼤压⼒。和缓存雪崩不同的是，缓存击穿指并发查同⼀条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从⽽查数据库。
解决⽅案：
● 设置热点数据永远不过期。加互斥锁

93.缓存过期都有哪些策略？

● 定时过期：每个设置过期时间的key都需要创建⼀个定时器，到过期时间就会⽴即清除。该策略可以
⽴ 即清除过期的数据，对内存很友好；但是会占⽤⼤量的CPU资源去处理过期的数据，从⽽影响缓
存的响应时间和吞吐量
● 惰性过期：只有当访问⼀个key时，才会判断该key是否已过期，过期则清除。该策略可以最⼤化地
节省CPU资源，但是很消耗内存、许多的过期数据都还存在内存中。极端情况可能出现⼤量的过期
56 key没有 再次被访问，从⽽不会被清除，占⽤⼤量内存。
● 定期过期：每隔⼀定的时间，会扫描⼀定数量的数据库的expires字典中⼀定数量的key（是随机
的）， 并清除其中已过期的key。该策略是定时过期和惰性过期的折中⽅案。通过调整定时扫描的
时间间隔和 每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
● 分桶策略：定期过期的优化，将过期时间点相近的key放在⼀起，按时间扫描分桶。

94.常见的缓存淘汰算法

● FIFO（First In First Out，先进先出），根据缓存被存储的时间，离当前最远的数据优先被淘汰；
● LRU（LeastRecentlyUsed，最近最少使⽤），根据最近被使⽤的时间，离当前最远的数据优先被淘汰；
● LFU（LeastFrequentlyUsed，最不经常使⽤），在⼀段时间内，缓存数据被使⽤次数最少的会被淘汰。

95.布隆过滤器原理，优缺点

● 位图：int[10]，每个int类型的整数是4*8=32个bit，则int[10]⼀共有320 bit，每个bit⾮0即1，初始
化时都是0
● 添加数据时：将数据进⾏hash得到hash值，对应到bit位，将该bit改为1，hash函数可以定义多个，则 ⼀个数据添加会将多个（hash函数个数）bit改为1，多个hash函数的⽬的是减少hash碰撞的 概率
● 查询数据：hash函数计算得到hash值，对应到bit中，如果有⼀个为0，则说明数据不在bit中，如果都为1，则该数据可能在bit中
优点：
● 占⽤内存⼩
● 增加和查询元素的时间复杂度为：O(K), (K为哈希函数的个数，⼀般⽐较⼩)，与数据量⼤⼩⽆关哈希函数相互之间没有关系，⽅便硬件并⾏运算
● 布隆过滤器不需要存储元素本身，在某些对保密要求⽐较严格的场合有很⼤优势 数据量很⼤时，布隆过滤器可以表示全集
● 使⽤同⼀组散列函数的布隆过滤器可以进⾏交、并、差运算
缺点：
● 误判率，即存在假阳性(False Position)，不能准确判断元素是否在集合中不能获取元素本身
● ⼀般情况下不能从布隆过滤器中删除元素

96.分布式缓存寻址算法

● hash算法：根据key进⾏hash函数运算、结果对分片数取模，确定分⽚ 适合固定分⽚数的场景，
扩展分⽚或者减少分⽚时，所有数据都需要重新计算分⽚、存储
● ⼀致性hash：将整个hash值得区间组织成⼀个闭合的圆环，计算每台服务器的hash值、映射到圆环中。使⽤相同的hash算法计算数据的hash值，映射到圆环，顺时针寻找，找到的第⼀个服务器就是数据存储的服务器。新增及减少节点时只会影响节点到他逆时针最近的⼀个服务器之间的值 存在hash环倾斜的问题，即服务器分布不均匀，可以通过虚拟节点解决
● hash slot：将数据与服务器隔离开，数据与slot映射，slot与服务器映射，数据进⾏hash决定存放的slot，新增及删除节点时，将slot进⾏迁移即可

97.什么是服务雪崩？什么是服务限流？

1. 当服务A调⽤服务B，服务B调⽤C，此时⼤量请求突然请求服务A，假如服务A本身能抗住这些请求，但是如果服务C抗不住，导致服务C请求堆积，从⽽服务B请求堆积，从⽽服务A不可⽤，这就是服务雪崩，解决⽅式就是服务降级和服务熔断。
2. 服务限流是指在⾼并发请求下，为了保护系统，可以对访问服务的请求进⾏数量上的限制，从⽽防⽌系统不被⼤量请求压垮，在秒杀中，限流是⾮常重要的

98.什么是服务熔断？什么是服务降级？区别是什么？

1. 服务熔断是指，当服务A调⽤的某个服务B不可⽤时，上游服务A为了保证⾃⼰不受影响，从⽽不再 调⽤服务B，直接返回⼀个结果，减轻服务A和服务B的压⼒，直到服务B恢复。
2. 服务降级是指，当发现系统压⼒过载时，可以通过关闭某个服务，或限流某个服务来减轻系统压
⼒，这就是服务降级。
相同点：
1. 都是为了防⽌系统崩溃
2. 都让⽤户体验到某些功能暂时不可⽤
不同点：熔断是下游服务故障触发的，降级是为了降低系统负载
99.怎么拆分微服务？
拆分微服务的时候，为了尽量保证微服务的稳定，会有⼀些基本的准则：
1. 微服务之间尽量不要有业务交叉。
2. 微服务之前只能通过接⼝进⾏服务调⽤，⽽不能绕过接⼝直接访问对⽅的数据。
3. ⾼内聚，低耦合。

100.如何进行消息队列选型？

● Kafka：
○ 优点： 吞吐量⾮常⼤，性能⾮常好，集群⾼可⽤。
○ 缺点：会丢数据，功能⽐较单⼀。
○ 使⽤场景：⽇志分析、⼤数据采集
● RabbitMQ：
○ 优点： 消息可靠性⾼，功能全⾯。
○ 缺点：吞吐量⽐较低，消息积累会严重影响性能。erlang语⾔不好定制。
○ 使⽤场景：⼩规模场景。
● RocketMQ：
○ 优点：⾼吞吐、⾼性能、⾼可⽤，功能⾮常全⾯。
○ 缺点：开源版功能不如云上商业版。官⽅⽂档和周边⽣态还不够成熟。客户端只⽀持java。
○ 使⽤场景：⼏乎是全场景。