場景：***時間內只能yyy次
在redis裡維護乙個數字型別的k-v，key的生成策略與頻控的維度有關，比如是使用者級的頻控，那麼key就是乙個userid；如果是總頻控，那麼key就是乙個string常量。
key的過期時間就是頻控的時間間隔，在建立key的時候設定過期時間。過頻控時，需要將key的計數值自增。
關於自增的時機：
第一種：先get再incr。
第二種：先incr再get。
這兩種都可以，看具體的場景。
如果過了頻控，後續的業務操作還有其他條件，不一定成功，這種需要用方案一。比如發獎勵，頻控只是一種條件，頻控沒問題，還需要判斷其他條件，比如冪等，預算等等，如果先incr，但是後續業務操作因為其他原因失敗了，也消耗了頻控的計數。對於這型別的場景，需要採用方案一，即先get判斷，操作成功後再incr。
如果後續業務操作沒有其他條件，可以採用方案二。比如api介面的頻控，只要有請求過來，就要消耗一次頻控計數。
優點：實現簡單，可以滿足一般的場景
缺點：1.由於incr和get不是原子的，所以頻控可能不准。如果是先incr，那麼可能會多攔掉一些請求。如果是先get，那麼可能會多放過一些請求；
2.只在時間段內滿足，比如要求是5分鐘內不超過10次。那麼相鄰的兩個5分鐘其實是兩個key，各管各的頻控。比如在第4分鐘時，訪問了9次，ok。緊接著在第六分鐘時也訪問了9次，也ok。在各自的時間段內，滿足頻控要求的，但是從業務上看，4-9分鐘這一段時間內，訪問了9+9=18次，是不滿足頻控要求的。這屬於方案本身的限制。
基於Redis的BloomFilter實戰
離線資料處理與實時資料處理有很大的不同，其中乙個例子就是去重。在聚資料中，訪問uv和購買uv都需要實時的去重。離線處理的時候，我們可以通過count groupby 或者count distinct 等方式比較容易的計算出uv，而且不用太擔心效能，大不了就是多一點map或者執行時間久一點。那麼在實時...
redis基於佇列實現的流控模型
前言 本文實現中使用的evalsha執行的lua，所以先描述下redis中eval和evalsha使用區別 基本語法如下 redis 127.0.0.1 6379 eval script numkeys key key arg arg 引數說明 script 引數是一段 lua 5.1 指令碼程式。...
基於redis的zSet集合做資料快取實現分頁查詢
最近公司要做手機頁面展示新聞文章資料查詢的優化工作，讓我提個優化方案。現狀是目前手機頁面的資料請求系統後台，系統後台然後呼叫其他系統的介面，返回分頁資料到前台展示，這樣一來，使用者每次下拉到頁面底部載入更多資料都要呼叫其他介面，使用者體驗顯然不是很好，那有沒有更好的方案呢？優化方案 redis正好適...