前言

現在刷抖音經常可以看到一些老外街坊，問他們最想把什么帶回自己的國家，我聽過很多的回答都是：淘寶，支付寶，美食，微信，外賣，高鐵等等。

確實如此，隨著國家的快速發展吸引了不少國際上羨慕的目光，更讓中國的新四大發明走向世界。說到這些，都離不開背后龐大的互聯網體系的支撐，阿里作為國內最頂級的互聯網企業必然也聚集了行業內頂級的IT人才。

眾所周知，阿里巴巴的主要開發語言就是Java，而對于Java開發者來說，最重要的就是學習Spring框架了。現在，我想跟大家分享出這份老外看外都不禁贊嘆的《阿里技術官Spring全家桶筆記》，趕緊一睹為快吧。

咱們都知道，學Spring最重要的還是它的核心思想AOP和IOC，這兩個內容也單獨拿出來做一份筆記來重點講解了，先睹為快！

由于篇幅限制，這兩個知識點講的干貨內容非常多，這里只能截取部分文檔內容展示，完整版獲取在上面，感謝配合。

正文

ZooKeeper 很流行，有個基本的疑問：

• ZooKeeper 是用來做什么的？
• 之前沒有ZK，為什么會誕生 ZK？

OK，解答一下上面的疑問：（下面是憑直覺說的）

• ZooKeeper 是用于簡化分布式應用開發的，對開發者屏蔽一些分布式應用開發過程中的底層細節
• ZooKeeper 對外暴露簡單的 API，用于支持分布式應用開發
• ZooKeeper 在提供上述功能的同時，其還是一個 高性能、高可用、高可靠的分布式集群

上面說這么多，總結一下，ZK 能解決分布式應用開發的問題，ZK 能很好的解決問題。到這一步，疑問就更多了：

1. 分布式應用開發，有哪些常見問題？ZK 是如何屏蔽這些底層細節的？
2. ZooKeeper 對外暴露了那些 API？這些 API 如何支持分布式應用開發的？這些 API 還能簡化嗎？API 的語義性怎么樣？
3. ZooKeeper 自身是一個高性能、高可用、高可靠的分布式集群，那有個簡單的問題：

• 高性能是指什么？ZooKeeper 為了達到高性能，做了哪些工作？
• 高可用同上
• 高可靠同上

Note：本篇 wiki 就是為了解決上述第一個疑問的。（其他疑問會在其他 blog 中逐步解答）

為什么有 ZooKeeper

一個應用程序，涉及多個進程協作時，業務邏輯代碼中混雜有大量復雜的進程協作邏輯。

上述多進程協作邏輯，有 2 個特點：

• 處理復雜
• 處理邏輯可重用

因此，考慮將多進程協作的共性問題拎出，作為基礎設施，讓 RD 更加專注業務邏輯開發，即：

ZooKeeper 就是上述多進程協作基礎服務的一種。

ZooKeeper 的特點

ZooKeeper 有幾個簡單特點：

• ZooKeeper 的 API：從 文件系統 API 得到的啟發，提供簡單的 API
• ZooKeeper 運行在專用服務器上，跟業務邏輯分離，保證了高容錯性和可擴展性

ZooKeeper 是存儲設施，但特別注意

• ZK上存儲的數據聚焦為：協作數據（元數據），而不是應用數據，應用數據有自己的存儲方案，例如 HDFS 等
• ZK 本質上，可以看作一種特殊的 FS

特別說明：

應用數據和元數據，由于使用場景不同，對一致性和持久性的要求有差異， 因此，架構設計、數據治理過程中，應將 2 類數據獨立看待、獨立存儲。

ZooKeeper 的使命

ZK 要解決的核心問題：

ZK 目標：簡化分布式應用開發中，多進程協作問題。為分布式應用，提供高效、可靠的分布式協調服務（基礎服務），例如：

• 統一的命名服務
• 分布式鎖
• 進程崩潰檢測
• Leader 選舉
• 配置管理：配置變更時，及時下發到各個 Client。

一個簡單的問題：多進程的協作是什么？尼瑪呀，有完沒完，啥問題你都有，面對這個掉咋天的腦殼，還是回答一下。

多進程協作，整體分為 2 類：

1. 協作：多進程需要一同處理某些事情，一些進程采取行動是的其他進程能夠正常工作，例如：主從結構，M 向 S 分配任務，S 才會執行，否則 S 就保持空閑狀態
2. 競爭：兩個進程不能同時工作，一個進程必須等待另個進程執行完畢，例如：主從結構，M 節點失效后，很多 S 都想成為 M，這時，就需要互斥鎖，只有第一個獲得鎖的 S 成為 M

特別說明：

1. 不跨網絡協作：多進程，可以在同一臺物理主機上，同步原語很方便(比如？管道、共享內存、消息隊列、信號量)
2. 跨網絡協作：多進程，分布在不同的物理主機上，ZK 關注這一類

