各位老鐵們好，相信很多人對kafka和mq的區別都不是特別的了解，因此呢，今天就來為大家分享下關于kafka和mq的區別以及rabbitmqkafka對比的問題知識，還望可以幫助大家，解決大家的一些困惑，下面一起來看看吧！
mq點對點和訂閱發布的區別
1.點對點
消息生產者消息發送到queue中，然后消費者從queue中取。注意：消息被消費以后，隊列中不再有存儲，所以消費者不能消費已經被消費的消息了。也就是不能重復消費。
2.發布/訂閱
生產者將消息發送到topic中，同事多個消費者消費這個消息。和點對點不同，發布到topic的消息會被所有訂閱在消費。
2.二者分析與區別
2.1點對點模式
?
生產者發送一條消息到queue，只有一個消費者能收到。
2.2發布訂閱模式
?
發布者發送到topic的消息，只有訂閱了topic的訂閱者才會收到消息。
小結
queue實現了負載均衡，一個消息只能被一個消費者接受，當沒有消費者可用時，這個消息會被保存直到有一個可用的消費者，一個queue可以有很多消費者，他們之間實現了負載均衡，
所以Queue實現了一個可靠的負載均衡。
topic實現了發布和訂閱，當你發布一個消息，所有訂閱這個topic的服務都能得到這個消息，所以從1到N個訂閱者都能得到一個消息的拷貝，
只有在消息代理收到消息時有一個有效訂閱時的訂閱者才能得到這個消息的拷貝。
疑問
發布訂閱模式下，能否實現訂閱者負載均衡消費呢？當發布者消息量很大時，顯然單個訂閱者的處理能力是不足的。實際上現實場景中是多個訂閱者節點組成一個訂閱組負載均衡消費topic消息即分組訂閱，
這樣訂閱者很容易實現消費能力線性擴展。
?
3流行消息隊列模型比較
傳統企業型消息隊列ActiveMQ遵循了JMS規范，實現了點對點和發布訂閱模型，但其他流行的消息隊列RabbitMQ、Kafka并沒有遵循老態龍鐘的JMS規范，是通過什么方式實現消費負載均衡、多訂閱呢？
3.1RabbitMQ
RabbitMQ實現了AQMP協議，AQMP協議定義了消息路由規則和方式。生產端通過路由規則發送消息到不同queue，消費端根據queue名稱消費消息。此外RabbitMQ是向消費端推送消息，訂閱關系和消費狀態保存在服務端。
?
生產端發送一條消息通過路由投遞到Queue，只有一個消費者能消費到。
?
當RabbitMQ需要支持多訂閱時，發布者發送的消息通過路由同時寫到多個Queue，不同訂閱組消費此消息。
RabbitMQ既支持內存隊列也支持持久化隊列，消費端為推模型，消費狀態和訂閱關系由服務端負責維護，消息消費完后立即刪除，不保留歷史消息。所以支持多訂閱時，消息會多個拷貝。
3.2Kafka
?
Kafka只支持消息持久化，消費端為拉模型，消費狀態和訂閱關系由客戶端端負責維護，消息消費完后不會立即刪除，會保留歷史消息。因此支持多訂閱時，消息只會存儲一份就可以了。
Spring boot是Java程序員必須掌握的框架之一么
毫不夸張的說：是的。
目前，不管是個人開發項目還是企業開發項目，如果選擇的是Java語言，那我們第一個想到的就是用SpringBoot框架開發，因為用它太快太爽了。幾分鐘就可以將一個Web后端的項目跑起來。而我們只需要寫業務代碼就好了。這對于程序員來說簡直就是天大的福利。
想想我們用SpringMVC的時候，是多么的痛苦。雖然SpringMVC也是非常優秀的框架（這也是必須要掌握的Java框架），但是基于XML文件的配置實在是太繁瑣。啟動一個JavaWeb項目，我們需要寫一大堆的xml文件，spring.xml、application.xml、web.xml、springmvc-servlet.xml等等，不勝其煩。而且即便這些東西都配置好了，項目還不一定能啟動起來。很多程序員應該都碰到過這個問題，bean加載的問題、數據源配置的問題、注解掃描路勁的問題，等等。反正，即使再NB的程序員，沒個半個一個小時，跑步起來基于SpringMVC框架的項目。（但是這不影響它成為一個非常優秀的Java框架）。
而SpringBoot完全拋棄了繁瑣的xml，在SpringBoot的項目中，幾乎看不到xml文件。干凈清爽的配置讓人欲罷不能，這也是為什么SpringBoot目前這么火的原因，也是現階段，Java程序員必須要掌握的框架。
最后總結一句：SpringBoot的好，誰用誰知道。springcloudstream是實時的嗎
springcloudstream是實時的。
SpringCloud可以輕松地將消息傳遞集成到基于Spring的微服務中，它是通過SpringCloudStream項目來實現這一點的。SpringCloudStream是一個由注解驅動的框架，它允許開發人員在Spring應用程序中輕松地構建消息發布者和消費者。
SpringCloudStream還允許開發人員抽象出正在使用的消息傳遞平臺的實現細節。SpringCloudStream可以使用多個消息平臺（包括ApacheKafka項目和RabbitMQ），而平臺的具體實現細節則被排除在應用程序代碼之外。在應用程序中實現消息發布和消費是通過平臺無關的Spring接口實現的。
Java大型互聯網架構-如何正常掌握分布式系統的大部分技術
分布式是一種思想，旨在將原本的單節點應用分布到不同的服務器節點，以求獲得更大的運算能力和更高的性能。
分布式技術太廣了，涉及到將多個服務器的CPU，內存硬盤等組成一個統一的整體，而服務，計算分布在不同的服務器上，服務之間的通信，分布式之后的全局唯一性，數據一致性，分布式事務等等，每一項可以說在實際工作中都會有大量的坑，不經歷過很難明白，下面是我的粗淺理解:
分布式存儲:
數據庫:數據庫的主從復制，讀寫分離，分庫分表這些東西，都是通過數據分布在不同的節點，以實現數據查詢與修改的更高的效率，同時防止數據在單一節點上因為某些原因的丟失，推薦自己搭建mysql主從，使用springaop代碼開發或者組件搭建讀寫分離，使用mycat等組件實現分庫分表！
文件:分布式文件存儲系統，有HDFS和Gluster等大型的系統，提供更好的容錯性和擴展能力！
分布式服務:對外提供高度內聚，透明，內部靈活，分散的服務集群！
前后端分離:將前后端的服務拆分在不同的集群中，以保證前后端技術架構上的分離，使用node.js部署前端服務，與用戶進行交互，后臺通過某種通信協議，提供動態數據給前端調用！
后端微服務:以單獨業務為導向，建立起細粒度的服務，同時服務之間通過服務發現組件進行通信，在用的springcloud還不錯，集成了網關，熔斷器，負載均衡等，可以進行快速的搭建！
服務之間的通信通常有服務暴露直接調用(zk.eureka等服務注冊與發現)，異步消息傳輸(kafka等消息隊列)！
分布式緩存:緩存通常是內存型緩存，可以用來快速的存取數據，減少數據庫的壓力！分布式緩存通常使用主從復制，高可用方式搭建起集群，提高整個緩存系統的容納能力，也避免單一緩存節點宕機對整個服務的影響，用的較多的是redis集群(基于redis的集群搭建，請參考https://www.wukong.com/question/6493663252021510414/)
redis緩存還因為單線程模型，可以用來做分布式鎖實現！
分布式計算:將一些大型的計算，使用策略分布到不同的機器上，然后匯總得到計算結果，一般使用map-reduce模型，hadoop，spark等都是成熟而且大規模使用的框架！
分布式技術并沒有嚴格分類，技術也五花八門，作為一個程序員只能是每天不斷的學習才能得以入門，每個人的學習能力，領悟到的東西也有不同，今天就寫這么多，更多的技術分享，敬請關注。。。
java自學到什么程度就能找工作了
本人去年12月自學javaweb，今年五月跳槽到了新公司做javaweb，以下皆為本人實際經驗。
現在javaweb最流行，本回答假設你學javaweb（如果不是也建議學javaweb）。
針對你的問題，只回答學到的程度，不寫不必要的東西（比如：如何學。如何學，請看我此分享:【我是如何下班后自學Java并拿到多個offer的-今日頭條】https://m.toutiao.com/is/ee3CaCq/）。
JavaWeb有如下技術棧：Java基礎、數據庫、緩存、框架、分布式、消息中間件、大數據。
1.Java基礎
基本代碼的編寫（比如：排序、遞歸）、類集（List、Set、Map）使用、多線程使用、JVM基本原理
2.數據庫
掌握增刪改查語句、索引的基本概念及用法、事務的概念及用法
3.緩存
Redis用法
4.框架
SpringMVC用法、SpringBoot用法
5.分布式
SpringCloud基本用法
6.消息中間件
RabbitMQ用法
7.大數據
ElasticSearch用法
以上，都需要通過小的Demo來掌握用法。然后，找個簡單一些的項目理解下項目實際使用就可以了，本處推薦：《深入淺出SpringBoot2.x》（此書有一章內容很適合作為項目練手，而且有SpringCloud入門級案例。第15章實踐一下——搶購商品；第17章分布式開發——SpringCloud）。我有此電子書，想要的可以私聊我。
理解項目大概流程就可以投遞簡歷找工作了。
注意：先投遞意向不強的公司，通過面試積累軟知識、原理類的經驗，沒遇到不會的，要記下來，盡快上網查詢或者看書查詢然后掌握。比如：
1.Java基礎
HashMap是如何實現的
2.數據庫
索引在什么時候會失效
3.緩存
如何避免緩存穿透
4.框架
SpringMVC請求流程
5.分布式
feign熔斷的原理
6.消息中間件
RabbitMQ的延時隊列是如何實現的
7.大數據
倒排索引與正排索引的區別
mq和kafka的區別
1)在架構模型方面，
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數據；無消息確認機制。
2)在吞吐量，
rabbitMQ在吞吐量方面稍遜于kafka，他們的出發點不一樣，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操作；基于存儲的可靠性的要求存儲可以采用內存或者硬盤。
kafka具有高的吞吐量，內部采用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁盤順序批量操作，具有O(1)的復雜度，消息處理的效率很高。
3)在可用性方面，
rabbitMQ支持miror的queue，主queue失效，mirorqueue接管。
kafka的broker支持主備模式。
4)在集群負載均衡方面，
rabbitMQ的負載均衡需要單獨的loadbalancer進行支持。
kafka采用zookeeper對集群中的broker、consumer進行管理，可以注冊topic到zookeeper上；通過zookeeper的協調機制，producer保存對應topic的broker信息，可以隨機或者輪詢發送到broker上；并且producer可以基于語義指定分片，消息發送到broker的某分片上。
OK，本文到此結束，希望對大家有所幫助。
