Redis简介

Redis官网

Redis中文网

Redis是一个非关系型的数据库，主要被用作高性能缓存服务器使用，也可以作为消息中间件和Session共享等。Redis独特的键值对模型使之支持丰富的数据结构类型，即它的值可以是字符串、哈希、列表、集合、有序集合，Redis是存储在内存中的，免去了磁盘I/O速度的影响，因此其读写性能极高。并且Redis是单线程的，避免了不必要的上下文切换和竞争条件，不存在多线程切换消耗 CPU

Redis主要做什么

1、缓存

缓存现在几乎是所有中大型网站都在用的必杀技，合理的利用缓存不仅能够提升网站访问速度，还能大大降低数据库的压力。Redis提供了键过期功能，也提供了灵活的键淘汰策略，所以，现在Redis用在缓存的场合非常多。

2、排行榜

很多网站都有排行榜应用的，如淘宝的月度销量榜单、商品按时间的上新排行榜等。Redis提供的有序集合数据类构能实现各种复杂的排行榜应用。

3、计数器

什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景。

4、分布式会话

集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。

5、分布式锁

在很多互联网公司中都使用了分布式技术，分布式技术带来的技术挑战是对同一个资源的并发访问，如全局ID、减库存、秒杀等场景，并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现，但在并发量高的场合中，利用数据库锁来控制资源的并发访问是不太理想的，大大影响了数据库的性能。可以利用Redis的setnx功能来编写分布式的锁，如果设置返回1说明获取锁成功，否则获取锁失败，实际应用中要考虑的细节要更多。

6、 社交网络

点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据，Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。

7、最新列表

Redis列表结构，LPUSH可以在列表头部插入一个内容ID作为关键字，LTRIM可用来限制列表的数量，这样列表永远为N个ID，无需查询最新的列表，直接根据ID去到对应的内容页即可。

8、消息系统

消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

Redis的优势

我们知道类似SQL Server和MySQL等数据库都是关系型数据库，存储方式都是直接存储在磁盘中的，受到磁盘I/O性能的影响，而Redis是直接存储在内存中的，因此运行速度极快

1、响应速度

Redis 响应非常快，每秒可以执行大约 110 000 个写入操作，或者 81 000 个读操作，其速度远超数据库。如果存入一些常用的数据，就能有效提高系统的性能。

2、支持多种数据类型

它们是字符串、哈希结构、列表、集合、可排序集合和基数。比如对于字符串可以存入一些基础数据类型，哈希可以存储对象，列表可以存储 List 对象等。这使得在应用中很容易根据自己的需要选择存储的数据类型，方便开发。

对于 Redis 而言，虽然只有 6 种数据类型，但是有两大好处：一方面可以满足存储各种数据的需要；另外一方面数据类型少，使得规则就少，需要的判断和逻辑就少，这样读/写的速度就更快。

3、原子性

所有 Redis 的操作都是原子的，从而确保当两个客户同时访问 Redis 服务器时，得到的是更新后的值（最新值）。在需要高并发的场合可以考虑使用 Redis 的事务，处理一些需要锁的业务。

4、MultiUtility 工具

Redis 可以在如缓存、消息传递队列中使用（Redis 支持“发布+订阅”的消息模式），在应用程序如 Web 应用程序会话、网站页面点击数等任何短暂的数据中使用。

Redis的数据类型

• STRING：字符串、整数或浮点数
• LIST：列表，可存储多个相同的字符串
• SET：集合，存储不同元素，无序排列
• HASH：散列表，存储键值对之间的映射，无序排列
• ZSET：有序集合，存储键值对，有序排列

类型	简介	特性	场景
String(字符串)	二进制安全	可以包含任何数据,比如jpg图片或者序列化的对象,一个键最大能存储512M	---
Hash(字典)	键值对集合,即编程语言中的Map类型	适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值(Memcached中需要取出整个字符串反序列化成对象修改完再序列化存回去)	存储、读取、修改用户属性
List(列表)	链表(双向链表)	增删快,提供了操作某一段元素的API	1,最新消息排行等功能(比如朋友圈的时间线) 2,消息队列
Set(集合)	哈希表实现,元素不重复	1、添加、删除,查找的复杂度都是O(1) 2、为集合提供了求交集、并集、差集等操作	1、共同好友 2、利用唯一性,统计访问网站的所有独立ip 3、好友推荐时,根据tag求交集,大于某个阈值就可以推荐
Sorted Set(有序集合)	将Set中的元素增加一个权重参数score,元素按score有序排列	数据插入集合时,已经进行天然排序	1、排行榜 2、带权重的消息队列

Redis的安装

首先呢，想要使用Redis需要要先安装下Redis,可以下载安装包安装，也可以去GitHub上下载GitHub地址

