分布式相關（面試題）

目錄

1.Redis 和 Memcache 的區別？

2、使用 Redis 有哪些好處？

3、什么是 redis 持久化？rdb 和 aof 的比較?

4、Redis 最適合的場景?

5、redis 哈希槽的概念?

6、怎么理解 Redis 事務？

7、redis 的淘汰策略有哪些?

8、redis 有哪些資料結構?

9、redis 快取穿透、快取雪崩、快取擊穿?

10、redis 如何實作高并發?

11、redis 如何實作高可用?

12、redis 單執行緒還能處理速度那么快？

13、為什么 Redis 的操作是原子性的，怎么保證原子性？

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 有哪幾種集群容錯方案，默認是那種？

50、Dubbo 有哪幾種負載均衡策略，默認是哪種？

51、Dubbo 的管理控制臺能做什么？

52、什么是 Spring Boot？

53、Spring Boot 有哪些優點？

54、什么是 JavaConfig？

55、如何重新加載 Spring Boot 上的更改，而無需重新啟動服務器？

56、Spring Boot 中的監視器是什么？

57、如何在 Spring Boot 中禁用 Actuator 端點安全性？

59、什么是 WebSocket？

60、什么是 Swagger？

61、什么是 Apache Kafka？

62、什么是 Spring Cloud？

63、使用 Spring Cloud 有什么優勢？

64、服務注冊和發現是什么意思？

---

1.Redis 和 Memcache 的區別？

1、存盤方式 Memecache 把資料全部存在記憶體之中，斷電后會掛掉，資料不能超過記憶體大小， Redis 有部份存在硬碟上，redis 可以持久化其資料

2、資料支持型別 memcached 所有的值均是簡單的字串，redis 作為其替代者，支持更為豐富的資料型別 ，提供 list，set，zset，hash 等資料結構的存盤

3、使用底層模型不同 它們之間底層實作方式 以及與客戶端之間通信的應用協議不一樣，Redis 直接自己構建了 VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求，

4、value 值大小不同：Redis 最大可以達到 1gb；memcache 只有 1mb，

5、redis 的速度比 memcached 快很多

6、Redis 支持資料的備份，即 master-slave 模式的資料備份，

2、使用 Redis 有哪些好處？

(1) 速度快，因為資料存在記憶體中，類似于 HashMap，HashMap 的優勢就是查找和操作的時間復雜度都是 O(1)

(2) 支持豐富資料型別，支持 string，list，set，sorted set，hash

(3) 支持事務，操作都是原子性，所謂的原子性就是對資料的更改要么全部執行，要么全部不執行

(4) 豐富的特性：可用于快取，訊息，按 key 設定過期時間，過期后將會自動洗掉

3、什么是 redis 持久化？rdb 和 aof 的比較?

持久化就是把記憶體的資料寫到磁盤中去，防止服務宕機了記憶體資料丟失，

比較：

1、aof 檔案比 rdb 更新頻率高，優先使用 aof 還原資料，

2、aof 比 rdb 更安全也更大

3、rdb 性能比 aof 好

4、如果兩個都配了優先加載 AOF

4、Redis 最適合的場景?

（1）、會話快取（Session Cache） 最常用的一種使用 Redis 的情景是會話快取（session cache），用 Redis 快取會話比其他存盤（如 Memcached）的優勢在于：Redis 提供持久化，

（2）、全頁快取（FPC） 除基本的會話 token 之外，Redis 還提供很簡便的 FPC 平臺，回到一致性問題，即使重啟了Redis 實體，因為有磁盤的持久化，用戶也不會看到頁面加載速度的下降，這是一個極大改進，類似 PHP 本地 FPC， 再次以 Magento 為例，Magento 提供一個插件來使用 Redis 作為全頁快取后端，此外，對 WordPress 的用戶來說，Pantheon 有一個非常好的插件 wp-redis，這個插件能幫助你以最快速度加載你曾瀏覽過的頁面，

（3）、佇列 Reids 在記憶體存盤引擎領域的一大優點是提供 list 和 set 操作，這使得 Redis 能作為一個很好的訊息佇列平臺來使用，Redis 作為佇列使用的操作，就類似于本地程式語言（如 Python）對 list 的 push/pop 操作，

（4），排行榜/計數器 Redis 在記憶體中對數字進行遞增或遞減的操作實作的非常好，集合（Set）和有序集合（SortedSet）也使得我們在執行這些操作的時候變的非常簡單，Redis 只是正好提供了這兩種資料結構，所以，我們要從排序集合中獲取到排名最靠前的 10 個用戶–我們稱之為“user_scores”，我們只需要像下面一樣執行即可：

