不使用zookeeper的kafka集群

• • 前言
  • • ZooKeeper的缺點
  • Kakfa Without ZooKeeper簡介
  • Kakfa Without ZooKeeper的優勢
  • 總結
  • 參考鏈接

---

前言

大名鼎鼎的Kafka作為最出名的消息處理中間件，Zookeeper在其中提供一致性服務，并且承擔了選主、服務發現、服務注冊、存儲各種Kafka的各種元數據。

隨著Kafka的演進，Kafka自己也變成了一個復雜的分布式系統，它和zookeeper一樣，都對外提供一致性服務。Kafka在其系統內再維護一套zookeeper分布式系統，這本身就是個吃力不討好的工作，更別提zookeeper的各種問題、限制和瓶頸。所以，Kafka的開發者提出了Kafka without zookeeper，將zookeeper踢出Kakfa系統，Kafka自己負責管理各種信息、數據。文章還起了個致敬祖師爺的標題：Apache Kafka Made Simple

開發者管這個新的模式叫Kafka Raft Metadata mode，簡稱KRaft。我猜他們也發現了，zab比起paxos，還是更像raft吧:) 該模式的Early Access已經提交到Kafka分支中，預計將發布在Kakfa 2.8版本中。

ZooKeeper的缺點

Kafka想淘汰zookeeper這個事情也不是一時興起的，社區的開發者們早就一直到zookeeper多少成為了整個系統的瓶頸，限制了集群的擴展能力。筆者去年也苦受zookeeper的折磨，下面我就列舉幾個常見的問題：

Zab協議自身的限制導致了zookeeper的很多瓶頸，比如，單leader瓶頸，切主時服務不可用、系統存儲的內容有限，可擴展性不足等等。

• 另外zookeeper集群的一致性模型也并沒有想象中完美，不提一些違背一致性的bug如ZOOKEEPER-2919，其本身的機制：更新操作都要forward給leader，讀操作follower節點可以獨立進行，就決定了zookeeper的一致性保證只能做到“Updates from a client will be applied in the order that they were sent”

身為一個分布式系統，本身就免不了有許多bug，Kakfa系統內部使用一個不屬于自己維護的共識系統，發生問題了維護不方便。有很多論文調查、研究分布式系統歷史上出現的各種bug，我列舉了幾篇放在參考鏈接3-5

zookeeper本身限制也導致了客戶端的訪問方式、處理事件的方式等等處處掣肘，客戶端不管其上層承載的業務模型是怎樣的，都要按照zookeeper的filesystem/trigger API去操作。

著名的zookeeper客戶端庫Curator專門總結了使用Zookeeper的Tech notes，我選擇一些重要的翻譯如下：

所有的watcher事件都應該在同一個線程里執行，然后再這個線程里對訪問的資源加鎖（這個操作應該由zk庫在zk線程里自己完成）

認真對待session生命周期，如果expired就需要重連，如果session已經expired了，所有與這個session相關的操作也應該失敗。session和臨時節點是綁定的，session expired了臨時節點也就沒了

zookeeper可以把sessionid和password保存起來，下次新建連接的時候可以直接用之前的

zookeeper不適合做消息隊列，因為

• zookeeper有1M的消息大小限制
• zookeeper的children太多會極大的影響性能
• znode太大也會影響性能
• znode太大會導致重啟zkserver耗時10-15分鐘
• zookeeper僅使用內存作為存儲，所以不能存儲太多東西。

最好單線程操作zk客戶端，不要并發，臨界、競態問題太多

Curator session 生命周期管理：

• CONNECTED：第一次建立連接成功時收到該事件
• READONLY：標明當前連接是read-only狀態
• SUSPENDED：連接目前斷開了(收到KeeperState.Disconnected事件，也就是說curator目前沒有連接到任何的zk server)，leader選舉、分布式鎖等操作遇到SUSPENED事件應該暫停自己的操作直到重連成功。Curator官方建議把SUSPENDED事件當作完全的連接斷開來處理。意思就是把收到SUSPENDED事件的時候就當作自己注冊的所有臨時節點已經掉了。
• LOST：如下幾種情況會進出LOST事件
  • curator收到zkserver發來的EXPIRED事件。
  • curator自己關掉當前zookeeper session
  • 當curator斷定當前session被zkserver認為已經expired時設置該事件。在Curator 3.x，Curator會有自己的定時器，如果收到SUSPENDED事件一直沒有沒有收到重連成功的事件，超時一定時間（2/3 * session_timeout）。curator會認為當前session已經在server側超時，并進入LOST事件。
• RECONNECTED：重連成功

對于何時進入LOST狀態，curator的建議：