跨網絡多進程協作，進程通信，基本思路有 2 個：

1. 消息機制：通過網絡，直接信息交換，多消息傳遞算法，實現同步原語
2. 共享存儲：利用外部共享存儲，實現多進程協作，要求共享存儲提供有序訪問，ZK 采用這種方式

真實系統中，跨網絡通信，有幾個共性問題：

1. 消息延遲：由于網絡原因，后發送先到達
2. 處理器性能：由于系統調度原因，消息到達后，延遲處理
3. 時鐘偏移：不同物理主機，時鐘發生偏移

ZK 精心設計用于屏蔽上述 3 個共性問題，使得這些問題在應用服務層面完全透明化。

ZooKeeper 特性

ZooKeeper 解決的本質問題

分布式系統的一致性問題：

1. 消息傳遞：延遲性，先發送的消息，不一定先到達；
2. 消息傳遞：丟失性，發送的消息，可能丟失；
3. 節點崩潰：分布式系統內，任何一個節點都可能崩潰；

在這種情況下，如何保證數據的一致性？

1. 提案投票：基于投票策略，2PC
2. 選舉投票：基于投票策略，投出優先級最高的節點（包含最新數據的節點）

Paxos 目標：解決分布式一致性問題，提高分布式系統容錯性的一致性算法。

Paxos 本質：基于消息傳遞的高度容錯的一致性算法

ZooKeeper 定位

ZooKeeper 是：

1. 分布式協調服務
2. 高效、可靠
3. 方便應用程序，聚焦業務邏輯開發，而不需要過多關注分布式進程間協作細節

ZooKeeper 不直接暴露原語，而是，暴露一部分調用方法組成的 API，類似文件系統的 API，支持應用程序實現自己的原語。

ZooKeeper 特性

ZooKeeper 可以保證如下分布式一致性特性：

• 順序一致性：同一個 Client 發起的事務請求，嚴格按照發起順序執行
• 原子性：事務請求，要么應用到所有節點，要么一個節點都沒有應用
• 單一視圖：Client 無論連接到哪個節點，看到的服務端數據都是一致的（Note：不準確，其實是最終一致性）
• 可靠性：事務一旦執行成功，狀態永久保留
• 實時性：事務一旦執行成功，Client 并不能立即看到最新數據，但 ZooKeeper 保證最終一致性

ZooKeeper 設計目標

ZooKeeper 致力于提供高性能、高可用、順序一致性的分布式協調服務，保證數據最終一致性。

目標一：高性能（簡單的數據模型）

1. 采用樹形結構組織數據節點；
2. 全量數據節點，都存儲在內存中；
3. Follower 和 Observer 直接處理非事務請求；

目標二：高可用（構建集群）

1. 半數以上機器存活，服務就能正常運行
2. 自動進行 Leader 選舉

目標三：順序一致性（事務操作的順序）

1. 每個事務請求，都會轉發給 Leader 處理
2. 每個事務，會分配全局唯一的遞增id（zxid，64位：epoch + 自增 id）

目標四：最終一致性

1. 通過提議投票方式，保證事務提交的可靠性
2. 提議投票方式，只能保證 Client 收到事務提交成功后，半數以上節點能夠看到最新數據

ZooKeeper 出現之前

ZK 出現之前，分布式系統常用兩種方式，實現多進程協作：

1. 分布式鎖管理器
2. 分布式數據庫

ZK 更專注于進程協作，而不提供任何鎖接口和通用的存儲數據接口。（疑問：ZK 也可以提供啊，我們不使用就行了）

應用服務器，常見的 2 種需求：

1. Master-Slave?Leader 選舉：要求提供Master節點選舉功能
2. 進程響應跟蹤?崩潰檢測：要求提供進程存活狀態的跟蹤
3. 分布式鎖：互斥排它鎖

ZK 為上述 2 種策略提供了基礎 API。

ZooKeeper 不適用的場景：

1. 海量數據存儲：ZK 本質是特殊的 FS，但 ZK 用于存儲元數據，需要單獨存儲應用數據

最后

面試題文檔來啦，內容很多，485頁！

由于筆記的內容太多，沒辦法全部展示出來，下面只截取部分內容展示。有想獲取完整版筆記的朋友，點贊后點擊這里免費領取哦

1111道Java工程師必問面試題

MyBatis 27題 + ZooKeeper 25題 + Dubbo 30題：

Elasticsearch 24 題 +Memcached +?Redis 40題：

Spring 26 題+ 微服務 27題+ Linux 45題：

Java面試題合集：

R2og42E-1622454470125)]

Elasticsearch 24 題 +Memcached +?Redis 40題：

[外鏈圖片轉存中…(img-WYOLv9UP-1622454470126)]

Spring 26 題+ 微服務 27題+ Linux 45題：

[外鏈圖片轉存中…(img-rSWlOipn-1622454470127)]

Java面試題合集：