（5）、發布/訂閱 最后（但肯定不是最不重要的）是 Redis 的發布/訂閱功能，發布/訂閱的使用場景確實非常多，我已看見人們在社交網路連接中使用，還可作為基于發布/訂閱的腳本觸發器，甚至用Redis 的發布/訂閱功能來建立聊天系統！

5、redis 哈希槽的概念?

Redis 集群沒有使用一致性 hash,而是引入了哈希槽的概念，Redis 集群有 16384 個哈希槽，每個 key 通過 CRC16 校驗后對 16384 取模來決定放置哪個槽，集群的每個節點負責一部分 hash 槽，

6、怎么理解 Redis 事務？

事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行，事務在執行的程序中，不會被其他客戶端發送來的命令請求所打斷，事務是一個原子操作：事務中的命令要么全部被執行，要么全部都不執行，

7、redis 的淘汰策略有哪些?

noeviction:回傳錯誤當記憶體限制達到并且客戶端嘗試執行會讓更多記憶體被使用的命令（大部分的寫入指令，但 DEL 和幾個例外） allkeys-lru: 嘗試回收最少使用的鍵（LRU），使得新添加的資料有空間存放，volatile-lru: 嘗試回收最少使用的鍵（LRU），但僅限于在過期集合的鍵,使得新添加的資料有空間存放， allkeys-random: 回收隨機的鍵使得新添加的資料有空間存放，volatile-random: 回收隨機的鍵使得新添加的資料有空間存放，但僅限于在過期集合的鍵，volatile-ttl: 回收在過期集合的鍵，并且優先回收存活時間（TTL）較短的鍵,使得新添加的資料有空間存放，

8、redis 有哪些資料結構?

String、List、Set、Zset(Sorted Set)、hash

9、redis 快取穿透、快取雪崩、快取擊穿?

10、redis 如何實作高并發?

redis 通過一主多從，主節點負責寫，從節點負責讀，讀寫分離，從而實作高并發，

11、redis 如何實作高可用?

主備切換，哨兵集群，主節點宕機的情況下，自動選舉出一個從節點變成主節點，從而保證 了 redis 集群的高可用，

12、redis 單執行緒還能處理速度那么快？

首先，redis 是單行程單執行緒的 k-v 記憶體型可持久化資料庫，單執行緒還能處理速度很快的原因：

1、redis 操作是基于記憶體的，記憶體的讀寫速度非常快

2、正是由于 redis 的單執行緒模式，避免了執行緒背景關系切換的損耗

3、redis 采用的 IO 多路復用技術，可以很好的解決多請求并發的問題， 多路代表多請求，復用代表多個請求重復使用同一個執行緒，

13、為什么 Redis 的操作是原子性的，怎么保證原子性？

對于 Redis 而言，命令的原子性指的是：一個操作的不可以再分，操作要么執行，要么不執行， Redis 的操作之所以是原子性的，是因為 Redis 是單執行緒的，Redis 本身提供的所有 API 都是原子操作，Redis 中的事務其實是要保證批量操作的原子性，多個命令在并發中也是原子性的嗎？ 不一定， 將 get 和 set 改成單命令操作，incr ，使用 Redis 的事務，或者使用 Redis+Lua==的方式實作.

14、redis 的主從復制的實作程序?

1、從服務發送一個 sync 同步命令給主服務要求全量同步

2、主服務接收到從服務的 sync 同步命令時，會 fork 一個子行程后臺執行 bgsave 命令（非阻塞）快照保存，生成 RDB 檔案，并將 RDB 檔案發送給從服務

3、從服務再將接收到的 RDB 檔案載入自己的 redis 記憶體

4、待從服務將 RDB 載入完成后，主服務再將緩沖區所有寫命令發送給從服務

5、從服務在將主服務所有的寫命令載入記憶體從而實作資料的完整同步

6、從服務下次在需要同步資料時只需要發送自己的 offset 位置（相當于 mysql binlog 的位置）即可，只同步新增加的資料，再不需要全量同步

15、redis 的哨兵機制的作用?

1、監控:Sentinel 會不斷的檢查主服務器和從服務器是否正常運行，

2、通知:當被監控的某個 redis 服務器出現問題，Sentinel 通過 API 腳本向管理員或者其他的應用程式發送通知，

3、自動故障轉移:當主節點不能正常作業時，Sentinel 會開始一次自動的故障轉移操作，它會將與失效主節點是主從關系 的其中一個從節點升級為新的主節點，并且將其他的從節點指向新的主節點，

16、redis 常見的性能問題和解決方案?

(1) Master 最好不要做任何持久化作業，如 RDB 記憶體快照和 AOF 日志檔案

(2) 如果資料比較重要，某個 Slave 開啟 AOF 備份資料，策略設定為每秒同步一次

(3) 為了主從復制的速度和連接的穩定性， Master 和 Slave 最好在同一個局域網內

