redis(13):排序-有解無憂

已經知道可以使用集合型別來存盤文章標簽資料，但是如果想要標簽排序呢？

一、有序集合的集合操作

集合型別提供了強大的集合操作命令，但是如果需要排序就要用到有序集合型別，Redis 的作者在設計Redis的命令時考慮到了不同資料型別的使用場景，對于不常用到的或者在不損失過多性能的前提下可以使用現有命令來實作的功能，Redis就不會單獨提供命令來實作，這一原則使得Redis在擁有強大功能的同時保持著相對精簡的命令，

有序集合常見的使用場景是大資料排序，如游戲的玩家排行榜，所以很少會需要獲得鍵中的全部資料，同樣 Redis 認為開發者在做完交集、并集運算后不需要直接獲得全部結果，而是會希望將結果存入新的鍵中以便后續處理，這解釋了為什么有序集合只有 ZINTERSTORE和ZUNIONSTORE命令而沒有ZINTER和ZUNION命令，

當然實際使用中確實會遇到需要直接獲得集合運算結果的情況，除了等待 Redis 加入相關命令，我們還可以使用 MULTI, ZINTERSTORE, ZRANGE, DEL和 EXEC這5 個命令自己實作ZINTER：

MULTI 
ZINTERSTORE tempKey ... 
ZRANGE tempKey ... 
DEL tempKey 
EXEC

二、sort命令

除了使用有序集合外，我們還可以借助 Redis 提供的 SORT命令來解決前言問題，

SORT命令可以對串列型別、集合型別和有序集合型別鍵進行排序，并且可以完成與關系資料庫中的連接查詢相類似的任務，

假如博客中標有“ruby ”標簽的文章的ID分別是“2”、“6”、“12”和“26”，由于在集合類型中所有元素是無序的，所以使用SMEMBERS命令并不能獲得有序的結果[3] ，為了能夠讓博客的標簽頁面下的文章也能按照發布的時間順序排列（如果不考慮發布后再修改文章發布時間，就是按照文章ID的順序排列），可以借助SORT命令實作，方法如下所示：

redis> SORT tag:ruby :posts
1) "2" 
2) "6" 
3) "12" 
4) "26"

除了集合型別，SORT 命令還可以對串列型別和有序集合型別進行排序：

redis> LPUSH mylist 4 2 6 1 3 7 
(integer) 6 
redis> SORT mylist 
1) "1" 
2) "2" 
3) "3" 
4) "4" 
5) "6" 
6) "7"

除了可以排列數字外，SORT命令還可以通過ALPHA引數實作按照字典順序排列非數字元素，就像這樣：

redis> LPUSH mylistalpha a c e d B C A
(integer) 7
redis> SORT mylistalpha 
(error) ERR One or more scores can't be converted into double
redis> SORT mylistalpha ALPHA 
1) "A" 
2) "B" 
3) "C" 
4) "a" 
5) "c" 
6) "d" 
7) "e"

從這段示例中可以看到如果沒有加ALPHA引數的話，SORT命令會嘗試將所有元素轉換成雙精度浮點數來比較，如果無法轉換則會提示錯誤，
回到前言問題，SORT 命令默認是按照從小到大的順序排列，而一般博客中顯示文章的順序都是按照時間倒序的，即最新的文章顯示在最前面，SORT命令的DESC引數可以實作
將元素按照從大到小的順序排列：

redis> SORT tag:ruby :posts DESC 
1) "26" 
2) "12" 
3) "6" 
4) "2"

那么如果文章數量過多需要分頁顯示呢？SORT命令還支持LIMIT引數來回傳指定范圍的結果，用法和 SQL 陳述句一樣，LIMIT offset count，表示跳過前 offset 個元素并獲取之后的 count個元素， SORT命令的引數可以組合使用，像這樣：

redis> SORT tag:ruby :posts DESC LIMIT 1 2 
1) "12" 
2) "6"

三、BY引數

很多情況下串列（或集合、有序集合）中存盤的元素值代表的是物件的ID（如標簽集合中存盤的是文章物件的ID），單純對這些ID自身排序有時意義并不大，更多的時候我們希望根據ID對應的物件的某個屬性進行排序，回想前面內容，我們通過使用有序集合鍵來存盤文章 ID串列，使得博客能夠支持修改文章時間，所以文章ID的順序和文章的發布時間的順序并不完全一致；

