一、概述

Redis 是速度非常快的非关系型（NoSQL）内存键值数据库，可以存储键和五种不同类型的值之间的映射。

键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。

Redis 支持很多特性，例如将内存中的数据持久化到硬盘中，使用复制来扩展读性能，使用分片来扩展写性能。

二、数据类型

What Redis data structures look like(opens new window)

STRING

• SET SET key value [EX seconds] [PX milliseconds] [NX|XX]
• SETNX SETNX key value
• SETEX SETEX key seconds value
• PSETEX PSETEX key milliseconds value
• GET GET key
• GETSET GETSET key value
• STRLEN STRLEN key
• APPEND APPEND key value
• SETRANGE SETRANGE key offset value
• GETRANGE GETRANGE key start end
• INCR INCR key
• INCRBY INCRBY key increment
• INCRBYFLOAT INCRBYFLOAT key increment
• DECR DECR key
• DECRBY DECRBY key decrement
• MSET MSET key value [key value …]
• MSETNX MSETNX key value [key value …]
• MGET MGET key [key …]

内部编码

Redis会根据当前值得到类型和长度决定使用哪种内部编码实现。

• int 小于8字节的长整型
• embstr 小于等于39字节的字符串
• raw 大于39字节的字符串

典型使用场景

1. 缓存功能
   将Redis作为缓存层，MySQL作为存储层，绝大部分请求的数据优先从Redis中获取。（注意：key的设计，过期时间的设置）

2. 计数统计
   实际一个真是的技术系统要考虑的问题会很多：防作弊、按照不同维度计数、数据持久化到底层数据源等。

3. 共享Session
   将Redis作为分布式服务下的Session存储服务，避免同一用户的请求被负载均衡到不同的服务器上时需要重新登录的问题。

4. 限速
   同样是通过计数功能，可以限制指定功能接口的请求频率。

LIST

• LPUSH LPUSH key value [value …] 从左边插入元素
• LPUSHX LPUSHX key value
• RPUSH RPUSH key value [value …] 从右边新增元素
• RPUSHX RPUSHX key value
• LPOP LPOP key 从左边删除元素
• RPOP RPOP key 从右边删除元素
• RPOPLPUSH RPOPLPUSH source destination
• LREM LREM key count value 删除指定元素，count>0 则从左到右删除count个，count<0 则从右到左删除，count=0 则删除所有
• LLEN LLEN key 获取列表长度
• LINDEX LINDEX key index 获取指定索引下标的元素
• LINSERT LINSERT key BEFORE|AFTER pivot value 向某个元素前或者后插入元素
• LSET LSET key index value 修改指定索引下标的元素
• LRANGE LRANGE key start stop 获取指定范围内的元素列表
• LTRIM LTRIM key start stop 只保留指定范围的元素，其余元素删除
• BLPOP BLPOP key [key …] timeout
• BRPOP BRPOP key [key …] timeout
• BRPOPLPUSH BRPOPLPUSH source destination timeout

特点

1. 列表中的元素是有序的
2. 列表中的元素是可以重复的

内部编码

• ziplist（压缩列表）当哈希类型元素个数小于hash-max-ziplist-entries配置（默512个）、同事所有值都小于hash-max-ziplist-value配置（默认64字节）时，Redis会使用ziplist作为哈希的内部实现，ziplist使用更加紧凑的结构实现多个元素的连续存储，所在节省内存方面比hashtable更加优秀。
• linkedlist（链表）当列表类型无法满足ziplist的条件时，Redis会使用linkedlist作为列表的内部实现。
• quicklist

典型应用场景

1. 消息队列

通过lpush+brpop命令组合即可实现阻塞队列，生产者使用lpush从列表左侧插入元素，消费者使用brpop命令阻塞式获取列表右侧的元素。

实际上列表的使用场景很多，在选择时可以参考一下口诀：

• lpush + lpop = Stack（栈）
• lpush + rpop = Queue（队列）
• lpush + ltrim = Capped Collection（有限集合）
• lpush + brpop = Message Queue（消息队列）

SET