(4) 盡量避免在壓力很大的主庫上增加從庫

(5) 主從復制不要用圖狀結構，用單向鏈表結構更為穩定，即： Master <- Slave1 <- Slave2 <-Slave3…

17、分布式快取?

硬碟上的資料，快取在別的計算機上（非程式運行的計算機）的記憶體上，而且可以快取的計算機的個數不止一個，可以使用 n 個用戶通過訪問 http 服務器，然后訪問應用服務器資源，應用服務器呼叫后端的資料庫，在第一次訪問的時候，直接訪問資料庫，然后將要快取的內容放入到 memcached 集群，集群規模根據快取檔案的大小而定，在第二次訪問的時候就直接進入快取讀取，不需要進行資料庫的操作，這個適合資料變化不頻繁的場景，比如：互聯網站顯示的榜單，閱讀排行等，

18、什么是 Nginx?

Nginx 是一個高性能的 HTTP 和反向代理服務器，及電子郵件代理服務器，同時也是一個非 常高效的反向代理、負載平衡，

19、nginx 相對于 apache 的優點?

輕量級，同樣起 web 服務，比 apache 占用更少的記憶體及資源 抗并發，nginx 處理請求是異步非阻塞的，而 apache 則是阻塞型的，在高并發下 nginx 能保持低資源低消耗高性能 高度模塊化的設計，撰寫模塊相對簡單社區活躍，各種高性能模塊出品迅速啊rewrite ，比 nginx 的 rewrite 強大 模塊超多，基本想到的都可以找到 少 bug ，nginx 的 bug 相對較多

20、 Nginx 優化的方式？

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 事件模型，處理效率高， 開啟高效傳輸模式 連接超時時間 主要目的是保護服務器資源，CPU，記憶體，控制連接數，因為建立連接也是需要消耗資源的

21、Nginx 如何處理一個請求的?

首先，nginx 在啟動時，會決議組態檔，得到需要監聽的埠與 ip 地址，然后在 nginx 的master 行程里面先初始化好這個監控的 socket，再進行 listen,然后再 fork 出多個子行程出來, 子行程會競爭 accept 新的連接，此時，客戶端就可以向 nginx 發起連接了，當客戶端與nginx 進行三次握手，與 nginx 建立好一個連接后,此時，某一個子行程會 accept 成功，然后創建 nginx 對連接的封裝，即 ngx_connection_t 結構體,接著，根據事件呼叫相應的事件處理模塊，如 http 模塊與客戶端進行資料的交換，最后，nginx 或客戶端來主動關掉連接，到此，一個連接就壽終正寢了

22、Nginx 是如何實作高并發的?

nginx 之所以可以實作高并發，與它采用的 epoll 模型有很大的關系，epoll 模型采用異步非阻塞的事件處理機制，這種機制可讓 nginx 行程同時監控多個事件， 簡單來說，就是異步非阻塞，使用了 epoll 模型和大量的底層代碼優化，如果深入一點的話，就是 nginx 的特殊行程模型和事件模型的設計，才使其可以實作高并發，

23、Nginx 的行程模型?

它是采用一個 master 行程和多個 worker 行程的作業模式，

1、master 行程主要負責收集、分發請求，當一個請求過來時，master 拉起一個 worker 行程負責處理這個請求，；

2、master 行程也要負責監控 worker 的狀態，保證高可靠性；

3、worker 行程議案設定為和 CPU 核心數一致或者其二倍，nginx 的 worker 行程和 Apache的不一樣，apache 的行程在同一時間只能處理一個請求，所以它會開啟很多個行程，幾百甚至幾千個，而 nginx 的 worker 行程在同一時間可以處理的請求數只受記憶體限制，因此可以處理更多請求，

24、Nginx 負載均衡的 4 種分配方式?

1、輪詢（默認） 每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器 down 掉，能自動剔除，

2、weight 指定輪詢幾率，weight 和訪問比率成正比，用于后端服務器性能不均的情況， 2、ip_hash 每個請求按訪問 ip 的 hash 結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決的 問題，

3、fair（第三方） 按后端服務器的回應時間來分配請求，回應時間短的優先分配，

4、url_hash（第三方） 按訪問 url 的 hash 結果來分配請求，使同樣的 url 定向到同一個后端服務器，后端服務器為快取時比較有效

25、為什么要用 Nginx？

