Redis 中如何根據兩個字段排序
Redis 是一個內存型數據庫，其最大的作用就是當做緩存使用。提供了幾種數據類型，方便開發(fā)過程中應對不同的需求場景。
需求是這樣的，有一些需要排序的數據，按照不止一個維度進行排序，對應到數據庫里，就是按照兩個字段進行綜合排序，那在 Redis 中應該使用哪種數據結構呢?
按單一字段排序
首先我們先把問題簡化一下，按照一個字段進行排序，看看應該怎么實現。
排行榜場景很常見，比如歷史數據排行榜、熱度排行榜(微博熱搜、知乎熱榜等、B站熱門等等)，根據播放量進行排序，那針對這樣的場景，使用 Redis 怎么解決呢?
我們首先忽略掉實時更新的問題，假設是昨日榜單，數據已經確定了的，不會改變。
解決方案
列表
有人立馬想到用列表方式解決，因為列表本身就是有序的，所以把榜單以 Lists 的形式放到 Redis 中，查詢的時候直接取 列表就好了，什么都不用管了。
這種方案就是把 Redis 純粹當做緩存使用，存什么取什么，其他額外的動作一概沒有。
但是這種方案的缺陷也在于此，存進來的數據就已經是排序好的數據，所以，這個排序邏輯要在外部程序中提前寫好，然后將排序好的數據存進去。
那如果外部程序不對榜單進行排序，或者說條件不允許的情況怎么辦呢?那列表就沒辦法了。
有序集合 sorted set
sorted set 是在 Sets 的基礎上增加了分數設置作為排序依據，所以除了具備 Sets 的特性外，還可以進行排序。
它提供了一個 score 屬性，正好可以用來做排序依據，對榜單類的需求完美匹配。
- # 按分數從小到大排序
- ZRANGE key start stop [WITHSCORES]
- # 按分數從大到小排序
- ZREVRANGE key start stop [WITHSCORES]
使用 sorted set 就可以降低外部程序的復雜度了，程序中不用對榜單進行排行了，只需要將符合入榜條件的記錄拿出來，存到 sorted set 中就可以了。
在 sorted set 結構中，就用訪問量當做分數，查詢的時候執(zhí)行 ZREVRANGE 命令就可以了。
按兩個字段排序
現在需求變了一下，排序的維度有所變化，加了一個維度。還比如說熱度排行榜吧，之前按訪問量排序，現在增加了按照訪問量和評論量總和排序，反應到數據庫上是這樣的：
- select * from post order by read_count,comment_count desc
這種情況下怎么做呢?
解決方案
當然還可以用列表
仍然還可以用列表實現，邏輯都不變，只要改變外部程序的查詢邏輯就可以了，之前按一個字段排序，現在按兩個來。
有序集合 sorted set
我們知道 sorted set 中只有一個 score 屬性，那怎么用這一個屬性實現兩個維度的排序呢?
這就需要在 score 屬性上做文章了，最簡單的實現，可以將訪問量+評論數的和作為 score。
但是這樣精度上太細了，如果訪問量足夠大，比如上百萬的訪問量，那幾千個評論數也就幾乎可以忽略不計了，最后實際的排序還是按照訪問量來的。但是在小訪問量上其實就可以用這種方式。
比如，訪問量有 9000、8500 的兩個文章，它倆的評論量分別為 100 和 700，那最后加起來的結果就是 9100 和 9200，所以，最后的排序結果實際上是閱讀量 8500 的排在前面。
如果訪問量過大的話，可以提高評論的權重，比如一個評論量等于 100或者1000 個閱讀量。
還可以降低閱讀量的精度，比如以萬、十萬為單位，如果以十萬為精度，那 111萬和 119萬就都按 110萬來算。
實時榜單
除了一些歷史數據榜單外， 還有很多榜單都是實時的，這種情況下就要保證 redis 中的數據是實時更新的。
那如果是實時更新的情況，用列表存儲就不合適了，讀寫 redis 是為了追求高性能，如果還用列表存儲就意味著外部程序要做實時的排序、更新 redis 操作，可想而知，那樣外部程序根本無法做到實時更新，或者代價極大。
所以，就要靠 sorted set 來解決了，可以使用 ZINCRBY命令快速更新 sorted 中的元素的分數，比如視頻的播放量更新的時候通過更新 redis 中的值，因為更新 redis 的速度是非常快的，所以可以實現播放量的實時更新。
- ZINCRBY key increment member
因為依靠的是 sorted set 中的分數來排序，所以，當成員的分數更新了之后，查詢出來的排行信息就是實時的榜單了。
本文轉載自微信公眾號「古時的風箏」，可以通過以下二維碼關注。轉載本文請聯(lián)系古時的風箏公眾號。