When Curator receives a KeeperState.Disconnected message it changes its state to SUSPENDED (see TN12, errors, etc.). As always, our recommendation is to treat SUSPENDED as a complete connection loss. Exit all locks, leaders, etc. That said, since 3.x, Curator tries to simulate session expiration by starting an internal timer when KeeperState.Disconnected is received. If the timer expires before the connection is repaired, Curator changes its state to LOST and injects a session end into the managed ZooKeeper client connection. The duration of the timer is set to the value of the “negotiated session timeout” by calling ZooKeeper#getSessionTimeout().
The astute reader will realize that setting the timer to the full value of the session timeout may not be the correct value. This is due to the fact that the server closes the connection when 2/3 of a session have already elapsed. Thus, the server may close a session well before Curator’s timer elapses. This is further complicated by the fact that the client has no way of knowing why the connection was closed. There are at least three possible reasons for a client connection to close:

• The server has not received a heartbeat within 2/3 of a session
• The server crashed
• Some kind of general TCP error which causes a connection to fail

In situtation 1, the correct value for Curator’s timer is 1/3 of a session - i.e. Curator should switch to LOST if the connection is not repaired within 1/3 of a session as 2/3 of the session has already lapsed from the server’s point of view. In situations 2 and 3 however, Curator’s timer should be the full value of the session (possibly plus some “slop” value). In truth, there is no way to completely emulate in the client the session timing as managed by the ZooKeeper server. So, again, our recommendation is to treat SUSPENDED as complete connection loss.

curator默認使用100%的session timeout時間作為SUSPENDED到LOST的轉換時間，但是用戶可以根據需求配置為33%的session timeout以滿足上文所說的情況的場景

可見，使用好zookeeper不是一件容易的事，筆者使用zookeeper的過程中也曾遇到以下問題：

zk session 處理

• 忽略了connecting事件，client與server心跳超時之后沒有將選主服務及時下線掉，導致雙主腦裂。
• 多個線程處理zk的連接狀態，導致產生了多套zk線程連接zkserver。
• zk超時時間不合理，導致重連頻率太高，打爆zkserver。
• 所有的zkserver全部重置（zk server全部狀態被重置），這種情況下客戶端不會受到expired事件，我之前實現的客戶端也不會重新去建立zk session。導致之前的zkclient建立的session全部不可用，陷入無限重連而連不上的窘境。

多線程競態

• zk客戶端自己的線程do_completion會調用watcher的回調函數，和業務線程產生競爭，導致core dump。

客戶端同步api

• 同步API沒有超時時間，如果zkserver狀態不對，發送給zkserver的rpc得不到回應，會導致調用同步zk API的線程阻塞卡死。
• 供業務使用的api設計不當，導致初始化時調用的同步版本api造成死鎖。

Kakfa Without ZooKeeper簡介

kafka將其引入的共識協議稱為Event-driven consensus，controller節點內部維護RSM（replicated state machine），而不像之前的zookeeper-based，節點需要首先訪問zookeeper獲取狀態信息。Kafka的元數據會通過raft一致性協議寫入quorum，并且系統會定期做snapshot。

不同于之前的Kafka集群，唯一的Controller從所有的brker中選出，負責Watch Zookeeper、partition的replica的集群分配，以及leader切換選舉等流程。KRaft中Controller可以被指定為奇數個節點（一般情況下3或5）組成raft quorum。controller節點中有一個active（選為leader），其他的hot standby。這個controller集群負責管理Kafka集群的元數據，通過raft協議達成共識。因此，每個controller都擁有幾乎update-to-date的Metadata，所以controller集群重新選主時恢復時間很短。

集群的其他節點通過配置選項controller.quorum.voters獲取controller。不同于之前的模式，controller發送Metadata給其他的broker。現在broker需要主動向active controller拉取Metadata。一旦broker收到Metadata，它會將其持久化。這個broker持久化Metadata的優化意味著一般情況下active controller不需要向broker發送完整的Metadata，只需要從某個特定的offset發送即可。但如果遇到一個新上線的broker，Controller可以發送snapshot給broker（類似raft的InstallSnapshot RPC）。

Kakfa Without ZooKeeper的優勢

減少了服務配置的復雜度，不再需要通過去配置zookeeper來協調Kafka。整個系統也變得更輕量級了

擺脫了之前提到的zookeeper種種限制，系統的可拓展性大大增強了，號稱可支持百萬partition。并且系統的節點啟動和關閉時間和之前先比也大大降低了。

總結

Kakfa Without ZooKeeper是維護者對Kafka做出的一大創舉，但是目前僅出于EA階段，很多功能還不完善，并且一個分布式系統需要經歷很多的迭代、bugfix，才能穩定下來，這都需要時間。但筆者認為這個方向是正確的，這是任何一個互聯網系統發展到一定階段必然會面對的問題。

參考鏈接

KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum

KIP-578: Add configuration to limit number of partitions

What Bugs Live in the Cloud? A Study of 3000+ Issues in Cloud Systems

TaxDC: A Taxonomy of Non-Deterministic Concurrency Bugs in Datacenter Distributed Systems

An Analysis of Network-Partitioning Failures in Cloud Systems

Kafka 設計原理

總結

以上是生活随笔為你收集整理的Kafka Without ZooKeeper ---- 不使用zookeeper的kafka集群的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。