跨平臺、配置簡單，非阻塞、高并發連接：處理 2-3 萬并發連接數，官方監測能支持 5 萬并發， 記憶體消耗小：開啟 10 個 nginx 才占 150M 記憶體 ，nginx 處理靜態檔案好,耗費記憶體少,內置的健康檢查功能：如果有一個服務器宕機，會做一個健康檢查，再發送的請求就不會發送到宕機的服務器了，重新將請求提交到其他的節點上， 節省寬帶：支持 GZIP 壓縮，可以添加瀏覽器本地快取 穩定性高：宕機的概率非常小 接收用戶請求是異步的：瀏覽器將請求發送到 nginx 服務器，它先將用戶請求全部接收下來，再一次性發送給后端 web 服務器，極大減輕了 web 服務器的壓力,一邊接收 web 服務器的回傳資料，一邊發送給瀏覽器客戶端, 網路依賴性比較低，只要 ping 通就可以負載均衡,可以有多臺 nginx 服務器 使用 dns 做負載均衡,事件驅動：通信機制采用 epoll 模型（nio2 異步非阻塞）

26、什么是正向代理?

一個位于客戶端和原始服務器之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求并指定目標(原始服務器)，然后代理向原始服務器轉交請求并將獲得的內容回傳給客戶端，客戶端才能使用正向代理 正向代理總結就一句話：代理端代理的是客戶端

27、什么是反向代理?

反向代理是指以代理服務器來接受 internet 上的連接請求，然后將請求，發給內部網路上的服務器,并將從服務器上得到的結果回傳給 internet 上請求連接的客戶端，此時代理服務器對外就表現為一個反向代理服務器 反向代理總結就一句話：代理端代理的是服務端

28、什么是負載均衡?

負載均衡即是代理服務器將接收的請求均衡的分發到各服務器中，負載均衡主要解決網路擁塞問題，提高服務器回應速度，服務就近提供，達到更好的訪問質量，減少后臺服務器大并發壓力

29、Nginx 的調度演算法有哪些？

1、sticky：通過 nginx-sticky 模塊，來實作 cookie 黏貼的方式將來自同一個客戶端的請求發送到同一個后端服務器上處理，這樣一定程度上可以解決多個后端服務器的 session 會話同步的問題；

2、round-robin（RR）：輪詢，每個請求按時間順序依次分配到不同的后端服務器，如果后端某臺服務器死機，自動剔除故障系統，使用戶訪問不受影響；

3、weight：輪詢權重，weight 的值越大分配到的訪問概率就越高，主要用于后端每臺服務器性能不均衡的情況下，或者僅僅為在主從的情況下設定不同的權重，達到合理有效的利用主機資源，

4、least_conn：請求被發送到當前活躍連接最少的 realserver 上，會考慮到 weight 的值；

5、ip_hash：每個請求按照 IP 的哈希結果分配，使來自同一個 IP 的訪客固定訪問后端服務器，可以有效的解決動態網頁存在的 session 共享問題，

6、fair：比 weight、ip_hash 更加智能的負載均衡演算法，fair 演算法可以根據頁面的大小和加載時間長短智能地進行負載均衡，也就是根據后端服務器的回應時間來分配請求，相應時間短的優先分配，nginx 本身不支持 fair，如果需要使用這種調度演算法，則必須安裝 upstream_fair模塊，

7、url_hash：按訪問的 URL 的哈希結果來分配請求，使每個 URL 定向到后端服務器，可以進一步提高后端快取服務器的效率，同樣，nginx 本身不支持 url_hash，如果需要這種調度演算法，則必須安裝 nginx 的 hash 軟體包，

30、Nginx 負載均衡調度狀態?

常用的狀態有：

1、down：表示當前的 server 暫時不參與負載均衡；

2、backup：預留的備份機器，當其他所有的非 backup 機器出現故障或者繁忙的時候，才會 請求 backup 機器，因此這臺機器的訪問壓力最低；

3、max_fails：允許請求失敗的次數，默認為 1，當超過最大次數時，回傳 proxy_next_upstraem模塊定義的錯誤；

4、fail_timeout：請求失敗超時時間，在經歷了 max_fails 次失敗后，暫停服務的時間，max_fails和 fail_timeout 可以一起使用，

31、可以從哪些方面來優化 nginx 服務？

1、配置 nginx 的 proxy 快取；

2、對靜態頁面開啟壓縮功能，如 br 壓碩訓者 gzip 壓縮；

3、調整 nginx 運行作業行程個數，最多開啟 8 個 ，8 個以上話性能就不會再提升了，而且穩定性變得更低，所以 8 個足夠用了；

4、調整 nginx 運行 CPU 的親和力；

5、修改 nginx 最多可打開的檔案數，若超過系統限制的最多打開檔案數（ulimit -n 命令查看系統的最多打開檔案數），還需要修改系統默認的檔案數；

6、修改單個 worker 的最大連接數；

7、開啟高效傳輸；

8、設定連接超時時間，以便保護服務器資源，因為建立連接也是需要消耗資源的；

9、優化 fastCGI 的一個超時時間，也可以根據實際情況對其配置快取動態頁面；

