redis list應用–大型網站緩衝隊列服務器

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個腳本負責同步相關操做，隊列裏面基本沒有任何擁堵信息。