各種消息中間件
都支持消息持久化,但是都有性能損耗
協(xié)議AMQP: rabitmq就是為AMQP而生的,ActiveMQ也支持, 但是性能就不好了
小公司并發(fā)低用前個(gè)就好了,
ActiveMQ
太老了, 江河日下
唯一優(yōu)點(diǎn)是java寫的
RabbitMQ
erlang寫的,語言很難 ,很難看源碼難以深入研究, 有問題難解決
erlang 高可用 99.999%
RocketMQ
誕生最晚,社區(qū)活躍度低,資料少
支持語言少 Java php
Java寫的, 并發(fā)可以
運(yùn)維難度大對(duì)技術(shù)有自信的公司可以用,
延遲隊(duì)列實(shí)現(xiàn)方便(RabbitMQ要延遲隊(duì)列就比較繞),可以做限時(shí)訂單
Kafka
很強(qiáng)大, 很強(qiáng)的技術(shù)維護(hù)
使用是簡單,需要強(qiáng)的開發(fā)團(tuán)隊(duì), JVM調(diào)優(yōu) 操作系統(tǒng)調(diào)優(yōu)
需要 大數(shù)據(jù),流計(jì)算 時(shí)用
一般就記記日志簡單用下
定義
其實(shí)并沒有標(biāo)準(zhǔn)定義。一般認(rèn)為:
分布式系統(tǒng)中一個(gè)子系統(tǒng)，
關(guān)注于數(shù)據(jù)的發(fā)送和接收，
利用高效可靠的異步消息傳遞機(jī)制對(duì)分布式系統(tǒng)中的其余各個(gè)子系統(tǒng)進(jìn)行集成。
關(guān)鍵:
- 高效: 一定要快
- 可靠: 持久化,不丟失
- 異步: 發(fā)成功了就行,不用一定等人收
為什么用
低耦合,擴(kuò)展性
不管是程序還是模塊之間，使用消息中間件進(jìn)行間接通信。
沒有mq是高耦合的, 要知道彼此
加入mq, 只管發(fā), 加了接收者的話 發(fā)送者不用改,不用知道
彼此有關(guān)系->只和mq關(guān)系
物流系統(tǒng)掛了, 交易系統(tǒng)也不會(huì)被影響
擴(kuò)展性: 增加新的業(yè)務(wù)產(chǎn)品時(shí)，不需改動(dòng)既有業(yè)務(wù)功
這是設(shè)計(jì)模式中的開閉原則（對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉）在架構(gòu)層面的一個(gè)原則。
異步
異步通信能力，使得子系統(tǒng)之間得以充分執(zhí)行自己的邏輯而無需等待。
發(fā)到mq就成功了, 不用等消費(fèi)者真的消費(fèi)完
使用場景: 讓用戶少等點(diǎn)時(shí)間, 優(yōu)化了, 因?yàn)榘l(fā)到mq就可以返回用戶完成了
如果通知用戶成功了, 后面的消費(fèi)者服務(wù)掛了, 沒成功怎么辦:
沒事,消息還在mq里面, 大不了加班, 最終事件還是能完成,不會(huì)丟, 只是異步的時(shí)間更久
緩沖
緩沖能力，消息中間件像是一個(gè)巨大的蓄水池，將高峰期大量的請(qǐng)求存儲(chǔ)下來慢慢交給后臺(tái)進(jìn)行處理，
對(duì)于秒殺業(yè)務(wù)來說尤為重要。
伸縮性
通過不斷向集群中加入服務(wù)器的
來緩解不斷上升的用戶并發(fā)訪問壓力和不斷增長的數(shù)據(jù)存儲(chǔ)需求。
不要了 ,可以拆掉
具體使用
- 異步,讓用戶減少等待
- 應(yīng)用解耦, 不會(huì)一個(gè)掛全部掛
-
日志系統(tǒng)
- 高效通訊: 純的消息通訊。點(diǎn)對(duì)點(diǎn)消息隊(duì)列，或者聊天室(同一個(gè)生產(chǎn)者)
-
削峰
不是mq,DB就撐不住掛了
和RPC 區(qū)別
這是RPC
對(duì)開發(fā)人員,看起來好像和單體調(diào)用本進(jìn)程的方法是一樣的
不同:
mq異步
-
RPC依賴性,mq松耦合
相同:
都是分布式下的 的通信方式
