Redis学习笔记-CSDN博客

本文链接：https://blog.csdn.net/qq_40674098/article/details/99684282

前言

关于NoSQL的介绍和为什么使用NoSQL，可以参考孙立先生写的文章《NoSQL 开篇——为什么要使用 NoSQL》。

1. Redis概述

1.1 什么是Redis？

Redis是用C语言开发的一个开源的高性能键值对（key-value）数据库，它能通过提供多种键值数据类型来适应不同场景下的存储需求。官方提供测试数据，50个并发执行100000个请求,读的速度是110000次/s,写的速度是81000次/s 。

1.2 Redis的应用场景

缓存（数据查询、短连接、新闻内容、商品内容等等）。（最多使用）
聊天室的在线好友列表。
任务队列。（秒杀、抢购、 12306等等）
应用排行榜。
网站访问统计。
数据过期处理（可以精确到毫秒）
分布式集群架构中的session分离。

很多人喜欢把Memcached与Redis进行比较，其实两者并非是一对“孪生兄弟”，这里推荐一篇不错的文章《脚踏两只船的困惑 - Memcached与Redis》，这篇文章很好的介绍了两者的区别，感兴趣的可以了解一下。

2. Redis的数据结构

redis存储的是：key - value格式的数据，其中key都是字符串，value有5种不同的数据结构：

2.1 字符串类型 string

2.2 哈希类型 hash

2.3 列表类型 list

底层是个链表，可选择在列表的左边或则右边插入元素，支持插入重复元素。lrange start end表示范围查询，lrange 0 -1表示查询集合中的所有元素

2.4 集合类型 set

string类型的无序集合，通过HashTable实现，不允许插入重复元素。

2.5 有序集合类型 sortedset

不允许重复元素，且元素有顺序。每个元素都会关联一个double类型的分数，redis正是通过分数来为集合中的成员进行从小到大排序，zset的成员是唯一的，但是分数(score)是可以重复的。

1）zadd key score member score2 member2… ：将所有成员以及该成员的分数存放到sorted- set中。如果该元素已经存在则会用新的分数替换原有的分数。返回值是新加入到集合中的元素个数，不包含之前已经存在的元素。

2）zscore key member: 返回指定成员的分数

3）zcard key: 获取集合中的成员分数

4）zrem key member[member…): 移除集合中指定的成员，可以指定多个成员。

5）zrange key start end [withscores]: 获取集合中脚标为start-end的成员，[withscores]参数表明返回的成员包含其分数。

6）zrevrange key start stop [with scores]: 照元素分数从大到小的顺序返回索引从start到stop之间的所有元素（包含两端的元素）。

7）zremrangebyrank key start stop: 按照排名范围删除元素

8）zremrangebyscore key min max: 按照分数范围删除元素

3. Redis的指令

关于Redis的指令，可参考文档《Redis 命令参考》。

4. Redis的事务

1）Redis通过multi命令开启一个事务，开启事务后所有操作指令都会按输入顺序暂存到一个命令队列中（在事务开启后，加入暂存队列的命令不包括exec、discard 、watch和multi，这四个指令会被立即执行。），在执行exec事务提交之前，可通过discard放弃执行队列中的所有命令，即开启事务之后的所有命令无效。

2）执行exec事务提交之后，暂存队列中的所有命令都将会被串行化的顺序执行，执行期间，Redis不会再为其它客户端的请求提供任何服务，从而保证了事物中的所有命令被原子的执行。

3）和关系型数据库中的事务相比，在Redis事务中如果有某条命令执行失败，其后的命令仍然会被继续执行。

4）在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行exec命令之后，那么该事务中的所有命令都会被服务器执行。

5）当使用 Append-Only模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外部分数据却已经丢失。 Redis服务器会在重新启动时执行系列必要的致性检测，旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的redis-check-aof工具，该工具可以帮助我们定位到数据不致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。

5. Redis的订阅与发布

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

1）subscribe channel: 订阅频道，例： subscribe mychat, 订阅mychat这个频道。

2）subscribe channel*: 批呈订阅频道，例： psubscribe s*, 订阅以"s"开头的频道。

3）publish channel content: 在指定的频道中发布消息，如publish mychat ‘today is a newday’。

6. Redis的持久化

Redis的高性能是由于Redis将所有数据都存储在内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存同步到硬盘中，这一过程就是持久化。

Redis支待两种方式的待久化，一种是RDB方式，一种是AOF方式。可以单独使用其中种或将二者结合使用。

6.1 RDB

RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。

在redis.conf中有以下这段配置：

save 900 1			# 表示900秒内如果至少有 1 个 key 的值变化，则保存
save 300 10			# 表示300秒内如果至少有 10 个 key 的值变化，则保存
save 60  100000		# 表示60秒内如果至少有 10000 个 key 的值变化，则保存

如果你只是用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。你也可以根据需要去更改这个配置，不过不建议更改。

使用RDB有以下几个优势：

1）一旦采用该方式，那么你的整个Redis数据库将只包含一个文件。对于灾难性恢复而言，我们只需要将一个单独的文件压缩后再转移到其他存储介质上。

2）性能最大化。对于Redis的服务进程而言，在开始待久化时，它唯一需要做的就是fork（分叉）出子进程，之后再由子进程完成这些待久化的工作，这样就可以极大的避免服务进程执行IO操作。

3）相比于AOF机制，如果数据集很大， RDB的启动效率会更高。

同时RDB的劣势也是很明显的：

1）系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2）由于RDB是通过fork子进程来协助完成数据待久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

6.2 AOF

AOF是以以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

如果要使用AOF（默认不开启），需要在配置文件中将appendonly设置为yes。可通过appendfilename配置修改指令存放文件名，默认为appendonly.aof。

AOF有三种同步策略：

appendfsync always		# 每次有数据修改发生时都会写入AOF文件
appendfsync everysec	# 每秒同步一次，该策略为AOF默认的缺省策略
appendfsync no			# 从不同步，高效但是数据不会被持久化

Redis同步AOF文件时通过append即追加的方式。Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。当appendfsync配置为always时，数据每到缓冲区就要被写入AOF文件，并且同步AOF文件，所以always的效率是最慢的，但同时也是最安全的。当appendfsync配置为everysec时，AOF中的数据每秒会更新一次，则最多丢失1秒的数据。当appendfsync配置为no时，数据会被写入缓冲区，但何时对AOF文件进行同步由操作系统决定。

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。

你可以通过bgrewriteaof命令执行对AOF文件的重新。

你也可以通过以下配置自动触发对AOF重写的时机：

auto-aof-rewrite-percentage		# 表示执行AOF重写时，当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。
auto-aof-rewrite-min-size		# 表示运行AOF重写时文件大小的最小值，默认为64MB

7. Redis内存回收策略

1）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 Key。

2）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 Key。

3）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 Key。

4）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 Key。

5）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。如果没有对应的键，则回退到noeviction策略。

6）noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。此时Redis只响应读操作。

8. 主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。

关于主从复制，可参考文章《Redis主从复制原理学习总结 - 运维笔记》。

9. 哨兵模式

sentinel（哨兵）是用来监测redis集群中master状态的工具。sentinel是redis高可用的解决方案，sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。