redis各数据类型应用概述

前言

1. redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存、亦可持久化的日志型、key-value数据库，并提供多种语言的API。
2. 它是内存存储的数据结构服务器，可用作数据库、高速缓存和消息队列代理。
3. 通过数据全部in-momery的方式保证高速访问，同时提供数据落地的功能，这是redis最主要的适用场景。
4. reids内置复制、Lua脚本、LRU收回、事物以及不同级别磁盘持久化功能，同时通过redis Sentinel提供高可用，通过Redis Cluster提供自动分区。
5. redis支持字符串、哈希表、列表、集合、有序集合、位图、hyperloglogs等数据类型。
6. redis最为常用的数据类型：stirng、hash、list、set、sorted set、pub/sub、transactions。

String类型

1. string类型就是简单的key-value类型，value不仅仅是string，也可以是数字。
2. 常用命令：set、get、decr、incr、mget等。

3. 除了提供与memcached一样的get、set、incr、decr 等操作外，redis还提供了下面的一些操作：

   ```

   （1）获取字符串长度；
   （2）往字符串append内容；
   （3）设置和获取字符串的某一段内容；
   （4）设置及获取字符串的某一位(bit)；
   （5）批量设置一系列字符串的内容；
   ```

Hash类型

1. hash特别适合用于存储对象。
2. 常用命令：hget、hset、hgetall等。
3. 应用场景：存储一些结构化的数据，比如用户的昵称、年龄、性别、积分等，存储一个用户信息对象数据。

4. 我们举个简单的实例来描述下Hash的应用场景，比如我们存储一个用户信息对象数据，包含以下信息：

   ```

   （1）用户id为查找的key；
   （2）存储的value包括姓名、年龄、生日等信息
   ```

5. 实例解析：

   ```

   （1）key是用户id，value是一个Map。
   （2）这个Map的key是成员的属性名，value是属性值；
   （3）这样对数据的修改和存取都可以直接通过其内部的Map的key（redis里称内部Map的key为field），也就是key(用户名id)+field(属性名)就可以操作对应属性数据了。
   ```

6. 注意：

   ```

   （1）redis提供了接口（hgetall）可以直接取到全部的属性数据，但是如果内部Map的成员很多，那么涉及到遍历整个Map的操作。
   （2）由于redis单线程模型的缘故，这个遍历操作可能会比较耗时，而令其他客户端的请求完全响应不到，这点需要注意。
   ```

List类型

1. list类型实质是一个每个元素都是string类型的双向链表，这使得list既可以用作栈，也可以用作队列。
2. list类型经常会被用于消息队列的服务，以完成多程序之间的消息交换。
3. 常用命令：lpush、rpush、lpop、rpop、lrange等。
4. lpush是插入到链表的左边，也就是头部;rpush是插入到链表的右边，也就是尾部;lrange(key,start,end)返回指定区间内的元素，从头部（左端）start开始到尾部（右端）区间内。
5. 应用场景：实现最新消息排行等功能，还有消息队列。

6. 简单消息队列举例分析：

   ```

   （1）假设一个应用程序执行lpush向链表中添加新的元素，我们通常将这样的程序称之为“生产者(producer)”；
   （2）而另外一个应用程序正在执行rpop操作从链表中取出元素，我们称这样的程序为“消费者(consumer)”；
   （3）在消费者消费消息的过程中，需要不停调用rpop查看list中是否有待处理消息。每调用一次都会发起一次链接，造成不必要的浪费。
   （4）另外，如果生产者速度大于消费者速度，消息队列长度会一直增大，时间久了会占用大量内存空间；
   （5）所以，可以使用brpop命令，这个命令只有在有元素时返回，没有则会阻塞直到超时返回null。
   ```

Set类型

1. set类型是string类型的无序集合。
2. set集合的概念就是一堆不重复值的组合。
3. set元素最大可以包含（2的32次方-1）个元素。
4. set内部实现是一个value永远为null的HashMap。
5. set对外提供的功能与list类似是一个列表的功能，特殊之处在于set时可以自动排重的。
6. 常用命令：sadd、spop、smembers、sunion等。
7. 当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择。
8. 并且set提供了判断某个成员是否在一个set集合内的重要接口，这个是list不能提供的。
9. 利用set数据结构，可以存储一些集合性的数据，比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。
10. redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能。

Zset类型

1. 和set一样，sorted set也是stirng类型元素的集合。不同的是每个元素都会关联一个double类型的score，元素顺序由score决定。
2. sorted set是插入有序的，即自动排序。
3. 常用命令：zadd、zrange、zrem、zcard等。
4. zRange(key,start,end)返回指定范围内的score从低到高顺序的所有元素；zRevRange(key,start,end)返回key对应的有序集合中指定区间的按照score从高到低的顺序的所有元素。
5. 当你需要一个有序的并且不重复的集合列表时，那么可以选择sorted set数据结构。

6. 应用举例：

   ```

   （1）例如存储全班同学的成绩，其集合value可以是同学的学号，而score就可以是成绩。
   （2）排行榜应用，根据得分列出topN的用户等。
   ```

