kafka01 與其他消息系統對比

消息系統分類

Peer-to-Peer

基于Pull或者Polling接收消息

發送到隊列中的消息被一個而且僅僅一個接受者所接收，即使有多個接收者在同一個隊列中偵聽同一消息

支援異步“即發即棄”的消息傳送方式（發送後沒接收就丢棄），也支援同步請求/應答傳送方式（發送了之後必須收到才發下一個）

釋出/訂閱

釋出到一個主題（Topic）的消息，可被多個訂閱者所接收釋出/訂閱

可基于Push消費資料，也可以基于Pull或者Polling

資料解耦能力比P2P模型要強

對比

Kafka	RabbitMQ	ActiveMQ	Redis
消息回溯	支援，無論是否被消費都會保留，可設定政策進行過濾删除（基于消息逾時或消息大小）	不支援，一旦被确認消費就會标記删除	不支援	可設定消息過期時間，自動過期
API完備性	高	高	中	高
單機吞吐量	十萬級	萬級	萬級	十萬級
首次部署難度	中	低	低	低
消息堆積	支援	支援（記憶體堆積達到特定門檻值可能會影響性能）	支援（有上線，當消息過期或儲存設備溢出時，會終結它）	支援（有上線，伺服器容量不夠會容易崩潰造成資料丢失）
消息持久化（資料持久化到硬碟）	支援	支援	不支援	支援
多語言支援	支援，Java優先	語言無關	支援，Java優先	支援
消息優先級設定（某些消息被優先處理）	不支援	支援	支援	支援
消息延遲（消息被發送之後，并不想讓消費者立刻拿到消息，而是等待特定時間後，消費者才能拿到這個消息進行消費）	不支援	支援	支援	支援
消費模式（①推模式：由消息中間件主動地将消息推送給消費者；②拉模式：由消費者主動向消息中間件拉取消息）	拉模式	推模式+拉模式	推模式+拉模式	拉模式
消息追溯	不支援	支援（有插件，可進行界面管理）	支援（可進行界面管理）	支援
常用場景	日志處理、大資料等	金融支援機構	降低服務之間的耦合	共享Cache、共享Session
運維管理	有多種插件可進行監控，如Kafka Management	有多種插件可進行監控，如rabbitmq_management(不利于做二次開發和維護）	無	有多種插件可進行監控，如zabbix