下载之后解压缩能看到下面的文件

在当前页面打开cmd窗口输入下面的命令，就可以启动Redis了

redis-server.exe redis.windows.conf

当看到下面的信息时，说明启动成功了 Redis的基本使用

配置文件

此处就直接复制官方文档的了，下面会讲到具体的使用情况怎么配置

redis.conf 配置项说明如下：

1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程

    daemonize no

2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定

    pidfile /var/run/redis.pid

3. 指定Redis监听端口，默认端口为6379

    port 6379

4. 绑定的主机地址

    bind 127.0.0.1

5.当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能

    timeout 300

6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose

    loglevel verbose

7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null

    logfile stdout

8. 设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id

    databases 16

9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

    save  

    Redis默认配置文件中提供了三个条件：

    save 900 1

    save 300 10

    save 60 10000

    分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。 

10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大

    rdbcompression yes

11. 指定本地数据库文件名，默认值为dump.rdb

    dbfilename dump.rdb

12. 指定本地数据库存放目录

    dir ./

13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步

    slaveof  

14. 当master服务设置了密码保护时，slav服务连接master的密码

    masterauth 

15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭

    requirepass foobared

16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息

    maxclients 128

17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区

    maxmemory 

18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no

    appendonly no

19. 指定更新日志文件名，默认为appendonly.aof

     appendfilename appendonly.aof

20. 指定更新日志条件，共有3个可选值：     no：表示等操作系统进行数据缓存同步到磁盘（快）     always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）     everysec：表示每秒同步一次（折衷，默认值）

    appendfsync everysec

 

21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）

     vm-enabled no

22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享

     vm-swap-file /tmp/redis.swap

23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0

     vm-max-memory 0

24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值

     vm-page-size 32

25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。

     vm-pages 134217728

26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4

     vm-max-threads 4

27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启

    glueoutputbuf yes

28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法

    hash-max-zipmap-entries 64

    hash-max-zipmap-value 512

29. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）

    activerehashing yes

30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

    include /path/to/local.conf

Redis命令

要想使用Redis命令，必须启动Redis的客户端，在我们之前下载的安装包中redis-cli.exe,当然我们不能直接双击运行，需要通过cmd命令启动

redis-cli.exe -h host -p port -a password

host为地址，host为127.0.0.1，可以通过更改配置文件bind配置，port为端口号，默认为6379，同样也可以通过配置文件port节点更改，password是密码，默认是没有密码的，需要密码更改配置文件requirepass节点设置密码。

进入客户端后就能执行redis的命令了，输入命令ping可以检测 redis 服务是否启动，如果启动是返回PONG，未启动则返回异常

简单的设置获取删除数据的命令

其他数据类型的操作就不一一介绍了，可以查看官网的教程

HyperLogLog

来源：Redis 中 HyperLogLog 的使用场景 - 知乎 (zhihu.com)

HyperLogLog 是一种基数估算算法。所谓基数估算，就是估算在一批数据中，不重复元素的个数有多少。

从数学上来说，基数估计这个问题的详细描述是：对于一个数据流 {x1，x2，...，xs} 而言，它可能存在重复的元素，用 n 来表示这个数据流的不同元素的个数，并且这个集合可以表示为{e1，...，en}。目标是：使用 m 这个量级的存储单位，可以得到 n 的估计值，其中 m<

对于上面这个问题，如果是想得到精确的基数，可以使用字典（dictionary）这一个数据结构。对于新来的元素，可以查看它是否属于这个字典；如果属于这个字典，则整体计数保持不变；如果不属于这个字典，则先把这个元素添加进字典，然后把整体计数增加一。当遍历了这个数据流之后，得到的整体计数就是这个数据流的基数了。

这种算法虽然精准度很高，但是使用的空间复杂度却很高。那么是否存在一些近似的方法，可以估算出数据流的基数呢？HyperLogLog 就是这样一种算法，既可以使用较低的空间复杂度，最后估算出的结果误差又是可以接受的。

应用场景

HyperLogLog 主要的应用场景就是进行基数统计。这个问题的应用场景其实是十分广泛的。例如：对于 Google 主页面而言，同一个账户可能会访问 Google 主页面多次。于是，在诸多的访问流水中，如何计算出 Google 主页面每天被多少个不同的账户访问过就是一个重要的问题。那么对于 Google 这种访问量巨大的网页而言，其实统计出有十亿 的访问量或者十亿零十万的访问量其实是没有太多的区别的，因此，在这种业务场景下，为了节省成本，其实可以只计算出一个大概的值，而没有必要计算出精准的值。

对于上面的场景，可以使用HashMap、BitMap和HyperLogLog来解决。对于这三种解决方案，这边做下对比：