• SADD SADD key member [member …] 添加元素
• SISMEMBER SISMEMBER key member 判断元素是否在集合中，存在返回1，否则返回0
• SPOP SPOP key [count] 从集合中随机弹出元素，会删除，count参数从3.2版本开始可用
• SRANDMEMBER SRANDMEMBER key [count] 随机从集合中弹出指定个数元素，count默认为1，不会删除
• SREM SREM key member [member …] 移除集合中的一个或多个元素，不存在的元素会被忽略
• SMOVE SMOVE source destination member 将 member 元素从 source 集合移动到 destination 集合。
• SCARD SCARD key 计算元素个数，时间复杂度为O(1)，因为是直接使用Redis内部的计数变量
• SMEMBERS SMEMBERS key 获取所有元素
• SSCAN SSCAN key cursor [MATCH pattern] [COUNT count]
• SINTER SINTER key [key …] 取多个集合的交集
• SINTERSTORE SINTERSTORE destination key [key …] 将多个集合的交集结果保存到第一个key中
• SUNION SUNION key [key …] 取多个集合的并集
• SUNIONSTORE SUNIONSTORE destination key [key …] 将多个集合的并集结果保存到第一个key中
• SDIFF SDIFF key [key …] 取多个集合的差集
• SDIFFSTORE SDIFFSTORE destination key [key …] 将多个集合的差集结果保存到第一个key中

特点

1. 不允许有重复元素，且元素在集合中无序。
2. 除了支持增删改查，还支持交集、并集和差集。

内部编码

• intset（整数集合）当集合中的元素都是整数且元素个数小于set-max-intset-entries配置（默认512个）时，Redis会选用intset来作为集合的内部实现，从而减少内存的使用。
• hashtable（哈希表）当即和类型无法满足intset的条件时，Redis会使用hashtable作为集合的内部实现

内存优化技巧

典型应用场景

1. 标签

例如一个用户可能对游戏、音乐比较感兴趣，另一个用户可能对音乐、体育感兴趣，这些兴趣点就是标签；再例如博客中文章的关键词也可以作为一种标签。（用户和标签的关系维护应该在一个事务内执行，放至部分命令失败造成的数据不一致。可通过Lua脚本将两个命令放在一个事物中）

集合类型的应用场景通常为以下几种：

• sadd = Tagging（标签）
• spop + srandmember = Random item（生成随机数，比如抽奖）
• sadd + sinter = Social Graph（社交需求）

HASH

• HSET HSET hash field value
• HSETNX HSETNX hash field value
• HGET HGET hash field
• HEXISTS HEXISTS hash field
• HDEL HDEL
• HLEN HLEN
• HSTRLEN HSTRLEN Redis3.2以上版本
• HINCRBY HINCRBY
• HINCRBYFLOAT HINCRBYFLOAT
• HMSET HMSET
• HMGET HMGET
• HKEYS HKEYS
• HVALS HVALS
• HGETALL HGETALL 谨慎使用
• HSCAN HSCAN

内部编码

• ziplist（压缩列表） 当哈希类型元素个数小于hash-max-ziplist-entries配置（默512个）、同事所有值都小于hash-max-ziplist-value配置（默认64字节）时，Redis会使用ziplist作为哈希的内部实现，ziplist使用更加紧凑的结构实现多个元素的连续存储，所在节省内存方面比hashtable更加优秀。
• hashtable（哈希表）当哈希类型无法满足ziplist的条件时，Redis会使用hashtable作为哈希的内部实现，因为此时ziplist的读写效率会下降，而hashtable的读写时间复杂度为O(1)。

内存优化技巧

典型应用场景

1. 缓存用户信息
   方法一：序列化字符串类型：将用户信息序列化后用一个键保存
   优势：简化编程，如果理的使用序列化，可以提高内存的使用效率。
   劣势：序列化和反序列化有一定的开销，同时每次更新属性都需要把全部属性取出进行反序列化，更新后再序列化到Redis中。

set user:1 serialize(userInfo)

方法二：每个用户属性使用一对key-value，value中保存用户信息。
优势：简单直观，如果使用合理可以减少内存空间的使用。
劣势：要控制哈希在ziplist和hashtable两种内部编码的转换，hashtable会消耗更多的内存。

hmset user:1 name tom age 18 city changsha

ZSET

