9.ActiveMQ理論

1、首先說下什麼是消息隊列?mysql

1.消息隊列是在消息的傳輸過程當中保存消息的容器。sql

2、爲何要用到消息隊列?數據庫

主要緣由是因爲在高併發環境下,因爲來不及同步處理,請求每每會發生堵塞,好比說,大量的insert,update之類的請求同時到達 MySQL ,直接致使無數的行鎖表鎖,甚至最後請求會堆積過多,從而觸發too many connections錯誤。經過使用消息隊列,咱們能夠異步處理請求,從而緩解系統的壓力。安全

3、消息隊列都分爲哪幾種?服務器

1. ActiveMQ/ApolloMQ多線程

優勢:老牌的消息隊列,使用Java語言編寫。對JMS支持最好,採用多線程併發,資源消耗比較大。若是你的主語言是Java,能夠重點考慮。架構

缺點:因爲歷史悠久,歷史包袱較多,版本更新很緩慢。集羣模式須要依賴Zookeeper實現。最新架構的產品被命名爲Apollo,號稱下一代ActiveMQ,目前案例較少。併發

2. RocketMQ/Kafka負載均衡

優勢:專爲海量消息傳遞打造,主張使用拉模式,自然的集羣、HA、負載均衡支持。話說仍是那句話,適合不適合看你有沒有那麼大的量。異步

缺點:所謂魚和熊掌不可兼得,放棄了一些消息中間件的靈活性,使用的場景較窄,需關注你的業務模式是否契合,不然山寨變相使用很彆扭。除此以外,RocketMQ沒有.NET下的客戶端可用。RocketMQ身出名門,但使用者很少,生態較小,畢竟消息量能達到這種體量的公司很少,你也能夠直接去購買阿里雲的消息服務。Kafka生態完善,其代碼是用Scala語言寫成,可靠性比RocketMQ低一些。

3. RabbitMQ

優勢:生態豐富,使用者衆,有不少人在前面踩坑。AMQP協議的領導實現,支持多種場景。淘寶的MySQL集羣內部有使用它進行通信,OpenStack開源雲平臺的通訊組件,最早在金融行業獲得運用。

缺點:Erlang代碼你Hold得住不? 雖然Erlang是自然集羣化的,但RabbitMQ在高可用方面作起來還不是特別駕輕就熟,別相信廣告。

 

 

背景知識點

JMS:Java Message Service Java消息服務

消息隊列:消息的傳輸過程當中保存消息的容器

消息隊列主要特色:異步處理

主要目的:減小請求響應時間和解耦

使用場景:將比較耗時並且不須要即時(同步)返回結果的操做做爲消息放入消息隊列

 

 

ActiceMQ相關概念
1.Destination

目的地,JMS Provider(消息中間件)維護,用於對Message進行管理的對象。

MessageProducer須要指定Destination才能發送消息,MessageConsumer須要指定Destination才能接收消息。

2.Producer

消息生成者(客戶端,生成消息),負責發送Message到目的地。應用接口爲MessageProducer

3.Consumer【Receiver】

消息消費者(處理消息),負責從目的地中消費【處理|監聽|訂閱】Message。應用接口爲MessageConsumer

4.Message

消息(Message),消息封裝一次通訊的內容。常見類型有:StreamMessage、BytesMessage、TextMessage、ObjectMessage、MapMessage。

5.ConnectionFactory
連接工廠, 用於建立連接的工廠類型。 注意,不能和 JDBC 中的 ConnectionFactory 混
淆。

6.Connection
連接. 用於創建訪問 ActiveMQ 鏈接的類型, 由連接工廠建立. 注意,不能和 JDBC 中的
Connection 混淆。

7.Session
會話, 一次持久有效有狀態的訪問. 由連接建立. 是具體操做消息的基礎支撐。

8.Queue&Topic

Queue是隊列目的地,Topic是主題目的地。都是Destination的子接口。

Queue特色:隊列中的消息,默認只能有惟一的一個消費者處理。

