Redis --- 概述、线程模型与基本使用

什么是redis？

redis简介(Remote dictionary Server 远程字典服务器):

Redis是开源免费的，由C语言编写的，数据存放在内存，并支持持久化的Nosql数据库，是一种内存数据库，所以它读写速度非常快，主要应用在数据缓存方向。Redis 也经常用来做分布式锁，甚至是消息队列。

Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支持事务 、持久化、Lua 脚本、多种集群方案。

ps：缓存数据处理流程

大致流程：

• 命中缓存就返回
• 缓存没命中，去数据库检查数据是否存在
• 数据库存在的话，更新缓存，返回数据
• 数据库不存在，返回空数据

redis具备的基本特征：

• 支持多数据类型
• 持久化机制
• 主从同步

redis关于key-value的三大特点:

1. redis是支持持久化的！我们可以控制数据何时、用何种方式保存到磁盘中，每次重启再次加载该文件，可以完成数据恢复。
2. redis不单单支持简单的key-value数据类型，同时还可以提供list、set、hash、zset等数据类型的存储
3. 支持数据的备份。mater-slave模式，即,当下时髦的主从复制读写分离。

应用场景：

• 内存存储的持久化: 虽然redis是单线程实现的，但是支持异步将数据持久化到硬盘上，同时不影响继续服务。
• 发布订阅：Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。
• 定时器、计时器: 我们可以把这个特性用到发短信的服务中，每次发送完短信后，就进入倒计时。在指定的时间内拒绝发送第二次，可以有效的缓解短信服务的压力，节流。
• 取出最新的N个数据的操作: 比如新浪微博的评论系统，他要展示最新的10条评论，就是把最新的10条评论的id放到redis的list里面。

redis为什么这么快？

• 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速；
• 数据结构简单，对数据操作也简单，比如SDS；
• 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
• 使用多路 I/O 复用模型，非阻塞 IO。

分布式缓存常见的技术选型？ Memcache 与 Redis区别
分布式缓存的话，使用的比较多的主要是 Memcached 和 Redis。不过，现在基本没有看过还有项目使用 Memcached 来做缓存，都是直接用 Redis。

Memcached 是分布式缓存最开始兴起的那会，比较常用的。后来，随着 Redis 的发展，大家慢慢都转而使用更加强大的 Redis 了。

分布式缓存主要解决的是单机缓存的容量受服务器限制并且无法保存通用的信息。因为，本地缓存只在当前服务里有效，比如如果你部署了两个相同的服务，他们两者之间的缓存数据是无法共同的。

共同点：

• 都是基于内存的数据库，一般都用来当做缓存使用。
  都有过期策略。
  两者的性能都非常高。

区别：

• 存储方式不同（持久化）： Memcache 把数据全部存在内存之中，断电后会丢失，满了会报异常。Redis 所有数据加载在内存，但也会持久化到磁盘，保证数据的持久性（优势），满了会将不用的数据存放在磁盘上。
• 支持数据类型不同： Memcache 对数据类型支持相对简单，只支持 key-value 结构。Redis 有复杂的数据类型（功能更强）。
• Memcached 是多线程，非阻塞 IO 复用的网络模型；Redis 使用单线程的多路 IO 复用模型。 （Redis 6.0 引入了多线程 IO ）
• 过期数据删除策略不同：Memcached 过期数据的删除策略只用了惰性删除，而 Redis 同时使用了惰性删除与定期删除。
• Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持。并且，Redis 支持更多的编程语言。

redis和mongodb区别

MongoDB和Redis都是NoSQL，采用结构型数据存储。二者在使用场景中，存在一定的区别，这也主要由于二者在内存映射的处理过程，持久化的处理方法不同。MongoDB建议集群部署，更多的考虑到集群方案，Redis更偏重于进程顺序写入，虽然支持集群，也仅限于主-从模式。

MongoDB 更类似 MySQL，支持字段索引、游标操作，其优势在于查询功能比较强大，擅长查询 JSON 数据，能存储海量数据，但是不支持事务。

MySQL 在大数据量时效率显著下降，MongoDB 更多时候作为关系数据库的一种替代。

Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。它支持多种类型的数据结构。

主要区别：

• 内存的管理机制：Redis 数据全部存在内存，定期写入磁盘，当内存不够时，可以选择指定的 LRU 算法删除数据；MongoDB 数据存在内存，由 linux系统 mmap 实现，当内存不够时，只将热点数据放入内存，其他数据存在磁盘。

• 持久化方式：mongodb的所有数据实际上是存放在硬盘的，所有要操作的数据通过mmap的方式映射到内存某个区域内。然后，mongodb就在这块区域里面进行数据修改，避免了零碎的硬盘操作。至于mmap上的内容flush到硬盘就是操作系统的事情了，所以，如果，mongodb在内存中修改了数据后，mmap数据flush到硬盘之前，系统宕机了，数据就会丢失。

