redis提供了兩種方式來作訊息佇列。
乙個是使用生產者消費模式模式， 另乙個就是發布訂閱者模式。
前者會讓乙個或者多個客戶端監聽訊息佇列，一旦訊息到達，消費者馬上消費，誰先搶到算誰的，如果佇列裡沒有訊息，則消費者繼續監聽；』後者也是乙個或多個客戶端訂閱訊息頻道，只要發布者發布訊息，所有訂閱者都能收到訊息，訂閱者都是平等的。
1.訊息佇列和多執行緒兩者並不衝突，多執行緒可以作為佇列的生產者和消費者。
使用外部的訊息佇列時，第一是可以提高應用的穩定性，當程式fail後，寫入外部訊息佇列的資料依舊是儲存的，如果使用兩步commit的佇列的話，可以更加提高這個專案。
2.用執行緒的話，會占用主伺服器資源，訊息佇列的話，可以放到其他機器上執行，讓主伺服器盡量多的服務其他請求。
3.解耦更充分，架構更合理
多執行緒是在程式語言層面解決問題
訊息佇列是在架構層面解決問題
我認為架構層面解決問題是「覺悟比較高的方式「，理想情況下應該限制語言層面濫用多執行緒，能不用就不用。
4.用執行緒池executorservice非同步處理：我理解executorservice其實也是內部使用了佇列（如linkedblockingqueue），所以從設計上，其實和使用中介軟體的訊息佇列是差不多一致的。只是這裡應用伺服器既充當生產者又充當消費者，也是訊息佇列中介軟體的實現者。這種應該適合非分布式的架構，比如簡單的只有一台伺服器。
使用訊息佇列：訊息佇列（指activemq，rabbitmq，kafaka，redis等）因為一般都是中介軟體，部署在其他機器，需要一定的網路消耗。
本著解耦的目的，使用後者更合理，因為應用伺服器一般記憶體也不會太多，佇列長度不易太長。讓應用伺服器只處理邏輯比較合理。適合分布式架構。
1、可靠性
redis ：沒有相應的機制保證訊息的可靠消費，如果發布者發布一條訊息，而沒有對應的訂閱者的話，這條訊息將丟失，不會存在記憶體中；
rabbitmq：具有訊息消費確認機制，如果發布一條訊息，還沒有消費者消費該佇列，那麼這條訊息將一直存放在佇列中，直到有消費者消費了該條訊息，以此可以保證訊息的可靠消費.
2、實時性
redis:實時性高，redis作為高效的快取伺服器，所有資料都存在在伺服器中，所以它具有更高的實時性。
3、消費者負載均衡：
rabbitmq佇列可以被多個消費者同時監控消費，但是每一條訊息只能被消費一次，由於rabbitmq的消費確認機制，因此它能夠根據消費者的消費能力而調整它的負載；
redis發布訂閱模式，乙個佇列可以被多個消費者同時訂閱，當有訊息到達時，會將該訊息依次傳送給每個訂閱者；
4、永續性
redis：redis的持久化是針對於整個redis快取的內容，它有rdb和aof兩種持久化方式（redis持久化方式，後續更新），可以將整個redis例項持久化到磁碟，以此來做資料備份，防止異常情況下導致資料丟失。
rabbitmq：佇列，訊息都可以選擇性持久化，持久化粒度更小，更靈活；
5、佇列監控
rabbitmq實現了後台監控平台，可以在該平台上看到所有建立的佇列的詳細情況，良好的後台管理平台可以方便我們使用；
redis沒有所謂的監控平台。
6、出入隊效能
對於rabbitmq和redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。
測試資料分為128bytes、512bytes、1k和10k四個不同大小的資料。
實驗資料表明：
入隊時，當資料比較小時redis的效能要高於rabbitmq，而如果資料大小超過了10k，redis則慢的無法忍受；
出隊時，無論資料大小，redis都表現出非常好的效能，而rabbitmq的出隊效能則遠低於redis。
redis： 輕量級，低延遲，高併發，低可靠性；
rabbitmq：重量級，高可靠，非同步，不保證實時；
rabbitmq是乙個專門的amqp協議佇列，他的優勢就在於提供可靠的佇列服務，並且可做到非同步，而redis主要是用於快取的，redis的發布訂閱模組，可用於實現及時性，且可靠性低的功能。
所以專案中所採用的redis可能只是用於乙個輕量級的應用，只是用於簡單的發簡訊，郵件等通知，如果業務要進一步的擴充套件，如果需要訊息佇列的話，可能還需要用到專用的那些重量級的訊息中介軟體比如rabbitmq等，他們的高可靠，負載均衡這些特性都是redis所沒有的。
什麼情況下應該使用Web Service
現在我將列舉三種情況，在這三種情況下，你將會發現使用web service會帶來極大的好處。此後，我還會舉出不應該使用web service的一些情況。跨越防火牆的通訊 如果你的應用程式有成千上萬的使用者，而且他們都分布在世界各地，那麼客戶端和伺服器之間的通訊將是乙個棘手的問題。那是因為客戶端和伺服...
什麼情況下用遞迴？
遞迴的特點，可以看出遞迴可以大大縮短程式的 有意識的使用遞迴，可以用較短的 解決一些複雜的問題。甚至有些問題非得使用遞迴解決不可。那麼什麼時候我們該使用遞迴呢？遞迴演算法的 基本思想 是 把規模大的 較難解決的問題變成規模較小的 易解決的同一問題。規模較小的問題又變成規模更小的問題，並且小到一定程度...
layoutSubviews在什麼情況下呼叫
1.在以下情況都會呼叫 注意 當view的size的值為0的時候，addsubview也不會呼叫layoutsubviews。當要給這個view新增子控制項的時候不管他的size有沒有值都會呼叫 2.先來看一下uiview的layoutsubviews在什麼情況下會呼叫 subview view s...