Topic特色:主題中的消息,會發送給全部的消費者同時處理。只有在消息能夠重複處理的業務場景中可以使用。

9.PTP

Point to Point。點對點消息模型,就是基於Queue實現的消息處理方式。

10.PUB&SUB

Publish&Subscribe。消息的發佈/訂閱模型。是基於Topic實現的消息處理方式。

PTP 和 PUB/SUB對比

 

 

地址的 sub 可以接收到消息;若是沒
有 sub 在監聽,該 topic 就丟失了。 |
| 消息發佈接受策略 | 一對一的消息發佈接受策略,一個sender發送的消息,只能有一個receiver接受。receiver接受完後,通知mq服務器已接受,mq服務器對queue裏的消息採起刪除或其餘操做 | 一對多的消息發佈接收策略,監聽同一個topic地址的多個sub都能收到publisher發送的消息。Sub接收完通知mq服務器 |

安全認證
暫時未用到,此處有待添加

持久化
1.kahadb方式

是 ActiveMQ 默認的持久化策略。kahadb 是一個文件型數據庫。是使用內存+文件保證
數據的持久化的。kahadb 能夠限制每一個數據文件的大小。不表明總計數據容量。

 

 

特性是:一、日誌形式存儲消息;二、消息索引以 B-Tree 結構存儲,能夠快速更新;三、
徹底支持 JMS 事務;四、支持多種恢復機制;

2.AMQ方式(過期不推薦)

3.JDBC持久化

下述文件爲 activemq.xml 配置文件部份內容。不要徹底複製。
首先定義一個 mysql-ds 的 MySQL 數據源,而後在 persistenceAdapter 節點中配置
jdbcPersistenceAdapter 而且引用剛纔定義的數據源。

dataSource 指定持久化數據庫的 bean,createTablesOnStartup 是否在啓動的時候建立數
據表,默認值是 true,這樣每次啓動都會去建立數據表了,通常是第一次啓動的時候設置爲
true,以後改爲 false。

 

 

相關表介紹:

activemq_msgs

用於存儲消息,Queue 和 Topic 都存儲在這個表中:
ID:自增的數據庫主鍵
CONTAINER:消息的 Destination
MSGID_PROD:消息發送者客戶端的主鍵
MSG_SEQ:是發送消息的順序,MSGID_PROD+MSG_SEQ 能夠組成 JMS 的 MessageID
EXPIRATION:消息的過時時間,存儲的是從 1970-01-01 到如今的毫秒數
MSG:消息本體的 Java 序列化對象的二進制數據
PRIORITY:優先級,從 0-9,數值越大優先級越高
activemq_acks

用於存儲訂閱關係。若是是持久化 Topic,訂閱者和服務器的訂閱關係在這個表保存:
主要的數據庫字段以下:
CONTAINER:消息的 Destination
SUB_DEST:若是是使用 Static 集羣,這個字段會有集羣其餘系統的信息
CLIENT_ID:每一個訂閱者都必須有一個惟一的客戶端 ID 用以區分
SUB_NAME:訂閱者名稱
SELECTOR:選擇器,能夠選擇只消費知足條件的消息。條件能夠用自定義屬性實現,
可支持多屬性 AND 和 OR 操做
LAST_ACKED_ID:記錄消費過的消息的 ID。
activemq_lock

在集羣環境中才有用,只有一個 Broker 能夠得到消息,稱爲 Master Broker,其餘的只能做爲備份等待 Master Broker 不可用,纔可能成爲下一個 Master Broker。這個表用於記錄哪一個 Broker 是當前的 Master Broker。只有在消息必須保證有效,且絕對不能丟失的時候。使用 JDBC 存儲策略。若是消息能夠容忍丟失,或使用集羣/主備模式保證數據安全的時候,建議使用 levelDB或 Kahadb。

 

————————————————版權聲明:本文爲CSDN博主「MaybeJ」的原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處連接及本聲明。原文連接:https://blog.csdn.net/qq_39905910/article/details/86447368

相關文章
相關標籤/搜索