基于Kafka 的公交GPS 數據實時通訊系統的設計與應用

何 偉 王 浩 綦忠平

（濟南公共交通集團有限公司，濟南 250013）

關鍵字：GPS；Kafka；實時處理；大數據技術

隨著城市擁堵加劇，為減少無效等待時間，降低等車焦慮，市民對公交車輛動態運行信息的實時性和準確性要求日益提高，保障車輛運行數據的穩定性和完整性已成為公交企業對外服務和內部管理的關鍵。保證核心業務系統的數據處理能力、有效應對每秒數萬筆的GPS 數據傳輸和處理成為重中之重，若不能進行流量緩沖將直接引發系統崩潰和服務停滯，亟需利用大數據技術幫助業務系統處理瞬間流量洪峰的沖擊，保持各個應用之間的消息通暢。

1 現狀及分析

公交運力隨著城市拓展不斷提升，傳統的公交數據通訊網關已無法滿足新時代公交調度和乘客信息服務的需求，需要建設滿足高可靠、高并發的實時數據通訊系統。

1.1 現狀問題

傳統的數據通訊系統存在以下幾個方面的問題：

（1）在處理海量并發數據方面，存在單點故障和負載不均衡等問題。

（2）系統模塊耦合度較高、功能復雜，存在故障定位、追溯和運維困難等問題。

（3）數據流經環節多，存在網關、數據庫、機房網絡等軟硬件綜合故障概率大等問題。

1.2 業務需求

公交GPS 數據實時通訊系統需能正確、高效地解析、轉發和存儲數據，滿足高吞吐、高并發、高可用等工作要求，能準確監控公交車輛運行位置、速度等狀態信息，在保障公交智能調度系統運行正常和滿足人們的出行信息服務需求方面發揮出關鍵作用。

（1）負載均衡：基于TCP 和HTTP 提供代理服務，需支持負載均衡。

（2）高并發性：支持高并發解析和處理數據，需保證實時響應能力。

（3）實時性：面對大量數據接入，需能正確、實時、完整地解析和處理數據。

（4）高可用性：保證主備服務器可用，應避免因單臺故障影響整體服務不可用。

（5）高穩定性：通信服務器應對大量連接保持穩定連接狀態，避免宕機。

（6）可拓展性：平臺模塊低耦合，模塊之間的需求發生改變不影響整個系統的可用性。

2 系統方案設計

針對上述業務需求，本文選擇基于分布式發布-訂閱消息系統Kafka 設計搭建公交GPS 數據通訊系統。Kafka 是一個高吞吐量的分布式消息訂閱-發布系統，具備高性能、持久化、多副本備份、橫向擴展能力。通過生產者向隊列里寫消息，消費者從隊列里取消息進行業務邏輯處理，相對于傳統的消息隊列，Kafka 可實現業務邏輯的解耦、削峰和異步處理。公交智能調度系統采用具備高性能異步通信能力的Netty 框架；選用HAProxy 構建代理服務器并結合Keepalive 健康檢查，解決通信服務器的單點故障、負載不均問題，實現故障轉移的高可用方案；選用Kafka 分布式消息隊列降低模塊耦合度，解決通信服務和數據庫耦合度高、模塊功能復雜且難以維護的問題；其他模塊利用Kafka 定制分發策略，將Kafka 作為數據源，達到模塊功能單一、系統性能最優的目的。系統設計模塊如圖1所示。

圖1 系統設計模塊

2.1 Kafka 消息隊列

典型的用于數據通訊的分布式消息中間件主要包括ActiveMQ、RabbitMQ、ZeroMQ、Kafka 等。ActiveMQ 不支持集群控制臺管理，訪問吞吐量較低，RabbitMQ 伸縮性不能滿足遞增的系統規模，ZeroMQ 由于采用內存進行存儲和轉發，沒有持久化機制。

Kafka 支持發布訂閱模式，滿足低延遲、高吞吐、高可用需求，吞吐量可隨集群擴展而線性增加，在海量數據處理領域被廣泛應用，同時支持離線數據處理和實時數據處理。通過對比分析，選擇Kafka應用于分布式公交GPS 大數據處理系統。消息傳遞模式如圖2 所示。

圖2 消息傳遞模式

2.2 Netty 通信框架

Netty 通訊框架具有高性能、異步通信、事件驅動的特點，適合用于構建高性能、分布式通信系統，可用于快速開發、維護基于網絡協議的服務器和客戶端。

2.3 HAProxy

HAProxy 提供基于TCP 的負載均衡，具有高性能、高可靠、高安全特性，支持萬級并發，包括GitHub、Twitter、亞馬遜等知名網站都使用了HAProxy。

2.4 數據庫

Redis 是高性能NoSQL 數據庫，數據采取內存存儲方式，利用復制特性擴展讀性能，利用客戶端分片擴展寫性能，采用單線程工作模型，避免頻繁上下文切換，采用非阻塞I/O 多路復用機制。

3 通訊系統架構

