卑微小吳勵志寫博客第23天。
前面學習了redis的五種數據類型，也給出了很多案例，但是都是單一的針對一種數據類型的案例。
業務場景一：
人工智能領域的語義識別和自動對話將是未來服務業機器人應答呼叫體系中的重要技術，百度自研的用戶語義評價服務，免費給企業試用，同時訓練百度自己的模型。現對試用用戶的使用行爲進行限速，限制每個用戶每分鐘最多發起十次調用。
解決方案
- 設計一個計數器，用於控制調用次數，就是統計客戶調用過的次數。用戶id作爲key，調用次數作爲value。
- 在調用前獲取次數，用於判斷是否超過限定次數。
不超過次數，調用次數+1。
業務調用失敗，計數-1. - 爲計數器設置生命週期，例如1分鐘，自動清空週期內使用次數。
setex key timeout value 命令就可以完成上面的設置。
例如： setex user:001 60 1
每次調用 incr user:001
解決方案改良
這樣做，每次都要判斷用戶的次數是不是大於10。怎樣可以讓用戶不用每次都判斷？
- 取消最大值的判定，利用incr操作超過最大值拋出異常的形式，來取消每次都判定最大值。
- 判斷是否爲nil，如果是，value設置爲MAX-次數，如果不是，計數+1，業務調用失敗，計數-1。
- 遇到異常則達到次數上限。
因爲value的值設置時是有大小限制的，我們去最大值作爲判斷的依據，這樣就可以不用每次都去判斷次數是否達到。
業務場景二：
使用微信的時候，接受到的消息一般都是時間最近的放在前面，當多個好友或者訂閱號同時發消息，排名會不斷更換。同時還有置頂功能。一旦用戶離線後，再次上線的時候消息應該按照怎樣的順序展示？
解決方案：
- 利用list的數據具有順序的特徵對消息進行管理，將list結構作爲棧使用。
- 對置頂與普通會話分別創建獨立的list分別管理。
- 當某個list中接收到用戶消息後，將消息發送方的id從list的一側加入list（此處設定爲左側）
- 多個相同id發出的消息，先在棧中刪除，然後再入棧。
- 推送消息時先推送置頂list，再推送普通會話list。
- 這裏面還可以做計數功能，也就是微信用戶對話數量，採用計數器的思想另行記錄，伴隨list操作同步更新。
tips:
redis可以應用於基於時間順序的數據操作，而不關注具體時間。
