1.

訊息佇列和多執行緒兩者並不衝突，多執行緒可以作為佇列的生產者和消費者。使用外部的訊息佇列時，第一是可以提高應用的穩定性，當程式fail後，寫入外部訊息佇列的資料依舊是儲存的，如果使用兩步commit的佇列的話，可以更加提高這個專案。

2.

用執行緒的話，會佔用主伺服器資源，訊息佇列的話，可以放到其他機器上執行，讓主伺服器儘量多的服務其他請求。

3.

解耦更充分，架構更合理多執行緒是在程式語言層面解決問題訊息佇列是在架構層面解決問題我認為架構層面解決問題是“覺悟比較高的方式“，理想情況下應該限制語言層面濫用多執行緒，能不用就不用

4.

用執行緒池ExecutorService非同步處理：我理解ExecutorService其實也是內部使用了佇列（如LinkedBlockingQueue），所以從設計上，其實和使用中間價的訊息佇列是差不多一致的。只是這裡應用伺服器

使用訊息佇列：訊息佇列（指activeMQ，rabbitMQ，kafaKa，Redis等）因為一般都是中介軟體，部署在其他機器，需要一定的網路消耗。

本著解耦的目的，使用後者更合理，因為應用伺服器一般記憶體也不會太多，佇列長度不易太長。讓應用伺服器只處理邏輯比較合理。適合分散式架構。

將redis釋出訂閱模式用做訊息佇列和rabbitmq的區別：

·        可靠性

·        redis ：沒有相應的機制保證訊息的可靠消費，如果釋出者釋出一條訊息，而沒有對應的訂閱者的話，這條訊息將丟失，不會存在記憶體中；

·        rabbitmq：具有訊息消費確認機制，如果釋出一條訊息，還沒有消費者消費該佇列，那麼這條訊息將一直存放在佇列中，直到有消費者消費了該條訊息，以此可以保證訊息的可靠消費.

實時性

·        redis:實時性高，redis作為高效的快取伺服器，所有資料都存在在伺服器中，所以它具有更高的實時性

消費者負載均衡：

·        rabbitmq佇列可以被多個消費者同時監控消費，但是每一條訊息只能被消費一次，由於rabbitmq的消費確認機制，因此它能夠根據消費者的消費能力而調整它的負載；

·        redis釋出訂閱模式，一個佇列可以被多個消費者同時訂閱，當有訊息到達時，會將該訊息依次傳送給每個訂閱者；

永續性

·        redis：redis的持久化是針對於整個redis快取的內容，它有RDB和AOF兩種持久化方式（redis持久化方式，後續更新），可以將整個redis例項持久化到磁碟，以此來做資料備份，防止異常情況下導致資料丟失。

·        rabbitmq：佇列，訊息都可以選擇性持久化，持久化粒度更小，更靈活；

佇列監控

·        rabbitmq實現了後臺監控平臺，可以在該平臺上看到所有建立的佇列的詳細情況，良好的後臺管理平臺可以方面我們更好的使用；

·        redis沒有所謂的監控平臺。

出入隊效能

對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試資料分為128Bytes、512Bytes、1K和10K四個不同大小的資料。實驗表明：入隊時，當資料比較小時Redis的效能要高於RabbitMQ，而如果資料大小超過了10K，Redis則慢的無法忍受；出隊時，無論資料大小，Redis都表現出非常好的效能，而RabbitMQ的出隊效能則遠低於Redis。

·        

總結

·        redis：       輕量級，低延遲，高併發，低可靠性；

·        rabbitmq：重量級，高可靠，非同步，不保證實時；

·        rabbitmq是一個專門的AMQP協議佇列，他的優勢就在於提供可靠的佇列服務，並且可做到非同步，而redis主要是用於快取的，redis的釋出訂閱模組，可用於實現及時性，且可靠性低的功能。

所以專案中所採用的Redis可能只是用於一個輕量級的應用。只是用於簡單的發簡訊，郵件等通知，如果業務要進一步的擴充套件，如果需要訊息佇列的話，可能還需要用到專用的那些重量級的訊息中介軟體比如rabbitmq等，他們的高可靠，負載均衡這些特性都是Redis所沒有的。