大佬教程收集整理的这篇文章主要介绍了分布式相关（面试题），大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
目录
1.redis 和 Memcache 的区别？
2、使用 redis 有哪些好处？
3、什么是 redis 持久化？rdb 和 aof 的比较?
4、redis 最适合的场景?
5、redis 哈希槽的概念?
6、怎么理解 redis 事务？
7、redis 的淘汰策略有哪些?
8、redis 有哪些数据结构?
9、redis 缓存穿透、缓存雪崩、缓存击穿?
12、redis 单线程还能处理速度那么快？
13、为什么 redis 的操作是原子性的c;怎么保证原子性？
14、redis 的主从复制的实现过程?
15、redis 的哨兵机制的作用?
16、redis 常见的性能问题和解决方案?
17、分布式缓存?
18、什么是 Nginx?
19、nginx 相对于 apache 的优点?
20、 Nginx 优化的方式？
21、Nginx 如何处理一个请求的?
22、Nginx 是如何实现高并发的?
23、Nginx 的进程模型?
24、Nginx 负载均衡的 4 种分配方式?
25、为什么要用 Nginx？
26、什么是正向代理?
27、什么是反向代理?
28、什么是负载均衡?
29、Nginx 的调度算法有哪些？
30、Nginx 负载均衡调度状态?
31、可以从哪些方面来优化 nginx 服务？
32、为什么要用 MQ？
33、使用 MQ 会有什么问题？
34、怎么保证 MQ 的高可用？
35、MQ 的优缺点?
36、Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别？
37、如何设置消息的过期时间？
38、消息的持久化是如何实现的？
39、Zookeeper 是什么？
40、Zookeeper 的应用场景?
41、四种类型的数据节点 Znode?
42、Zookeeper Watcher 机制?
43、Zookeeper 下 Server 工作状态?
44、Zookeeper 是如何保证事务的顺序一直性的？
45、ZK 节点宕机如何处理？
46、Zookeeper 有哪几种部署模式？
47、Dubbo 内置了哪几种容器？
48、Dubbo 里面有哪几种角色？
49、Dubbo 有哪几种集群容错方案c;默认是那种？
50、Dubbo 有哪几种负载均衡策略c;默认是哪种？
51、Dubbo 的管理控制台能做什么？
52、什么是 Spring Boot？
53、Spring Boot 有哪些优点？
54、什么是 JavaConfig？
55、如何重新加载 Spring Boot 上的更改c;而无需重新启动服务器？
56、Spring Boot 中的监视器是什么？
57、如何在 Spring Boot 中禁用 Actuator 端点安全性？
59、什么是 WebSocket？
60、什么是 Swagger？
61、什么是 Apache Kafka？
62、什么是 Spring Cloud？
63、使用 Spring Cloud 有什么优势？
64、服务注册和发现是什么意思？
1、存储方式 Memecache 把数据全部存在内存之中c;断电后会挂掉c;数据不能超过内存大小。 redis 有部份存在硬盘上c;redis 可以持久化其数据
2、数据支持类型 memcached 所有的值均是简单的字符串c;redis 作为其替代者c;支持更为丰富的数据类型 c;提供 listc;setc;zsetc;hash 等数据结构的存储
3、使用底层模型不同 它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。redis 直接自己构建了 VM 机制 c;因为一般的系统调用系统函数的话c;会浪费一定的时间去移动和请求。
4、value 值大小不同：redis 最大可以达到 1gb；memcache 只有 1mb。
5、redis 的速度比 memcached 快很多
6、redis 支持数据的备份c;即 master-slave 模式的数据备份。
(1) 速度快c;因为数据存在内存中c;类似于 HashMapc;HashMap 的优势就是查找和操作的时间复杂度都是 O(1)
(2) 支持丰富数据类型c;支持 Stringc;listc;setc;sorted setc;hash
(3) 支持事务c;操作都是原子性c;所谓的原子性就是对数据的更改要么全部执行c;要么全部不执行
(4) 丰富的特性：可用于缓存c;消息c;按 key 设置过期时间c;过期后将会自动删除
持久化就是把内存的数据写到磁盘中去c;防止服务宕机了内存数据丢失。
1、aof 文件比 rdb 更新频率高c;优先使用 aof 还原数据。
（1）、会话缓存（Session Cache） 最常用的一种使用 redis 的情景是会话缓存（session cache）。用 redis 缓存会话比其他存储（如 Memcached）的优势在于：redis 提供持久化。
（2）、全页缓存（FPC） 除基本的会话 token 之外c;redis 还提供很简便的 FPC 平台。回到一致性问题c;即使重启了redis 实例c;因为有磁盘的持久化c;用户也不会看到页面加载速度的下降c;这是一个极大改进c;类似 php 本地 FPC。 再次以 Magento 为例c;R_471_11845@agento 提供一个插件来使用 redis 作为全页缓存后端。此外c;对 WordPress 的用户来说c;Pantheon 有一个非常好的插件 wp-redisc;这个插件能帮助你以最快速度加载你曾浏览过的页面。
（3）、队列 REIDs 在内存存储引擎领域的一大优点是提供 list 和 set 操作c;这使得 redis 能作为一个很好的消息队列平台来使用。redis 作为队列使用的操作c;就类似于本地程序语言（如 Python）对 list 的 push/pop 操作。
（4）c;排行榜/计数器 redis 在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（SortedSet）也使得我们在执行这些操作的时候变的非常简单c;redis 只是正好提供了这两种数据结构。所以c;我们要从排序集合中获取到排名最靠前的 10 个用户–我们称之为“user_scores”c;我们只需要像下面一样执行即可：
（5）、发布/订阅 最后（但肯定不是最不重要的）是 redis 的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用c;还可作为基于发布/订阅的脚本触发器c;甚至用redis 的发布/订阅功能来建立聊天系统！
redis 集群没有使用一致性 hash,而是引入了哈希槽的概念c;redis 集群有 16384 个哈希槽c;每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽c;集群的每个节点负责一部分 hash 槽。
事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行c;事务在执行的过程中c;不会被其他客户端发送来的命令请求所打断。事务是一个原子操作：事务中的命令要么全部被执行c;要么全部都不执行。
noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令c;但 DEL 和几个例外） allkeys-lru: 尝试回收最少使用的键（LRU）c;使得新添加的数据有空间存放。volatile-lru: 尝试回收最少使用的键（LRU）c;但仅限于在过期集合的键,使得新添加的数据有空间存放。 allkeys-random: 回收随机的键使得新添加的数据有空间存放。volatile-random: 回收随机的键使得新添加的数据有空间存放c;但仅限于在过期集合的键。volatile-ttl: 回收在过期集合的键c;并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。
String、List、Set、Zset(sorted set)、hash
redis 通过一主多从c;主节点负责写c;从节点负责读c;读写分离c;从而实现高并发。
主备切换c;哨兵集群c;主节点宕机的情况下c;自动选举出一个从节点变成主节点c;从而保证 了 redis 集群的高可用。
首先c;redis 是单进程单线程的 k-v 内存型可持久化数据库。单线程还能处理速度很快的原因：
2、正是由于 redis 的单线程模式c;避免了线程上下文切换的损耗
3、redis 采用的 IO 多路复用技术c;可以很好的解决多请求并发的问题。 多路代表多请求c;复用代表多个请求重复使用同一个线程。
对于 redis 而言c;命令的原子性指的是：一个操作的不可以再分c;操作要么执行c;要么不执行。 redis 的操作之所以是原子性的c;是因为 redis 是单线程的。redis 本身提供的所有 API 都是原子操作c;redis 中的事务其实是要保证批量操作的原子性。多个命令在并发中也是原子性的吗？ 不一定c; 将 get 和 set 改成单命令操作c;incr 。使用 redis 的事务c;或者使用 redis+Lua==的方式实现.
2、主服务接收到从服务的 sync 同步命令时c;会 fork 一个子进程后台执行 bgsave 命令（非阻塞）快照保存c;生成 RDB 文件c;并将 RDB 文件发送给从服务
3、从服务再将接收到的 RDB 文件载入自己的 redis 内存
4、待从服务将 RDB 载入完成后c;主服务再将缓冲区所有写命令发送给从服务
5、从服务在将主服务所有的写命令载入内存从而实现数据的完整同步
6、从服务下次在需要同步数据时只需要发送自己的 offset 位置（相当于 mysql binlog 的位置）即可c;只同步新增加的数据c;再不需要全量同步
1、监控:SenTinel 会不断的检查主服务器和从服务器是否正常运行。
2、通知:当被监控的某个 redis 服务器出现问题c;SenTinel 通过 API 脚本向管理员或者其他的应用程序发送通知。
3、自动@R_9_10772@:当主节点不能正常工作时c;SenTinel 会开始一次自动的@R_9_10772@操作c;它会将与失效主节点是主从关系 的其中一个从节点升级为新的主节点c;并且将其他的从节点指向新的主节点。
(1) Master 最好不要做任何持久化工作c;如 RDB 内存快照和 AOF 日志文件
(2) 如果数据比较重要c;某个 Slave 开启 AOF 备份数据c;策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性c; Master 和 Slave 最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库
(5) 主从复制不要用图状结构c;用单向链表结构更为稳定c;即： Master <- Slave1 <- Slave2 <-Slave3…
硬盘上的数据c;缓存在别的计算机上（非程序运行的计算机）的内存上c;而且可以缓存的计算机的个数不止一个c;可以使用 n 个用户通过访问 http 服务器c;然后访问应用服务器资源c;应用服务器调用后端的数据库c;在第一次访问的时候c;直接访问数据库c;然后将要缓存的内容放入到 memcached 集群c;集群规模根据缓存文件的大小而定。在第二次访问的时候就直接进入缓存读取c;不需要进行数据库的操作。这个适合数据变化不频繁的场景c;比如：互联网站显示的榜单c;阅读排行等。
Nginx 是一个高性能的 http 和反向代理服务器c;及电子邮件代理服务器c;同时也是一个非 常高效的反向代理、负载平衡。
轻量级c;同样起 web 服务c;比 apache 占用更少的内存及资源 抗并发c;nginx 处理请求是异步非阻塞的c;而 apache 则是阻塞型的c;在高并发下 nginx 能保持低资源低消耗高性能 高度模块化的设计c;编写模块相对简单社区活跃c;各种高性能模块出品迅速啊rewrite c;比 nginx 的 rewrite 强大 模块超多c;基本想到的都可以找到 少 bug c;nginx 的 bug 相对较多
Nginx 运行工作进程数量 Nginx 运行工作进程个数一般设置 CPU 的核心或者核心数 x2 Nginx 运行 CPU 亲和力 比如 4 核配置： worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000 Nginx 最大打开文件数 worker_rlimit_nofile 65535; Nginx 事件处理模型 events { use epoll; worker_connections 65535; multi_accept on; } nginx 采用 epoll 事件模型c;处理效率高。 开启高效传输模式 连接超时时间 主要目的是保护服务器资源c;CPUc;内存c;控制连接数c;因为建立连接也是需要消耗资源的
首先c;nginx 在启动时c;会解析配置文件c;得到需要监听的端口与 ip 地址c;然后在 nginx 的master 进程里面先初始化好这个监控的 socketc;再进行 listen,然后再 fork 出多个子进程出来, 子进程会竞争 accept 新的连接。此时c;客户端就可以向 nginx 发起连接了。当客户端与nginx 进行三次握手c;与 nginx 建立好一个连接后,此时c;某一个子进程会 accept 成功c;然后创建 nginx 对连接的封装c;即 ngx_connection_t 结构体,接着c;根据事件调用相应的事件处理模块c;如 http 模块与客户端进行数据的交换。最后c;nginx 或客户端来主动关掉连接c;到此c;一个连接就寿终正寝了
nginx 之所以可以实现高并发c;与它采用的 epoll 模型有很大的关系。epoll 模型采用异步非阻塞的事件处理机制。这种机制可让 nginx 进程同时监控多个事件。 简单来说c;就是异步非阻塞c;使用了 epoll 模型和大量的底层代码优化。如果深入一点的话c;就是 nginx 的特殊进程模型和事件模型的设计c;才使其可以实现高并发。
它是采用一个 master 进程和多个 worker 进程的工作模式。
1、master 进程主要负责收集、分发请求。当一个请求过来时c;R_471_11845@aster 拉起一个 worker 进程负责处理这个请求。；
2、master 进程也要负责监控 worker 的状态c;保证高可靠性；
3、worker 进程议案设置为和 CPU 核心数一致或者其二倍。nginx 的 worker 进程和 Apache的不一样。apache 的进程在同一时间只能处理一个请求c;所以它会开启很多个进程c;几百甚至几千个。而 nginx 的 worker 进程在同一时间可以处理的请求数只受内存限制c;因此可以处理更多请求。
1、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器c;如果后端服务器 down 掉c;能自动剔除。
2、weight 指定轮询几率c;weight 和访问比率成正比c;用于后端服务器性能不均的情况。 2、ip_hash 每个请求按访问 ip 的 hash 结果分配c;这样每个访客固定访问一个后端服务器c;可以解决的 问题。
3、fair（第三方） 按后端服务器的响应时间来分配请求c;响应时间短的优先分配。
4、url_hash（第三方） 按访问 url 的 hash 结果来分配请求c;使同样的 url 定向到同一个后端服务器c;后端服务器为缓存时比较有效
跨平台、配置简单c;非阻塞、高并发连接：处理 2-3 万并发连接数c;官方监测能支持 5 万并发c; 内存消耗小：开启 10 个 nginx 才占 150M 内存 c;nginx 处理静态文件好,耗费内存少,内置的健康检查功能：如果有一个服务器宕机c;会做一个健康检查c;再发送的请求就不会发送到宕机的服务器了。重新将请求提交到其他的节点上。 节省宽带：支持 GZIP 压缩c;可以添加浏览器本地缓存 稳定性高：宕机的概率非常小 接收用户请求是异步的：浏览器将请求发送到 nginx 服务器c;它先将用户请求全部接收下来c;再一次性发送给后端 web 服务器c;极大减轻了 web 服务器的压力,一边接收 web 服务器的返回数据c;一边发送给浏览器客户端, 网络依赖性比较低c;只要 ping 通就可以负载均衡,可以有多台 nginx 服务器 使用 dns 做负载均衡,事件驱动：通信机制采用 epoll 模型（nio2 异步非阻塞）
一个位于客户端和原始服务器之间的服务器c;为了从原始服务器取得内容c;客户端向代理发送一个请求并指定目标(原始服务器)c;然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理 正向代理总结就一句话：代理端代理的是客户端
反向代理是指以代理服务器来接受 internet 上的连接请求c;然后将请求c;发给内部网络上的服务器,并将从服务器上得到的结果返回给 internet 上请求连接的客户端c;此时代理服务器对外就表现为一个反向代理服务器 反向代理总结就一句话：代理端代理的是服务端
负载均衡即是代理服务器将接收的请求均衡的分发到各服务器中c;负载均衡主要解决网络拥塞问题c;提高服务器响应速度c;服务就近提供c;达到更好的访问质量c;减少后台服务器大并发压力
1、sticky：通过 nginx-sticky 模块c;来实现 cookie 黏贴的方式将来自同一个客户端的请求发送到同一个后端服务器上处理c;这样一定程度上可以解决多个后端服务器的 session 会话同步的问题；
2、round-robin（RR）：轮询c;每个请求按时间顺序依次分配到不同的后端服务器c;如果后端某台服务器死机c;自动剔除故障系统c;使用户访问不受影响；
3、weight：轮询权重c;weight 的值越大分配到的访问概率就越高c;主要用于后端每台服务器性能不均衡的情况下c;或者仅仅为在主从的情况下设置不同的权重c;达到合理有效的利用主机资源。
4、least_conn：请求被发送到当前活跃连接最少的 realserver 上c;会考虑到 weight 的值；
5、ip_hash：每个请求按照 IP 的哈希结果分配c;使来自同一个 IP 的访客固定访问后端服务器c;可以有效的解决动态网页存在的 session 共享问题。
6、fair：比 weight、ip_hash 更加智能的负载均衡算法c;fair 算法可以根据页面的大小和加载时间长短智能地进行负载均衡c;也就是根据后端服务器的响应时间来分配请求c;相应时间短的优先分配。nginx 本身不支持 fairc;如果需要使用这种调度算法c;则必须安装 upstream_fair模块。
7、url_hash：按访问的 URL 的哈希结果来分配请求c;使每个 URL 定向到后端服务器c;可以进一步提高后端缓存服务器的效率。同样c;nginx 本身不支持 url_hashc;如果需要这种调度算法c;则必须安装 nginx 的 hash 软件包。
1、down：表示当前的 server 暂时不参与负载均衡；
2、BACkup：预留的备份机器。当其他所有的非 BACkup 机器出现故障或者繁忙的时候c;才会 请求 BACkup 机器c;因此这台机器的访问压力最低；
3、max_fails：允许请求失败的次数c;默认为 1c;当超过最大次数时c;返回 proxy_next_upstraem模块定义的错误；
4、fail_timeout：请求失败超时时间c;在经历了 max_fails 次失败后c;暂停服务的时间。max_fails和 fail_timeout 可以一起使用。
2、对静态页面开启压缩功能c;如 br 压缩或者 gzip 压缩；
3、调整 nginx 运行工作进程个数c;最多开启 8 个 c;8 个以上话性能就不会再提升了c;而且稳定性变得更低c;所以 8 个足够用了；
5、修改 nginx 最多可打开的文件数c;若超过系统限制的最多打开文件数（ulimit -n 命令查看系统的最多打开文件数）c;还需要修改系统默认的文件数；
8、设置连接超时时间c;以便保护服务器资源c;因为建立连接也是需要消耗资源的；
9、优化 fastCGI 的一个超时时间c;也可以根据实际情况对其配置缓存动态页面；
10、expires 缓存调优c;主要针对图片、css、js 等元素更改较少的情况下使用。
12、优化内核参数c;如进程可以同时打开的最大句柄数；开启 tcp 重用机制c;以便允许TIME_WAIT sockets 重新用于新的 TCP 连接
1、解耦：如果多个模块或者系统中c;互相调用很复杂c;维护起来比较麻烦c;但是这个调用又不是同步调用c;就可以运用 MQ 到这个业务中。
2、异步：这个很好理解c;比如用户的操作日志的维护c;可以不用同步处理c;节约响应时间。
3、削峰：在高峰期的时候c;系统每秒的请求量达到 5000c;那么调用 MySQL 的请求也是5000c;一般情况下 MySQL 的请求大概在 2000 左右c;那么在高峰期的时候c;数据库就被打垮了c;那系统就不可用了。此时引入 MQc;在系统 A 前面加个 MQc;用户请求先到 MQc;系统 A 从 MQ 中每秒消费 2000 条数据c;这样就把本来 5000 的请求变为 MySQL 可以接受的请求数量了c;可以保证系统不挂掉c;可以继续提供服务。MQ 里的数据可以慢慢的把它消费掉。
RabbitMQ 是比较有代表性的c;因为是基于主从做高可用性的。以他为例c;自行查阅以下模 式。 rabbitmq 有三种模式：单机模式、普通集群模式、镜像集群模式。
在特殊场景下有其对应的好处c;解耦、异步、削峰。缺点有以下几个： 系统可用性降低 系统引入的外部依赖越多c;越容易挂掉。万一 MQ 挂了c;R_471_11845@Q 一挂c;整套系统崩溃c;你不 就完了？ 系统复杂度提高 硬生生加个 MQ 进来c;你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保 证消息传递的顺序性？问题一大堆。 一致性问题 A 系统处理完了直接返回成功了c;人都以为你这个请求就成功了；但是问题是c;要是 BCD 三个系统那里c;BD 两个系统写库成功了c;结果 C 系统写库失败了c;咋整？你这数据就不一致了。
对于吞吐量来说 kafka 和 RocketMQ 支撑高吞吐c;ActiveMQ 和 RabbitMQ 比他们低一个数量 级。对于延迟量来说 RabbitMQ 是最低的。
1.从社区活跃度 按照目前网络上的资料c;RabbitMQ、activeM 、ZeroMQ 三者中c;综合来看c;RabbitMQ 是首 选。
2.持久化消息比较 ActiveMq 和 RabbitMq 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了c;消息不会丢失的机制。
3.综合技术实现 可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。 RabbitMq/Kafka 最好c;ActiveMq 次之c;ZeroMq 最差。当然 ZeroMq 也可以做到c;不过自己必须手动写代码实现c;代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。
4.高并发 毋庸置疑c;RabbitMQ 最高c;原因是它的实现语言是天生具备高并发高可用的 erlang 语言。
5.比较关注的比较c;RabbitMQ 和 Kafka RabbitMq 比 Kafka 成熟c;在可用性上c;稳定性上c;可靠性上c;RabbitMq 胜于 Kafka（理论上）。另外c;Kafka 的定位主要在日志等方面c; 因为 Kafka 设计的初衷就是处理日志的c;可以看做是一个日志（消息）系统一个重要组件c;针对性很强c;所以 如果业务方面还是建议选择 RabbitMq 。 还有就是c;Kafka 的性能（吞吐量、TPS）比 RabbitMq 要高出来很多。
设置队列属性c;队列中所有消息都有相同的过期时间 对消息本身进行单独设置c;每条消息的 TTL 可以不同如果两种方法一起使用c;则消息的 TTL 以两者之间较小的那个数值为准
RabbitMQ 的持久化分为:交换器的持久化、队列的持久化和消息的持久化 交换器和队列的持久化都是通过在声明时将 durable 参数置为 true 实现的消息的持久化是在发送消息指定 deliverymode 为 2 实现的
ZooKeeper 是一个开放源码的分布式协调服务c;它是集群的管理者c;监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终c;将简单易用的接口和性能高效、功能稳定的系统提供给用户。
数据发布/订阅负载均衡 命名服务 分布式协调/通知集群管理 Master 选举分布式锁 分布式队列
PERSISTENT-持久节点 除非手动删除c;否则节点一直存在于 Zookeeper 上EPHEMERAL-临时节点 临时节点的生命周期与客户端会话绑定c;一旦客户端会话失效（客户端与 zookeeper 连接断开不一定会话失效）c;那么这个客户端创建的所有临时节点都会被移除。PERSISTENT_SEQUENTIAL-持久顺序节点 基本特性同持久节点c;只是增加了顺序属性c;节点名后边会追加一个由父节点维护的自增整型数字。 EPHEMERAL_SEQUENTIAL-临时顺序节点 基本特性同临时节点c;增加了顺序属性c;节点名后边会追加一个由父节点维护的自增整型数字。
1、一次性 无论是服务端还是客户端c;一旦一个 Watcher 被触发c;Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力c;不然对于更新非常频繁的节点c;服务端会不断的向客户端发送事件通知c;无论对于网络还是服务端的压力都非常大。
2、客户端串行执行 客户端 Watcher 回调的过程是一个串行同步的过程。
3、轻量 3.1Watcher 通知非常简单c;只会告诉客户端发生了事件c;而不会说明事件的具体内容。3.2 客户端向服务端注册 Watcher 的时候c;并不会把客户端真实的 Watcher 对象实体传递到服务端c;仅仅是在客户端请求中使用 Boolean 类型属性进行了标记。
4、watcher event 异步发送 watcher 的通知事件从 server 发送到 client 是异步的c;这就存在一个问题c;不同的客户端和服务器之间通过 socket 进行通信c;由于网络延迟或其他因素导致客户端在不通的时刻监听到事件c;由于 Zookeeper 本身提供了 ordering guaranteec;即客户端监听事件后c;才会感知它所监视 znode 发生了变化。所以我们使用 Zookeeper 不能期望能够监控到节点每次的变化。Zookeeper 只能保证最终的一致性c;而无法保证强一致性。
5、注册 watcher getData、exists、getChildren
6、触发 watcher create、delete、setData
7、当一个客户端连接到一个新的服务器上时c;watch 将会被以任意会话事件触发。当与一个服务器失去连接的时候c;是无法接收到 watch 的。而当 client 重新连接时c;如果需要的话c;所有先前注册过的 watchc;都会被重新注册。通常这是完全透明的。只有在一个特殊情况下c;watch 可能会丢失：对于一个未创建的 znode 的 exist watchc;如果在客户端断开连接期间被创建了c;并且随后在客户端连接上之前又删除了c;这种情况下c;这个 watch 事件可能会被丢失。
服务器具有四种状态c;分别是 LOOKING、FOLLOWING、LEADING、OBserviNG。LOOKING：寻找 Leader 状态。当服务器处于该状态时c;它会认为当前集群中没有 Leaderc;因此需要进入 Leader 选举状态。 FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。LEADING：领导者状态。表明当前服务器角色是 Leader。 OBserviNG：观察者状态。表明当前服务器角色是 Observer。
zookeeper 采用了全局递增的事务 Id 来标识c;所有的 proposal（提议）都在被提出的时候加上了 zxidc;zxid 实际上是一个 64 位的数字c;高 32 位是 epoch（时期; 纪元; 世; 新时代）用来标识 leader 周期c;如果有新的 leader 产生出来c;epoch 会自增c;低 32 位用来递增计数。当新产生 proposal 的时候c;会依据数据库的两阶段过程c;首先会向其他的 server 发出事务执行请求c;如果超过半数的机器都能执行并且能够成功c;那么就会开始执行。
Zookeeper 本身也是集群c;推荐配置不少于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时c;其他节点会继续提供服务。 如果是一个 Follower 宕机c;还有 2 台服务器提供访问c;因为 Zookeeper 上的数据是有多个副本的c;数据并不会丢失； 如果是一个 Leader 宕机c;Zookeeper 会选举出新的 Leader。ZK 集群的机制是只要超过半数的节点正常c;集群就能正常提供服务。只有在 ZK 节点挂得太多c;只剩一半或不到一半节点能工作c;集群才失效。所以 3 个节点的 cluster 可以挂掉 1 个节点(leader 可以得到 2 票>1.5)2 个节点的 cluster 就不能挂掉任何 1 个节点了(leader 可以得到 1 票<=1)
Spring Containerjetty ContainerLog4j Container
Provider：暴露服务的服务提供方 Consumer：调用远程服务的服务消费方Registry：服务注册与发现的注册中心Monitor：统计服务的调用次数和调用时间的监控中心Container：服务运行容器
Failover Cluster：失败自动切换c;自动重试其他服务器（默认）Failfast Cluster：快速失败c;立即报错c;只发起一次调用Failsafe Cluster：失败安全c;出现异常时c;直接忽略 FailBACk Cluster：失败自动恢复c;记录失败请求c;定时重发Forking Cluster：并行调用多个服务器c;只要一个成功即返回Broadcast Cluster：广播逐个调用所有提供者c;任意一个报错则报错
Random LoadBalance:随机c;按权重设置随机概率(默认) RoundRobin LoadBalance：轮询c;按公约后的权重设置轮询比率leastActive LoadBalance：最少活跃调用次数c;相同活跃数的随机 ConsistentHash LoadBalance：一直性 Hashc;相同参数的请求总是发到同一提供者
管理控制台主要包含：路由规则c;动态配置c;服务降级c;访问控制c;权重调整c;负载均衡c;等管理功能。
多年来c;随着新功能的增加c;spring 变得越来越复杂。只需访问 https://spring.io/projects 页面c;我们就会看到可以在@R_155_9616@程序中使用的所有 Spring 项目的不同功能。如果必须启动一个新的 Spring 项目c;我们必须添加构建路径或添加 Maven 依赖关系c;配置应用程序服务器c;添加 spring 配置。因此c;开始一个新的 spring 项目需要很多努力c;因为我们现在必须从头开始做所有事情。 Spring Boot 是解决这个问题的方法。Spring Boot 已经建立在现有 spring 框架之上。使用 spring启动c;我们避免了之前我们必须做的所有样板代码和配置。因此c;Spring Boot 可以帮助我们以最少的工作量c;更加健壮地使用现有的 Spring 功能。
减少开发c;测试时间和努力。 使用 JavaConfig 有助于避免使用 XML。 避免大量的 Maven 导入和各种版本冲突。 提供意见发展方法。 通过提供默认值快速开始开发。 没有单独的 Web 服务器需要。这意味着你不再需要启动 tomcatc;Glassfish 或其他任何东西。需要更少的配置 因为没有 web.xml 文件。只需添加用@ Configuration 注释的类c;然后添加用@Bean 注释的方法c;Spring 将自动加载对象并像以前一样对其进行管理。您甚至可以将@Autowired 添加到 bean 方法中c;以使 Spring 自动装入需要的依赖关系中。基 于环 境的 配置 使 用这 些属 性c; 您可 以将 您正 在使 用的 环境 传递 到应 用程 序：-Dspring.profiles.active = {enviornment} 。 在 加 载 主 应 用 程 序 属 性 文 件 后 c; Spring 将 在（application{environment} .properties）中加载后续的应用程序属性文件。
Spring JavaConfig 是 Spring 社区的产品c;它提供了配置 Spring IoC 容器的纯 Java 方法。因此它有助于避免使用 XML 配置。使用 JavaConfig 的优点在于： 面向对象的配置。由于配置被定义为 JavaConfig 中的类c;因此用户可以充分利用 Java 中的面向对象功能。一个配置类可以继承另一个c;重写它的@Bean 方法等。 减少或消除 XML 配置。基于依赖注入原则的外化配置的好处已被证明。但是c;许多开发人员不希望在 XML 和 Java 之间来回切换。JavaConfig 为开发人员提供了一种纯 Java 方法来配置与 XML 配置概念相似的 Spring 容器。从技术角度来讲c;只使用 JavaConfig 配置类来配置容器是可行的c;但实际上很多人认为将 JavaConfig 与 XML 混合匹配是理想的。类型安全和重构友好。JavaConfig提供了一种类型安全的方法来配置Spring容器。由于Java 5.0对泛型的支持c;现在可以按类型而不是按名称检索 beanc;不需要任何强制转换或基于字符串的查找。
这可以使用 DEV 工具来实现。通过这种依赖关系c;您可以节省任何更改c;嵌入式 tomcat 将重新启动。Spring Boot 有一个开发工具（DevTools）模块c;它有助于提高开发人员的生产力。Java 开发人员面临的一个主要挑战是将文件更改自动部署到服务器并自动重启服务器。开发人员可以重新加载 Spring Boot 上的更改c;而无需重新启动服务器。这将消除每次手动部署更改的需要。Spring Boot 在发布它的第一个版本时没有这个功能。这是开发人员最需要的功能。DevTools 模块完全满足开发人员的需求。该模块将在生产环境中被禁用。它还提供 H2数据库控制台以更好地测试应用程序。
Spring boot actuator 是 spring 启动框架中的重要功能之一。Spring boot 监视器可帮助您访问生产环境中正在运行的应用程序的当前状态。有几个指标必须在生产环境中进行检查和监控。即使一些外部应用程序可能正在使用这些服务来向相关人员触发警报消息。监视器模块公开了一组可直接作为 http URL 访问的 REST 端点来检查状态。
默认情况下c;所有敏感的 http 端点都是安全的c;只有具有 ACTUATOR 角色的用户才能访问它们。安全性是使用标准的 httpServletrequest.isUserInRole 方法实施的。 我们可以使用management.security.enabled = false 来禁用安全性。只有在执行机构端点在防火墙后访问时c;才建议禁用安全性。
WebSocket 是一种计算机通信协议c;通过单个 TCP 连接提供全双工通信信道。WebSocket 是双向的 -使用 WebSocket 客户端或服务器可以发起消息发送。WebSocket 是全双工的 -客户端和服务器通信是相互独立的。单个 TCP 连接 -初始连接使用 httpc;然后将此连接升级到基于套接字的连接。然后这个单一连接用于所有未来的通信 Light -与 http 相比c;WebSocket 消息数据交换要轻得多。
你用 Spring Boot 实现了它吗？ Swagger 广泛用于可视化 APIc;使用 Swagger UI 为前端开发人员提供在线沙箱。Swagger 是用于生成 RESTful Web 服务的可视化表示的工具c;规范和完整框架实现。它使文档能够以与服务器相同的速度更新。当通过 Swagger 正确定义时c;消费者可以使用最少量的实现逻辑来理解远程服务并与其进行交互。因此c;Swagger 消除了调用服务时的猜测。
Apache Kafka 是一个分布式发布 - 订阅消息系统。它是一个可扩展的c;容错的发布 - 订阅消息系统c;它使我们能够构建分布式应用程序。这是一个 Apache 顶级项目。Kafka 适合离线和在线消息消费。
Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序c;提供与外部系统的集成。Spring cloud Taskc;一个生命周期短暂的微服务框架c;用于快速构建执行有限数据处理的应用程序。
使用 Spring Boot 开发分布式微服务时c;我们面临以下问题 1、与分布式系统相关的复杂性-这种开销包括网络问题c;延迟开销c;带宽问题c;安全问题。 2、服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录c;在该目录中注册服务c;然后能够查找并连接到该目录中的服务。 3、冗余-分布式系统中的冗余问题。 4、负载平衡 --负载平衡改善跨多个计算资源的工作负荷c;诸如计算机c;计算机集群c;网络链路c;中央处理单元c;或磁盘驱动器的分布。 5、性能-问题 由于各种运营开销导致的性能问题。6、部署复杂性-Devops 技能的要求。
Spring Cloud 如何实现？ 当我们开始一个项目时c;我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署c;添加和修改这些属性变得更加复杂。有些服务可能会下降c;而某些位置可能会发生变化。手动更改属性可能会产生问题。 Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找c;因此无需处理服务地点的任何更改和处理。
以上是大佬教程为你收集整理的分布式相关（面试题）全部内容，希望文章能够帮你解决分布式相关（面试题）所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。