• ZADD ZADD key score member [[score member] [score member] …] 添加元素
• ZSCORE ZSCORE key member 返回元素对应的score值
• ZINCRBY ZINCRBY key increment member 增加元素的score值
• ZCARD ZCARD key 返回集合中元素个数
• ZCOUNT ZCOUNT key min max 返回集合中元素的score值在[min, max]之间的元素个数
• ZRANGE ZRANGE key start stop [WITHSCORES] 返回指定索引范围内已从低到高排序好的元素集合，加上withscores，还会返回元素的score值
• ZREVRANGE ZREVRANGE key start stop [WITHSCORES] 返回指定索引范围内已从高到低排序好的元素集合，加上withscores，还会返回元素的score值
• ZRANGEBYSCORE ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]
• ZREVRANGEBYSCORE ZREVRANGEBYSCORE key max min [WITHSCORES] [LIMIT offset count]
• ZRANK ZRANK key member 返回元素在集合中的排名，从低到高排序，0为顶
• ZREVRANK ZREVRANK key member 返回元素在集合中的排名，从高到低排序，0为低
• ZREM ZREM key member [member …] 删除指定元素
• ZREMRANGEBYRANK ZREMRANGEBYRANK key start stop 删除指定索引范围的所有元素
• ZREMRANGEBYSCORE ZREMRANGEBYSCORE key min max 删除指定score范围内的所有元素
• ZRANGEBYLEX ZRANGEBYLEX key min max [LIMIT offset count]
• ZLEXCOUNT ZLEXCOUNT key min max
• ZREMRANGEBYLEX ZREMRANGEBYLEX key min max
• ZSCAN ZSCAN key cursor [MATCH pattern] [COUNT count]
• ZUNIONSTORE ZUNIONSTORE destination numkeys key [key …] [WEIGHTS weight [weight …]] [AGGREGATE SUM|MIN|MAX]
• ZINTERSTORE ZINTERSTORE destination numkeys key [key …] [WEIGHTS weight [weight …]] [AGGREGATE SUM|MIN|MAX]

min max 支持开区间（小括号）和闭区间（中括号），-inf和+inf分别代表无限小和无限大

特点

1. 集合内元素不能重复
2. 可以通过给元素设置一个score作为排序的依据，以达到排序效果

内部编码

• ziplist（压缩列表）当有序集合的元素个数小于zset-max-ziplist-entries配置（默128个），同时每个元素的值都小于zset-max-ziplist-value配置（默认 64字节）时，Redis会使用ziplist作为有序集合的内部实现，ziplist可以有效减少内存的使用。
• skiplist（跳跃表）当ziplist条件不满足时，有序集合会使用skiplist作为内部实现，因为此时ziplist的读写效率会下降。

典型应用场景

1. 排行榜

例如视频网站需要对用户上传到视频做排行榜，榜单的维度可能是多个方面：时间、播放量、点赞数等。

三、数据结构

字典

dictht 是一个散列表结构，使用拉链法解决哈希冲突。

/* This is our hash table structure. Every dictionary has two of this as we
 * implement incremental rehashing, for the old to the new table. */
typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;
typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;
} dictEntry;

Redis 的字典 dict 中包含两个哈希表 dictht，这是为了方便进行 rehash 操作。在扩容时，将其中一个 dictht 上的键值对 rehash 到另一个 dictht 上面，完成之后释放空间并交换两个 dictht 的角色。

typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    unsigned long iterators; /* number of iterators currently running */
} dict;

rehash 操作不是一次性完成，而是采用渐进方式，这是为了避免一次性执行过多的 rehash 操作给服务器带来过大的负担。

渐进式 rehash 通过记录 dict 的 rehashidx 完成，它从 0 开始，然后每执行一次 rehash 都会递增。例如在一次 rehash 中，要把 dict[0] rehash 到 dict[1]，这一次会把 dict[0] 上 table[rehashidx] 的键值对 rehash 到 dict[1] 上，dict[0] 的 table[rehashidx] 指向 null，并令 rehashidx++。

在 rehash 期间，每次对字典执行添加、删除、查找或者更新操作时，都会执行一次渐进式 rehash。

采用渐进式 rehash 会导致字典中的数据分散在两个 dictht 上，因此对字典的查找操作也需要到对应的 dictht 去执行。

/* Performs N steps of incremental rehashing. Returns 1 if there are still
 * keys to move from the old to the new hash table, otherwise 0 is returned.
 *
 * Note that a rehashing step consists in moving a bucket (that may have more
 * than one key as we use chaining) from the old to the new hash table, however
 * since part of the hash table may be composed of empty spaces, it is not
 * guaranteed that this function will rehash even a single bucket, since it
 * will visit at max N*10 empty buckets in total, otherwise the amount of
 * work it does would be unbound and the function may block for a long time. */
