搜狗開源框架釋出純自研C++ Kafka客戶端

搜狗於今年7月釋出了C++非同步排程伺服器引擎——Workflow，除了計算通訊融為一體的高效能特點以外，還集成了多種常用的網路協議，包括：Http、Redis、MySQL，所有協議都是純自研自解析，無需依賴第三方庫，而具體協議所對應的資源複用和執行緒排程等都由Workflow以統一的方式去進行管理，目前獲得了越來越多開發者的青睞和肯定。而最近，Workflow又支援併發布了一項複雜的通用網路協議：Kafka，使得所有使用Workflow及其生態專案的開發者都可以通過統一而簡便的方式與Kafka互動，這也是業內唯一一款使用C++語言實現的Kafka客戶端，值引得開源社群開發者們的關注。

一、開發背景

在Workflow釋出Kafka客戶端之前，業內用得比較多的是librdkafka，但這個純C的kafka客戶端有許多不足，以下是我們原先使用時遇到的部分問題：

1、執行緒資源和網路資源消耗比較多

2、介面設計比較複雜臃腫，使用成本比較高

3、Kafka版本相容性不是很好

4、消耗資源高，但是效能卻不高

5、broker主從切換低版本出現服務hang住情況，高版本偶發丟資料問題

6、非同步同步偶發出現丟資料情況

針對這些問題，更好的替代方案是Workflow的Kafka客戶端。

由於實現在Workflow的基礎上，作為Kafka客戶端即具有超高效能、超大吞吐和極省的資源佔用等特點，且和其他協議的介面一樣，此Kafka客戶端還具有介面清晰，程式碼可讀性強等優點，不僅節省機器成本還節省人力維護成本，非常值得一試。

二、新一代高效能C++ Kafka客戶端

Workflow的Kafka客戶端使用介面非常簡潔，首先需要建立一個client物件：

其他使用方式與框架內的其他任務無異，使用Workflow的同學可以瞬間上手：

為什麼Workflow的Kafka客戶端能有以上的優點呢？主要得益於以下三方面的細節：

一. 內部基於Workflow的任務流實現。Workflow的核心設計理念是將任務抽象成"任務流"的概念，這樣一個任意複雜的任務可以拆分成若干個並行任務流和序列任務流，它們之間通過串聯、並聯等方式組成一個或者多個串並聯圖，然後由Workflow內部的引擎高效非同步地執行。

以Kafka協議的fetch訊息為例，下圖是執行過程中任務流的串並聯圖：

一個fetch訊息的任務由一組任務組成，其中包括獲取Kafka Broker的Meta任務、一系列的消費者組相關的任務、獲取offset的任務和真正的拉取訊息的任務。前面的多個任務由於有依賴關係，所以組成串聯任務；而最終拉取訊息的任務和Broker的個數有關，因此可以將它轉換成一個broker數目相同的並行任務。這樣做一方面可以使得邏輯很清晰，同時也可以保證執行的高效性。

二. 連線複用。傳統的網路通訊往往是在程式初始化的時候，建立大規模連線池來提高網路吞吐，這麼做的一個弊端是系統資源佔用過多，會導致降低程式的魯棒性。而目前這個Kafka客戶端由於內部是基於Workflow框架，Workflow對連線的管理做了很多優化，可以在保證高效高吞吐的同時，將資源控制在一個合理的範圍內。

三.記憶體管理。為了方便使用者的使用，內部的所有物件都基於計數實現，通過工廠方法建立任務後，在回撥函式中實現處理邏輯即可。記憶體的分配和釋放都是框架自動完成，全程無需手動操作任務級別的記憶體，非常方便；同時它的邏輯又是完備自洽的，保證了高效可靠。

三、外掛式釋出，與Workflow完美融合

基於Workflow精巧的層次結構，Kafka協議是以外掛式釋出的，即無需安裝Kafka的使用者不會把Kafka相關程式碼編譯進去，由此可以看出Workflow本身的架構解耦和模組對稱性都做得非常優秀。

而Kafka的協議由於需要多次互動，Workflow複合任務又天生支援內部互動的隱藏，使得整體使用上對使用者非常簡潔透明。基於二級工廠模式也可以把許多全域性資訊統一管理到記憶體中，也是工程上結合的一大亮點。

可以說，Kafka協議與Workflow的融合相當完美，且目前在搜狗已經大規模使用，經得住工業級檢索系統大規模請求的實際考驗，歡迎業內需要的開發同學積極嘗試並與我們熱心的開發小組進行技術交流。