10、expires 快取調優，主要針對圖片、css、js 等元素更改較少的情況下使用，

11、配置防盜鏈；

12、優化內核引數，如行程可以同時打開的最大句柄數；開啟 tcp 重用機制，以便允許TIME_WAIT sockets 重新用于新的 TCP 連接

32、為什么要用 MQ？

1、解耦：如果多個模塊或者系統中，互相呼叫很復雜，維護起來比較麻煩，但是這個呼叫又不是同步呼叫，就可以運用 MQ 到這個業務中，

2、異步：這個很好理解，比如用戶的操作日志的維護，可以不用同步處理，節約回應時間，

3、削峰：在高峰期的時候，系統每秒的請求量達到 5000，那么呼叫 MySQL 的請求也是5000，一般情況下 MySQL 的請求大概在 2000 左右，那么在高峰期的時候，資料庫就被打垮了，那系統就不可用了，此時引入 MQ，在系統 A 前面加個 MQ，用戶請求先到 MQ，系統 A 從 MQ 中每秒消費 2000 條資料，這樣就把本來 5000 的請求變為 MySQL 可以接受的請求數量了，可以保證系統不掛掉，可以繼續提供服務，MQ 里的資料可以慢慢的把它消費掉，

33、使用 MQ 會有什么問題？

（1）降低了系統可用性 （2）增加了系統的復雜性

34、怎么保證 MQ 的高可用？

RabbitMQ 是比較有代表性的，因為是基于主從做高可用性的，以他為例，自行查閱以下模 式， rabbitmq 有三種模式：單機模式、普通集群模式、鏡像集群模式，

35、MQ 的優缺點?

在特殊場景下有其對應的好處，解耦、異步、削峰，缺點有以下幾個： 系統可用性降低 系統引入的外部依賴越多，越容易掛掉，萬一 MQ 掛了，MQ 一掛，整套系統崩潰，你不 就完了？ 系統復雜度提高 硬生生加個 MQ 進來，你怎么保證訊息沒有重復消費？怎么處理訊息丟失的情況？怎么保 證訊息傳遞的順序性？問題一大堆， 一致性問題 A 系統處理完了直接回傳成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那里，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這資料就不一致了，

36、Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么區別？

對于吞吐量來說 kafka 和 RocketMQ 支撐高吞吐，ActiveMQ 和 RabbitMQ 比他們低一個數量 級，對于延遲量來說 RabbitMQ 是最低的，

1.從社區活躍度 按照目前網路上的資料，RabbitMQ、activeM 、ZeroMQ 三者中，綜合來看，RabbitMQ 是首 選，

2.持久化訊息比較 ActiveMq 和 RabbitMq 都支持，持久化訊息主要是指我們機器在不可抗力因素等情況下掛掉了，訊息不會丟失的機制，

3.綜合技術實作 可靠性、靈活的路由、集群、事務、高可用的佇列、訊息排序、問題追蹤、可視化管理工具、插件系統等等， RabbitMq/Kafka 最好，ActiveMq 次之，ZeroMq 最差，當然 ZeroMq 也可以做到，不過自己必須手動寫代碼實作，代碼量不小，尤其是可靠性中的：持久性、投遞確認、發布者證實和高可用性，

4.高并發 毋庸置疑，RabbitMQ 最高，原因是它的實作語言是天生具備高并發高可用的 erlang 語言，

5.比較關注的比較，RabbitMQ 和 Kafka RabbitMq 比 Kafka 成熟，在可用性上，穩定性上，可靠性上，RabbitMq 勝于 Kafka（理論上），另外，Kafka 的定位主要在日志等方面， 因為 Kafka 設計的初衷就是處理日志的，可以看做是一個日志（訊息）系統一個重要組件，針對性很強，所以 如果業務方面還是建議選擇 RabbitMq ， 還有就是，Kafka 的性能（吞吐量、TPS）比 RabbitMq 要高出來很多，

37、如何設定訊息的過期時間？

設定佇列屬性，佇列中所有訊息都有相同的過期時間 對訊息本身進行單獨設定，每條訊息的 TTL 可以不同如果兩種方法一起使用，則訊息的 TTL 以兩者之間較小的那個數值為準

38、訊息的持久化是如何實作的？

RabbitMQ 的持久化分為:交換器的持久化、佇列的持久化和訊息的持久化 交換器和佇列的持久化都是通過在宣告時將 durable 引數置為 true 實作的訊息的持久化是在發送訊息指定 deliveryMode 為 2 實作的

39、Zookeeper 是什么？

ZooKeeper 是一個開放原始碼的分布式協調服務，它是集群的管理者，監視著集群中各個節點的狀態根據節點提交的反饋進行下一步合理操作，最終，將簡單易用的介面和性能高效、功能穩定的系統提供給用戶，

