RPOPLPUSH · W3School Redis 教程 & 命令參考

# RPOPLPUSH **RPOPLPUSH source destination** 命令 [RPOPLPUSH](#rpoplpush) 在一個原子時間內，執行以下兩個動作： * 將列表 `source` 中的最后一個元素(尾元素)彈出，并返回給客戶端。 * 將 `source` 彈出的元素插入到列表 `destination` ，作為 `destination` 列表的的頭元素。舉個例子，你有兩個列表 `source` 和 `destination` ， `source` 列表有元素 `a, b, c` ， `destination` 列表有元素 `x, y, z` ，執行 `RPOPLPUSH source destination` 之后， `source` 列表包含元素 `a, b` ， `destination` 列表包含元素 `c, x, y, z` ，并且元素 `c` 會被返回給客戶端。如果 `source` 不存在，值 `nil` 被返回，并且不執行其他動作。如果 `source` 和 `destination` 相同，則列表中的表尾元素被移動到表頭，并返回該元素，可以把這種特殊情況視作列表的旋轉(rotation)操作。 **可用版本：** >= 1.2.0 **時間復雜度：** O(1) **返回值：** 被彈出的元素。 ``` # source 和 destination 不同 redis> LRANGE alpha 0 -1 # 查看所有元素 1) "a" 2) "b" 3) "c" 4) "d" redis> RPOPLPUSH alpha reciver # 執行一次 RPOPLPUSH 看看 "d" redis> LRANGE alpha 0 -1 1) "a" 2) "b" 3) "c" redis> LRANGE reciver 0 -1 1) "d" redis> RPOPLPUSH alpha reciver # 再執行一次，證實 RPOP 和 LPUSH 的位置正確 "c" redis> LRANGE alpha 0 -1 1) "a" 2) "b" redis> LRANGE reciver 0 -1 1) "c" 2) "d" # source 和 destination 相同 redis> LRANGE number 0 -1 1) "1" 2) "2" 3) "3" 4) "4" redis> RPOPLPUSH number number "4" redis> LRANGE number 0 -1 # 4 被旋轉到了表頭 1) "4" 2) "1" 3) "2" 4) "3" redis> RPOPLPUSH number number "3" redis> LRANGE number 0 -1 # 這次是 3 被旋轉到了表頭 1) "3" 2) "4" 3) "1" 4) "2" ``` ## 模式：安全的隊列 Redis的列表經常被用作隊列(queue)，用于在不同程序之間有序地交換消息(message)。一個客戶端通過 [_LPUSH_](lpush.html#lpush) 命令將消息放入隊列中，而另一個客戶端通過 [_RPOP_](rpop.html#rpop) 或者 [_BRPOP_](brpop.html#brpop) 命令取出隊列中等待時間最長的消息。不幸的是，上面的隊列方法是『不安全』的，因為在這個過程中，一個客戶端可能在取出一個消息之后崩潰，而未處理完的消息也就因此丟失。使用 [RPOPLPUSH](#rpoplpush) 命令(或者它的阻塞版本 [_BRPOPLPUSH_](brpoplpush.html#brpoplpush) )可以解決這個問題：因為它不僅返回一個消息，同時還將這個消息添加到另一個備份列表當中，如果一切正常的話，當一個客戶端完成某個消息的處理之后，可以用 [_LREM_](lrem.html#lrem) 命令將這個消息從備份表刪除。最后，還可以添加一個客戶端專門用于監視備份表，它自動地將超過一定處理時限的消息重新放入隊列中去(負責處理該消息的客戶端可能已經崩潰)，這樣就不會丟失任何消息了。 ## 模式：循環列表通過使用相同的 `key` 作為 [RPOPLPUSH](#rpoplpush) 命令的兩個參數，客戶端可以用一個接一個地獲取列表元素的方式，取得列表的所有元素，而不必像 [_LRANGE_](lrange.html#lrange) 命令那樣一下子將所有列表元素都從服務器傳送到客戶端中(兩種方式的總復雜度都是 O(N))。以上的模式甚至在以下的兩個情況下也能正常工作： * 有多個客戶端同時對同一個列表進行旋轉(rotating)，它們獲取不同的元素，直到所有元素都被讀取完，之后又從頭開始。 * 有客戶端在向列表尾部(右邊)添加新元素。這個模式使得我們可以很容易實現這樣一類系統：有 N 個客戶端，需要連續不斷地對一些元素進行處理，而且處理的過程必須盡可能地快。一個典型的例子就是服務器的監控程序：它們需要在盡可能短的時間內，并行地檢查一組網站，確保它們的可訪問性。注意，使用這個模式的客戶端是易于擴展(scala)且安全(reliable)的，因為就算接收到元素的客戶端失敗，元素還是保存在列表里面，不會丟失，等到下個迭代來臨的時候，別的客戶端又可以繼續處理這些元素了。