• HashMap：算法简单，统计精度高，对于少量数据建议使用，但是对于大量的数据会占用很大内存空间；
• BitMap：位图算法，具体内容可以参考我的这篇文章，统计精度高，虽然内存占用要比HashMap少，但是对于大量数据还是会占用较大内存；
• HyperLogLog：存在一定误差，占用内存少，稳定占用 12k 左右内存，可以统计 2^64 个元素，对于上面举例的应用场景，建议使用。

Redis事务

Redis的事务跟我们常用的数据库有点区别，下面就进行详细的介绍

multi命令开启事务，exec命令执行事务，下面是事务正常情况下的使用情况

discard取消事务，事务取消后再exec就会返回错误

当事务中间执行的时候报错了会怎么处理呢

可以看到，当我们输入错误的命令的时候，事务返回了报错，也并没有执行事务中的其他命令

可以看到，我们没有输入错误的命令，但是执行的时候报错了，这时候其他的命令还是执行成功了。

已经执行完成的事务并不会回滚，需要在代码中进行手动回滚，需要记录被影响数据执行前的状态，回滚的时候再修改回去，这也就是Redis和SQL Server等数据库事务不同的地方。

为什么这么设计呢，主要也是处于对性能的考虑。

持久化存储

RDB

实现起来其实很简单，默认RDB是开启的，我们可以查看配置可以看到，执行命令save就会备份当前Redis,会在当前Redis目录中生成备份文件dump.rdb，想要恢复的时候只需要把备份文件复制到目录中，然后重启服务就行了，命令bgsave 既后台保存的意思， 它和 save 命令最大的区别就是 bgsave 会 fork() 一个子进程来执行持久化，整个过程中只有在 fork() 子进程时有短暂的阻塞，当子进程被创建之后，Redis 的主进程就可以响应其他客户端的请求了。一般推荐bgsave命令。flushall命令是清空Redis所有数据，慎用。

save 900 1
save 300 10
save 60 10000

# bgsave 失败之后，是否停止持久化数据到磁盘，yes 表示停止持久化，no 表示忽略错误继续写文件。
stop-writes-on-bgsave-error yes

# RDB 文件压缩
rdbcompression yes

# 写入文件和读取文件时是否开启 RDB 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。
rdbchecksum yes

# RDB 文件名
dbfilename dump.rdb

# RDB 文件目录
dir ./

其中比较重要的参数如下列表：

1、save 参数 它是用来配置触发 RDB 持久化条件的参数，满足保存条件时将会把数据持久化到硬盘。 默认配置说明如下：

• save 900 1：表示 900 秒内如果至少有 1 个 key 值变化，则把数据持久化到硬盘；

• save 300 10：表示 300 秒内如果至少有 10 个 key 值变化，则把数据持久化到硬盘；

• save 60 10000：表示 60 秒内如果至少有 10000 个 key 值变化，则把数据持久化到硬盘。

2、rdbcompression 参数 它的默认值是 yes 表示开启 RDB 文件压缩，Redis 会采用 LZF 算法进行压缩。如果不想消耗 CPU 性能来进行文件压缩的话，可以设置为关闭此功能，这样的缺点是需要更多的磁盘空间来保存文件。

3、rdbchecksum 参数 它的默认值为 yes 表示写入文件和读取文件时是否开启 RDB 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。

优缺点

优点

• RDB 的内容为二进制的数据，占用内存更小，更紧凑，更适合做为备份文件；
• RDB 对灾难恢复非常有用，它是一个紧凑的文件，可以更快的传输到远程服务器进行 Redis 服务恢复；
• RDB 可以更大程度的提高 Redis 的运行速度，因为每次持久化时 Redis 主进程都会 fork() 一个子进程，进行数据持久化到磁盘，Redis 主进程并不会执行磁盘 I/O 等操作；

与 AOF 格式的文件相比，RDB 文件可以更快的重启。

缺点

• 因为 RDB 只能保存某个时间间隔的数据，如果中途 Redis 服务被意外终止了，则会丢失一段时间内的 Redis 数据；
• RDB 需要经常 fork() 才能使用子进程将其持久化在磁盘上。如果数据集很大，fork() 可能很耗时，并且如果数据集很大且 CPU 性能不佳，则可能导致 Redis 停止为客户端服务几毫秒甚至一秒钟。

AOF

使用 RDB 持久化有一个风险，它可能会造成最新数据丢失的风险。因为 RDB 的持久化有一定的时间间隔，在这个时间段内如果 Redis 服务意外终止的话，就会造成最新的数据全部丢失。

可能会操作 Redis 服务意外终止的条件：