int dictRehash(dict *d, int n) {
    int empty_visits = n * 10; /* Max number of empty buckets to visit. */
    if (!dictIsRehashing(d)) return 0;

    while (n-- && d->ht[0].used != 0) {
        dictEntry *de, *nextde;

        /* Note that rehashidx can't overflow as we are sure there are more
         * elements because ht[0].used != 0 */
        assert(d->ht[0].size > (unsigned long) d->rehashidx);
        while (d->ht[0].table[d->rehashidx] == NULL) {
            d->rehashidx++;
            if (--empty_visits == 0) return 1;
        }
        de = d->ht[0].table[d->rehashidx];
        /* Move all the keys in this bucket from the old to the new hash HT */
        while (de) {
            uint64_t h;

            nextde = de->next;
            /* Get the index in the new hash table */
            h = dictHashKey(d, de->key) & d->ht[1].sizemask;
            de->next = d->ht[1].table[h];
            d->ht[1].table[h] = de;
            d->ht[0].used--;
            d->ht[1].used++;
            de = nextde;
        }
        d->ht[0].table[d->rehashidx] = NULL;
        d->rehashidx++;
    }

    /* Check if we already rehashed the whole table... */
    if (d->ht[0].used == 0) {
        zfree(d->ht[0].table);
        d->ht[0] = d->ht[1];
        _dictReset(&d->ht[1]);
        d->rehashidx = -1;
        return 0;
    }

    /* More to rehash... */
    return 1;
}

跳跃表

是有序集合的底层实现之一。

跳跃表是基于多指针有序链表实现的，可以看成多个有序链表。

在查找时，从上层指针开始查找，找到对应的区间之后再到下一层去查找。下图演示了查找 22 的过程。

与红黑树等平衡树相比，跳跃表具有以下优点：

• 插入速度非常快速，因为不需要进行旋转等操作来维护平衡性；
• 更容易实现；
• 支持无锁操作。

四、使用场景

计数器

可以对 String 进行自增自减运算，从而实现计数器功能。

Redis 这种内存型数据库的读写性能非常高，很适合存储频繁读写的计数量。

缓存

将热点数据放到内存中，设置内存的最大使用量以及淘汰策略来保证缓存的命中率。

查找表

例如 DNS 记录就很适合使用 Redis 进行存储。

查找表和缓存类似，也是利用了 Redis 快速的查找特性。但是查找表的内容不能失效，而缓存的内容可以失效，因为缓存不作为可靠的数据来源。

消息队列

List 是一个双向链表，可以通过 lpush 和 rpop 写入和读取消息

不过最好使用 Kafka、RabbitMQ 等消息中间件。

会话缓存

可以使用 Redis 来统一存储多台应用服务器的会话信息。

当应用服务器不再存储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容易实现高可用性以及可伸缩性。

分布式锁实现

在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。

可以使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现。

其它

Set 可以实现交集、并集等操作，从而实现共同好友等功能。

ZSet 可以实现有序性操作，从而实现排行榜等功能。

五、Redis 与 Memcached

两者都是非关系型内存键值数据库，主要有以下不同：

数据类型

Memcached 仅支持字符串类型，而 Redis 支持五种不同的数据类型，可以更灵活地解决问题。

数据持久化

Redis 支持两种持久化策略：RDB 快照和 AOF 日志，而 Memcached 不支持持久化。

分布式

Memcached 不支持分布式，只能通过在客户端使用一致性哈希来实现分布式存储，这种方式在存储和查询时都需要先在客户端计算一次数据所在的节点。

Redis Cluster 实现了分布式的支持。

内存管理机制

• 在 Redis 中，并不是所有数据都一直存储在内存中，可以将一些很久没用的 value 交换到磁盘，而 Memcached 的数据则会一直在内存中。
• Memcached 将内存分割成特定长度的块来存储数据，以完全解决内存碎片的问题。但是这种方式会使得内存的利用率不高，例如块的大小为 128 bytes，只存储 100 bytes 的数据，那么剩下的 28 bytes 就浪费掉了。

六、键的过期时间

Redis 可以为每个键设置过期时间，当键过期时，会自动删除该键。

对于散列表这种容器，只能为整个键设置过期时间（整个散列表），而不能为键里面的单个元素设置过期时间。

