3.redis基本命令--列表

Dear 丶 2021-11-04 09:26 327阅读 0赞

**1.LPUSH key value \[value …\]  
2.LPUSHX key value**

*  将值 value 插入到列表 key 的表头，当且仅当 key 存在并且是一个列表。
 *  和 LPUSH key value \[value …\] 命令相反，当 key 不存在时， LPUSHX 命令什么也不做。
 *  lpush也会将新增的值放在列表的最前面。

**3.RPUSH key value \[value …\]**

**4.RPUSHX key value**

**5.LPOP key**

**6.RPOP key**

**7.RPOPLPUSH source destination**

*  将列表 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)操作。

**8.LREM key count value**

*  count > 0 : 从表头开始向表尾搜索，移除与 value 相等的元素，数量为 count 。
 *  count < 0 : 从表尾开始向表头搜索，移除与 value 相等的元素，数量为 count 的绝对值。
 *  count = 0 : 移除表中所有与 value 相等的值。

**9.LINDEX key index**

*  返回列表 key 中，下标为 index 的元素。
 *  下标(index)参数 start 和 stop 都以 0 为底，也就是说，以 0 表示列表的第一个元素，以 1 表示列表的第二个元素，以此类推。
 *  你也可以使用负数下标，以 -1 表示列表的最后一个元素， -2 表示列表的倒数第二个元素，以此类推。
 *  如果 key 不是列表类型，返回一个错误。

**10.LINSERT key BEFORE|AFTER pivot value**

*  将值 value 插入到列表 key 当中，位于值 pivot 之前或之后。
 *  当 pivot 不存在于列表 key 时，不执行任何操作。
 *  当 key 不存在时， key 被视为空列表，不执行任何操作。
 *  如果 key 不是列表类型，返回一个错误。

**11.LSET key index value**

*  将列表 key 下标为 index 的元素的值设置为 value 。
 *  当 index 参数超出范围，或对一个空列表( key 不存在)进行 LSET 时，返回一个错误。
 *  索引下表从0开始。

**12.LRANGE key start stop**

**13.LTRIM key start stop**

*  对一个列表进行修剪(trim)，就是说，让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除。
 *  举个例子，执行命令 LTRIM list 0 2 ，表示只保留列表 list 的前三个元素，其余元素全部删除。
 *  下标(index)参数 start 和 stop 都以 0 为底，也就是说，以 0 表示列表的第一个元素，以 1 表示列表的第二个元素，以此类推。
 *  你也可以使用负数下标，以 -1 表示列表的最后一个元素， -2 表示列表的倒数第二个元素，以此类推。
 *  当 key 不是列表类型时，返回一个错误。
 *  LTRIM 命令通常和 LPUSH key value \[value …\] 命令或 RPUSH key value \[value …\] 命令配合使用

**14.BLPOP key \[key …\] timeout**

*  它是 LPOP key 命令的阻塞版本，当给定列表内没有任何元素可供弹出的时候，连接将被 BLPOP 命令阻塞，直到等待超时或发现可弹出元素为止。
 *  当给定多个 key 参数时，按参数 key 的先后顺序依次检查各个列表，弹出第一个非空列表的头元素。

**14.1.非阻塞行为**

*  当 BLPOP 被调用时，如果给定 key 内至少有一个非空列表，那么弹出遇到的第一个非空列表的头元素，并和被弹出元素所属的列表的名字一起，组成结果返回给调用者。
 *  当存在多个给定 key 时， BLPOP 按给定 key 参数排列的先后顺序，依次检查各个列表。
 *  假设现在有 job 、 command 和 request 三个列表，其中 job 不存在， command 和 request 都持有非空列表。考虑以下命令：
 *  BLPOP job command request 0
 *  BLPOP 保证返回的元素来自 command ，因为它是按”查找 job -> 查找 command -> 查找 request “这样的顺序，第一个找到的非空列表。

**14.2.相同的key被多个客户端同时阻塞**

*  相同的 key 可以被多个客户端同时阻塞。
 *  不同的客户端被放进一个队列中，按『先阻塞先服务』(first-BLPOP，first-served)的顺序为 key 执行 BLPOP 命令。

**14.3.MULTI/EXEC事务中的BLPOP**

*  BLPOP 可以用于流水线(pipline,批量地发送多个命令并读入多个回复)，但把它用在 MULTI / EXEC 块当中没有意义。因为这要求整个服务器被阻塞以保证块执行时的原子性，该行为阻止了其他客户端执行 LPUSH key value \[value …\] 或 RPUSH key value \[value …\] 命令。
 *  因此，一个被包裹在 MULTI / EXEC 块内的 BLPOP 命令，行为表现得就像 LPOP key 一样，对空列表返回 nil ，对非空列表弹出列表元素，不进行任何阻塞操作。

**14.4模式：事件提醒**