mmap详解链接：http://www.cnblogs.com/techdoc/archive/2010/12/22/1913521.html

（mmap系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式，进程可以像读写内存一样对普通文件进行操作。
mmap 系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问，不必再调用。 read()，write（）等操作。mmap并不分配空间, 只是将文件映射到调用进程的地址空间里, 然后你就可以用memcpy等操作写文件, 而不用write()了.写完后用msync()同步一下, 你所写的内容就保存到文件里了. 不过这种方式没办法增加文件的长度, 因为要映射的长度在调用mmap()的时候就决定了。）

redis所有数据都是放在内存中的，持久化是使用RDB方式或者aof方式。
mysql：无论数据还是索引都存放在硬盘中。到要使用的时候才交换到内存中。能够处理远超过内存总量的数据。

• 支持的数据结构不同：Redis 支持的数据结构丰富，包括hash、set、list等。MongoDB 数据结构比较单一，但是支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。

• 数据量和性能：当物理内存够用的时候，性能：redis>mongodb>mysql。当物理内存不够用的时候，redis和mongodb都会使用虚拟内存。实际上如果redis要开始虚拟内存，那很明显要么加内存条，要么你换个数据库了。但是，mongodb不一样，只要，业务上能保证，冷热数据的读写比，使得热数据在物理内存中，mmap的交换较少。mongodb还是能够保证性能。

• 事务支持：Redis 事务支持比较弱，只能保证事务中的每个操作连续执行，mongodb不支持事务

redis安装与启动

安装redis

去官网下载压缩包：https://redis.io/download 或者通过 redis 官网提供的在线 redis 环境。

安装依赖、编译、安装：

1[root@instance-lynj0v9k-19 redis-5.0.9]# yum install gcc-c++
2[root@instance-lynj0v9k-19 redis-5.0.9]# make
3[root@instance-lynj0v9k-19 redis-5.0.9]# make install

我们自己安装的程序默认都在 /usr/local/bin目录下

启动redis

将redis的配置文件拷贝到/usr/local/bin目录下，之后使用这个配置文件启动。

修改配置文件，让redis后台启动。

1daemonize no # 修改成 yes

指定配置文件，启动redis。

1redis-server /绝对路径/redis.conf

使用redis-client连接redis。

1redis-cli -h 地址 -p 端口号

退出

1# 关闭redis-server
2127.0.0.1:16379> shutdown
3
4# 退出redis-cli
5not connected> exit
6
7# 重新尝试连接，因为redis-server被关闭了，所以会被拒绝
8[root@instance-lynj0v9k-19 bin]# redis-cli -p 16379
9Could not connect to Redis at 127.0.0.1:16379: Connection refused
10not connected> exit
11
12# 查看redis-server是否还在
13[root@instance-lynj0v9k-19 bin]# netstat -luntp | grep 16379
14[root@instance-lynj0v9k-19 bin]#

redis常用基础命令

点击查看所有命令

1# redis默认存在16个数据库，默认一开始使用的是第0个
2[root@instance-lynj0v9k-19 bin]# cat redis.conf | grep  'databases'
3databases 16
4
5# 切换数据库
6127.0.0.1:16379> select 2
7OK
8127.0.0.1:16379[2]>
9
10# 查看数据库容量
11127.0.0.1:16379[2]> DBSIZE
12(integer) 0
13
14# 查看所有的key
15127.0.0.1:16379[2]> keys *
16(empty list or set)
17
18# 清空当前数据库中的值
19127.0.0.1:16379[2]> flushdb
20OK
21
22# 清空所有库
23127.0.0.1:16379[2]> flushall
24OK

数据库的相关命令	指令
关闭redis	shutdown
选择数据库（共16个库，默认使用第一个，索引为0）	select 库索引
查看当前数据库中key的数量	Dbsize
清空当前库	Flushdb
通杀所有库	Flushall

key常用命令	指令
查看所有key	keys *
判断某个key是否存在	exists key
把key移动到别的库	move key db
为key 设定过期时间	expire key 秒钟
查看还有多少秒过期	ttl key
查看当前key是什么类型的	type key

补充问题：为什么用redis？

简单说：提升用户体验和应对更多的用户

下面我们主要从“高性能”和“高并发”这两点来看待这个问题。

高性能 ：

对照上面 👆 我画的图。我们设想这样的场景：

假如用户第一次访问数据库中的某些数据的话，这个过程是比较慢，毕竟是从硬盘中读取的。但是，如果说，用户访问的数据属于高频数据并且不会经常改变的话，那么我们就可以很放心地将该用户访问的数据存在缓存中。

