Kafka Without ZooKeeper ---- 不使用zookeeper的kafka叢集

不使用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的折磨，下面我就列舉幾個常見的問題：

1. 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”

2. 身為一個分布式系統，本身就免不了有許多bug，Kakfa系統内部使用一個不屬于自己維護的共識系統，發生問題了維護不友善。有很多論文調查、研究分布式系統曆史上出現的各種bug，我列舉了幾篇放在參考連結3-5
3. zookeeper本身限制也導緻了用戶端的通路方式、處理事件的方式等等處處掣肘，用戶端不管其上層承載的業務模型是怎樣的，都要按照zookeeper的filesystem/trigger API去操作。

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

1. 所有的watcher事件都應該在同一個線程裡執行，然後再這個線程裡對通路的資源加鎖（這個操作應該由zk庫在zk線程裡自己完成）
2. 認真對待session生命周期，如果expired就需要重連，如果session已經expired了，所有與這個session相關的操作也應該失敗。session和臨時節點是綁定的，session expired了臨時節點也就沒了
3. zookeeper可以把sessionid和password儲存起來，下次建立連接配接的時候可以直接用之前的
4. zookeeper不适合做消息隊列，因為
   • zookeeper有1M的消息大小限制
   • zookeeper的children太多會極大的影響性能
   • znode太大也會影響性能
   • znode太大會導緻重新開機zkserver耗時10-15分鐘
   • zookeeper僅使用記憶體作為存儲，是以不能存儲太多東西。
5. 最好單線程操作zk用戶端，不要并發，臨界、競态問題太多
6. 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的過程中也曾遇到以下問題：

1. zk session 處理
   • 忽略了connecting事件，client與server心跳逾時之後沒有将選主服務及時下線掉，導緻雙主腦裂。
   • 多個線程處理zk的連接配接狀态，導緻産生了多套zk線程連接配接zkserver。
   • zk逾時時間不合理，導緻重連頻率太高，打爆zkserver。
   • 所有的zkserver全部重置（zk server全部狀态被重置），這種情況下用戶端不會受到expired事件，我之前實作的用戶端也不會重新去建立zk session。導緻之前的zkclient建立的session全部不可用，陷入無限重連而連不上的窘境。
2. 多線程競态
   • zk用戶端自己的線程do_completion會調用watcher的回調函數，和業務線程産生競争，導緻core dump。
3. 用戶端同步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的優勢

1. 減少了服務配置的複雜度，不再需要通過去配置zookeeper來協調Kafka。整個系統也變得更輕量級了
2. 擺脫了之前提到的zookeeper種種限制，系統的可拓展性大大增強了，号稱可支援百萬partition。并且系統的節點啟動和關閉時間和之前先比也大大降低了。

總結

Kakfa Without ZooKeeper

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

參考連結

1. KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum
2. KIP-578: Add configuration to limit number of partitions
3. What Bugs Live in the Cloud? A Study of 3000+ Issues in Cloud Systems
4. TaxDC: A Taxonomy of Non-Deterministic Concurrency Bugs in Datacenter Distributed Systems
5. An Analysis of Network-Partitioning Failures in Cloud Systems
6. Kafka 設計原理