七、数据淘汰策略

可以设置内存最大使用量，当内存使用量超出时，会施行数据淘汰策略。

Redis 具体有 6 种淘汰策略：

作为内存数据库，出于对性能和内存消耗的考虑，Redis 的淘汰算法实际实现上并非针对所有 key，而是抽样一小部分并且从中选出被淘汰的 key。

使用 Redis 缓存数据时，为了提高缓存命中率，需要保证缓存数据都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量，然后启用 allkeys-lru 淘汰策略，将最近最少使用的数据淘汰。

Redis 4.0 引入了 volatile-lfu 和 allkeys-lfu 淘汰策略，LFU 策略通过统计访问频率，将访问频率最少的键值对淘汰。

八、持久化

Redis 是内存型数据库，为了保证数据在断电后不会丢失，需要将内存中的数据持久化到硬盘上。

RDB 持久化

将某个时间点的所有数据都存放到硬盘上。

可以将快照复制到其它服务器从而创建具有相同数据的服务器副本。

如果系统发生故障，将会丢失最后一次创建快照之后的数据。

如果数据量很大，保存快照的时间会很长。

AOF 持久化

将写命令添加到 AOF 文件（Append Only File）的末尾。

使用 AOF 持久化需要设置同步选项，从而确保写命令同步到磁盘文件上的时机。这是因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区，然后由操作系统决定什么时候同步到磁盘。有以下同步选项：

• always 选项会严重减低服务器的性能；
• everysec 选项比较合适，可以保证系统崩溃时只会丢失一秒左右的数据，并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响；
• no 选项并不能给服务器性能带来多大的提升，而且也会增加系统崩溃时数据丢失的数量。

随着服务器写请求的增多，AOF 文件会越来越大。Redis 提供了一种将 AOF 重写的特性，能够去除 AOF 文件中的冗余写命令。

九、事务

一个事务包含了多个命令，服务器在执行事务期间，不会改去执行其它客户端的命令请求。

事务中的多个命令被一次性发送给服务器，而不是一条一条发送，这种方式被称为流水线，它可以减少客户端与服务器之间的网络通信次数从而提升性能。

Redis 最简单的事务实现方式是使用 MULTI 和 EXEC 命令将事务操作包围起来。

十、事件

Redis 服务器是一个事件驱动程序。

文件事件

服务器通过套接字与客户端或者其它服务器进行通信，文件事件就是对套接字操作的抽象。

Redis 基于 Reactor 模式开发了自己的网络事件处理器，使用 I/O 多路复用程序来同时监听多个套接字，并将到达的事件传送给文件事件分派器，分派器会根据套接字产生的事件类型调用相应的事件处理器。

时间事件

服务器有一些操作需要在给定的时间点执行，时间事件是对这类定时操作的抽象。

时间事件又分为：

• 定时事件：是让一段程序在指定的时间之内执行一次；
• 周期性事件：是让一段程序每隔指定时间就执行一次。

Redis 将所有时间事件都放在一个无序链表中，通过遍历整个链表查找出已到达的时间事件，并调用相应的事件处理器。

事件的调度与执行

服务器需要不断监听文件事件的套接字才能得到待处理的文件事件，但是不能一直监听，否则时间事件无法在规定的时间内执行，因此监听时间应该根据距离现在最近的时间事件来决定。

事件调度与执行由 aeProcessEvents 函数负责，伪代码如下：

def aeProcessEvents():
    # 获取到达时间离当前时间最接近的时间事件
    time_event = aeSearchNearestTimer()
    # 计算最接近的时间事件距离到达还有多少毫秒
    remaind_ms = time_event.when - unix_ts_now()
    # 如果事件已到达，那么 remaind_ms 的值可能为负数，将它设为 0
    if remaind_ms < 0:
        remaind_ms = 0
    # 根据 remaind_ms 的值，创建 timeval
    timeval = create_timeval_with_ms(remaind_ms)
    # 阻塞并等待文件事件产生，最大阻塞时间由传入的 timeval 决定
    aeApiPoll(timeval)
    # 处理所有已产生的文件事件
    procesFileEvents()
    # 处理所有已到达的时间事件
    processTimeEvents()

将 aeProcessEvents 函数置于一个循环里面，加上初始化和清理函数，就构成了 Redis 服务器的主函数，伪代码如下：

