一、rabbitmq
rabbitmq屬於比較傳統的訊息佇列系統，支援標準的訊息佇列協議（amqp, stomp，mqtt等），如果你的應用程式需要支援這些協議，那麼還是使用rabbitmq。另外rabbitmq支援比較複雜的consumer routing，這點也是kafka不提供的。
。二、kafka
，是大資料生態中不可或缺的產品之一；讓資料整合變得簡單：您能將 kafka 中的訊息匯入到 odps、hbase、hbase 等離線資料倉儲；可廣泛的與流計算引擎整合，包括阿里雲平台的 streamcompute、e-mapreduce 和開源產品 spark、storm 等。
經典應用場景：
1、**活動跟蹤
成功的**運營都會非常關注站點的使用者行為並進行分析。通過訊息佇列 kafka，您可以實時收集**活動資料（包括使用者瀏覽頁面、搜尋及其他行為等），並通過「發布/訂閱」模型實現：
2、日誌聚合
許多公司，比如**、天貓平台每天都會產生大量的日誌（一般為流式資料，如搜尋引擎 pv、查詢等），相較於日誌為中心的系統，比如 scribe 或者 flume 來說，kafka 在提供同樣高效的效能時，可以實現更強的資料持久化以及更低的端到端響應時間。kafka 的這種特性決定它非常適合作為日誌收集中心：
3、流計算處理
在很多領域，如**走向分析、氣象資料測控、**使用者行為分析，由於資料產生快、實時性強且量大，您很難統一採集這些資料並將其入庫儲存後再做處理，這便導致傳統的資料處理架構不能滿足需求。
與傳統架構不同，kafka 以及 storm/samza/spark 等流計算引擎的出現，就是為了更好地解決這類資料在處理過程中遇到的問題，流計算模型能實現在資料流動的過程中對資料進行實時地捕捉和處理，並根據業務需求進行計算分析，最終把結果儲存或者分發給需要的元件。
4、資料中轉樞紐
近 10 多年來，諸如 kv 儲存（hbase）、搜尋（elasticsearch）、流式處理（storm/spark streaming/samza）、時序資料庫（opentsdb）等專用系統應運而生。這些系統是因為單一的目標而產生，也因其簡單性使得在商業硬體上構建分布式系統變得更加容易且價效比更高。
通常，同乙份資料集需要被注入到多個專用系統內。例如，當應用日誌用於離線日誌分析，搜尋單個日誌記錄同樣不可或缺，而構建各自獨立的工作流來採集每種型別的資料再匯入到各自的專用系統顯然不切實際，利用 kafka 作為資料中轉樞紐，同份資料可以被匯入到不同專用系統中。
三、redis
四、activemq
kafka只是訊息引擎系統嗎
kafka真的只是訊息引擎系統嗎？要搞清楚這個問題，就要從kafka的發展歷史說起，縱觀kafka的發展歷史，它確實是訊息引擎起家的，但它不僅是乙個訊息引擎系統，同時也是乙個分布式流處理平台 distributed stream processing platform 如果這一節你只能記住一句話的話...
MySQL引擎各個引擎對比介紹
1.什麼是儲存引擎?模擬於,就是資料庫表裡的資料儲存在資料庫裡及磁碟上的系統格式特徵,不同的儲存引擎訪問,引擎功能,占用的空間大小,讀取效能等可能有區別.2.mysql的儲存引擎是mysql資料庫的重要組成部分,最常用的為myisam和innodb兩種,mysql的儲存引擎結構如圖所示 3.常用引擎...
mysql儲存引擎對比
下面我們重點介紹幾種常用的儲存引擎並對比各個儲存引擎之間的區別和推薦使用方式。特點myisam bdbmemory innodb archive 儲存限制 沒有沒有 有64tb 沒有事務安全 支援支援 鎖機制表鎖 頁鎖表鎖 行鎖行鎖 b樹索引 支援支援 支援支援 雜湊索引 支援支援 全文索引 支援集...