在搜尋的時候，商品已經修改了，跟我門搜尋的東西不一緻，這是不合适的，這得同步redis.
還有就是更改商品，動态頁面也要變，什麼時候更改索引庫？
稽核過的時候更改？還是上下架的時候更改？
最終上下架的時候更改，因為商家稽核之後，還有一個環節就是商品的上下架。
1.不管上架還是下架都得修改 商品 的狀态都得修改is_markertble：
2.同步更新（添加或修改） solr索引庫
3.同步更新（同步或修改）靜态頁面
如下圖所示，在商品管理的頁面上，需要 增加如下功能，并且 需要依靠三個依賴，倘若直接添加依賴，就會導緻耦合性太高，是以 需要怎麼做？
而且下面這個圖，如果第一個方法不執行成功，第二個方法就不會執行，那麼太降低效率了！
怎麼解決？
這三個方法都需要在一個方法内需要做的事，而且如下圖一樣，每個方法都需要時間，是以 怎麼想辦法，告訴頁面修改成功 ？而不用等到用的時候再去檢視頁面有沒有修改成功，再去繼續下一步操作 ？
經過上面的問題剖析：我們需要解決的問題，就是降低耦合，改變原來的同步消息 為異步消息。
是以引出來一項技術：消息隊列，什麼是消息隊列？
消息隊列中間件是分布式系統中的重要的元件，主要解決應用耦合，異步消息，流量削峰。實作高可用可伸縮和最終一緻性的架構。
使用較多的消息隊列有ActiveMQ等。
應用舉例：
經過 分析，将上面的三個同步并且耦合性較高的方法改造成如下圖所示：
下面就是到了怎麼應用ActiveMQ？
我們先暫時的把ActiveMQ了解成存儲消息的一個經典軟體。
繼續分析：就是我們 先暫時把注冊成功的資訊放入到消息對列中，放入到mq中後，就可以直接響應給使用者了，這樣使用者就可以用55ms的時間得到注冊成功或者注冊失敗的消息。
然後發送郵件和發送短信什麼時候發送呢？
我們需要再寫兩個功能，一個寫發送郵件，一個寫發送短信。
發送郵件的這個的這個功能，隻要 一看到MQ中有消息，就取出來，并且消費掉（所謂的消費就是執行自己的功能）。
那麼再繼續分析下去，如果發送郵件失敗也不會影響使用者的注冊成功。
如果郵件發送失敗，那麼就該異常寫入日志，如果失敗的話，就再繼續發送。
那麼這樣解決的話 ，就會大大的提高我們的效率。
接下來我們再解析流量削峰
如果秒殺活動中，一下湧入進來10萬個請求，怎麼解決 ？
就是 我們把秒殺需要的100個請求，放入隊列中，我們慢慢處理，其餘的請求就不管了！
以這樣的方法區解決流量削峰的高并發問題。
就比如地鐵高峰，人來的再多，那也得放入排隊中挨着解決。
然後我們回到我們最原始的那個問題中：
我們把同步更新的任務，直接放入到Mq中，讓MQ去做。同時，那麼shop_web也不用引入右下邊的兩個service項目了。看下圖分析
然後在MQ中釋出訂閱模式，去讓search方法和itempage_service監控着Mq，然後去取，并且消費！
當然這樣做的好處就是，我們也不用再去王shop_web中寫入依賴，那麼也同時降低了耦合性，并且把同步消息改成了異步消息！大大提高了效率！
JMS規範
然後我們提到了這個MQ,因為有很多MQ類似的軟體，我們用的ActiveMQ這個軟體，但是我們都得遵守這個麼JMS規範。這個JMS是操作Mq的，于是提供了一個操作Mq的一個接口。
它準備了兩個模式：
Point to Point
釋出訂閱模式
問題
1、點對點模式，消費者那端代碼執行過程中出異常了怎麼處理？
一定要捕獲異常，放到log中，并且放到表中，然後有我們開發人員解決。