# Redis的7個應用場景 一：緩存——熱數據 熱點數據（經常會被查詢，但是不經常被修改或者刪除的數據），首選是使用redis緩存，畢竟強大到冒泡的QPS和極強的穩定性不是所有類似工具都有的，而且相比于memcached還提供了豐富的數據類型可以使用，另外，內存中的數據也提供了AOF和RDB等持久化機制可以選擇，要冷、熱的還是忽冷忽熱的都可選。 結合具體應用需要注意一下：很多人用spring的AOP來構建redis緩存的自動生產和清除，過程可能如下： Select 數據庫前查詢redis，有的話使用redis數據，放棄select 數據庫，沒有的話，select 數據庫，然后將數據插入redis update或者delete數據庫錢，查詢redis是否存在該數據，存在的話先刪除redis中數據，然后再update或者delete數據庫中的數據 上面這種操作，如果并發量很小的情況下基本沒問題，但是高并發的情況請注意下面場景： 為了update先刪掉了redis中的該數據，這時候另一個線程執行查詢，發現redis中沒有，瞬間執行了查詢SQL，并且插入到redis中一條數據，回到剛才那個update語句，這個悲催的線程壓根不知道剛才那個該死的select線程犯了一個彌天大錯！于是這個redis中的錯誤數據就永遠的存在了下去，直到下一個update或者delete。 二：計數器 諸如統計點擊數等應用。由于單線程，可以避免并發問題，保證不會出錯，而且100%毫秒級性能！爽。 命令：INCRBY 當然爽完了，別忘記持久化，畢竟是redis只是存了內存！ 三：隊列 相當于消息系統，ActiveMQ，RocketMQ等工具類似，但是個人覺得簡單用一下還行，如果對于數據一致性要求高的話還是用RocketMQ等專業系統。 由于redis把數據添加到隊列是返回添加元素在隊列的第幾位，所以可以做判斷用戶是第幾個訪問這種業務 隊列不僅可以把并發請求變成串行，并且還可以做隊列或者棧使用 四：位操作（大數據處理） 用于數據量上億的場景下，例如幾億用戶系統的簽到，去重登錄次數統計，某用戶是否在線狀態等等。 想想一下騰訊10億用戶，要幾個毫秒內查詢到某個用戶是否在線，你能怎么做？千萬別說給每個用戶建立一個key，然后挨個記（你可以算一下需要的內存會很恐怖，而且這種類似的需求很多，騰訊光這個得多花多少錢。。）好吧。這里要用到位操作——使用setbit、getbit、bitcount命令。 原理是： redis內構建一個足夠長的數組，每個數組元素只能是0和1兩個值，然后這個數組的下標index用來表示我們上面例子里面的用戶id（必須是數字哈），那么很顯然，這個幾億長的大數組就能通過下標和元素值（0和1）來構建一個記憶系統，上面我說的幾個場景也就能夠實現。用到的命令是：setbit、getbit、bitcount 五：分布式鎖與單線程機制 驗證前端的重復請求（可以自由擴展類似情況），可以通過redis進行過濾：每次請求將request Ip、參數、接口等hash作為key存儲redis（冪等性請求），設置多長時間有效期，然后下次請求過來的時候先在redis中檢索有沒有這個key，進而驗證是不是一定時間內過來的重復提交 秒殺系統，基于redis是單線程特征，防止出現數據庫“爆破” 全局增量ID生成，類似“秒殺” 六：最新列表 例如新聞列表頁面最新的新聞列表，如果總數量很大的情況下，盡量不要使用select a from A limit 10這種low貨，嘗試redis的 LPUSH命令構建List，一個個順序都塞進去就可以啦。不過萬一內存清掉了咋辦？也簡單，查詢不到存儲key的話，用mysql查詢并且初始化一個List到redis中就好了。 七：排行榜 誰得分高誰排名往上。命令：ZADD（有續集，sorted set） 最近在研究股票，發現量化交易是個非常好的辦法，通過臆想出來規律，用程序對歷史數據進行驗證，來判斷這個臆想出來的規律是否有效，這玩意真牛！有沒有哪位玩這個的給我留個言，交流一下唄。