博客是使用散列型別鍵存盤文章物件的，其中time欄位存盤的就是文章的發布時間，現在我們知道ID為“2”、“6”、“12”和“26”的四篇文章的time欄位的值分別為“1352619200”、“1352619600”、“1352620100”和“1352620000”（Unix時間），如果要按照文章的發布時間遞減排列結果應為“12”、“26”、“6”和“2”，為了獲得這樣的結果，需要使用 SORT命令的另一個強大的引數：BY，

BY引數的語法為BY參考鍵，其中參考鍵可以是字串型別鍵或者是散列型別鍵的某個欄位（表示為鍵名->欄位名），如果提供了 BY 引數，SORT 命令將不再依據元素自身的值進行排序，而是對每個元素使用元素的值替換參考鍵中的第一個*并獲取其值，然后依據該值對元素排序，就像這樣：

redis> SORT tag:ruby :posts BY post:*->time DESC 
1) "12" 
2) "26" 
3) "6" 
4) "2"

在上例中SORT命令會讀取post:2、post:6、post:12、post:26幾個散列鍵中的time欄位的值并以此決定tag:ruby:posts鍵中各個文章ID的順序，除了散列型別之外，參考鍵還可以是字串型別，比如：

redis> LPUSH sortby list 2 1 3 
(integer) 3 
redis> SET itemscore:1 50 
OK
redis> SET itemscore:2 100
OK
redis> SET itemscore:3 -10 
OK
redis> SORT sortbylist BY itemscore:* DESC 
1) "2" 
2) "1" 
3) "3"

當參考鍵名不包含*時（即常量鍵名，與元素值無關），SORT 命令將不會執行排序操作，因為Redis認為這種情況是沒有意義的（因為所有要比較的值都一樣），例如：

redis> SORT sortbylist BY anytext 
1) "3" 
2) "1" 
3) "2"

例子中 anytext 是常量鍵名（甚至 anytext 鍵可以不存在），此時 SORT 的結果與 LRANGE的結果相同，沒有執行排序操作，在不需要排序但需要借助SORT命令獲得與元素相關聯的資料時，常量鍵名是很有用的，
如果幾個元素的參考鍵值相同，則 SORT 命令會再比較元素本身的值來決定元素的順序，像這樣：

redis> LPUSH sortby list 4 
(integer) 4 
redis> SET itemscore:4 50 
OK
redis> SORT sortbylist BY itemscore:* DESC 
1) "2" 
2) "4" 
3) "1" 
4) "3"

示例中元素"4"的參考鍵itemscore:4的值和元素"1"的參考鍵itemscore:1的值都是50，所以 SORT命令會再比較"4"和"1"元素本身的大小來決定二者的順序，當某個元素的參考鍵不存在時，會默認參考鍵的值為0：

redis> LPUSH sortby list 5 
(integer) 5 
redis> SORT sortbylist BY itemscore:* DESC 
1) "2" 
2) "4" 
3) "1" 
4) "5" 
5) "3"

上例中"5"排在了"3"的前面，是因為"5"的參考鍵不存在，所以默認為 0，而"3"的參考鍵值為?10，
補充知識參考鍵雖然支持散列型別，但是*只能在“->”符號前面（即鍵名部分）才有用，在“->”后（即欄位名部分）會被當成欄位名本身而不會作為占位符被元素的值替換，即常量鍵名，但是實際運行時會發現一個有趣的結果：

redis> SORT sortby list BY somekey->somefield:* 
1) "1" 
2) "2" 
3) "3" 
4) "4" 
5) "5"

上面提到了當參考鍵名是常量鍵名時 SORT 命令將不會執行排序操作，然而上例中確進行了排序，而且只是對元素本身進行排序，這是因為 Redis 判斷參考鍵名是不是常量鍵名的方式是判斷參考鍵名中是否包含“*”，而 somekey->somefield:中包含“”所以不是常量鍵名，所以在排序的時候Redis對每個元素都會讀取鍵somekey中的 somefield:欄位（“”不會被替換），無論能否獲得其值，每個元素的參考鍵值是相同的，所以Redis會按照元素本身的大小排列，

四、get引數

