排行榜：有序集合经典使用场景。例如小说视频等网站需要对用户上传的小说视频做排行榜，榜单可以按照用户关注数，更新时间，字数等打分，做排行。
消息队列：带权重的消息队列。
有序集合的命令都是 以 z 开头 zadd 、 zrange、 zscore。如下图：
最后，还有对key通用的操作命令，对所有的数据类型都可以使用，如下图：
Redis是一个内存数据库，数据保存在内存中，但是我们都知道内存的数据变化是很快的，容易发生丢失，而且redis重启后数据就全丢失了，幸好Redis还为我们提供了持久化的机制，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB(Redis DataBase)，原理是将Reids在内存中的数据库记录定时dump到磁盘文件中，另外一种是AOF(Append Only File)持久化，原理是将Reids的操作日志以追加的方式写入文件。
Redis的数据可以保存在磁盘上，这个流程可以分为五个过程：
（1）客户端向服务端发送写操作(数据在客户端的内存中)。
（2）数据库服务端接收到写请求的数据(数据在服务端的内存中)。
（3）服务端调用write这个系统调用，将数据往磁盘上写(数据在系统内存的缓冲区中)。
（4）操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。
（5）磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。
这5个过程是在理想条件下一个正常的保存流程，但是在大多数情况下，我们的机器都会有各种各样的故障，这里划分了两种情况：1、Redis数据库发生故障，只要在上面的第三步执行完毕，那么就可以持久化保存，剩下的两步由操作系统替我们完成/2、操作系统发生故障，必须上面5步都完成才可以。
在这里只考虑了保存的过程可能发生的故障，其实保存的数据也有可能发生损坏，需要一定的恢复机制，不过在这里就不再延伸了。接下来我们主要谈谈Redis如何来实现上面5个保存磁盘的步骤。
RDB持久化RDB其实就是把数据以快照的形式保存在磁盘上。快照你可以理解成把当前时刻的数据拍成一张照片保存下来。RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，也是默认的持久化方式，这种方式就是Redis运行过程中，达到了一定时间点或者其他限制（比如手动刷写），启动一个子进程fork整个主进程，在子进程中将redis内存中数据以快照的方式写入到二进制的临时文件中，等这个持久化过程结束后，将这个临时文件替换上次持久化的文件，默认的文件名为dump.rdb，其实就是冷备份。既然RDB机制是通过把某个时刻的所有数据生成一个快照来保存，那么就应该有一种触发机制，来实现这个过程。对于RDB来说，提供了三种机制：save、bgsave、自动化。
save触发方式该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止，也就是说IO类型是同步串行的。执行完成的时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。
bgsave触发方式执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
自动触发自动触发是由我们的配置文件来完成的。在redis.conf配置文件中，里面有如下配置：
名称 内容save 用来配置快照触发的条件，也就是什么时候将内存中的数据保存到硬盘，比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。save ""表示关闭RDB。
stop-writes-on-bgsave-error 当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。默认值为yes，如果最后一次后台保存数据失败了，此时可以让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了；如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制
rdbcompression 对于存储到磁盘中的快照，可以设置是否进行压缩存储。默认值是yes，这需要消耗额外的CPU资源
rdbchecksum 在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。默认值是yes。
dbfilename 存储的RDB数据文件名称，默认为dump.rdb
dir 设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。
我们可以修改这些配置来实现我们想要的效果。
优劣势优势：
（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复，适合大规模的数据恢复且对数据完整性和一致性要求不高。
（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快，启动效率会更高。。
劣势：