40、Zookeeper 的應用場景?

資料發布/訂閱負載均衡 命名服務 分布式協調/通知集群管理 Master 選舉分布式鎖 分布式佇列

41、四種型別的資料節點 Znode?

PERSISTENT-持久節點 除非手動洗掉，否則節點一直存在于 Zookeeper 上EPHEMERAL-臨時節點 臨時節點的生命周期與客戶端會話系結，一旦客戶端會話失效（客戶端與 zookeeper 連接斷開不一定會話失效），那么這個客戶端創建的所有臨時節點都會被移除，PERSISTENT_SEQUENTIAL-持久順序節點 基本特性同持久節點，只是增加了順序屬性，節點名后邊會追加一個由父節點維護的自增整型數字， EPHEMERAL_SEQUENTIAL-臨時順序節點 基本特性同臨時節點，增加了順序屬性，節點名后邊會追加一個由父節點維護的自增整型數字，

42、Zookeeper Watcher 機制?

1、一次性 無論是服務端還是客戶端，一旦一個 Watcher 被觸發，Zookeeper 都會將其從相應的存盤中移除，這樣的設計有效的減輕了服務端的壓力，不然對于更新非常頻繁的節點，服務端會不斷的向客戶端發送事件通知，無論對于網路還是服務端的壓力都非常大，

2、客戶端串行執行 客戶端 Watcher 回呼的程序是一個串行同步的程序，

3、輕量 3.1Watcher 通知非常簡單，只會告訴客戶端發生了事件，而不會說明事件的具體內容，3.2 客戶端向服務端注冊 Watcher 的時候，并不會把客戶端真實的 Watcher 物件物體傳遞到服務端，僅僅是在客戶端請求中使用 boolean 型別屬性進行了標記，

4、watcher event 異步發送 watcher 的通知事件從 server 發送到 client 是異步的，這就存在一個問題，不同的客戶端和服務器之間通過 socket 進行通信，由于網路延遲或其他因素導致客戶端在不通的時刻監聽到事件，由于 Zookeeper 本身提供了 ordering guarantee，即客戶端監聽事件后，才會感知它所監視 znode 發生了變化，所以我們使用 Zookeeper 不能期望能夠監控到節點每次的變化，Zookeeper 只能保證最終的一致性，而無法保證強一致性，

5、注冊 watcher getData、exists、getChildren

6、觸發 watcher create、delete、setData

7、當一個客戶端連接到一個新的服務器上時，watch 將會被以任意會話事件觸發，當與一個服務器失去連接的時候，是無法接收到 watch 的，而當 client 重新連接時，如果需要的話，所有先前注冊過的 watch，都會被重新注冊，通常這是完全透明的，只有在一個特殊情況下，watch 可能會丟失：對于一個未創建的 znode 的 exist watch，如果在客戶端斷開連接期間被創建了，并且隨后在客戶端連接上之前又洗掉了，這種情況下，這個 watch 事件可能會被丟失，

43、Zookeeper 下 Server 作業狀態?

服務器具有四種狀態，分別是 LOOKING、FOLLOWING、LEADING、OBSERVING，LOOKING：尋找 Leader 狀態，當服務器處于該狀態時，它會認為當前集群中沒有 Leader，因此需要進入 Leader 選舉狀態， FOLLOWING：跟隨者狀態，表明當前服務器角色是 Follower，LEADING：領導者狀態，表明當前服務器角色是 Leader， OBSERVING：觀察者狀態，表明當前服務器角色是 Observer，

44、Zookeeper 是如何保證事務的順序一直性的？

zookeeper 采用了全域遞增的事務 Id 來標識，所有的 proposal（提議）都在被提出的時候加上了 zxid，zxid 實際上是一個 64 位的數字，高 32 位是 epoch（時期; 紀元; 世; 新時代）用來標識 leader 周期，如果有新的 leader 產生出來，epoch 會自增，低 32 位用來遞增計數，當新產生 proposal 的時候，會依據資料庫的兩階段程序，首先會向其他的 server 發出事務執行請求，如果超過半數的機器都能執行并且能夠成功，那么就會開始執行，

45、ZK 節點宕機如何處理？

Zookeeper 本身也是集群，推薦配置不少于 3 個服務器，Zookeeper 自身也要保證當一個節點宕機時，其他節點會繼續提供服務， 如果是一個 Follower 宕機，還有 2 臺服務器提供訪問，因為 Zookeeper 上的資料是有多個副本的，資料并不會丟失； 如果是一個 Leader 宕機，Zookeeper 會選舉出新的 Leader，ZK 集群的機制是只要超過半數的節點正常，集群就能正常提供服務，只有在 ZK 節點掛得太多，只剩一半或不到一半節點能作業，集群才失效，所以 3 個節點的 cluster 可以掛掉 1 個節點(leader 可以得到 2 票>1.5)2 個節點的 cluster 就不能掛掉任何 1 個節點了(leader 可以得到 1 票<=1)

