一：緩存——熱數據前端
熱點數據（常常會被查詢，可是不常常被修改或者刪除的數據），首選是使用redis緩存，畢竟強大到冒泡的QPS和極強的穩定性不是全部相似工具都有的，並且相比於memcached還提供了豐富的數據類型可使用，另外，內存中的數據也提供了AOF和RDB等持久化機制能夠選擇，要冷、熱的仍是忽冷忽熱的均可選。mysql
結合具體應用須要注意一下：不少人用spring的AOP來構建redis緩存的自動生產和清除，過程可能以下：redis
-
Select 數據庫前查詢redis，有的話使用redis數據，放棄select 數據庫，沒有的話，select 數據庫，而後將數據插入redisspring
-
update或者delete數據庫錢，查詢redis是否存在該數據，存在的話先刪除redis中數據，而後再update或者delete數據庫中的數據sql
上面這種操做，若是併發量很小的狀況下基本沒問題，可是高併發的狀況請注意下面場景：數據庫
爲了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）
最近在研究股票，發現量化交易是個很是好的辦法，經過臆想出來規律，用程序對歷史數據進行驗證，來判斷這個臆想出來的規律是否有效，這玩意真牛！有沒有哪位玩這個的給我留個言，交流一下唄。