kafka與rabbitmq
xmind 思維導圖
axure 原型設計
一:rabbitmq集群：
1.1普通集群
rabbitmq 每個節點上有乙個broker，每個broker負責本機上佇列的維護，並且borker之間可以互相通訊。集群中有兩個佇列a和b，每個佇列都分為master queue和mirror queue（備份）
乙個主多個備，只有主做接受和傳送，備就是乙個映象，不承擔壓力，用在失敗後成為主（為什麼備不承擔壓力，應該是為了資料一致性吧）
例子：機器1 佇列a，佇列b b-master a-mirrow(在此消費a佇列，需要從機器2上讀取到機器1，在給消費者)
機器2 對列a 對列b a-mster b-mirrow
1.2映象集群
可以指定某個佇列在多個節點上 儲存，而不需要在拉取的時候在多個節點上傳遞資料
二：kafka集群 只有lead partition 才提供讀寫
kafka 多個master 也就是多個partition，並且這多個partitionr之間的資料沒有交集（rabbit的主也沒有交集）
乙個佇列有多個主partition，每個主partition又有若干副partition做備份，同步機制類似於rabbitmq。
1個partition只能被同組的乙個consumer消費，同組的consumer則起到均衡效果
rabbitmq每個佇列只能有乙個master，即master queue單節點
kafka乙個佇列可以有多個master(partition)（併發高原因），也就是說同乙個佇列可以發往任何乙個partition，多個partition沒有交集
每個分割槽的offset是有序的，多個分割槽之間無序
順序性：
多個消費者 不能保證順序，乙個會保證的，kafka由於partition機制，乙個partition可以一直對應乙個客戶端,根據訊息傳送的key生產者可以固定partition
如果消費者是多執行緒的話，可以放到乙個全域性佇列裡面
乙個topic 可以有多個partition,乙個消費組裡可以有多個消費者，乙個消費組內的消費組不能收到重複的topic，負載均衡，
乙個消費者只能在乙個partition上消費，即如果消費者大於partition數量的話，有乙個消費者是空閒的
乙個消費組有乙個offset
kafka只保證按乙個partition中的順序將訊息發給consumer，不保證乙個topic的整體（多個partition間）的順序。
消費者從哪個分割槽上取資料是固定的，(如果不改變分割槽數和消費者數的話)
在多個消費者，或者單個消費多個執行緒的時候，都不保證順序的
最終要讓訊息有序，就要保證消費者唯一。
rabbitmq ：乙個佇列對應乙個消費者
kafka：同乙個key，發到到同乙個partition
rabbitmq本身是基於erlang編寫的，erlang天生支援分布式（通過同步erlang集群各節點的cookie來實現），因此不需要像kafka那樣通過zookeeper來實現分布式集群(維護生產者和消費者轉台)
可靠性： 效率最高是發完啥也不管了，都有同步和非同步的。
rabbit
生產者：通過事務(channel.txselect)或者生產者confirm模(實際也是ack)，有同步和非同步的confirm，非同步(監聽)效能高 channel.addconfirmlistener
消費者：ack，broker收到後立刻刪除(效率低乙個原因)
broker：持久化
先是記憶體，滿了磁碟
kafka
生產者：kafka的ack機制 request.required.acks
=0 直接返回。
=1 leader確認訊息存後再返回，保證至少一次語義
=all leader和isr中所有replica都確認訊息再返回，保證至少一次語義
消費者： 1.讀取訊息 -> 提交offset -> 處理訊息 2.讀取訊息 -> 處理訊息 -> 提交offset 。 commit offset 和業務操作弄成乙個事務
broker：返回ack的時機 request.required.acks=0 直接返回 =1 leader確認訊息存下來了，再返回，保證至少一次語義 =all leader和isr中所有replica都確認訊息存下來了，再返回，保證至少一次語義
提交offset:
自動通過auto.commit.interval.ms指定時間間隔，可能會丟資料，因為自動提交了，
但是客戶端處理失敗了，就會丟失，解決辦法是客戶端如果失敗的話在catch 裡儲存資訊，通過乙個定時任務重試，直到成功。
手動 分同步和非同步，同步會重試，非同步不會重試
databus mysql通過binlog，實現快取等等。
消費者在消費完訊息後傳送乙個回執給rabbitmq，rabbitmq收到訊息回執（message acknowledgment）後才將該訊息從queue中移除；
而kafka是通過客戶端更新offset來實現的。可以自動實現，也可以客戶端通過**實現
kafka的consumer的offset儲存:
一種是存放在broker的日誌目錄中，另一種方式是存放在zookeeper中。兩種存放方式和你使用kafka-console-consumer命令使用的選項有關。如果使用的是bootstrap-server，那麼就存放在broker；如果使用的是–zookeeper那麼就存放在zookeeper。
訊息被處理的狀態是在consumer端維護 注意是維護 不是儲存
offset是代表某個分割槽被某個組目前消費的位置，
比如 p1 group1 10
比如說，p1裡面有來了一些資料，那p1的資料位置 15
消費者用 p1 group1 10和 15一比較，就可以得到 10~15的資料
乙個topic可以給多個分割槽訊息，多個分割槽不會重複資料
乙個broke上可以有多個分割槽，多個分割槽有乙個lead
同乙個消費組內的消費者要小於分割槽數，不然會有消費者永遠 收不到資料
基於replicated方案,那麼就意味著需要對多個備份進行排程;每個partition都有乙個server為"leader";leader負責所有的讀寫操作,如果leader失效,那麼將會有其他follower來接管(成為新的leader);follower只是單調的和leader跟進,同步訊息即可…由此可見作為leader的server承載了全部的請求壓力,因此從集群的整體考慮,有多少個partitions就意味著有多少個"leader",kafka會將"leader"均衡的分散在每個例項上,來確保整體的效能穩定.
producers
producer將訊息發布到指定的topic中,同時producer也能決定將此訊息歸屬於哪個partition;比如基於"round-robin"方式或者通過其他的一些演算法等.
key指定
redis 分片集群 主寫從讀，只在從配置就好(從拉取的方式)，通過rdb傳送給從快照，需要哨兵
集群不同的分片上不同key。redis 3.0以後才有分片集群
缺點 多個key的操作不支援
kafka資料檢索 Kafka日誌分段與訊息查詢
kafka作為乙個訊息中介軟體 後面kafka逐漸轉向乙個流失處理平台kafkastream 訊息最終的儲存都落在日誌中。kafka的訊息最終傳送是以topic下的分割槽為最終目標的，因此kafka的日誌儲存也是以分割槽為單位。配置檔案中log.dir引數決定了kafka資料檔案的存放目錄，該引數可...
kafka 檢視待消費資料 kafka檢視消費資料
kafka檢視消費資料 一 如何檢視 在老版本中，使用kafka run class.sh 指令碼進行檢視。但是對於最新版本，kafka run class.sh 已經不能使用，必須使用另外乙個指令碼才行，它就是kafka consumer groups.sh 普通版檢視所有組 要想查詢消費資料，必...
kafka 檢視待消費資料 kafka檢視消費資料
一 如何檢視 在老版本中，使用kafka run class.sh 指令碼進行檢視。但是對於最新版本，kafka run class.sh 已經不能使用，必須使用另外乙個指令碼才行，它就是kafka consumer groups.sh 普通版檢視所有組 要想查詢消費資料，必須要指定組。那麼線上執行...