46、Zookeeper 有哪幾種部署模式？

部署模式：單機模式、偽集群模式、集群模式，

47、Dubbo 內置了哪幾種容器？

Spring ContainerJetty ContainerLog4j Container

48、Dubbo 里面有哪幾種角色？

Provider：暴露服務的服務提供方 Consumer：呼叫遠程服務的服務消費方Registry：服務注冊與發現的注冊中心Monitor：統計服務的呼叫次數和呼叫時間的監控中心Container：服務運行容器

49、Dubbo 有哪幾種集群容錯方案，默認是那種？

Failover Cluster：失敗自動切換，自動重試其他服務器（默認）Failfast Cluster：快速失敗，立即報錯，只發起一次呼叫Failsafe Cluster：失敗安全，出現例外時，直接忽略 Failback Cluster：失敗自動恢復，記錄失敗請求，定時重發Forking Cluster：并行呼叫多個服務器，只要一個成功即回傳Broadcast Cluster：廣播逐個呼叫所有提供者，任意一個報錯則報錯

50、Dubbo 有哪幾種負載均衡策略，默認是哪種？

Random LoadBalance:隨機，按權重設定隨機概率(默認) RoundRobin LoadBalance：輪詢，按公約后的權重設定輪詢比率LeastActive LoadBalance：最少活躍呼叫次數，相同活躍數的隨機 ConsistentHash LoadBalance：一直性 Hash，相同引數的請求總是發到同一提供者

51、Dubbo 的管理控制臺能做什么？

管理控制臺主要包含：路由規則，動態配置，服務降級，訪問控制，權重調整，負載均衡，等管理功能，

52、什么是 Spring Boot？

多年來，隨著新功能的增加，spring 變得越來越復雜，只需訪問 https://spring.io/projects 頁面，我們就會看到可以在我們的應用程式中使用的所有 Spring 專案的不同功能，如果必須啟動一個新的 Spring 專案，我們必須添加構建路徑或添加 Maven 依賴關系，配置應用程式服務器，添加 spring 配置，因此，開始一個新的 spring 專案需要很多努力，因為我們現在必須從頭開始做所有事情， Spring Boot 是解決這個問題的方法，Spring Boot 已經建立在現有 spring 框架之上，使用 spring啟動，我們避免了之前我們必須做的所有樣板代碼和配置，因此，Spring Boot 可以幫助我們以最少的作業量，更加健壯地使用現有的 Spring 功能，

53、Spring Boot 有哪些優點？

減少開發，測驗時間和努力， 使用 JavaConfig 有助于避免使用 XML， 避免大量的 Maven 匯入和各種版本沖突， 提供意見發展方法， 通過提供默認值快速開始開發， 沒有單獨的 Web 服務器需要，這意味著你不再需要啟動 Tomcat，Glassfish 或其他任何東西，需要更少的配置 因為沒有 web.xml 檔案，只需添加用@ Configuration 注釋的類，然后添加用@Bean 注釋的方法，Spring 將自動加載物件并像以前一樣對其進行管理，您甚至可以將@Autowired 添加到 bean 方法中，以使 Spring 自動裝入需要的依賴關系中，基 于環 境的 配置 使 用這 些屬 性， 您可 以將 您正 在使 用的 環境 傳遞 到應 用程 序：-Dspring.profiles.active = {enviornment} ， 在 加 載 主 應 用 程 序 屬 性 文 件 后 ， Spring 將 在（application{environment} .properties）中加載后續的應用程式屬性檔案，

54、什么是 JavaConfig？

Spring JavaConfig 是 Spring 社區的產品，它提供了配置 Spring IoC 容器的純 Java 方法，因此它有助于避免使用 XML 配置，使用 JavaConfig 的優點在于： 面向物件的配置，由于配置被定義為 JavaConfig 中的類，因此用戶可以充分利用 Java 中的面向物件功能，一個配置類可以繼承另一個，重寫它的@Bean 方法等， 減少或消除 XML 配置，基于依賴注入原則的外化配置的好處已被證明，但是，許多開發人員不希望在 XML 和 Java 之間來回切換，JavaConfig 為開發人員提供了一種純 Java 方法來配置與 XML 配置概念相似的 Spring 容器，從技術角度來講，只使用 JavaConfig 配置類來配置容器是可行的，但實際上很多人認為將 JavaConfig 與 XML 混合匹配是理想的，型別安全和重構友好，JavaConfig提供了一種型別安全的方法來配置Spring容器，由于Java 5.0對泛型的支持，現在可以按型別而不是按名稱檢索 bean，不需要任何強制轉換或基于字串的查找，

