1. 起因， 隨著twitter sina微博，騰訊微博的開放平臺相繼推出, 大部分和互聯網相關的公司又多了一個營銷的手段：信息同步。也即是用戶把自己的新浪微博賬號或者騰訊微博賬號和你的網站關聯起來了，用戶在你的網站產生的 任何信息都可以同步發送到sina微博，qq微博上去（前提是經過用戶的允許，這樣用戶既可以不需要同樣的信息復制到多個網站， 又可以相應的推廣你的網站的入口曝光率）。目前同步比較好的例子是：微博通，街旁，切客等。
2. 為什么要用緩沖隊列服務，我們舉個例子。如果你做了一個網站，用戶在你的網站上關聯了sina微博，QQ微博，開心網，人人網， 豆瓣，twitter, facebook（可能還要在國外設置代理）等等第三方平臺，用戶產生了一個動作后（比如發了一條心情狀態），你的網站要同時同步到這些網站去，每個第三 方平臺都要經過多次外網http請求，所有的這些請求加起來是可能是很長的時間(幾秒， 甚至幾十秒)，這對于前段用戶肯定肯定是無法忍受的。所以這個時候同步信息的話必須采取異步的方式，也就是用戶在你的網站發表一個狀態服務端只是把這條狀 體對應的信息存儲起來， 然后就提示用戶發表成功， 具體的信息同步是后端以腳本的方式異步運行的。用戶通俗的話來說就是用戶先發表后同步，由于校本執行速度很快， 用戶幾乎感覺不出來同步的時間差。你也許會問我怎么知道哪些信息要同步到第三方平臺去呢，這也就是使用redis使用緩沖隊列服務器的原因，當用戶發表信 息后，我們同事把信息寫入緩沖隊列服務器，后臺腳本會不停的去檢查緩沖隊列服務器是否有數據，如果有數據則取出發送到第三方開放平臺。
3. 系統擴展性
a). 如果腳本處理過慢，可能造成緩沖隊列擁堵，我們可能通過擴展后臺腳本個數來加快同步到第三方平臺的處理速度。
b). 如果需要同步的信息量過大, 造成寫入隊列的并發數極大，肯能通過擴展隊列服務來達到分散減壓的目的(基本不會出現)。
5. 效率如何 假設你的網站每天產生100W條信息 需要同步到第三方平臺。
redis官方測試數據（SET操作每秒鐘 110000 次，GET操作每秒鐘 81000 次）。
一個腳本每天的同步量, 86400/2 = 43200, (假設平均每同步一條信息花費時間為2s，) 一個腳本每天大概可以同步4W條數據。
平均每秒同步的數據 100W/86400 < 12個 高峰時期擴大十倍也就是每秒 120條信息。由此可見每天100W 甚至 1000W的信息同步量對redis來說都是沒有任何壓力的。
我們只需要加快腳本處理的速度即可， 100W數據只需要同事25個腳本負責同步即可，（數據量增加了，擴展起來非常方面）。
總結，此方式已經應用于國內某LBS社區，每天的PV大概300W，產生的信息同步量每天大概2W左右。當前是2個腳本負責同步相關操作，隊列里面基本沒有任何擁堵信息。