pub/sub

1. subscribe、unsubscribe和publish三个命令实现了发布与订阅泛型。
2. 发送者（发送信息的客户端）不是直接将信息发给特定的接收者（接受信息的客户端），而是将信息发给频道（channel），然后由频道将信息转发给所有对这个频道感兴趣的订阅者。
3. 发送者无需知道任何关于订阅者的信息，而订阅者也无需知道是哪个客户端给它发送信息，它只要关注自己感兴趣的频道即可。
4. 发布／订阅在redis中，被设计的非常轻量级和简洁，它做到了消息的发布和订阅的基本能力；但是尚未提供关于消息持久化等各种企业级的特性。
5. 一个redis client发布消息，其他多个redis client订阅消息，发布的消息即发即失，redis不会持久保存发布的消息；消息订阅者也只能得到订阅后的消息，通道中此前的消息无从获得。
6. 消息发布者，即publish客户端，无需独占链接，你可以在publish消息的同时，使用同一个redis-client链接进行其他操作（如incr等）；
7. 消息订阅者，即subscribe客户端，需要独占链接，即进行subscribe期间，redis-client无法穿插其他操作。
8. 此时client以阻塞的方式等待publish端的消息，因此subscribe需要使用单独的链接，甚至需要在额外的线程中使用。
9. tcp默认连接时间固定，如果在这世间内sub端没有接收到pub端消息，或pub端没有消息产生，sub端的连接都会强制回收。
10. 这就需要特殊手段解决，用定时器来模拟pub和sub之间的保活机制，定时器时间不能超过tcp最大连接时间。
11. 一旦subscribe端断开链接，将会失去部分消息，即链接失效期间的消息将会被丢失，所以，这里需要考虑redis的list来持久化；

12. 如果你非常关注每个消息，那么你应该基于redis做一些额外的补充工作，如果你希望订阅是持久的，那么如下设计思路可以借鉴：

    ```

    （1）subscribe端：首先向一个set集合中增加“订阅者id”，此set集合保存了“活跃订阅”者；订阅者id标记每个唯一的订阅者，此set为“活跃订阅者集合”。
    （2）subscribe端开启订阅操作，并基于redis创建一个以订阅者id为key的list数据结构，此list中存储了所有的尚未消费的消息，此list称为“订阅者消息队列”；
    （3）publish端：每发布一条消息之后，publish端都需要遍历活跃订阅者集合，并依次向每个“订阅者消息队列”尾部追加此次发布的消息；
    （4）到此为止，我们基本可以保证，发布的每一条消息，都会持久的保存在每个“订阅者消息队列”中；
    （5）subscribe端，每接收到一个订阅消息，在消费周后，必须删除自己的“订阅者消息队列”头部的一条消息；
    （6）subscribe端启动时，如果发现自己的“订阅者消息队列”中有残存记录，那么将会首先消费这些消息，然后再去订阅。
    ```

13. 以上方法可以保证成功到达的消息必消费不丢失

transactions

1. redis事务可以一次执行多个命令。

2. 一个事务从开始到执行会经历三个阶段：

   ```

   （1）开始事务
   （2）命令入队
   （3）执行事务
   ```

3. 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序执行。
4. 事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
5. 单个redis命令的执行时原子性的，但redis没有在事务上增加任何维持原子性的机制，所以redis事务的执行并不是原子性的。
6. 事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。
7. multi、exec、discard和watch命令是redis事务的基础。

8. multi：

   ```

   （1）multi命令用于开启一个事务，它总是返回ok。
   （2）multi命令执行之后，客户端可以继续向服务器发送任意多条命令；
   （3）这些命令不会立即被执行，而是被放到一个队列中；
   （4）当exec命令被调用时，所有队列中的命令才会被执行。
   ```

9. exec：

   ```

   （1）exec命令负责触发并执行事务中的所有命令；
   （2）如果客户端在使用multi开启了一个事务后，却因为断线而没有成功执行exec命令，那么事务中所有的命令都不会被执行。
   （3）另一方面，如果客户端成功在开启事务之后执行exec命令，那么事务中的所有命令都会被执行。
   ```

10. discard：

    ```

    （1）通过调用discard，客户端可以清空事务队列，并放弃执行事务。
    ```

11. watch：

    ```

    （1）watch命令可以为redis事务提供check-and-set （CAS）行为。
    （2）watch使得exec命令有条件的执行：事务只能在所有被监控健都没有被修改的前提下执行，如果这个前提不能满足，事务就不会执行。
    （3）如果你用watch监视来一个带过期时间的健，那么即使这个健过期了，事务仍然可以执行。
    （4）watch可以被调用多次，对健的监视从watch被执行之后就生效，直到调用exec为止。
    （5）当exec被调用时，不管事务是否被成功执行，对所有健的监视都会被取消。
    （6）当客户端断开链接时，该客户端对健的监视也会被取消。
    ```

原文地址：https://segmentfault.com/a/1190000016374634