商城-RabbitMQ及消息同步-RabbitMQ
- 1.RabbitMQ
-
- 1.1.搜尋與商品服務的問題
- 1.2.消息隊列（MQ）
-
- 1.2.1.什麼是消息隊列
- 1.2.2.AMQP和JMS
- 1.2.3.常見MQ産品
- 1.2.4.RabbitMQ
- 1.3.下載下傳和安裝
-
- 1.3.1.下載下傳
- 1.3.2.安裝
1.RabbitMQ
1.1.搜尋與商品服務的問題
目前我們已經完成了商品詳情和搜尋系統的開發。我們思考一下，是否存在問題？
- 商品的原始資料儲存在資料庫中，增删改查都在資料庫中完成。
- 搜尋服務資料來源是索引庫，如果資料庫商品發生變化，索引庫資料不能及時更新。
- 商品詳情做了頁面靜态化，靜态頁面資料也不會随着資料庫商品發生變化。
如果我們在背景修改了商品的價格，搜尋頁面和商品詳情頁顯示的依然是舊的價格，這樣顯然不對。該如何解決？
這裡有兩種解決方案：
- 方案1：每當背景對商品做增删改操作，同時要修改索引庫資料及靜态頁面
- 方案2：搜尋服務和商品頁面服務對外提供操作接口，背景在商品增删改後，調用接口
以上兩種方式都有同一個嚴重問題：就是代碼耦合，背景服務中需要嵌入搜尋和商品頁面服務，違背了微服務的
獨立
原則。
是以，我們會通過另外一種方式來解決這個問題：消息隊列
1.2.消息隊列（MQ）
1.2.1.什麼是消息隊列
消息隊列，即MQ，Message Queue。
消息隊列是典型的：生産者、消費者模型。生産者不斷向消息隊列中生産消息，消費者不斷的從隊列中擷取消息。因為消息的生産和消費都是異步的，而且隻關心消息的發送和接收，沒有業務邏輯的侵入，這樣就實作了生産者和消費者的解耦。
結合前面所說的問題：
- 商品服務對商品增删改以後，無需去操作索引庫或靜态頁面，隻是發送一條消息，也不關心消息被誰接收。
- 搜尋服務和靜态頁面服務接收消息，分别去處理索引庫和靜态頁面。
如果以後有其它系統也依賴商品服務的資料，同樣監聽消息即可，商品服務無需任何代碼修改。
1.2.2.AMQP和JMS
MQ是消息通信的模型，并不是具體實作。現在實作MQ的有兩種主流方式：AMQP、JMS。
兩者間的差別和聯系：
- JMS是定義了統一的接口，來對消息操作進行統一；AMQP是通過規定協定來統一資料互動的格式
- JMS限定了必須使用Java語言；AMQP隻是協定，不規定實作方式，是以是跨語言的。
- JMS規定了兩種消息模型；而AMQP的消息模型更加豐富
1.2.3.常見MQ産品
- ActiveMQ：基于JMS
- RabbitMQ：基于AMQP協定，erlang語言開發，穩定性好
- RocketMQ：基于JMS，阿裡巴巴産品，目前交由Apache基金會
- Kafka：分布式消息系統，高吞吐量
1.2.4.RabbitMQ
RabbitMQ是基于AMQP的一款消息管理系統
官網： http://www.rabbitmq.com/
官方教程：http://www.rabbitmq.com/getstarted.html
1.3.下載下傳和安裝
1.3.1.下載下傳
官網下載下傳位址：http://www.rabbitmq.com/download.html
目前最新版本是：3.7.5
我們的課程中使用的是：3.4.1版本
課前資料提供了安裝包：
1.3.2.安裝
詳見課前資料中的：