現在博客已經可以按照文章的發布順序獲得一個標簽下的文章 ID 串列了，接下來要做的事就是對每個ID都使用HGET命令獲取文章的標題以顯示在博客串列頁中，有沒有覺得很麻煩？不論你的答案如何，都有一種更簡單的方式來完成這個操作，那就是借助SORT 命令的GET引數，

GET引數不影響排序，它的作用是使 SORT命令的回傳結果不再是元素自身的值，而是 GET引數中指定的鍵值，GET引數的規則和BY引數一樣，GET引數也支持字串型別和散列型別的鍵，并使用“*”作為占位符，要實作在排序后直接回傳ID對應的文章標題，可以這樣寫：

redis> SORT tag:ruby :posts BY post:*->time DESC GET post:*->title 
1) "Windows 8 app designs" 
2) "RethinkDB - An open-source distributed database built with love" 
3) "Uses for cURL" 
4) "The Nature of Ruby "

在一個SORT命令中可以有多個GET引數（而BY引數只能有一個），所以還可以這樣用：

redis> SORT tag:ruby :posts BY post:*->time DESC GET post:*->title GET post:*->time 
1) "Windows 8 app designs" 
2) "1352620100" 
3) "RethinkDB - An open-source distributed database built with love" 
4) "1352620000" 
5) "Uses for cURL" 
6) "1352619600" 
7) "The Nature of Ruby " 
8) "1352619200"

可見有N個GET引數，每個元素回傳的結果就有N行，這時有個問題：如果還需要回傳文章ID 該怎么辦？答案是使用 GET #，就像這樣：

redis> SORT tag:ruby :posts BY post:*->time DESC GET post:*->title GET post:*->time
GET #
1) "Windows 8 app designs" 
2) "1352620100" 
3) "12" 
4) "RethinkDB - An open-source distributed database built with love" 
5) "1352620000" 
6) "26" 
7) "Uses for cURL" 
8) "1352619600" 
9) "6" 
10) "The Nature of Ruby" 
11) "1352619200" 
12) "2"

也就是說，GET #會回傳元素本身的值，

五、store引數

默認情況下SORT會直接回傳排序結果，如果希望保存排序結果，可以使用STORE參數，如希望把結果保存到sort.result鍵中：

redis> SORT tag:ruby :posts BY post:*->time DESC GET post:*->title GET post:*->time GET # STORE sort.result 
(integer) 12 
redis> LRANGE sort.result 0 -1 
1) "Windows 8 app designs" 
2) "1352620100" 
3) "12" 
4) "RethinkDB - An open-source distributed database built with love" 
5) "1352620000" 
6) "26" 
7) "Uses for cURL" 
8) "1352619600" 
9) "6" 
10) "The Nature of Ruby" 
11) "1352619200" 
12) "2"

保存后的鍵的型別為串列型別，如果鍵已經存在則會覆寫它，加上STORE引數后SORT 命令的回傳值為結果的個數，
STORE引數常用來結合EXPIRE命令快取排序結果，如下面的偽代碼：

#判斷是否存在之前排序結果的快取 
$isCacheExists = EXISTS cache.sort 
if $isCacheExists is 1 
	#如果存在則直接回傳 
	return LRANGE cache.sort, 0, -1
else #如果不存在，則使用 SORT命令排序并將結果存入 cache.sort鍵中作為快取 
   $sortResult = SORT some.list STORE cache.sort 
   #設定緩存的過期時間為 10分鐘 
   EXPIRE cache.sort, 600 
   #回傳排序結果 
   return $sortResult

六、性能優化

SORT是Redis中最強大最復雜的命令之一，如果使用不好很容易成為性能瓶頸，SORT命令的時間復雜度是O(n+mlog(m))，其中n表示要排序的串列（集合或有序集合）中的元素個數，m表示要回傳的元素個數，當n較大的時候SORT命令的性能相對較低，并且Redis在排序前會建立一個長度為n 的容器來存盤待排序的元素，雖然是一個臨時的程序，但如果同時進行較多的大資料量排序操作則會嚴重影響性能，

所以開發中使用SORT命令時需要注意以下幾點，

盡可能減少待排序鍵中元素的數量（使N盡可能小），
使用LIMIT引數只獲取需要的資料（使M盡可能小），
如果要排序的資料數量較大，盡可能使用STORE引數將結果快取，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/260660.html

標籤：其他

上一篇：MySQL基礎筆記

下一篇：求助mysql行程關閉！