[1]. 介紹一下ZooKeeper

ZooKeeper是一個開源的分布式協(xié)調(diào)服務，核心功能是通過樹形數(shù)據(jù)模型（ZNode）和Watch機制，解決分布式系統(tǒng)的一致性問題。

它使用ZAB協(xié)議保障數(shù)據(jù)一致性，典型場景包括分布式鎖、配置管理和服務注冊發(fā)現(xiàn)、集群管理等。

ZooKeeper通常以集群的方式部署，由多個ZooKeeper服務器組成。集群中有一個領導者服務器，負責處理客戶端的寫請求，并將數(shù)據(jù)同步到其他服務器；其他服務器是追隨者，負責處理客戶端的讀請求。

[2]. ZAB協(xié)議

ZAB協(xié)議是一種基于Paxos算法的改進協(xié)議，專門為ZooKeeper這種分布式協(xié)調(diào)服務而設計，保證了在ZooKeeper集群中，數(shù)據(jù)變更能夠以原子性和順序性廣播到所有節(jié)點，從而實現(xiàn)最終一致性。

ZAB協(xié)議主要有兩種模式：消息廣播模式和崩潰恢復模式。

在消息廣播模式下，Leader接收到客戶端的寫請求后，會將這個請求封裝成一個Proposal廣播給所有Follower。Follower收到Proposal后，寫入本地事務日志，并向Leader發(fā)送ACK確認。當Leader收到超過半數(shù)的Follower的ACK后，就認為這個Proposal已經(jīng)提交，然后Leader會向所有Follower發(fā)送Commit命令。

在崩潰恢復模式下，集群會進行Leader選舉，選出一個新的Leader，然后新的Leader會從事務日志中恢復數(shù)據(jù)，并確保所有節(jié)點的數(shù)據(jù)保持一致。

[3]. ZooKeeper的選舉機制

ZooKeeper使用一種Leader選舉機制來保證集群的高可用性。

當集群啟動或Leader服務器發(fā)生故障時，就會觸發(fā)選舉。選舉過程中，每個服務器都會將自己作為候選Leader進行投票，投票信息包括服務器ID和事務ID（zxid）。

服務器會將自己的投票廣播給其他服務器，并接收其他服務器的投票。在接收到投票后，如果發(fā)現(xiàn)收到的投票信息中的zxid比自己的大，或者zxid相同但服務器ID比自己的大，則更新自己的投票信息。

最后，每個服務器統(tǒng)計收到的投票信息，如果某個服務器收到了超過半數(shù)服務器的投票，則該服務器成為新的Leader。選舉過程中，zxid最大的服務器會被優(yōu)先選為Leader，如果多個服務器的zxid相同，則服務器ID較大的服務器會被選為Leader。

[4]. Memcached的緩存機制

Memcached是一個高性能的分布式內(nèi)存對象緩存系統(tǒng)，用于加速動態(tài)Web應用程序。

Memcached使用哈希表來存儲鍵值對，并使用slab分配機制來管理內(nèi)存。當Memcached的內(nèi)存空間不足時，會使用LRU算法來淘汰最近最少使用的數(shù)據(jù)。

在分布式緩存方面，Memcached通常使用一致性哈希算法來實現(xiàn)數(shù)據(jù)的分片。

Memcached具有高性能、簡單易用、可擴展性強等優(yōu)點，但同時也存在無持久化機制和內(nèi)存限制等缺點。

[5]. 基本數(shù)據(jù)類型和包裝類的區(qū)別

基本數(shù)據(jù)類型存儲在棧中，效率高，占用內(nèi)存少；包裝類存儲在堆中，需要更多的內(nèi)存。

基本數(shù)據(jù)類型功能簡單，只能進行基本運算；包裝類提供了豐富的方法，方便操作。

基本數(shù)據(jù)類型主要用于數(shù)值運算等場景；包裝類通常用于需要對象的地方，比如集合框架，或者需要使用包裝類提供的方法，以及進行類型轉(zhuǎn)換等。