*  有时候，为了等待一个新元素到达数据中，需要使用轮询的方式对数据进行探查。
 *  另一种更好的方式是，使用系统提供的阻塞原语，在新元素到达时立即进行处理，而新元素还没到达时，就一直阻塞住，避免轮询占用资源。
 *  对于 Redis ，我们似乎需要一个阻塞版的 SPOP key 命令，但实际上，使用 BLPOP 或者 BRPOP key \[key …\] timeout 就能很好地解决这个问题。

**15.BRPOP key \[key …\] timeout  
16.BRPOPLPUSH source destination timeout**

*  BRPOPLPUSH 是 RPOPLPUSH source destination 的阻塞版本，当给定列表 source 不为空时， BRPOPLPUSH 的表现和 RPOPLPUSH source destination 一样。
 *  当列表 source 为空时， BRPOPLPUSH 命令将阻塞连接，直到等待超时，或有另一个客户端对 source 执行 LPUSH key value \[value …\] 或 RPUSH key value \[value …\] 命令为止。
 *  超时参数 timeout 接受一个以秒为单位的数字作为值。超时参数设为 0 表示阻塞时间可以无限期延长(block indefinitely) 。

**模式： 安全的队列**

*  Redis的列表经常被用作队列(queue)，用于在不同程序之间有序地交换消息(message)。一个客户端通过 LPUSH key value \[value …\] 命令将消息放入队列中，而另一个客户端通过 RPOP key 或者 BRPOP key \[key …\] timeout 命令取出队列中等待时间最长的消息。
 *  不幸的是，上面的队列方法是『不安全』的，因为在这个过程中，一个客户端可能在取出一个消息之后崩溃，而未处理完的消息也就因此丢失。
 *  使用 RPOPLPUSH 命令(或者它的阻塞版本 BRPOPLPUSH source destination timeout )可以解决这个问题：因为它不仅返回一个消息，同时还将这个消息添加到另一个备份列表当中，如果一切正常的话，当一个客户端完成某个消息的处理之后，可以用 LREM key count value 命令将这个消息从备份表删除。
 *  最后，还可以添加一个客户端专门用于监视备份表，它自动地将超过一定处理时限的消息重新放入队列中去(负责处理该消息的客户端可能已经崩溃)，这样就不会丢失任何消息了。

**模式：循环列表**

*  通过使用相同的 key 作为 RPOPLPUSH 命令的两个参数，客户端可以用一个接一个地获取列表元素的方式，取得列表的所有元素，而不必像 LRANGE key start stop 命令那样一下子将所有列表元素都从服务器传送到客户端中(两种方式的总复杂度都是 O(N))。
 *  以上的模式甚至在以下的两个情况下也能正常工作：
    
     *  有多个客户端同时对同一个列表进行旋转(rotating)，它们获取不同的元素，直到所有元素都被读取完，之后又从头开始。
     *  有客户端在向列表尾部(右边)添加新元素。
 *  这个模式使得我们可以很容易实现这样一类系统：有 N 个客户端，需要连续不断地对一些元素进行处理，而且处理的过程必须尽可能地快。一个典型的例子就是服务器的监控程序：它们需要在尽可能短的时间内，并行地检查一组网站，确保它们的可访问性。
 *  注意，使用这个模式的客户端是易于扩展(scala)且安全(reliable)的，因为就算接收到元素的客户端失败，元素还是保存在列表里面，不会丢失，等到下个迭代来临的时候，别的客户端又可以继续处理这些元素了。

**1.如果把列表作为队列使用**

*  队列：先进先出 rpop

**队列的非阻塞方式**

*  就是当使用pop进行出队的时候，如果队列是空的，将会得到一个null。

**队列的阻塞方式**

*  当我们使用brpop（brpop queue 0：这里的0表示阻塞的时间，0表示一直阻塞）时，如果队列中没有数据，会一直阻塞。
 *  如果队列中有数据，则会直接返回。
 *  brpop也可以一次阻塞多个队列。

**用redis的list当作队列可能存在的问题**

*  1)redis崩溃的时候队列功能失效
 *  2)如果入队端一直在塞数据，而出队端没有消费数据，或者是入队的频率大而多，出队端的消费频率慢会导致内存暴涨
 *  3)Redis的队列也可以像rabbitmq那样  即可以做消息的持久化，也可以不做消息的持久化。
 *  当做持久话的时候，需要启动redis的dump数据的功能.暂时不建议开启持久化。
 *  Redis其实只适合作为缓存，而不是数据库或是存储。它的持久化方式适用于救救急啥的，不太适合当作一个普通功能来用。因为dump时候，会影响性能，数据量小的时候还看不出来，当数据量达到百万级别，内存10g左右的时候，非常影响性能。
 *  4)假如有多个消费者同时监听一个队列，其中一个出队了一个元素，另一个则获取不到该元素。
 *  5)Redis的队列应用场景是一对多或者一对一的关系，即有多个入队端，但是只有一个消费端(出队)。