def main():
    # 初始化服务器
    init_server()
    # 一直处理事件，直到服务器关闭为止
    while server_is_not_shutdown():
        aeProcessEvents()
    # 服务器关闭，执行清理操作
    clean_server()

从事件处理的角度来看，服务器运行流程如下：

十一、复制

通过使用 slaveof host port 命令来让一个服务器成为另一个服务器的从服务器。

一个从服务器只能有一个主服务器，并且不支持主主复制。

连接过程

1. 主服务器创建快照文件，发送给从服务器，并在发送期间使用缓冲区记录执行的写命令。快照文件发送完毕之后，开始向从服务器发送存储在缓冲区中的写命令；
2. 从服务器丢弃所有旧数据，载入主服务器发来的快照文件，之后从服务器开始接受主服务器发来的写命令；
3. 主服务器每执行一次写命令，就向从服务器发送相同的写命令。

主从链

随着负载不断上升，主服务器可能无法很快地更新所有从服务器，或者重新连接和重新同步从服务器将导致系统超载。为了解决这个问题，可以创建一个中间层来分担主服务器的复制工作。中间层的服务器是最上层服务器的从服务器，又是最下层服务器的主服务器。

十二、Sentinel

Sentinel（哨兵）可以监听集群中的服务器，并在主服务器进入下线状态时，自动从从服务器中选举出新的主服务器。

十三、分片

分片是将数据划分为多个部分的方法，可以将数据存储到多台机器里面，这种方法在解决某些问题时可以获得线性级别的性能提升。

假设有 4 个 Redis 实例 R0，R1，R2，R3，还有很多表示用户的键 user:1，user:2，... ，有不同的方式来选择一个指定的键存储在哪个实例中。

• 最简单的方式是范围分片，例如用户 id 从 01000 的存储到实例 R0 中，用户 id 从 10012000 的存储到实例 R1 中，等等。但是这样需要维护一张映射范围表，维护操作代价很高。
• 还有一种方式是哈希分片，使用 CRC32 哈希函数将键转换为一个数字，再对实例数量求模就能知道应该存储的实例。

根据执行分片的位置，可以分为三种分片方式：

• 客户端分片：客户端使用一致性哈希等算法决定键应当分布到哪个节点。
• 代理分片：将客户端请求发送到代理上，由代理转发请求到正确的节点上。
• 服务器分片：Redis Cluster。

十四、一个简单的论坛系统分析

该论坛系统功能如下：

• 可以发布文章；
• 可以对文章进行点赞；
• 在首页可以按文章的发布时间或者文章的点赞数进行排序显示。

文章信息

文章包括标题、作者、赞数等信息，在关系型数据库中很容易构建一张表来存储这些信息，在 Redis 中可以使用 HASH 来存储每种信息以及其对应的值的映射。

Redis 没有关系型数据库中的表这一概念来将同种类型的数据存放在一起，而是使用命名空间的方式来实现这一功能。键名的前面部分存储命名空间，后面部分的内容存储 ID，通常使用 : 来进行分隔。例如下面的 HASH 的键名为 article:92617，其中 article 为命名空间，ID 为 92617。

点赞功能

当有用户为一篇文章点赞时，除了要对该文章的 votes 字段进行加 1 操作，还必须记录该用户已经对该文章进行了点赞，防止用户点赞次数超过 1。可以建立文章的已投票用户集合来进行记录。

为了节约内存，规定一篇文章发布满一周之后，就不能再对它进行投票，而文章的已投票集合也会被删除，可以为文章的已投票集合设置一个一周的过期时间就能实现这个规定。

对文章进行排序

为了按发布时间和点赞数进行排序，可以建立一个文章发布时间的有序集合和一个文章点赞数的有序集合。（下图中的 score 就是这里所说的点赞数；下面所示的有序集合分值并不直接是时间和点赞数，而是根据时间和点赞数间接计算出来的）

参考资料

• Carlson J L. Redis in Action[J]. Media.johnwiley.com.au, 2013.
• [黄健宏. Redis 设计与实现 M]. 机械工业出版社, 2014.(opens new window)
• REDIS IN ACTION(opens new window)
• Skip Lists: Done Right(opens new window)
• 论述 Redis 和 Memcached 的差异(opens new window)
• Redis 3.0 中文版- 分片(opens new window)
• Redis 应用场景(opens new window)
• Using Redis as an LRU cache