一種物聯網設施管理系統中的Kafka優化方法?

顧 鑫 程淑玲

（1.武漢郵電科學研究院 武漢 430074）

（2.烽火通信科技股份有限公司 武漢 430074）

1 引言

近些年，隨著物聯網、大數據、云計算等技術的快速發展，需要分析、處理和傳輸的信息量飛速增長［1］。將物聯網技術應用于人井、光交箱、室外柜、電子鎖等物聯設施可以大大地提高對這些設施的管理效率［2］。我們的基礎設施物聯管理系統就是在這樣的背景下建立的一個平臺，旨在借助于這些技術對物聯設施的運行維護提供更準確的實時檢測、指標分析及其他的一些服務，保障物聯設施安全、穩定、高效地運行。

本系統作為一個管理十萬級物聯網設施的大數據平臺，消息中間件起著關鍵的作用［3］。設施上報的原始數據不直接進入處理程序，而是先存入Kafka消息隊列中?；谙㈥犃?，獨立的節點無需緊耦合工作，能夠以異步的方式交換信息，從而可以提高系統的靈活性［4］。雖然消息中間件的應用能帶來收益，但它造成的負面影響也是需要我們關注的。在大規模的分布式系統中，消息中間件的表現已經成為制約系統整體性能的重要瓶頸［5］，為了更高效地利用Kafka消息中間件，降低其造成的延時和資源消耗是十分有必要的。

2 選用Kafka的原因

2.1 Kafka介紹

Kafka是一個分布式的、基于發布/訂閱的開源消息系統，廣泛地用于各種消息交換系統、實時數據流應用和大數據平臺中［6］。它的數據組織是按主題來劃分的，每個主題就是一個消息流［7］。主題又被分解成多個分區，同時也被復制多份。消息生產者向指定的主題中發布消息，消息消費者便可以獲取消息［8］。一個Kafka集群由一個或多個broker節點組成。

2.2 Kafka的優勢

Kafka與傳統的消息系統相比有著很多優勢之處：被設計成分布式的消息集群［9］，適合于演進式系統，隨著業務量增加可以動態伸縮；消息可以被持久化存儲，這樣除了支持實時消息處理外，也能做到離線批量數據分析處理；消息發布和消息訂閱的吞吐量非常巨大，性能優異［10］；當集群中有節點發生故障時，能自動重新負載均衡，容錯性強；多個微服務之間的消息交互也可以使用Kafka來交換，這種響應式的異步數據交換模式能提高系統的性能。

3 Kafka造成的延時和資源消耗

系統的數據流如圖1所示。物聯設施的告警信息可能存在告警風暴的場景，為了降低告警風暴對系統造成的沖擊，添加Kafka消息中間件是十分有必要的。Kafka將接收到的告警信息存放在消息隊列中，異步地將這些信息以數據流的形式傳輸到數據分析層和數據存儲層［11］。

圖1 系統的數據流

3.1 延時

通常情況下，Kafka消息中間件的緩存越大，造成的額外延時就會越高［12～13］。由于系統對實時性的要求較高，需要找出合適的緩存大小來確保低延時。我們以每條0.2KB，每秒10000條的速度發送JSON格式的消息，測量了Kafka消息中間件在不同緩存大小造成的額外延時，如圖2所示。經比較發現，添加16MB緩存的三節點Kafka集群幾乎不會額外地增加系統延時，和不添加Kafka消息中間件一樣，都是有99.95%的消息低于100ms延時的門限。所以，在物聯設施管理系統中使用16MB以下緩存的Kafka集群是可行的。

圖2 不同緩存大小的Kafka延時

3.2 額外CPU資源消耗

由于16MB以下緩存的Kafka消息中間件幾乎不會增加系統延時，我們測量了添加16MB以下不同緩存大小的Kafka集群造成的額外CPU資源消耗，如圖3所示。緩存大小在1MB時，添加Kafka消息中間件造成的額外CPU資源消耗最低，為5.4%。

圖3 不同緩存大小的Kafka額外CPU資源消耗

4 優化方案

Kafka消息中間件帶來的額外CPU資源消耗有比較大一部分原因是KafkaProducer的Serializer接口不必要的內存分配和復制導致的［14］，由于低效的內存管理導致的垃圾回收暫停會增加CPU的使用率［15］。Kafka庫中的Serializer接口如圖4所示?？梢宰⒁獾?，序列化方法返回byte［］字節數組，這實際上迫使計算機創建一個總是分配新字節數組內存空間和復制內存內容的實現。由于這種API設計，KafkaProducer在堆內存上分配了過多的字節數組，不能夠重用已分配的內存，特別是當對象序列化為可變長度數組的時候。

圖4 Kafka的Serializer接口

java.nio.ByteBuffer充當連續內存的可變指針，能夠記錄開始和結束的位置。在它的幫助下我們可以預先分配并重用內存，以避免為每個序列化對象都分配新的內存空間。為了在優化時對現有代碼產生的影響盡可能小，在Serializer接口中添加了一個帶有default實現的方法，如圖5所示。在Seri?alizer實現中重新聲明serializeAsByteBuffer方法，在此更改之后，可以直接使用ByteBuffers來替換字節數組，返回指向序列化對象開始和結束的預分配內存。優化之后，我們重新測量了不同緩存大小的三節點Kafka集群造成的額外CPU資源消耗，與優化之前的對比結果如表1所示?？梢钥吹?，優化后緩存大小在2MB時額外的CPU資源消耗最低，為3.3%。

圖5 添加到Serializer接口中的方法

表1 優化前后Kafka不同緩存大小的額外CPU資源消耗

5 優化的意義

我們的物聯設施管理系統是部署在云端的，計算資源的利用成為了關鍵的影響因素之一，因此如何降低資源消耗是值得研究的。從優化前使用1MB緩存的Kafka消息中間件的5.4%最低額外CPU資源消耗到優化后使用2MB緩存的Kafka消息中間件的3.3%最低額外CPU資源消耗，此優化方案讓Kafka造成的額外CPU資源消耗降低了39%。由于系統管理的物聯設施數量巨大，未來還會有新的設施接入，伴隨著數據量的增加，Kafka集群會根據需要進行擴展，這樣一來優化帶來的收益會進一步增加。

6 結語

本文針對KafkaProducer的Serializer接口提出了優化方案，顯著地降低了使用Kafka消息中間件帶來的額外CPU資源消耗，提高了物聯設施管理系統的性能，同時也為將來伴隨系統擴展而擴展的Kafka集群的使用打下了基礎。除了Serializer接口，還有其他的方面可以對Kafka消息中間件進行優化，這也是未來需要繼續探究的。另外，這種優化消息中間件的思想也可以應用在Kafka以外的其他消息中間件和消息系統。