標籤:use 支援 問題 oop 開發環境 mit 計數器 日誌 活性
Redis在很多方面與其他資料庫解決方案不同:它使用記憶體提供主儲存支援,而僅使用硬碟做持久性的儲存;它的資料模型非常獨特,用的是單線程。另一個大區別在於,你可以在開發環境中使用Redis的功能,但卻不需要轉到Redis。轉向Redis當然也是可取的,許多開發人員從一開始就把Redis作為首選資料庫;但設想如果你的開發環境已經搭建好,應用已經在上面運行了,那麼更換資料庫架構顯然不那麼容易。另外在一些需要大容量資料集的應用,Redis也並不適合,因為它的資料集不會超過系統可用的記憶體。所以如果你有大資料應用,而且主要是讀取存取模式,那麼Redis並不是正確的選擇。
然而我喜歡Redis的一點就是你可以把它融入到你的系統中來,這就能夠解決很多問題,比如那些你現有的資料庫處理起來感到緩慢的任務。這些你就可以通過Redis來進行最佳化,或者為應用建立些新的功能。在本文中,我就想探討一些怎樣將Redis加入到現有的環境中,並利用它的原語命令等功能來解決 傳統環境中碰到的一些常見問題。在這些例子中,Redis都不是作為首選資料庫。
1、顯示最新的項目列表
下面這個語句常用來顯示最新項目,隨著資料多了,查詢毫無疑問會越來越慢。
SELECT * FROM foo WHERE ... ORDER BY time DESC LIMIT 10
在Web應用中,“列出最新的回複”之類的查詢非常普遍,這通常會帶來可擴充性問題。這令人沮喪,因為項目本來就是按這個順序被建立的,但要輸出這個順序卻不得不進行排序操作。
類似的問題就可以用Redis來解決。比如說,我們的一個Web應用想要列出使用者貼出的最新20條評論。在最新的評論邊上我們有一個“顯示全部”的連結,點擊後就可以獲得更多的評論。
頻繁的查詢資料庫,肯定是很慢的,我們可以當使用者插入一條資料,lpush進隊列 主鍵ID,需要保留最新的20條,我們截斷隊列,ltrim 隊列名 0 20,
這樣,總是保留最新的20條主鍵ID,然後根據主鍵直接命中資料庫,很快,當然如果不是大的資料,我們可以直接緩衝到redis中,用hash,或者set
2.熱門排行榜相關
另一個很普遍的需求是各種資料庫的資料並非儲存在記憶體中,因此在按得分排序以及即時更新這些幾乎每秒鐘都需要更新的功能上資料庫的效能不夠理想。
即時變化的資料不可能使用緩衝,但是頻繁的操作DB會增加資料庫的負擔,這時候考慮記憶體。
典型的比如那些線上遊戲的熱門排行榜,比如一個Facebook的遊戲,根據得分你通常想要:
- 列出前100名高分選手
- 列出某使用者當前的全球排名
這些操作對於Redis來說小菜一碟,即使你有幾百萬個使用者,每分鐘都會有幾百萬個新的得分。
模式是這樣的,每次獲得新得分時,我們用這樣的代碼:
模式是這樣的,每次獲得新得分時,我們用這樣的代碼:
ZADD leaderboard <score> <username>
你可能用userID來取代username,這取決於你是怎麼設計的。
得到前100名高分使用者很簡單:ZREVRANGE leaderboard 0 99。
使用者的全球排名也相似,只需要:ZRANK leaderboard <username>。
3計數
Redis是一個很好的計數器,這要感謝INCRBY和其他相似命令。
我相信你曾許多次想要給資料庫加上新的計數器,用來擷取統計或顯示新資訊,但是最後卻由於寫入敏感而不得不放棄它們。
好了,現在使用Redis就不需要再擔心了。有了原子遞增(atomic increment),你可以放心的加上各種計數,用GETSET重設,或者是讓它們到期。
例如這樣操作:
INCR user:<id> EXPIRE
user:<id> 60
你可以計算出最近使用者在頁面間停頓不超過60秒的頁面瀏覽量,當計數達到比如20時,就可以顯示出某些條幅提示,或是其它你想顯示的東西
4隊列
你應該已經注意到像list push和list pop這樣的Redis命令能夠很方便的執行隊列操作了,但能做的可不止這些:比如Redis還有list pop的變體命令,能夠在列表為空白時阻塞隊列。
現代的互連網應用大量地使用了訊息佇列(Messaging)。訊息佇列不僅被用於系統內部組件之間的通訊,同時也被用於系統跟其它服務之間的互動。訊息佇列的使用可以增加系統的可擴充性、靈活性和使用者體驗。非基於訊息佇列的系統,其運行速度取決於系統中最慢的組件的速度(註:短板效應)。而基於訊息佇列可以將系統中各組件解除耦合,這樣系統就不再受最慢組件的束縛,各組件可以非同步運行從而得以更快的速度完成各自的工作。
此外,當伺服器處在高並行作業的時候,比如頻繁地寫入記錄檔。可以利用訊息佇列實現非同步處理。從而實現高效能的並行作業
redis應用情境