如何驗證 Kafka 系統的可靠性

今天就跟大家聊聊有關如何驗證 Kafka 系統的可靠性，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

當通過 Kafka 構建的系統需要提供特定的可靠性，我們對 Kafka  做了相應配置，對生產者和消費者的應用做了必要的處理之后，如何驗證整個系統確實實現了期望的可靠性呢?

1. 概述

仍然是那句話，可靠性不是一個可以輕易獲得的東西，驗證的方法也不簡單，分為三個階段：

• 在沒有生產者和消費者參與的情況下，對 Kafka 的配置進行驗證，確認 Kafka 的表現與預期一致;

• 加入生產者和消費者的應用，確認生產者和消費者的表現和預期一致;

• 應用上線后，對應用和 Kafka 的指標、日志等進行監控，發現與可靠性有關的問題，進行修復。

2. 驗證配置

驗證：其實就是測試，實際效果和預期效果是否一致，因此在驗證前必須確認期望看到的結果，如果這一步有誤差，驗證可能很難成功。

驗證配置不是指用肉眼去確認配置文件是否正確，而是使用 Kafka 提供的工具，Kafka 在 org.apacha.kafka.tools  包下有兩個類：VerifiableProducer 和 VerifiableConsumer，這兩個類既可以通過命令行運行，也可以在各種測試框架中使用。

VerifiableProducer 可以按照我們指定的參數來發送一定數量的消息，消息內容為從 1 開始遞增的數字，參數包括  acks，重試次數和發送速率等等，運行時會打印每條消息發送成功或失敗。VerifiableConsumer 消費 VerifiableProducer  生產的消息，按照消費順序打印消息內容，并且打印提交 offset 和分區重分配的消息。

下面來實戰一下，先看下這兩個命令行工具都有哪些參數：

因為我也是第一次使用，所以我就隨便選幾個參數設置一下：

使用 VerifiableProducer 發送數據：

然后用 VerifiableConsumer 接收收據：

因為將 max-messages 設置為 10，而 topic 中只有 5 條消息，所以沒有退出。

以上只是演示，因為 broker 只有一臺，而且非常穩定，實際測試時需要構建更復雜的場景：

• leader 選舉，關掉 leader 所在的 broker，producer 和 consumer 需要多長時間恢復?

• controller 選舉，重啟 controller，整個系統需要多長時間恢復?

• 滾動重啟，一臺一臺的重啟 broker，能否做到一條消息都不丟失?

• 臟 leader 選舉，當發生了臟 leader 選舉時，producer 和 consumer 會發生什么，能否接受后果?

根據實際的需要去構建測試場景，當測試都通過之后可以進入下一步。

3. 驗證應用

其實這一步的驗證方法和上一步非常類似，唯一的區別是：生產者和消費者替換成了自己開發的應用代碼，保持 Kafka  的配置不變，啟動應用中的生產和消費者，在構建的場景中測試，比如：

• 生產者和消費者與 Kafka 集群斷開網絡

• 發生了 leader 選舉

• broker 進行滾動重啟

• 消費者進行滾動重啟

• 生產者進行滾動重啟

如果測試結果不符合預期，找到原因，修復它，全部驗證通過后，進入下一步。

4. 線上監控

這一步非常重要，因為萬一前兩步有所疏漏，或者來不及做，監控可以確保及時發現問題，避免損失。

監控的內容可以包括：JMX、日志以及其它更復雜的自定義的指標。

JMX 監控

Kafka 自帶了 JMX 監控，對于broker，生產者和消費者，分別有不同的指標可以關注。

對于 broker，值得監控的指標很多，比如達不到 ISR 最小副本數的分區個數，正在同步的分區副本數，下線分區數，controller  數量，失敗的生產請求數，leader 選舉次數和時間等等，都很重要。

對于生產者，兩個和可靠性相關的指標是每條消息的平均錯誤率和平均重試率，這兩個指標如果上升了，表明系統肯定是出了問題。

對于消費者，最重要的指標是消費 lag，它表明了這個消費者當前消費到的位置落后于這個 topic 的各個分區最新消息有多遠，理想情況是在 0  和一個很小的值之間波動，如果增大到一定的閾值，則需要進行處理。

日志監控

Kafka 的日志監控和其它應用的日志監控區別不大，關注日志中出現的 WARN 和 ERROR，任何異常都有可能影響可靠性。

其它監控

如果不滿足于 JMX 監控和日志監控，可以自己擴展或增加其它的監控，JMX 報告的指標是可以擴展的，日志的內容也是可以增加的，但可能需要修改源碼。

監控系統

一般來說，Kafka 的監控任務應當由專門的監控和運維故障管理系統來完成，我用過兩個系統來監控 Kafka：小米的 Open-Falcon 和  InfluxData 的 Telegraf + InfluxDB + Grafana 套件。都還行，可以比較靈活的定制想要監控的內容，同時支持多種報警方式，比如  Open-Falcon 支持郵件和微信報警，而 Grafana 的頁面美觀性相當不錯，其它應當還有不少，但是我沒有用過就不胡扯了。

看完上述內容，你們對如何驗證 Kafka 系統的可靠性有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。