redis精進 - list的使用和應用場景

redis精進 - list的使用和應用場景

最近在精進學習Redis，邊學邊寫

先贊後讀，養成習慣

1、List類型使用說明

• list類型是用來存儲多個有序的字符串的，支持存儲2^32次方-1個元素。
• redis能夠從鏈表的兩端進行插入（pubsh）和彈出（pop）元素,充當隊列或者棧
• 支持讀取指定範圍的元素集
• 讀取指定下標的元素等

注意它是鏈表而不是數組。這意味着 list 的插入和刪除操做很是快，時間複雜度爲 O(1)，可是索引定位很慢，時間複雜度爲 O(n)
另外當列表彈出了最後一個元素以後，該數據結構自動被刪除，內存被回收。
複製代碼

2、String類型經常使用命令：

右邊進左邊出：隊列

# 進入隊列
> rpush books python java golang
(integer) 3
 # 隊列長度
> llen books
(integer) 3
 # 取出隊列
> lpop books
"python"
> lpop books
"java"
> lpop books
"golang"
> lpop books
(nil)
複製代碼

右邊進右邊出：棧

# 入棧
> rpush books python java golang
(integer) 3
 # 出棧
> rpop books
"golang"
> rpop books
"java"
> rpop books
"python"
> rpop books
(nil)
複製代碼

慢操做

lindex 至關於 Java 鏈表的get(int index)方法，它須要對鏈表進行遍歷，性能隨着參數index增大而變差。

> rpush books python java golang
(integer) 3
 > lindex books 1 # O(n) 慎用
"java"
 > lrange books 0 -1 # 獲取全部元素，O(n) 慎用
1) "python"
2) "java"
3) "golang"
 > ltrim books 1 0 # O(n) 慎用 這實際上是清空了整個列表，由於區間範圍長度爲負
OK
 > llen books
(integer) 0
複製代碼

ltrim 和字面意思不太同樣，與其說去除不如說保留。

由於 ltrim 兩個參數start_index和end_index定義了一個區間內的值將被保留下來。
這使它很是適合實現一個定長的鏈表

3、使用場景：鏈表用來作異步隊列

鏈表經常使用來作異步隊列使用

• 將須要延後處理的任務結構體序列化（JSON）成字符串塞進 Redis 的列表

• 另外一個線程從這個列表中輪詢數據進行處理。

• lpush + lpop = stack 先進後出的棧

• lpush + rpop = queue 先進先出的隊列

• lpush + ltrim = capped collection 有限集合

• lpush + brpop = message queue 消息隊列

Redis 隊列繞不開的消息丟失問題

通常藉助List來實現消息隊列:

• 經過命令LPUSH（BLPUSH）把消息入隊
• 經過命令RPOP（BRPOP）獲取消息。

但這種方式實現的隊列是不安全的。

由於RPOP（BRPOP）命令的特性：

• 移除list的隊尾元素(消息)並返回給客戶端。這時該元素只存在於客戶端的上下文中，redis服務器中沒有這個元素.
• 若是客戶端在處理元素的過程崩潰了，那麼這個元素就永遠丟失了。這種狀況致使：客戶端雖然成功收到了消息，可是卻沒有處理它。

試圖搶救一下

那怎麼來實現一個更安全的隊列呢？ 能夠試試redis的RPOPLPUSH (或者其阻塞版本的 BRPOPLPUSH）命令。

具體是操做是：

• 在A隊列推出元素(並刪除)時，保存元素到 B隊列。
• 若是處理 元素 的客戶端奔潰了，還能夠在B隊列找到

redis> RPUSH mylist "one"
(integer) 1
redis> RPUSH mylist "two"
(integer) 2
redis> RPUSH mylist "three"
(integer) 3
redis> RPOPLPUSH mylist myotherlist
"three"
redis> LRANGE mylist 0 -1
1) "one"
2) "two"
redis> LRANGE myotherlist 0 -1
1) "three"
redis> 
複製代碼

這種方法存在兩個問題，

• 多個消費者同時將消息轉存入第二個隊列，第二隊列會出現( 已執行、未執行 )消息堆積
• 假設你的消息很特別，內容不會重複，你能夠經過lrem a 0 "元素"函數找到並刪除消息，另外啓動的那個專門處理第二個隊列的client面對的隊列中的信息數量必須很小，若是很大client處理不過來又不能使用併發，由於使用併發必須將消息pop出隊列2，若是pop出隊列2，那就又回到了咱們原本要繞開的問題。

最後

因此折騰試試，發現redislist

• 作消費者確認ACK麻煩
• 不能重複消費，一旦消費就會被刪除
• 隊列不去重

所以對於一致性要求高的場景，隊列建議使用Redis 5的 Stream 或者 RocketMQ。 目前還沒發現特別適合redis list使用場景，有想到的小夥伴留言交流下❤️