針對公交車輛運行實時數據，本系統利用Netty 集群解決高并發通信問題，選用Kafka 集群作為實時消息處理模塊的中間件，利用Kafka 的異步解耦功能，避免系統業務之間相互耦合影響，實現上、下游業務系統松耦合，降低系統復雜度，縮短用戶請求的響應時間，保證智能調度子系統或子模塊的故障不影響整個鏈路。

利用Kafka 技術搭建大規模的消息系統，Kafka具有消息持久化、高吞吐、分布式、實時、低耦合、多客戶端支持、數據可靠等諸多特點，系統流程如圖3 所示。

圖3 系統設計流程

3.1 系統整體架構

公交車載終端與通訊服務器建立TCP 連接，車輛運行數據經代理服務器、Netty 集群通信服務器轉發推送到Kafka 集群消息隊列服務器。為保證對外服務的時效性，減少數據入庫延遲影響，公交手機來車預報APP、電子站牌等業務首選從Kafka獲取車輛GPS 數據，從數據庫獲取車輛注冊數據。智能調度車輛運行監控、數據統計分析、安全管理等業務系統從數據庫獲取車輛運行動靜態數據。系統整體架構如圖4 所示。

圖4 系統整體架構

（1）數據源層（公交車載GPS），用于產生原始GPS 數據，通過4G 無線網絡實時上傳，每5 秒上傳1 次。

（2）數據通訊層，利用Netty 集群與車載設備實時連接，實現公交車載設備上線注冊、數據通訊、負載均衡等功能。每臺虛擬服務器可支持500 輛車實時通訊。

（3）數據分發層，利用Kafka 集群實時處理5000 多個終端的高并發GPS 數據，并以毫秒級延遲實時發布，滿足內外不同應用場景的消息訂閱需求。

（4）數據存儲層，利用Redis 數據庫緩存實時數據，提高數據訪問效率；利用Oracle 數據庫存儲數據，根據業務需求進行計算與交互。

（5）數據輸出層，分為對外便民服務和內部業務管理兩部分，對外服務重點保障高實時性，內部管理兼顧實時性與數據統計分析。

本文設計的通訊系統架構，部署在虛擬機集群之上提供服務，可有效避免由于智能調度系統故障或數據庫故障導致的對外服務停滯問題，提高了系統整體的可用性和可靠性。

3.2 內部功能模塊

GPS 數據通訊系統是公交智能調度系統的關鍵子系統之一，主要包括車輛注冊、心跳連接、數據解析、數據存儲、數據接口等功能（圖5）。該系統從總體設計方面來講，每個模塊功能較為單一，降低了模塊之間的耦合度，提高了模塊靈活性和復用率。

圖5 通訊系統內部模塊

（1）車輛注冊功能：通信服務器與車載終端建立連接，接收車輛登錄和注冊信息，將車輛注冊信息存入數據庫。

（2）健康檢查功能：采用心跳連接，系統自身維護車載終端和通信服務器長鏈接狀態。

（3）數據解析功能：依據衛星定位系統終端通訊協議，正確解析數據，并校驗數據的正確性。

（4）數據存儲功能：結合業務需要，分類分庫存儲。車輛運行數據存入Redis 數據庫，提高訪問效率，同時車輛基礎數據和運行數據存入Oracle 數據庫，便于數據追溯。

（5）數據接口：系統對外公布服務接口，供企業內部其他系統或外部第三方獲取動態數據。

4 系統評價

本文提出的基于Kafka 的公交GPS數據實時通訊系統充分利用了先進的實時大數據流處理技術，并針對公交GPS數據流的特點對技術選型和系統架構進行了研究和設計。經過研究分析及實際應用（圖6），本文設計的數據實時通訊系統具有如下優勢。

圖6 系統環境配置及并發訪問

（1）數據處理高效。系統采用當前先進的高可靠、高吞吐量的Kafka 消息系統，基于內存數據庫進行數據處理，實時處理能力強，較傳統架構處理效率顯著提升。

（2）功能擴展性強。系統采用的Kafka 消息隊列、Netty 通信集群、Oracle數據庫和Redis 數據庫均采用分布式集群架構，具備較強的擴展能力。隨著公交車輛增多，系統處理能力可平滑擴展，有效降低了系統擴展成本。

（3）系統可用性強。通過服務器集群提供負載均衡，通過Kafka 消息隊列集群和Oracle 數據庫集群多通道提供實時數據，縮小單點故障的影響范圍，避免造成出行信息服務停滯。

（4）可恢復性高。系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，即使一個處理消息的進程掛掉，加入隊列中的消息仍可在系統恢復后被處理。

5 結語

本文設計的公交GPS 數據實時通訊系統實現了公交車輛GPS 運行數據的解析、存儲和分發，為市民提供實時車輛運行信息，引導市民優先選擇綠色出行，為企業調度運營提供數據支持，滿足市民美好出行體驗的需要，不斷提高公交乘客滿意度，獲得良好的經濟和社會效益。