55、如何重新加載 Spring Boot 上的更改，而無需重新啟動服務器？

這可以使用 DEV 工具來實作，通過這種依賴關系，您可以節省任何更改，嵌入式 tomcat 將重新啟動，Spring Boot 有一個開發工具（DevTools）模塊，它有助于提高開發人員的生產力，Java 開發人員面臨的一個主要挑戰是將檔案更改自動部署到服務器并自動重啟服務器，開發人員可以重新加載 Spring Boot 上的更改，而無需重新啟動服務器，這將消除每次手動部署更改的需要，Spring Boot 在發布它的第一個版本時沒有這個功能，這是開發人員最需要的功能，DevTools 模塊完全滿足開發人員的需求，該模塊將在生產環境中被禁用，它還提供 H2資料庫控制臺以更好地測驗應用程式，

56、Spring Boot 中的監視器是什么？

Spring boot actuator 是 spring 啟動框架中的重要功能之一，Spring boot 監視器可幫助您訪問生產環境中正在運行的應用程式的當前狀態，有幾個指標必須在生產環境中進行檢查和監控，即使一些外部應用程式可能正在使用這些服務來向相關人員觸發警報訊息，監視器模塊公開了一組可直接作為 HTTP URL 訪問的 REST 端點來檢查狀態，

57、如何在 Spring Boot 中禁用 Actuator 端點安全性？

默認情況下，所有敏感的 HTTP 端點都是安全的，只有具有 ACTUATOR 角色的用戶才能訪問它們，安全性是使用標準的 HttpServletRequest.isUserInRole 方法實施的， 我們可以使用management.security.enabled = false 來禁用安全性，只有在執行機構端點在防火墻后訪問時，才建議禁用安全性，

59、什么是 WebSocket？

WebSocket 是一種計算機通信協議，通過單個 TCP 連接提供全雙工通信信道，WebSocket 是雙向的 -使用 WebSocket 客戶端或服務器可以發起訊息發送，WebSocket 是全雙工的 -客戶端和服務器通信是相互獨立的，單個 TCP 連接 -初始連接使用 HTTP，然后將此連接升級到基于套接字的連接，然后這個單一連接用于所有未來的通信 Light -與 http 相比，WebSocket 訊息資料交換要輕得多，

60、什么是 Swagger？

你用 Spring Boot 實作了它嗎？ Swagger 廣泛用于可視化 API，使用 Swagger UI 為前端開發人員提供在線沙箱，Swagger 是用于生成 RESTful Web 服務的可視化表示的工具，規范和完整框架實作，它使檔案能夠以與服務器相同的速度更新，當通過 Swagger 正確定義時，消費者可以使用最少量的實作邏輯來理解遠程服務并與其進行互動，因此，Swagger 消除了呼叫服務時的猜測，

61、什么是 Apache Kafka？

Apache Kafka 是一個分布式發布 - 訂閱訊息系統，它是一個可擴展的，容錯的發布 - 訂閱訊息系統，它使我們能夠構建分布式應用程式，這是一個 Apache 頂級專案，Kafka 適合離線和在線訊息消費，

62、什么是 Spring Cloud？

Spring cloud 流應用程式啟動器是基于 Spring Boot 的 Spring 集成應用程式，提供與外部系統的集成，Spring cloud Task，一個生命周期短暫的微服務框架，用于快速構建執行有限資料處理的應用程式，

63、使用 Spring Cloud 有什么優勢？

使用 Spring Boot 開發分布式微服務時，我們面臨以下問題 1、與分布式系統相關的復雜性-這種開銷包括網路問題，延遲開銷，帶寬問題，安全問題， 2、服務發現-服務發現工具管理群集中的流程和服務如何查找和互相交談，它涉及一個服務目錄，在該目錄中注冊服務，然后能夠查找并連接到該目錄中的服務， 3、冗余-分布式系統中的冗余問題， 4、負載平衡 --負載平衡改善跨多個計算資源的作業負荷，諸如計算機，計算機集群，網路鏈路，中央處理單元，或磁盤驅動器的分布， 5、性能-問題 由于各種運營開銷導致的性能問題，6、部署復雜性-Devops 技能的要求，

64、服務注冊和發現是什么意思？

Spring Cloud 如何實作？ 當我們開始一個專案時，我們通常在屬性檔案中進行所有的配置，隨著越來越多的服務開發和部署，添加和修改這些屬性變得更加復雜，有些服務可能會下降，而某些位置可能會發生變化，手動更改屬性可能會產生問題， Eureka 服務注冊和發現可以在這種情況下提供幫助，由于所有服務都在 Eureka 服務器上注冊并通過呼叫 Eureka 服務器完成查找，因此無需處理服務地點的任何更改和處理，