这样有什么好处呢？ 那就是保证用户下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。

不过，要保持数据库和缓存中的数据的一致性。 如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

高并发：

一般像 MySQL 这类的数据库的 QPS 大概都在 1w 左右（4 核 8g） ，但是使用 Redis 缓存之后很容易达到 10w+，甚至最高能达到 30w+（就单机 redis 的情况，redis 集群的话会更高）。

ps：QPS（Query Per Second）：服务器每秒可以执行的查询次数；

所以，直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而，我们也就提高的系统整体的并发。

redis线程模型（单 -> 多线程）

Redis 基于 Reactor 模式来设计开发了自己的一套高效的事件处理模型 （Netty 的线程模型也基于 Reactor 模式，Reactor 模式不愧是高性能 IO 的基石），这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。

既然是单线程，那怎么监听大量的客户端连接呢？

• Redis 通过IO 多路复用程序 来监听来自客户端的大量连接（或者说是监听多个 socket），它会将感兴趣的事件及类型(读、写）注册到内核中并监听每个事件是否发生。

• 这样的好处非常明显： I/O 多路复用技术的使用让 Redis 不需要额外创建多余的线程来监听客户端的大量连接，降低了资源的消耗（和 NIO 中的 Selector 组件很像）。

• 另外， Redis 服务器是一个事件驱动程序，服务器需要处理两类事件： 1. 文件事件; 2. 时间事件。

• 时间事件不需要多花时间了解，我们接触最多的还是 文件事件（客户端进行读取写入等操作，涉及一系列网络通信）。

《Redis 设计与实现》有一段话是如是介绍文件事件的，我觉得写得挺不错。

• Redis 基于 Reactor 模式开发了自己的网络事件处理器：这个处理器被称为文件事件处理器（file event handler）。文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字，并根据 套接字目前执行的任务来为套接字关联不同的事件处理器。

• 当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关 闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

• 虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与 Redis 服务器中其他同样以单线程方式运行的模块进行对接，这保持了 Redis 内部单线程设计的简单性。

文件事件处理器，主要包括四个部分：

• 多个 socket（客户端连接）
• IO 多路复用程序（支持多个客户端连接的关键）
• 文件事件分派器（将 socket 关联到相应的事件处理器）
• 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

虽然说 Redis 是单线程模型，但是，实际上，Redis 在 4.0 之后的版本中就已经加入了对多线程的支持。

不过，Redis 4.0 增加的多线程主要是针对一些大键值对的删除操作的命令，使用这些命令就会使用主处理之外的其他线程来“异步处理”。

Redis在处理客户端的请求时，包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理，这就是所谓的“单线程”。但如果严格来讲从Redis4.0之后并不是单线程，除了主线程外，它也有后台线程在处理一些较为缓慢的操作，例如清理脏数据、无用连接的释放、大 key 的删除等等。

大体上来说，Redis 6.0 之前主要还是单线程处理。那，Redis6.0 之前 为什么不使用多线程？

我觉得主要原因有下面 3 个：

• 单线程编程容易并且更容易维护；
• Redis 的性能瓶颈不在 CPU ，主要在内存和网络；
• 多线程就造成执行顺序不确定，会存在死锁、线程上下文切换，加解锁等问题，甚至会影响性能。

Redis6.0 引入多线程主要是为了充分利用cpu资源，提高网络 IO 读写性能，因为这个算是 Redis 中的一个性能瓶颈（Redis 的瓶颈主要受限于内存和网络）。

虽然，Redis6.0 引入了多线程，但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了， 执行命令仍然是单线程顺序执行。因此，你也不需要担心线程安全问题。

# Redis6.0 的多线程默认是禁用的，只使用主线程。如需开启需要修改 redis 配置文件 redis.conf ：
io-threads-do-reads yes

# 开启多线程后，还需要设置线程数，否则是不生效的。同样需要修改 redis 配置文件 redis.conf :
io-threads 4 #官网建议4核的机器建议设置为2或3个线程，8核的建议设置为6个线程

ps：Redis6.0与Memcached多线程模型对比

• 相同点：都采用了 master线程-worker 线程的模型

• 不同点：Memcached 执行主逻辑也是在 worker 线程里，模型更加简单，实现了真正的线程隔离，符合我们对线程隔离的常规理解。而 Redis 把处理逻辑交还给 master 线程，虽然一定程度上增加了模型复杂度，但也解决了线程并发安全等问题。

ps：Redis线程中经常提到IO多路复用，如何理解？

• 这是IO模型的一种，即经典的Reactor设计模式，有时也称为异步阻塞IO。

• 多路指的是多个socket连接，复用指的是复用一个线程。多路复用主要有三种技术：select，poll，epoll。epoll是最新的也是目前最好的多路复用技术。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗），且Redis在内存中操作数据的速度非常快（内存内的操作不会成为这里的性能瓶颈），主要以上两点造就了Redis具有很高的吞吐量。

拓展：高性能IO模型

服务器端编程经常需要构造高性能的IO模型，常见的IO模型有四种：

• 同步阻塞IO（Blocking IO）：最简单，用户线程在内核进行IO操作时被阻塞。用户线程通过系统调用read发起IO读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作。
  缺点：整个IO请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够。

• 同步非阻塞IO（Non-blocking IO）：同步非阻塞IO是在同步阻塞IO的基础上，将socket设置为NONBLOCK。由于socket是非阻塞的方式，因此用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。
  缺点：虽然用户线程每次发起IO请求后可以立即返回，但是为了等到数据，仍需要不断地轮询、重复请求，消耗了大量的CPU的资源。一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。

• IO多路复用（IO Multiplexing）：即经典的Reactor设计模式，有时也称为异步阻塞IO，Java中的Selector和Linux中的epoll都是这种模型。IO多路复用模型是建立在内核提供的多路分离函数select基础之上的，使用select函数可以避免同步非阻塞IO模型中轮询等待的问题。
  基本流程：用户首先将需要进行IO操作的socket添加到select中，然后阻塞等待select系统调用返回。当数据到达时，socket被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。
  从流程上来看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视socket，以及调用select函数的额外操作，效率更差。但是，使用select以后最大的优势是用户可以在一个线程内同时处理多个socket的IO请求。用户可以注册多个socket，然后不断地调用select读取被激活的socket，即可达到在同一个线程内同时处理多个IO请求的目的。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的。
  然而，使用select函数的优点并不仅限于此。虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只注册自己感兴趣的socket或者IO请求，然后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率。

• 异步IO（Asynchronous IO）：即经典的Proactor设计模式，也称为异步非阻塞IO。“真正”的异步IO需要操作系统更强的支持。在IO多路复用模型中，事件循环将文件句柄的状态事件通知给用户线程，由用户线程自行读取数据、处理数据。而在异步IO模型中，当用户线程收到通知时，数据已经被内核读取完毕，并放在了用户线程指定的缓冲区内，内核在IO完成后通知用户线程直接使用即可。

拓展：同步、异步和阻塞、非阻塞

• 同步和异步的概念描述的是用户线程与内核的交互方式：同步是指用户线程发起IO请求后需要等待或者轮询，内核IO操作完成后才能继续执行；而异步是指用户线程发起IO请求后仍继续执行，当内核IO操作完成后会通知用户线程，或者调用用户线程注册的回调函数。

• 阻塞和非阻塞的概念描述的是用户线程调用内核IO操作的方式：阻塞是指IO操作需要彻底完成后才返回到用户空间；而非阻塞是指IO操作被调用后立即返回给用户一个状态值，无需等到IO操作彻底完成。

拓展：Reactor设计模式

• EventHandler抽象类表示IO事件处理器，它拥有IO文件句柄Handle（通过get_handle获取），以及对Handle的操作handle_event（读/写等）。
• 继承于EventHandler的子类可以对事件处理器的行为进行定制。
• Reactor类用于管理EventHandler（注册、删除等），并使用handle_events实现事件循环，不断调用同步事件多路分离器（一般是内核）的多路分离函数select，只要某个文件句柄被激活（可读/写等），select就返回（阻塞），handle_events就会调用与文件句柄关联的事件处理器的handle_event进行相关操作。

通过Reactor的方式，可以将用户线程轮询IO操作状态的工作统一交给handle_events事件循环进行处理。用户线程注册事件处理器之后可以继续执行做其他的工作（异步），而Reactor线程负责调用内核的select函数检查socket状态。当有socket被激活时，则通知相应的用户线程（或执行用户线程的回调函数），执行handle_event进行数据读取、处理的工作。由于select函数是阻塞的，因此多路IO复用模型也被称为异步阻塞IO模型。注意，这里的所说的阻塞是指select函数执行时线程被阻塞，而不是指socket。一般在使用IO多路复用模型时，socket都是设置为NONBLOCK的，不过这并不会产生影响，因为用户发起IO请求时，数据已经到达了，用户线程一定不会被阻塞。

IO多路复用是最常使用的IO模型，但是其异步程度还不够“彻底”，因为它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO，而非真正的异步IO。

巨人的肩膀：

https://snailclimb.gitee.io/javaguide/#/docs/database/Redis/redis-all

https://mp.weixin.qq.com/s/CMu7oXVIKp2s-PXTdMlimA

https://www.cnblogs.com/yanguhung/p/10145755.html

https://www.jianshu.com/p/2b523fbee36f