• 安装 Redis 的机器停止运行，蓝屏或者系统崩溃；

• 安装 Redis 的机器出现电源故障，例如突然断电；

• Redis被强制关闭等等。

那么如何解决以上的这些问题呢？Redis 为我们提供了另一种持久化的方案——AOF。

AOF 把 Redis 每个键值对操作都记录到文件（appendonly.aof）中。

AOF 持久化开启之后，只要满足一定条件，就会触发 AOF 持久化。

AOF 的触发条件分为两种：自动触发和手动触发。

#AOF 开关yes和no
appendonly yes
#AOF 文件名
appendfilename "appendonly.aof"

#AOF 刷盘配置
#always：每条 Redis 操作命令都会写入磁盘，最多丢失一条数据；
#everysec：每秒钟写入一次磁盘，最多丢失一秒的数据；
#no：不设置写入磁盘的规则，根据当前操作系统来决定何时写入磁盘，Linux 默认 30s 写入一次数据至磁盘。
appendfsync everysec

#AOF 重写时是否做appendfsync操作，如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
#如果设置为yes，这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区。因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。
no-appendfsync-on-rewrite no

#AOF 文件重写的大小比例，默认值是 100，表示 100%，也就是只有当前 AOF 文件，比最后一次（上次）的 AOF 文件大一倍时，才会启动 AOF 文件重写。
auto-aof-rewrite-percentage 100

#AOF 重写的最小文件容量，默认是 64mb。
auto-aof-rewrite-min-size 64mb

# 是否开启启动时加载 AOF 文件效验，默认值是 yes，表示尽可能的加载 AOF 文件，忽略错误部分信息，并启动 Redis 服务。
# 如果值为 no，则表示，停止启动 Redis，用户必须手动修复 AOF 文件才能正常启动 Redis 服务。
aof-load-truncated yes

#混合持久化
aof-use-rdb-preamble yes

AOF重写

什么是AOF重写？为什么需要重写？

AOF 是通过保存被执行的写命令来记录数据库状态的，当我们开启了AOF功能的时候，所有的操作都会存在一个AOF文件中，但是随着使用时间的增加和数据量的增加，这个AOF文件会越来越大，而这个文件大小到达了我们设置的最小文件容量或者重写的大小比例的时候就会自动去触发重写，Redis创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。

但是，如果AOF文件特别大或者数据特别多的时候，往往重写的速度会比较长，如果这时候进来新的appendfsync操作怎么办呢，当然可以设置no-appendfsync-on-rewrite为no，这时候就先不会执行appendfsync的操作，会阻塞当前进程，如果当前AOF文件很大，那么相应的重写时间会变长，appendfsync被阻塞的时间也会更长，等重写完成后才会继续执行appendfsync操作。如果no-appendfsync-on-rewrite设置成yes，Redis会复制一个缓存区，fork出子进程去执行重写的操作，这时候住进程执行了appendfsync操作后，会同时更新到AOF和AOF重写两个缓存，这样就不会阻塞主进程的操作，但是这种方式也存在问题，可能会丢失数据，这个是无法避免的。

总结

出于数据安全的考虑，可以选择设置no-appendfsync-on-rewrite为no，出于性能和体验的考虑，可以设置no-appendfsync-on-rewrite设置成yes。

那有没有折中的解决方案呢？

因为AOF重写可能会丢失数据的可能，这种情况一般发生在使用的高峰期，AOF文件触发了自动重写的机制。我们可以关闭自动重写，选择在低峰期的时候手动调用bgrewriteaof命令手动重写，这个低峰期的时间就根据业务情况自己选择，一般都是在凌晨。

优缺点

优点

• AOF 持久化保存的数据更加完整。
• AOF 提供了三种保存策略：每次操作保存、每秒钟保存一次、跟随系统的持久化策略保存，其中每秒保存一次，从数据的安全性和性能两方面考虑是一个不错的选择，也是 AOF 默认的策略，即使发生了意外情况，最多只会丢失 1s 钟的数据。
• AOF 采用的是命令追加的写入方式，所以不会出现文件损坏的问题，即使由于某些意外原因，导致了最后操作的持久化数据写入了一半，也可以通过 redis-check-aof 工具轻松的修复。
• AOF 持久化文件，非常容易理解和解析，它是把所有 Redis 键值操作命令，以文件的方式存入了磁盘。即使不小心使用 flushall 命令删除了所有键值信息，只要使用 AOF 文件，删除最后的 flushall 命令，重启 Redis 即可恢复之前误删的数据。

缺点

• 对于相同的数据集来说，AOF 文件要大于 RDB 文件；
• 在 Redis 负载比较高的情况下，RDB 比 AOF 性能更好；
• RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 更健壮。