39套Java架構師，高併發，高性能，高可用，分佈式，集羣，電商，緩存，微服務，微信支付寶支付，公衆號開發，java8新特性，P2P金融項目，程序設計，功能設計，數據庫設計，第三方支付，web安全，性能調優，設計模式，數據結構，併發編程，虛擬機，中間件，數據庫，項目實戰，大型分佈式電商項目實戰視頻教程
視頻課程包含：
39套包含：架構師，高併發，高性能，高可用，高可擴展，分佈式，集羣，電商，緩存，微服務，微信支付寶支付，公衆號開發，java8新特性，P2P金融項目，程序設計，功能設計，數據庫設計，架構設計，web安全，性能調優，設計模式，數據結構，項目實戰，工作流，程序調優，負載均衡，Solr集羣與應用，主從複製，中間件，全文檢索，任務調度，jvm虛擬機，Spring boot，Spring cloud，Docker，Kubernetes，jvm，Dubbo，Elasticsearch，ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat，Spring，Git，Nosql，Mecached，Netty，Nio，Mina，Nutch，Webservice，Activiti，Shiro，Tomcat，Mysql，Oracle，Quartz，ELK Stack，zookeeper，Activiti大型分佈式電商實戰等高端視頻課程......
39套精品課程介紹：
1、39套精品是掌櫃最近整理出的最新課程，都是當下最火的技術，最火的課程，也是全網課程的精品；
2、39套資源包含：全套完整高清視頻、完整源碼、配套文檔；
3、知識也是需要投資的，有投入纔會有產出（保證投入產出比是幾百上千倍），如果有心的朋友會發現，身邊投資知識的大都是技術經理或者項目經理，工資一般相對於不投資的也要高出很多；
總目錄：39套Java架構師項目實戰高併發高性能高可用分佈式集羣緩存性能調優設計模式數據結構算法併發編程微服務架構虛擬機中間件數據庫微信支付公衆號大型電商視頻課程
第一套：【系統學習】高併發大型電商詳情頁系統的大型高性能與高可用緩存架構實戰視頻教程
第二套：【項目實戰】4套Spring Boot基礎到精通，實戰與原理分析，微服務架構應用視頻課程
第01套.Spring boot入門到精通視頻課程
第02套.SpringBoot全套教程2018年更新
第03套.SpringBoot微服務架構應用
第04套.Spring Boot實戰與原理分析視頻課程
第三套：【微服務課】Spring Cloud微服務最新技術入門到精通視頻教程
第四套：【微服務課】5套Docker基本概念與架構，Docker構建微服務，Docker到Kubernetes之技術實戰視頻課程
第01套、Docker基本概念與架構
第02套、Docker雲計算與自動化實踐
第03套、Docker實戰系列課程
第04套、Docker構建微服務實戰
第05套：Docker到Kubernetes技術系列實戰視頻教程
第五套：【2套項目實戰】微信支付實戰，支付寶支付實戰，公衆號網頁支付實戰，web商城支付系列實戰視頻課程
第01套.【項目實戰】微信支付實戰視頻課程—公衆號網頁支付實戰（ Java版）
第02套.【項目實戰】支付寶即時到賬web商城支付系列實戰視頻課程 （Java版）
第六套：【項目實戰】微信二次開發實戰JAVA版，微信驗證，微信公衆平臺，智能客服，微信菜單定製，人臉識別系統視頻課程
第七套：【併發編程】Java高併發編程，線程安全深入解析，鎖原理，同步容器，實戰講解視頻教程
第八套：從無到有搭建中小型互聯網公司後臺服務架構與運維架構視頻課程
第九套：【系統學習】深入理解spring架構與原理從設計模式與原則理解Sring視頻課程
第十套：【項目實戰】設計模式綜合項目（實戰），設計模式綜合應用的實戰案例視頻教程
第十一套：【項目實戰】軟件系統功能設計（實戰）訓練（6個設計案例，真實項目功能需求）視頻教程
第十二套：【系統學習】Java數據結構和算法精講版（數組、棧、隊列、鏈表、遞歸、排序、二叉樹、紅黑樹、堆、哈希表）視頻課程
第十三套：【系統學習】Java虛擬機，深入JVM內核-原理，診斷與優化+內存模型+虛擬機原理
第十四套：【項目實戰】Java8新特性原理，高級進階實戰視頻教程
第十五套：深入Java程序性能調優視頻(阿姆達爾定律、緩存組件、並行開發、線程池、JVM調優)
第十六套：【系統學習】Elasticsearch基礎到深入，底層深入解析，結構化搜索，全文檢索高級案例實戰視頻課程
01.Elasticsearch基礎到深入，底層深入解析，結構化搜索，全文檢索高級案例實戰視頻課程-基礎篇
02.Elasticsearch基礎到深入，底層深入解析，結構化搜索，全文檢索高級案例實戰視頻課程-高級篇
第十七套：【中 間 件】3套ActiveMq，RocketMQ，RabbitMQ中間件架構，基礎到精通高級實戰視頻課程
01.【中 間 件】ActiveMq中間件基礎到精通高級實戰視頻課程
02.【中 間 件】JAVA-ACE架構師系列課程 Rocketmq
03.【中 間 件】RabbitMQ中間件基礎到精通，消息訂閱視頻課程
第十八套：【中 間 件】Kafka原理剖析及實戰演練
第十九套：【數 據 庫】4套Mysql，從小白到大神，數據庫查詢優化，大型分佈式集羣，數據庫運維視頻課程
01.【數據庫】Mysql從小白到大神
02.【數據庫】MySQL高級大型分佈式集羣，主從複製，負載均衡，數據庫中間件視頻課程
03.【數據庫】MySQL數據庫查詢優化
04.【數據庫】MySQL數據庫運維全套視頻教程 阿里巴巴DBA講授
第二十套：【數 據 庫】2套Oracle引航，深入，性能優化，高可用，海量數據庫設計視頻課程
01.【數據庫】oracle五部曲
02.【數據庫】Oracle性能優化視頻教程
第二十一套：【數 據 庫】Mycat從基礎到精通，分佈式數據庫中間件視頻課程
第二十二套：【3套項目實戰】Apache Shiro權限框架實戰Springboot與Shiro整合+項目案例+權限設計實現視頻課程
第03套.【項目實戰】Apache Shiro權限框架實戰+項目案例+權限設計實現視頻課程
第01套.SpringBoot與Shiro整合-權限管理實戰視頻
第02套.Shiro基礎到精通，原理與架構視頻課程
第二十三套：【系統學習】spring+quartz的分佈式任務調度及源碼解析視頻課程
第二十四套：【項目實戰】Dubbo分佈式系統架構-第三方支付項目的系統架構實戰視頻教程
第二十五套：【微服務課】基於支付系統場景的微服務架構的分佈式事務解決方案視頻課程
第二十七套：【項目實戰】日誌分析之ELK stack實戰視頻教程
第二十八套：【項目實戰】Zookeeper分佈式系統開發實戰視頻課程
第二十九套：【項目實戰】瘋狂講義Activiti6.X工作流進階與項目實戰，Activiti整合Drools視頻課程
第三十套：【項目實戰】P2P互聯網金融平臺項目SSM+Redis+Mysql+Bootstrap+JQuery視頻課程
第三十一套：【項目實戰】P2P網絡借貸平臺項目SSH+Redis+ActiveMQ+POI+Shiro+AngularJS+Nginx+Quartz視頻程
第三十三套：【項目實戰】大型分佈式電商系統redis+solr+Linux+nginx+springmvc+mybatis電商項目
第三十四套：【項目實戰】大型分佈式電商系統redis+solr+Linux+nginx+springmvc+mybatis電商項目
第三十五套：【架構師課】站在架構師的角度架構屬於自己的項目框架（ORM、MVC、IOC框架）視頻課程
第三十六套：【架構師課】架構師必備大規模高性能分佈式存儲系統設計與實現視頻課程
第三十七套：【架構師課】Java高級系統培訓架構師課程148課時（階段一）（maven+spring+mybatis+git+memcached+activemq+nginx+內存調優）
(01-07)Java架構師之Maven和Git課程
(08-30)Maven+Git+Spring+Mybatis+X-gen基本業務功能塊構建
(31-42)Java架構師之Ngnix入門到精通
(43-57)Java架構師之Varnish入門到精通部分
(58-70)Memcached+Nginx+Varnish內存調優緩存機制部分
(71-100)Java架構師之ActiveMQ消息存儲持久化+Spring+JMS+Queue隊列部分
(101-131)Java架構師之MongoDB入門到精通課程
(132-142)Java架構師之MogileFS部分+Nginx+Memcached的集成課程
(143-148)Nginx+Varnish+ActiveMQ階段小結和整體部署
第三十八套：【架構師課】Java高級系統培訓架構師課程116課時（階段二）（分佈式事物+單點登錄+高併發+性能優化+邏輯層處理+數據庫性能優化）
(1-23)、分佈式架構和部署部分
(24-50)、高併發和Web層的性能優化部分
(51-98)、邏輯層處理和性能優化部分
(99-110)、數據層處理和性能優化部分
(111-116)、數據庫性能優化
第三十九套：【架構師課】Java高級互聯網架構師系統培訓班課程（nginx+redis+zookeeper+activemq+storm+dubbo+netty+jvm+併發編程鎖+項目實戰）
高級互聯網架構師（源碼資料）
高級互聯網架構師（項目實戰）
中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解
消息中間件現在有不少，網上很多文章都對其做過對比，在這我對其做進一步總結與整理。
RocketMQ
淘寶內部的交易系統使用了淘寶自主研發的Notify消息中間件，使用Mysql作爲消息存儲媒介，可完全水平擴容，爲了進一步降低成本，我們認爲存儲部分可以進一步優化，2011年初，Linkin開源了Kafka這個優秀的消息中間件，淘寶中間件團隊在對Kafka做過充分Review之後，Kafka無限消息堆積，高效的持久化速度吸引了我們，但是同時發現這個消息系統主要定位於日誌傳輸，對於使用在淘寶交易、訂單、充值等場景下還有諸多特性不滿足，爲此我們重新用Java語言編寫了RocketMQ，定位於非日誌的可靠消息傳輸（日誌場景也OK），目前RocketMQ在阿里集團被廣泛應用在訂單，交易，充值，流計算，消息推送，日誌流式處理，binglog分發等場景。
Kafka
Kafka是LinkedIn開源的分佈式發佈-訂閱消息系統，目前歸屬於Apache定級項目。Kafka主要特點是基於Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸。0.8版本開始支持複製，不支持事務，對消息的重複、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。
RabbitMQ
RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基於AMQP協議來實現。AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發佈/訂閱）、可靠性、安全。AMQP協議更多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。
有關測試結論
Kafka的吞吐量高達17.3w/s，不愧是高吞吐量消息中間件的行業老大。這主要取決於它的隊列模式保證了寫磁盤的過程是線性IO。此時broker磁盤IO已達瓶頸。
RocketMQ也表現不俗，吞吐量在11.6w/s，磁盤IO %util已接近100%。RocketMQ的消息寫入內存後即返回ack，由單獨的線程專門做刷盤的操作，所有的消息均是順序寫文件。
RabbitMQ的吞吐量5.95w/s，CPU資源消耗較高。它支持AMQP協議，實現非常重量級，爲了保證消息的可靠性在吞吐量上做了取捨。我們還做了RabbitMQ在消息持久化場景下的性能測試，吞吐量在2.6w/s左右。
在服務端處理同步發送的性能上，Kafka>RocketMQ>RabbitMQ。
對比了最簡單的小消息發送場景,Kafka暫時勝出。但是,作爲經受過歷次雙十一洗禮的RocketMQ,在互聯網應用場景中更有它優越的一面。
阿里官網對比
功能消息隊列 RocketMQApache RocketMQ
（開源）消息隊列 KafkaApache Kafka
（開源）RabbitMQ
（開源）
安全防護支持不支持支持不支持支持
主子賬號支持支持不支持支持不支持不支持
可靠性- 同步刷盤
- 同步雙寫
- 超3份數據副本
- 99.99999999%- 同步刷盤
- 異步刷盤- 同步刷盤
- 同步雙寫
- 超3份數據副本
- 99.99999999%異步刷盤，丟數據概率高同步刷盤
可用性- 非常好，99.95%
- Always Writable好- 非常好，99.95%
- Always Writable好好
橫向擴展能力- 支持平滑擴展
- 支持百萬級 QPS支持- 支持平滑擴展
- 支持百萬級 QPS支持- 集羣擴容依賴前端
- LVS 負載均衡調度
Low Latency支持不支持支持不支持不支持
消費模型Push / PullPush / PullPush / PullPullPush / Pull
定時消息支持（可精確到秒級）支持（只支持18個固定 Level）暫不支持不支持支持
事務消息支持不支持不支持不支持不支持
順序消息支持支持暫不支持支持不支持
全鏈路消息軌跡支持不支持暫不支持不支持不支持
消息堆積能力百億級別
不影響性能百億級別
影響性能百億級別
不影響性能影響性能影響性能
消息堆積查詢支持支持支持不支持不支持
消息回溯支持支持支持不支持不支持
消息重試支持支持暫不支持不支持支持
死信隊列支持支持不支持不支持支持
性能（常規）非常好
百萬級 QPS非常好
十萬級 QPS非常好
百萬級 QPS非常好
百萬級 QPS一般
萬級 QPS
性能（萬級 Topic 場景）非常好
百萬級 QPS非常好
十萬級 QPS非常好
百萬級 QPS低低
性能（海量消息堆積場景）非常好
百萬級 QPS非常好
十萬級 QPS非常好
百萬級 QPS低低
對比
ActiveMQRabbitMQRocketMqZeroMQKafka
關注度高高中中高
成 熟度
成熟成熟比較成熟不成熟成熟
所屬社區/公司
ApacheMozilla
Public
License
Alibaba
Apache
社區活躍度高高中低高
文檔多多中中多
特點功能齊全，被大量開源項目使用由於Erlang 語言的併發能力，性能很好
各個環節分佈式擴展設計，主從 HA；支持上萬個隊列；多種消費模式；性能很好低延時，高性能，最高 43萬條消息每秒
授權方式開源開源開源開源開源
開發語言JavaErlangJavaC
支持的協議OpenWire、
STOMP、
REST、XMPP、
AMQPAMQP
自己定義的一
套(社區提供
JMS--不成熟)TCP、UDP
客戶端支持語言Java、C、
C++、
Python、
PHP、
Perl、.net 等 Java、C、
C++、
Python、
PHP、
Perl、.net 等
Java
C++（不成熟）python、 java、 php、.net 等
持久化內存、文件、數據庫內存、文件磁盤文件在消息發送端保存
事務支持不支持支持不支持
集羣支持支持支持不支持
負載均衡支持支持支持不支持
管理界面一般好無社區有 web
console 實現無
部署方式獨立、嵌入獨立獨立獨立
順序無法保證嚴格的順序 保證嚴格的消費順序
評價優點：
成熟的產品，已經在很多公司得到應用（非大規模場景）。有較多的文檔。各種協議支持較好，有多重語言的成熟的客戶端；
缺點：
根據其他用戶反饋，會出莫名其妙的問題，切會丟失消息。 其重心放到activemq6.0 產品—apollo 上去了，目前社區不活躍，且對 5.x 維護較少；
Activemq 不適合用於上千個隊列的應用場景優點： 由於erlang語言的特性，mq 性能較好；管理界面較豐富，在互聯網公司也有較大規模的應用；支持amqp系誒，有多中語言且支持 amqp 的客戶端可用
缺點：
erlang語言難度較
大。集羣不支持動態擴展。優點：
模型簡單，接口易用（JMS 的接口很多場合並不太實用）。在阿里大規模應用。目前支付寶中的餘額寶等新興產
品均使用rocketmq。集羣規模大概在50 臺左右，單日處理消息上百億；性能非常好，可以大量堆
積消息在broker 中；支持多種消費，包括集羣消費、廣播消費等。開發度較活躍，版本更新很快。
缺點：
沒有在 mq 核心中去實現JMS 等接口，
RabbitMQ
是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。同時實現了一個經紀人(Broker)構架，這意味着消息在發送給客戶端時先在中心隊列排隊。對路由(Routing)，負載均衡(Load balance)或者數據持久化都有很好的支持。
Redis
是一個Key-Value的NoSQL數據庫，開發維護很活躍，雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分爲128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於Redis。
ZeroMQ
號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。ZMQ能夠實現RabbitMQ不擅長的高級/複雜的隊列，但是開發人員需要自己組合多種技術框架，技術上的複雜度是對這MQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務器或中間件，因爲你的應用程序將扮演了這個服務角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然後你就可以愉快的在應用程序之間發送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果down機，數據將會丟失。其中，Twitter的Storm中使用ZeroMQ作爲數據流的傳輸。
ActiveMQ
是Apache下的一個子項目。 類似於ZeroMQ，它能夠以代理人和點對點的技術實現隊列。同時類似於RabbitMQ，它少量代碼就可以高效地實現高級應用場景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。
Jafka/Kafka
Kafka是Apache下的一個子項目，是一個高性能跨語言分佈式Publish/Subscribe消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現複雜均衡；支持Hadoop數據並行加載，對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的並行加載機制來統一了在線和離線的消息處理，這一點也是本課題所研究系統所看重的。Apache Kafka相對於ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分佈式系統。
rabbitmq比kafka可靠，kafka更適合IO高吞吐的處理，比如ELK日誌收集**
Kafka和RabbitMq一樣是通用意圖消息代理，他們都是以分佈式部署爲目的。但是他們對消息語義模型的定義的假設是非常不同的。我對”AMQP 更成熟”這個論點是持懷疑態度的。讓我們用事實說話來看看用什麼解決方案來解決你的問題。
a) 以下場景你比較適合使用Kafka。你有大量的事件(10萬以上/秒)、你需要以分區的，順序的，至少傳遞成功一次到混雜了在線和打包消費的消費者、你希望能重讀消息、你能接受目前是有限的節點級別高可用或則說你並不介意通過論壇/IRC工具得到還在幼兒階段的軟件的支持。
b) 以下場景你比較適合使用RabbitMQ。你有較少的事件（2萬以上/秒）並且需要通過複雜的路由邏輯去找到消費者、你希望消息傳遞是可靠的、你並不關心消息傳遞的順序、你需要現在就支持集羣-節點級別的高可用或則說你需要7*24小時的付費支持（當然也可以通過論壇/IRC工具）。
redis 消息推送（基於分佈式 pub/sub）多用於實時性較高的消息推送，並不保證可靠。
redis 消息推送（基於分佈式 pub/sub）多用於實時性較高的消息推送，並不保證可靠。其他的mq和kafka保證可靠但有一些延遲（非實時系統沒有保證延遲）。redis-pub/sub斷電就清空，而使用redis-list作爲消息推送雖然有持久化，但是又太弱智，也並非完全可靠不會丟。另外一點，redis 發佈訂閱除了表示不同的 topic 外，並不支持分組，比如kafka中發佈一個東西，多個訂閱者可以分組，同一個組裏只有一個訂閱者會收到該消息，這樣可以用作負載均衡。比如，kafka 中發佈：topic = “發佈帖子” data=”文章1” 這個消息，後面有一百臺服務器每臺服務器都是一個訂閱者，都訂閱了這個 topic，但是他們可能分爲三組，A組50臺，用來真的做發佈文章，A組50臺裏所有 subscriber 都訂閱了這個topic。由於在同一組，這條消息 （topic=”發佈帖子”, data=”文章1”）只會被A組裏面一臺當前空閒的機器收到。而B組25臺服務器用於統計，C組25臺服務器用於存檔備份，每組只有一臺會收到。用不同的組來決定每條消息要抄送出多少分去，用同組內哪些訂閱者忙，哪些訂閱者空閒來決定消息會被分到哪臺服務器去處理，生產者消費者模型嘛。redis完全沒有這類機制，這兩點是最大的區別。
redis是內存數據庫！redis他爹做了disque，你要不要試試。mq一般都採用訂閱～發佈模型，如果你考慮性能，主要關注點就放在消費模型是pull還是push。影響最大的，應該是存儲結構。kafka的性能要在topic數量小於64的時候，才能發揮威力。partition決定的。極限情況下丟消息，例如：主寫入消息後，主機器宕機，並硬盤損壞。review代碼的時候發現的。rabbit不知道，但是rocket的性能是（萬條每秒），並且能夠橫向無限擴展，單機topic數量在256時，性能損失較小。rocket可以說是kafka的變種，是阿里在充分reviewkafka代碼後，開發的metaQ。在不斷更新，修補以後，阿里把metaQ3.0更名爲rocket，並且rocket是java寫的易於維護。另外就是rocket和kafka有類似無限堆積的能力。想想，斷電不丟消息，積壓兩億條消息毫無壓力，niubilitykafka和rocket性能根本不是你需要考慮的問題。
在應用場景方面，
RabbitMQ,遵循AMQP協議，由內在高併發的erlanng語言開發，用在實時的對可靠性要求比較高的消息傳遞上。
kafka是Linkedin於2010年12月份開源的消息發佈訂閱系統,它主要用於處理活躍的流式數據,大數據量的數據處理上。
在架構模型方面，
RabbitMQ遵循AMQP協議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer通過連接channel和server進行通信，Consumer從queue獲取消息進行消費（長連接，queue有消息會推送到consumer端，consumer循環從輸入流讀取數據）。rabbitMQ以broker爲中心；有消息的確認機制。
kafka遵從一般的MQ結構，producer，broker，consumer，以consumer爲中心，消息的消費信息保存的客戶端consumer上，consumer根據消費的點，從broker上批量pull數據；無消息確認機制。
在吞吐量，
kafka具有高的吞吐量，內部採用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁盤順序批量操作，具有O(1)的複雜度，消息處理的效率很高。
rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不一樣，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操作；基於存儲的可靠性的要求存儲可以採用內存或者硬盤。
在可用性方面，
rabbitMQ支持miror的queue，主queue失效，miror queue接管。
kafka的broker支持主備模式。
在集羣負載均衡方面，
kafka採用zookeeper對集羣中的broker、consumer進行管理，可以註冊topic到zookeeper上；通過zookeeper的協調機制，producer保存對應topic的broker信息，可以隨機或者輪詢發送到broker上；並且producer可以基於語義指定分片，消息發送到broker的某分片上。
rabbitMQ的負載均衡需要單獨的loadbalancer進行支持。
Kafka是可靠的分佈式日誌存儲服務。用簡單的話來說，你可以把Kafka當作可順序寫入的一大卷磁帶， 可以隨時倒帶，快進到某個時間點重放。先說下日誌的定義：日誌是數據庫的核心，是對數據庫的所有變更的嚴格有序記錄，“表”是變更的結果。日誌的其他名字有： Changelog, Write Ahead Log, Commit Log, Redo Log, Journaling.Kafka的特徵如下：高寫入速度：Kafka能以超過1Gbps NIC的速度寫這盤磁帶（實際可以到SATA 3速度，參考Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines))，充分利用了磁盤的物理特性，即，隨機寫入慢（磁頭衝停），順序寫入快（磁頭懸浮）。高可靠性： 通過zookeeper做分佈式一致性，同步到任意多塊磁盤上，故障自動切換選主，自愈。高容量：通過橫向擴展，LinkedIn每日通過Kafka存儲的新增數據高達175TB，8000億條消息，可無限擴容，類似把兩條磁帶粘到一起。傳統業務數據庫的根本缺陷在於：1. 太慢，讀寫太昂貴，無法避免的隨機尋址。（磁盤最快5ms尋址，固態又太昂貴。）2. 根本無法適應持續產生的數據流，越用越慢。（索引效率問題）3. 無法水平scale。中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解中間件系列ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat讓你深入理解（多半是讀寫分離，一主多備。另: NewSQL通過一致性算法，有多主。）針對這些問題，Kafka提出了一種方法: “log-centric approach（以日誌爲中心的方法）。”將傳統數據庫分爲兩個獨立的系統，即日誌系統和索引系統。“持久化和索引分開，日誌儘可能快的落地，索引按照自己的速度追趕。”在數據可靠性在得到Kafka這種快速的，類似磁帶順序記錄方式保障的大前提下。數據的呈現，使用方式變得非常靈活，可以根據需要將數據流同時送入搜索系統，RDBMS系統，數據倉庫系統， 圖數據庫系統，日誌分析等這些各種不同的數據庫系統。 這些不同的系統只不過是一種對Kafka磁帶數據的一種詮釋，一個側面，一個索引，一個快照。數據丟了，沒關係，重放一遍磁帶即可，更多的時候，對這些各式數據庫系統的維護只是需要定期做一個快照，並拷貝到一個安全的對象存儲(如S3) 而已。 一句話：“日誌都是相同的日誌，索引各有各的不同。”關於流計算：在以流爲基本抽象的存儲模型下，數據流和數據流之間，可以多流混合處理，或者流和狀態，狀態和狀態的JOIN處理，這就是Kafka Stream提供的功能。 一個簡單的例子是，在用戶觸發了某個事件後，和用戶表混合處理，產生數據增補（Augment)，再進入數據倉庫進行相關性分析，一些簡單的窗口統計和實時分析也很容易就能滿足，比如 在收到用戶登錄消息的時候，在線人數+1， 離線的時候-1，反應出當前系統的在線用戶總數。這方面可以參考PipelineDB https://www.pipelinedb.com/Kafka會讓你重新思考系統的構建方式，使以前不可能的事變爲可能，是一個系統中最重要的最核心的部分，不誇張的說，系統設計都需要圍繞Kafka做。