Redis

1、NoSQL简介

REmote Dictionary Server：是一种用C语言开发的开源的高性能键值对数据库。

1.1、WEB1.0 及WEB2.0

​ Web1.0的时代，数据访问量很有限，用一夫当关的高性能的单节点服务器可以解决大部分问题。

Web2.0时代的到来，用户访问量大幅度提升，同时产生了大量的用户数据，加上后来的智能移动设备的普及，所有的互联网平台都面临了巨大的性能挑战。

后来为了解决服务器CPU内存压力。

思考：Session共享问题如何解决？

• 方案一：存在Cookie中

这种方案需要将Session数据以Cookie的形式存在客户端,不安全，网络负担效率低。

• 方案二：存在文件服务器或者是数据库里

此种方案会导致大量的IO操作，效率低。

• 方案三：Session复制

此种方案会导致每个服务器之间必须将Session广播到集群内的每个节点，Session数据会冗余，节点越多浪费越大,存在广播风暴问题。

• 方案四：存在Redis中

目前来看，此种方案是最好的。将Session数据存在内存中，每台服务器都从内存中读取数据，速度快，结构还相对简单。

1.2、Redis是如何解决IO压力的呢？

将活跃的数据缓存到Redis中，客户端的请求先打到缓存中来获取对应的数据，如果能获取到，直接返回，不需要从MySQL中读取。如果缓存中没有，再从MySQL数据库中读取数据，将读取的数据返回并存一份到Redis中，方便下次读取。

扩展: 对于持久化的数据库来说，单个库单个表存在性能瓶颈，因此会通过水平切分、垂直切分、读取分离等技术提升性能，此种解决方案会破坏一定的业务逻辑，但是可以换取更高的性能。

1.3、NoSQL数据库概述

1. NoSQL(NoSQL = Not Only SQL )，意即==“不仅仅是SQL”，泛指非关系型的数据库。==

   NoSQL 不依赖业务逻辑方式存储，而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。

2. NoSQL的特点

   • 不遵循SQL标准
   • 不支持ACID（原子性，一致性，持久性，隔离性）
   • 远超于SQL的性能。

3. NoSQL的适用场景

   • 对数据高并发的读写
   • 海量数据的读写
   • 对数据高可扩展性的

4. NoSQL的不适用场景

   • 需要事务支持
   • 基于sql的结构化查询存储，处理复杂的关系,需要及时查询。

5. 建议: 用不着sql的和用了sql也不行的情况，请考虑用NoSql

2、Redis简介及安装

2.1、Redis是什么

简单来说 redis 就是一个数据库，不过与传统数据库不同的是 redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向。另外，redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外，redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

Redis是一个开源的key-value存储系统。

是完全开源免费的，用c语言编写的，是一个单线程，高性能的（key/value）内存数据库，基于内存运行并支持持久化的nosql数据库。

和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis支持各种不同方式的排序。

与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

2.2、Redis的应用场景

1. 配合关系型数据库做高速缓存

   ​ 高频次，热门访问的数据库，降低数据库IO。

2. 由于其拥有持久化能力，利用其多样的数据结构存储特定的数据。

   • 最新N个数据→通过List实现按自然事件排序的数据
   • 排行榜，TopN→利用zset(有序集合)
   • 时效性的数据，比如手机验证码→Expire过期
   • 计数器，秒杀→原子性，自增方法INCR、DECR
   • 去除大量数据中的重复数据→利用set集合
   • 构建队列→利用list集合
   • 发布订阅消息系统→pub/sub模式

2.3、Redis的启动

1. 默认前台方式启动

   ​ 直接执行redis-server 即可启动后不能操作当前命令窗口。

2. 后台方式启动（推荐）

   • 拷贝一份redis.conf配置文件到其他目录，例如根目录下的myredis目录 /myredis
   • 修改redis.conf文件中的一项配置 daemonize 将no 改为yes，代表后台启动
   • 设置自己的端口号
   • cd /etc/local/bin
   • 执行配置文件进行启动 执行 redis-server /etc/redis.conf
   • ps -ef | grep 进程名
   • 连接客户端 redis-cli
   • kill -9 进程号

启动多个Redis：

• 复制conf文件
• 改port
• 改pidfile
• 改logfile
• 改dir，每个不一样

集群配置：

cluster-enabled yes打开注释

cluster-config-file nodes-6379.conf打开注释并修改（可不改）

当你安装完成之后，你可以先执行 redis-server 让 Redis 启动起来，然后运行命令 redis-benchmark -n 100000 -q 来检测本地同时执行 10 万个请求时的性能：

redis-cli -h localhost -p 6379

2.4、Redis的关闭

1. 单实例关闭

   • 如果还未通过客户端访问，可直接 redis-cli shutdown
   • 如果已经进入客户端,直接 shutdown即可。

2. 多实例关闭

   • 指定端口关闭 redis-cli -p 端口号 shutdown

如何启动多个Redis：

#默认配置启动
redis-server
redis-server –-port 6379
redis-server –-port 6380 ……
# 指定配置文件启动
redis-server redis.conf
redis-server redis-6379.conf
redis-server redis-6380.conf ……
redis-server conf/redis-6379.conf
redis-server config/redis-6380.conf ……
#默认连接
redis-cli
#连接指定服务器
redis-cli -h 127.0.0.1
redis-cli –port 6379
redis-cli -h 127.0.0.1 –port 6379

2.5、Redis的单线程+多路IO复用技术

NIO（多路IO复用）的优势：

• redis是基于内存的，内存的读写速度非常快（纯内存）。
• redis是单线程的，省去了很多上下文切换线程的时间（避免线程切换和竞态消耗）。
• redis使用epoll多路复用技术，可以处理并发的连接（非阻塞IO即NIO）。

阻塞IO：给女神发一条短信, 说我来找你了, 然后就默默的一直等着女神下楼, 这个期间除了等待你不会做其他事情, 属于备胎做法。

非阻塞IO：给女神发短信, 如果不回, 接着再发, 一直发到女神下楼, 这个期间你除了发短信等待不会做其他事情, 属于专一做法。

IO多路复用：找一个宿管大妈来帮你监视下楼的女生, 这个期间你可以些其他的事情. 例如可以顺便看看其他妹子,玩玩王者荣耀, 上个厕所等等.。

IO复用又包括 select, poll, epoll 模式. 那么它们的区别是什么?

1. **select大妈：**每一个女生下楼, select大妈都不知道这个是不是你的女神, 她需要一个一个询问, 并且select大妈能力还有限, 最多一次帮你监视1024个妹子。对应的编程模型就是：一个连接来了，就必须遍历所有已经注册的文件描述符，来找到那个需要处理信息的文件描述符，如果已经注册了几万个文件描述符，那会因为遍历这些已经注册的文件描述符，导致cpu爆炸。
2. poll大妈：不限制盯着女生的数量, 只要是经过宿舍楼门口的女生, 都会帮你去问是不是你女神。
3. epoll大妈不限制盯着女生的数量, 并且也不需要一个一个去问. 那么如何做呢? epoll大妈会为每个==进宿舍楼的女生脸上贴上一个大字条,==上面写上女生自己的名字, 只要女生下楼了, epoll大妈就知道这个是不是你女神了, 然后大妈再通知你.

以上这些同步IO有一个共同点就是, 当女神走出宿舍门口的时候, 你已经站在宿舍门口等着女神的, 此时你属于阻塞状态。

接下来还有一种异步IO的做法，更屌。

你告诉女神我来了, 然后你就去王者荣耀了, 一直到女神下楼了, 发现找不见你了, 女神再给你打电话通知你, 说我下楼了, 你在哪呢? 这时候你才来到宿舍门口. 此时属于逆袭做法。

具体的epoll场景（加深理解）：

一个酒吧服务员（一个线程），前面趴了一群醉汉，突然一个吼一声“倒酒”（事件），你小跑过去给他倒一杯，然后随他去吧，突然又一个要倒酒，你又过去倒上，就这样一个服务员服务好多人，有时没人喝酒，服务员处于空闲状态，可以干点别的玩玩手机。至于epoll与select，poll的区别在于后两者的场景中醉汉不说话，你要挨个问要不要酒，没时间玩手机了。io多路复用大概就是指这几个醉汉共用一个服务员。

为什么 Redis 中要使用 I/O 多路复用这种技术呢？

首先，Redis 是单线程的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。

那么阻塞出现的原因是什么呢？

由于进程的执行过程是线性的(也就是顺序执行)，当我们调用低速系统I/O(read，write，accept等等)，进程可能阻塞，此时进程就阻塞在这个调用上，不能执行其他操作，阻塞很正常。接下来考虑这么一个问题：

一个服务器进程和一个客户端进程通信，服务器端read(socket-fd1,bud,bufsize)，此时客户端进程没有发送数据，那么read(阻塞调用)将阻塞直到客户端write(socket-fd,but,size)发来数据。在一个客户和服务器通信时这没什么问题，当多个客户与服务器通信时，若服务器阻塞于其中一个客户socket-fd1，当另一个客户的数据到达套接字socket-fd2时，服务器仍不能处理，仍然阻塞在read(sockfd1,…)上。

此时，问题就出现了，不能及时处理另一个客户的服务，肿么办？

I/O多路复用来解决！

继续上面的问题，有多个客户连接，socket-fd1、socket-fd2、socket-fd3 … socket-fdn同时监听这n个客户，当其中有一个发来消息时就从select的阻塞中返回，然后就调用read读取收到消息的sockfd，然后又循环回select阻塞；这样就不会因为阻塞在其中一个上而不能处理另一个客户的消息。

Q：那这样子，在读取socket1的数据时，如果其它socket有数据来，那么也要等到socket1读取完了才能继续读取其它socket的数据吧。那不是也阻塞住了吗？而且读取到的数据也要开启线程处理吧，那这和多线程I/O有什么区别呢？

A:

1. CPU本来就是线性的，不论什么都需要顺序处理，并行只能是多核CPU。
2. I/O多路复用本来就是用来解决对多个I/O监听时，一个I/O阻塞影响其他I/O的问题，跟多线程没关系。
3. 跟多线程相比较，线程切换需要切换到内核进行线程切换，需要消耗时间和资源。而I/O多路复用不需要切换线/进程，效率相对较高，特别是对高并发的应用nginx就是用I/O多路复用，故而性能极佳。但多线程编程逻辑和处理上比I/O多路复用简单，而I/O多路复用处理起来较为复杂。

接下来就接着进一步理解I/O多路复用

2.5.1、什么是I/O多路复用

关于I/O多路复用(又被称为“事件驱动”)，首先要理解的是，操作系统为你提供了一个功能，当你的某个socket可读或者可写的时候，它可以给你一个通知。这样当配合非阻塞的socket使用时，只有当系统通知我哪个描述符可读了，我才去执行read操作，可以保证每次read都能读到有效数据而不做纯返回-1和EAGAIN的无用功。写操作类似。操作系统的这个功能通过select/poll/epoll/kqueue之类的系统调用函数来使用，这些函数都可以同时监视多个描述符的读写就绪状况，这样，多个描述符的I/O操作都能在一个线程内并发交替地顺序完成，这就叫I/O多路复用，这里的“复用”指的是复用同一个线程。

I/O 多路复用其实是在单个线程中通过记录跟踪每一个socket（I/O流） 的状态来管理多个I/O流。结合下图可以清晰地理解I/O多路复用。

select, poll, epoll 都是I/O多路复用的具体的实现。epoll性能比其他几者要好。redis中的I/O多路复用的所有功能通过包装常见的select、epoll、evport和kqueue这些I/O多路复用函数库来实现的。

2.5.2、Reactor（反应器模式）

IO多路复用模型是建立在内核提供的多路分离函数select基础之上的，使用select函数可以避免同步非阻塞IO模型中轮询等待的问题。

• 用户线程监视一个socket，socket把监视信息注册到内核缓存recvBuf，等待数据到达，（用户线程不阻塞）
• 数据到达之后，内核发送socket刻度信息，用户线程发送read请求去从recvBuf中读数据
• read完成

多路分离函数select：

如上图所示，用户线程发起请求的时候，首先会将需要进行IO操作的socket添加到select中，这时阻塞等待select函数返回。当数据到达时，select被激活，select函数返回，此时用户线程才正式发起read请求，读取数据并继续执行。

从流程上来看，使用select函数进行I/O请求和同步阻塞模型没有太大的区别，甚至还多了添加监视socket，以及调用select函数的额外操作，效率更差。但是，使用select以后最大的优势是用户可以在一个线程内同时处理多个socket的I/O请求。用户可以注册多个socket，然后不断地调用select读取被激活的socket，即可达到在同一个线程内同时处理多个I/O请求的目的。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的。

用户线程使用select函数的伪代码描述为：

{
   select(socket);//将需要进行IO操作的socket加入到select中

   while(1) {
       sockets = select();//获取被激活的socket
       for(socket in sockets) {
           if(can_read(socket)) {//拿被激活的socket去读
               read(socket, buffer);//从socket中把数据库读到buffer中
               process(buffer);//处理缓存中的数据
           }
       }
   }
}

其中while循环前将socket添加到select监视中，然后在while内一直调用select获取被激活的socket，一旦socket可读，便调用read函数将socket中的数据读取出来。

然而，使用select函数的优点并不仅限于此。虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只注册自己感兴趣的socket或者IO请求，然后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率。

IO多路复用模型使用了Reactor设计模式实现了这一机制。

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

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

2.5.3、小总结

I/O 多路复用模型是利用select、poll、epoll可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有I/O事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll是只轮询那些真正发出了事件的流），依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗），且Redis在内存中操作数据的速度非常快（内存内的操作不会成为这里的性能瓶颈），主要以上两点造就了Redis具有很高的吞吐量。

2.5.4、IO多路复用总结

Redis 采用网络IO多路复用技术，来保证在多连接的时候系统的高吞吐量。

多路-指的是多个socket网络连接，复用-指的是复用一个线程。

多路复用主要有三种技术：select，poll，epoll。epoll是最新的、也是目前最好的多路复用技术。

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

2.6、为什么Redis是单线程的

2.6.1、官方答案

因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

redis 核心就是 如果我的数据全都在内存里，我单线程的去操作 就是效率最高的，为什么呢，因为多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。

redis 用 单个CPU 绑定一块内存的数据，然后针对这块内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处理这个事。在内存的情况下，这个方案就是最佳方案。

2.6.2、详细原因

1. 不需要各种锁的性能消耗

Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。

总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁、释放锁操作，没有因为可能出现死锁而导致的性能消耗。

2. **CPU消耗**

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。

但是如果CPU成为Redis瓶颈，或者不想让服务器其他CPU核闲置，那怎么办？

可以考虑多起几个Redis进程，Redis是key-value数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些key放在哪个Redis。

# 清除屏幕中的信息
clear

# 退出客户端
quit
exit
<ESC>

I/O多路复用，I/O就是指的我们网络I/O,多路指多个TCP连接(或多个Channel)，复用指复用一个或少量线程。串起来理解就是很多个网络I/O复用一个或少量的线程来处理这些连接。

首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。

阻塞式的 I/O 模型并不能满足这里的需求，我们需要一种效率更高的 I/O 模型来支撑 Redis 的多个客户（redis-cli），这里涉及的就是 I/O 多路复用模型了。
Redis 服务采用 Reactor 的方式来实现文件事件处理器（每一个网络连接其实都对应一个文件描述符）。

3、Redis的五大数据类型

3.1、Redis键（key）

命令	解释
keys *	查询当前库所有key
exists key	判断某个key是否存在，返回值1存在，返回值0不存在
move key db	将当前库的key转移到另一个库
del key	删除指定的key数据
unlike key	根据value选择非阻塞删除（仅将keys从keyspace元数据中删除，真正的删除会在后续异步操作。）
expire key 10	10秒钟：为给定的key设置过期时间
ttl key	查看还有多少秒过期，-1表示永不过期，-2表示已过期
type key	查看key是什么类型
select	切换数据库（默认有0~15共16个库）
dbsize	查看当前数据库的key数量
flushdb	清空当前库
flushall	清空全部库

3.2、String类型

3.2.1、简介

String是 Redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个 value。

String类型是二进制安全的。这就意味着Redis的String可以包含任意数据。比如。jpg图片或者序列化对象。

String类型是 Redis 最基本的数据类型，String类型的值最大能存储 512MB。

3.2.2、常用命令

命令	解释
set key value	设置指定的key，如果key存在，就覆盖掉
get key	获取指定的key值
append key value	将给定的value追加到原值的末尾
strlen key	获取值的长度
setnx key value	只有在key不存在时，设置key的值
incr key	将key中储存的数字值进行原子的+1操作，只能对数字值操作，如果为空，新增值为1
decr key	将key中储存的数字值进行原子的-1操作
incrby / decrby <步长>	将key中储存的数字值增减，自定义步长
mset	同时设置一个或多个key-value对
mget	同时获取一个或者多个value
msetnx	同时设置一个或多个key-value对，当且仅当所有给定key都不存在。原子性，有一个失败则都失败。
getrange<起始位置><结束位置>	获取值的范围，类似java中的substring，前包，后包
setrange<起始位置>	用覆写所储存的字符串值，从<起始位置>开始（索引从0开始）
setex<过期时间>	设置键值对的同时，设置过期时间，单位秒
getset	以新值换旧值，设置新值的同时获得旧址

3.2.3、数据结构

String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串，内部结构实现上类似于Java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配。

如图中所示，内部为当前字符串实际分配的空间capacity一般要高于实际字符串长度len。当字符串长度小于1M时，扩容都是加倍现有的空间，如果超过1M，扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。

3.3、List类型

3.3.1、简介

单键多值

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。

3.3.2、常用命令

命令	解释
lpush / rpush	从左边/右边插入一个或者多个值
lpop / rpop	从左边/右边吐出一个值，值在键在，值光键亡。
rpoplpush	从key1列表右边吐出一个值，插到列表左边
lrange	按照索引下标获得元素(从左到右)
lrange mylist 0 -1	0左边第一个，-1右边第一个，（0-1表示获取所有==）==
lindex	按照索引下标获得元素(从左到右)
llen	获得列表长度
linsert before	在的前面插入插入值
lrem	从左边删除n个value(从左到右)
lset	将列表key下标为index的值替换成value

3.3.3、数据结构

List的数据结构为快速链表quickList。

首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是ziplist，即压缩列表。

它将所有的元素紧挨着一起存储，分配的是一块连续的内存。

当数据量比较多的时候才会改成quicklist。

因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是int类型的数据，结构上还需要两个额外的指针prev和next。

Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

3.4、Set类型

3.4.1、简介

Redis Set对外提供的功能与List类似是一个列表的功能，特殊之处在于Set是可以**自动排重**的，当你需要存储一个列表数据，又不希望出现重复数据时，Set是一个很好的选择，并且Set提供了判断某个成员是否在一个Set集合内的重要接口，这个也是List所不能提供的。

Redis的Set是String类型的无序集合。它底层其实是一个value为null的hash表，所以添加，删除，查找的==复杂度都是 O(1)==。

一个算法，随着数据的增加，执行时间的长短，如果是O(1)，数据增加，查找数据的时间不变

3.4.2、常用命令

命令	解释
sadd …	将一个或多个 member 元素加入到集合 key 中，已经存在的 member 元素将被忽略。
smembers	取出该集合的所有值。
sismember	判断集合是否为含有该值，有1，没有0
scard	返回该集合的元素个数
srem …	删除集合中的某个元素。
spop	随机从该集合中吐出一个值。
srandmember	随机从该集合中取出n个值。不会从集合中删除 。
smove value	把集合中一个值从一个集合移动到另一个集合
sinter	返回两个集合的交集元素
sunion	返回两个集合的并集元素
sdiff	返回两个集合的**差集**元素(key1中的，不包含key2中的)

3.4.3、数据结构

Set数据结构是dict字典，字典是用哈希表实现的。

Java中HashSet的内部实现使用的是HashMap，只不过所有的value都指向同一个对象。Redis的set结构也是一样，它的内部也使用hash结构，所有的value都指向同一个内部值。

3.5、Hash类型

3.5.1、简介

Redis Hash 是一个键值对集合。

Redis Hash 是一个String类型的field和value的映射表，hash特别适合用于存储对象。

类似Java里面的Map<String,Object>

用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：

第一种方式：

​ 每次修改用户的某个属性需要，先反序列化改好后再序列化回去。开销较大。

​ 用户ID数据冗余。

​ 第二种方式：

​ 通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。

3.5.2、常用命令

命令	解释
hset	给集合中的 键赋值
hget	从集合取出 value
hmset …	批量设置Hash的值
hexists	查看哈希表 key 中，给定域 field 是否存在
hkeys	列出该hash集合的所有field
hvals	列出该hash集合的所有value
hincrby	为哈希表 key 中的域 field 的值加上增量 1 -1
hsetnx	将哈希表 key 中的域 field 的值设置为 value ，当且仅当域 field 不存在 。

3.5.3、数据结构

Hash类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。当field-value长度较短且个数较少时，使用 ziplist，否则使用 hashtable。

3.6、ZSet类型（有序集合）

3.6.1、简介

Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。

不同之处是有序集合的每个成员都关联了一个**评分（score）**,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了 。

因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。

访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。

3.6.2、常用命令

命令	解释
zadd …	将一个或多个 member 元素及其 score 值加入到有序集 key 当中。
zrange [WITHSCORES]	返回有序集 key 中，下标在 之间的元素；带WITHSCORES，可以让分数一起和值返回到结果集。
zrangebyscore key minmax [withscores] [limit offset count]	返回有序集 key 中，所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列。
zrevrangebyscore key maxmin [withscores] [limit offset count]	同上，改为从大到小排列。
zincrby	为元素的score加上增量
zrem	删除该集合下，指定值的元素
zcount	统计该集合，分数区间内的元素个数
zrank	返回该值在集合中的排名，从0开始。

案例：如何利用zset实现一个文章访问量的排行榜？

3.6.3、数据结构

SortedSet(zset)是Redis提供的一个非常特别的数据结构，一方面它等价于Java的数据结构Map<String, Double>，可以给每一个元素value赋予一个权重score，另一方面它又类似于TreeSet，内部的元素会按照权重score进行排序，可以得到每个元素的名次，还可以通过score的范围来获取元素的列表。

zset底层使用了两个数据结构：

1. hash，hash的作用就是关联元素value和权重score，保障元素value的唯一性，可以通过元素value找到相应的score值。
2. 跳跃表，跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。

3.6.4、跳跃表（跳表）

​ 1、简介：

​ 有序集合在生活中比较常见，例如根据成绩对学生排名，根据得分对玩家排名等。对于有序集合的底层实现，可以用数组、平衡树、链表等。数组不便元素的插入、删除；平衡树或红黑树虽然效率高但结构复杂；链表查询需要遍历所有效率低。Redis采用的是跳跃表。跳跃表效率堪比红黑树，实现远比红黑树简单。

​ 2、实例

​ 对比有序链表和跳跃表，从链表中查询出51

（1）有序链表

​ 要查找值为51的元素，需要从第一个元素开始依次查找、比较才能找到。共需要6次比较。

（2）跳跃表

从第2层开始，1节点比51节点小，向后比较。

21节点比51节点小，继续向后比较，后面就是NULL了，所以从21节点向下到第1层

在第1层，41节点比51节点小，继续向后，61节点比51节点大，所以从41向下

在第0层，51节点为要查找的节点，节点被找到，共查找4次。

从此可以看出跳跃表比有序链表效率要高。

4、Redis配置文件

自定义目录：/etc/redis.conf

4.1、Units 单位

​ 配置大小单位,开头定义了一些基本的度量单位，只支持bytes，不支持bit

​ 大小写不敏感。

4.2、INCLUDES包含

​ 类似jsp中的include，多实例的情况可以把公用的配置文件提取出来。

4.3、网络相关配置

4.3.1、bind

默认情况bind=127.0.0.1只能接受本机的访问请求。

不写的情况下，无限制接受任何ip地址的访问。

生产环境肯定要写你应用服务器的地址；服务器是需要远程访问的，所以需要将其注释掉。

如果开启了protected-mode，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应。

保存配置，停止服务，重启启动查看进程，不再是本机访问了。

4.3.2、 protected-mode

将本机访问保护模式设置no

4.3.3、Port

端口号，默认 6379

4.3.4、tcp-backlog

设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。

在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。

注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值（128），所以需要确认增大/proc/sys/net/core/somaxconn和/proc/sys/net/ipv4/tcp_max_syn_backlog（128）两个值来达到想要的效果。

4.3.5、timeout

一个空闲的客户端维持多少秒会关闭，0表示关闭该功能。即永不关闭。

4.3.6、tcp-keepalive

对访问客户端的一种心跳检测，每隔n秒检测一次。

单位为秒，如果设置为0，则不会进行Keepalive检测，官方推荐设置为60s 。

4.4、GENERAL通用

4.4.1、daemonize

是否为后台进程，设置为yes

守护进程，后台启动

4.4.2、pidfile

存放pid文件的位置，每个实例会产生一个不同的pid文件。

4.4.3、loglevel

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

四个级别根据使用阶段来选择，生产环境选择notice 或者warning。

4.4.4、logfile

日志文件名称

4.4.5、databases 16

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

4.5、SECURITY安全

4.5.1、设置密码

访问密码的查看、设置和取消

在命令中设置密码，只是临时的。重启redis服务器，密码就还原了。

永久设置，需要再配置文件中进行设置。

4.6、LIMITS限制

4.6.1、maxclients

• 设置redis同时可以与多少个客户端进行连接。
• 默认情况下为10000个客户端
• 如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。

4.6.2、maxmemory

• 建议**必须设置**，否则，将内存占满，造成服务器宕机
• 设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。
• 如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
• 但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。

4.6.3、maxmemory-policy

• volatile-lru：使用LRU算法移除key，只对设置了过期时间的键；（最近最少使用）；
• allkeys-lru：在所有集合key中，使用LRU算法移除key
• volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
• allkeys-random：在所有集合key中，移除随机的key
• volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
• noeviction：不进行移除。针对写操作，只是返回错误信息

4.6.4、maxmemory-samples

• 设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。
• 一般设置3到7的数字，数值越小样本越不准确，但性能消耗越小。

5、Redis的发布和订阅

5.1、什么是发布和订阅

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

Redis 客户端可以订阅任意数量的频道。

5.2、Redis的发布和订阅

1. 客户端可以订阅频道如下图

​ 2.当给这个频道发布消息后，消息就会发送给订阅的客户端

5.3、发布订阅命令行实现

1. 打开一个客户端订阅channel1

SUBSCRIBE channel1

​ 2.打开另一个客户端，给channel1发布消息hello

​ publish channel1 hello

​ 返回的1是订阅者数量

​ 3.打开第一个客户端可以看到发送的消息

​ 注：发布的消息没有持久化，如果在订阅的客户端收不到hello，只能收到订阅后发布的消息。

6、Redis的新数据类型

6.1、Bitmaps

6.1.1、简介

现代计算机用二进制（位） 作为信息的基础单位， 1个字节等于8位， 例如“abc”字符串是由3个字节组成， 但实际在计算机存储时将其用二进制表示， “abc”分别对应的ASCII码分别是97、 98、 99， 对应的二进制分别是01100001、 01100010和01100011，如下图：

合理地使用操作位能够有效地提高内存使用率和开发效率。

Redis提供了Bitmaps这个“数据类型”可以实现对位的操作：

1. Bitmaps本身不是一种数据类型， 实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作。
2. Bitmaps单独提供了一套命令， 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组， 数组的每个单元只能存储0和1， 数组的下标在Bitmaps中叫做偏移量。

6.1.2、命令

1. setbit

   （1）格式

   setbit设置Bitmaps中某个偏移量的值（0或1）

   

   *offset:偏移量从0开始。

   （2）实例

   每个独立用户是否访问过网站存放在Bitmaps中， 将访问的用户记做1， 没有访问的用户记做0， 用偏移量作为用户的id。

   设置键的第offset个位的值（从0算起） ， 假设现在有20个用户，userid=1， 6， 11， 15， 19的用户对网站进行了访问， 那么当前Bitmaps初始化结果如图

   

unique:users:20201106代表2020-11-06这天的独立访问用户的Bitmaps

注：

​ 很多应用的用户id以一个指定数字（例如10000） 开头， 直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费， 通常的做法是每次做setbit操作时将用户id减去这个指定数字。

在第一次初始化Bitmaps时， 假如偏移量非常大， 那么整个初始化过程执行会比较慢， 可能会造成Redis的阻塞。

2. getbit

   (1) 格式

   getbit获取Bitmaps中某个偏移量的值

   

   获取键的第offset位的值（从0开始算）

   (2) 实例

   获取id=8的用户是否在2020-11-06这天访问过， 返回0说明没有访问过：

   

   注：因为100根本不存在，所以也是返回0。

3. bitcount

   统计字符串被设置为1的bit数。一般情况下，给定的整个字符串都会被进行计数，通过指定额外的 start 或 end 参数，可以让计数只在特定的位上进行。start 和 end 参数的设置，都可以使用负数值：比如 -1 表示最后一个位，而 -2 表示倒数第二个位，start、end 是指bit组的字节的下标数，二者皆包含。

   (1) 格式

   bitcount[start end] 统计字符串从start字节到end字节比特值为1的数量

   

   (2) 实例

   计算2022-11-06这天的独立访问用户数量

   

   start和end代表起始和结束字节数， 下面操作计算用户id在第1个字节到第3个字节之间的独立访问用户数， 对应的用户id是11， 15， 19。

   

举例： K1 【01000001 01000000 00000000 00100001】，对应【0，1，2，3】

bitcount K1 1 2 ： 统计下标1、2字节组中bit=1的个数，即01000000 00000000

–》bitcount K1 1 2 　　--》1

bitcount K1 1 3 ： 统计下标1、2字节组中bit=1的个数，即01000000 00000000 00100001

–》bitcount K1 1 3　　--》3

bitcount K1 0 -2 ： 统计下标0到下标倒数第2，字节组中bit=1的个数，即01000001 01000000 00000000

–》bitcount K1 0 -2　　--》3

注意：redis的setbit设置或清除的是bit位置，而bitcount计算的是byte位置。

4. bitop

   (1) 格式

   bitop and(or/not/xor) [key…]

   

   bitop是一个复合操作， 它可以做多个Bitmaps的and（交集） 、 or（并集） 、 not（非） 、 xor（异或） 操作并将结果保存在destkey中。

   (2) 实例

   2020-11-04 日访问网站的userid=1,2,5,9。

   setbit unique:users:20201104 1 1

   setbit unique:users:20201104 2 1

   setbit unique:users:20201104 5 1

   setbit unique:users:20201104 9 1

   2020-11-03 日访问网站的userid=0,1,4,9。

   setbit unique:users:20201103 0 1

   setbit unique:users:20201103 1 1

   setbit unique:users:20201103 4 1

   setbit unique:users:20201103 9 1

   计算出两天都访问过网站的用户数量

   bitop and unique:users:and:20201104_03

   unique:users:20201103unique:users:20201104

   

计算出任意一天都访问过网站的用户数量（例如月活跃就是类似这种） ， 可以使用or求并集。

6.1.3、bitmaps和set对比

假设网站有1亿用户， 每天独立访问的用户有5千万， 如果每天用集合类型和Bitmaps分别存储活跃用户可以得到表：

	set和Bitmaps存储一	天活跃用户对比
数据 类型	每个用户id占用空间	需要存储的用户量	全部内存量
集合 类型	64位	50000000	64位*50000000 = 400MB
Bitmaps	1位	100000000	1位*100000000 = 12.5MB

很明显， 这种情况下使用Bitmaps能节省很多的内存空间， 尤其是随着时间推移节省的内存还是非常可观的。

	set和Bitmaps存储独	立用户空间对比
数据类型	一天	一个月	一年
集合类型	400MB	12GB	144GB
Bitmaps	12.5MB	375MB	4.5GB

但Bitmaps并不是万金油， 假如该网站每天的独立访问用户很少， 例如只有10万（大量的僵尸用户） ， 那么两者的对比如下表所示， 很显然， 这时候使用Bitmaps就不太合适了， 因为基本上大部分位都是0。

set和Bitmaps存储一	天活跃用户对比（独立	用户比较少）
数据类型	每个userid占用空间	需要存储的用户量	全部内存量
集合类型	64位	100000	64位*100000 = 800KB
Bitmaps	1位	100000000	1位*100000000 = 12.5MB

6.2、HyperLogLog

6.2.1、简介

​ 在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站PV（PageView页面访问量）,可以使用Redis的incr、incrby轻松实现。

​ 但像UV（UniqueVisitor，独立访客）、独立IP数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。

解决基数问题有很多种方案：

1. 数据存储在MySQL表中，使用distinct count计算不重复个数
2. 使用Redis提供的hash、set、bitmaps等数据结构来处理

以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。

能否能够降低一定的精度来平衡存储空间？Redis推出了HyperLogLog

Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。

但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

什么是基数?

比如数据集 {1, 3, 5, 7, 5, 7, 8}， 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。 基数估计就是在误差可接受的范围内，快速计算基数。

6.2.2、命令

1. pfadd

   (1) 格式

   pfadd < element> [element …] 添加指定元素到 HyperLogLog 中

   

   (2) 示例

   

   将所有元素添加到指定HyperLogLog数据结构中。如果执行命令后HLL估计的近似基数发生变化，则返回1，否则返回0。

2. pfcount

   (1) 格式

   pfcount [key …] 计算HLL的近似基数，可以计算多个HLL，比如用HLL存储每天的UV，计算一周的UV可以使用7天的UV合并计算即可

   

   (2) 示例

   

3. pfmerge

   (1) 格式

   pfmerge [sourcekey …] 将一个或多个HLL合并后的结果存储在另一个HLL中，比如每月活跃用户可以使用每天的活跃用户来合并计算可得

   

   (2) 示例

6.3、Geospatial

6.3.1、简介

Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。

6.3.2、命令

1. geoadd

   (1) 格式

   geoadd< longitude> [longitude latitude member…] 添加地理位置（经度，纬度，名称）

   

   (2) 示例

   geoadd china:city 121.47 31.23 shanghai

   geoadd china:city 106.50 29.53 chongqing 114.05 22.52 shenzhen 116.38 39.90 beijing

   

   两极无法直接添加，一般会下载城市数据，直接通过 Java 程序一次性导入。

   有效的经度从 -180 度到 180 度。有效的纬度从 -85.05112878 度到 85.05112878 度。

   当坐标位置超出指定范围时，该命令将会返回一个错误。

   已经添加的数据，是无法再次往里面添加的。

2. geopos

   (1) 格式

   geopos [member…] 获得指定地区的坐标值

   

   (2) 示例

   

3. geodist

   (1) 格式

   geodist [m|km|ft|mi ] 获取两个位置之间的直线距离

   

   (2) 示例

   获取两个位置之间的直线距离

   

   单位：

   m 表示单位为米[默认值]。

   km 表示单位为千米。

   mi 表示单位为英里。

   ft 表示单位为英尺。

   如果用户没有显式地指定单位参数， 那么 GEODIST 默认使用米作为单位

4. georadius

   (1) 格式

   georadius< longitude>radius m|km|ft|mi 以给定的经纬度为中心，找出某一半径内的元素

   

   经度 纬度 距离 单位

   (2) 示例

   

7、Redis事务

在Redis中，MULTI/EXEC/DISCARD/WATCH这四个命令是我们实现事务的基石。

7.1、Redis的事务定义

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis事务的主要作用就是串联多个命令防止别的命令插队。

7.2、multi、exec、discard

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。

组队的过程中可以通过discard来放弃组队。

案例：

这是组队成功的情况。

以下是组队阶段报错，提交失败：

以下是 组队成功，提交有成功有失败的情况：

7.3、事务的错误处理

组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。

如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

7.4、事务冲突问题

7.4.1、例子

一个请求想给金额减8000

一个请求想给金额减5000

一个请求想给金额减1000

7.4.2、悲观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

7.4.3、乐观锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

7.4.4、watch key [key…]

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个（或这些）key被其它命令所改动，那么事务将被打断。并且返回nil，在Jedis中会返回null。

7.4.5、unwatch

取消 WATCH 命令对所有 key 的监视。

如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。

7.5、Redis事务的三特性：

• 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
• 不保证原子性：Redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

7.6、Redis事务—秒杀案例

7.6.1、解决计数器和人员记录的事务操作

7.6.2、秒杀并发模拟（ab工具）

​ 安装ab： yum install httpd-tools

​ 常用参数说明：

​ -n: 总的请求个数

​ -c: 一次并发的请求数

​ -t: 持续的时间，默认没有限制

​ -k:它会增加请求头Connection: Keep-Alive，相当于开启了HTTP长连接，

		  这样做一方面可以降低测试服务器动态端口被耗尽的风险，

​ 另一方面也有助于给目标服务器更大的压力，测试出更接近极限的结果

​ 说明：ab使用的是HTTP/1.0，缺省开启的是短链接，用-k参数则可以打开长连接

​ ab运行例子：

​ ab -c 100 -n 10000 http://127.0.0.1/a.html

ab工具测试说明了一个问题，在并发条件下，超卖问题就浮出水面了。

7.6.3、超卖问题

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-brqR6GJB-1633487969555)(C:/Users/%E7%88%B8%E7%88%B8/AppData/Roaming/Typora/typora-user-images/image-20210930103712918.png)]

超卖问题是由什么原因导致的呢？

因为没有加事务，多个操作之间互相影响，即两个或多个操作读取了相同的库存数（10），但是最终又都执行了-1操作，导致最终库存会被减至负数。

超卖问题的解决方案：利用乐观锁淘汰用户：

代码如下：

​ 1.增加乐观锁

//增加乐观锁
jedis.watch(qtkey);
 
//3.判断库存
String qtkeystr = jedis.get(qtkey);
if(qtkeystr==null || "".equals(qtkeystr.trim())) {
System.out.println("未初始化库存");
jedis.close();
return false ;
}
 
int qt = Integer.parseInt(qtkeystr);
if(qt<=0) {
System.err.println("已经秒光");
jedis.close();
return false;
}

2. 增加事务

//事务
Transaction multi = jedis.multi();
 
//4.减少库存
//jedis.decr(qtkey);
multi.decr(qtkey);
 
//5.加人
//jedis.sadd(usrkey, uid);
multi.sadd(usrkey, uid);
 
//执行事务
List<Object> list = multi.exec();
 
//判断事务提交是否失败
if(list==null || list.size()==0) {
System.out.println("秒杀失败");
jedis.close();
return false;
}
System.err.println("秒杀成功");
jedis.close();

我们通过加事务和乐观锁的方式解决了超卖问题，但是此时又出现了新的问题，那就是**连接超时和库存遗留**的问题。

库存遗留放到后面解决，我们先来解决连接超时的问题。

7.6.5、连接超时问题

节省每次连接redis服务带来的消耗，把连接好的实例反复利用。

通过参数管理连接的行为。

工具类实现如下：

public class JedisPoolUtils {
    private static JedisPool jedisPool;
    static {
        //读取配置文件
        InputStream is=JedisPoolUtils.class.getClassLoader().getResourceAsStream("jedis.properties");
        //创建Propertie对象
        Properties properties=new Properties();
        try {
            properties.load(is);
        } catch (IOException e) {
            e.printStackTrace();
        }
        JedisPoolConfig config=new JedisPoolConfig();
        config.setMaxTotal(Integer.parseInt(properties.getProperty("maxTotal")));
        config.setMaxIdle(Integer.parseInt(properties.getProperty("maxIdle")));

        //初始化Jedispool
        jedisPool=new JedisPool(config,properties.getProperty("host"), Integer.parseInt(properties.getProperty("port")));


    }
    /*获取连接的方法*/
    public static Jedis getJedis(){
        return jedisPool.getResource();
    }
}

配置文件放于src目录下 src/jedis.properties

host=127.0.0.1
port=6379
maxTotal=50
maxIdle=10

使用实例：

@Test
public void test8() {
    //通过JedisPoolUtils工具类获取连接池
    Jedis jedis = JedisPoolUtils.getJedis();
    //使用
    jedis.set("username","lisi");
    //关闭，归还连接
    jedis.close();
}

连接池参数:

• MaxTotal：控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；如果赋值为-1，则表示不限制；如果pool已经分配了MaxTotal个jedis实例，则此时pool的状态为exhausted。

• maxIdle：控制一个pool最多有多少个状态为idle(空闲)的jedis实例；

• MaxWaitMillis：表示当borrow一个jedis实例时，最大的等待毫秒数，如果超过等待时间，则直接抛JedisConnectionException；

• testOnBorrow：获得一个jedis实例的时候是否检查连接可用性（ping()）；如果为true，则得到的jedis实例均是可用的；

7.6.6、库存遗留问题

在项目中的具体体现就是，已经秒光了，但是用redis查询的时候还显示有库存。

原因，就是乐观锁导致很多请求都失败。先点的没秒到，后点的可能秒到了。

再进一步分析，假如有5个商品，10个人抢。

此时商品的版本号假设为1.0，当第一个人购买之后，就修改版本号为1.1。

如果有人在第一个人修改版本号之前也读取了版本号为1.0的商品，那么版本号被修改成1.1之后，这些人将不能进行购买。即乐观锁只保证安全，不保证你是否卖完。

解决方案： LUA脚本

Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并没有提供强大的库，一个完整的Lua解释器不过200k，所以Lua不适合作为开发独立应用程序的语言，而是作为嵌入式脚本语言。

很多应用程序、游戏使用LUA作为自己的嵌入式脚本语言，以此来实现可配置性、可扩展性。

这其中包括魔兽争霸地图、魔兽世界、博德之门、愤怒的小鸟等众多游戏插件或外挂。

LUA脚本在Redis中的优势

将复杂的或者多步的redis操作，写为一个脚本，一次提交给redis执行，减少反复连接redis的次数。提升性能。

LUA脚本是类似redis事务，有一定的原子性，不会被其他命令插队，可以完成一些redis事务性的操作。

但是注意redis的lua脚本功能，只有在Redis 2.6以上的版本才可以使用。

利用lua脚本淘汰用户，解决超卖问题。

redis 2.6版本以后，通过lua脚本解决**争抢问题**，实际上是redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。

8、Redis持久化

怎么保证 redis 挂掉之后再重启数据可以进行恢复

Redis提供了2个不同形式的持久化方式 RDB 和 AOF：

• RDB：在指定的时间间隔内，将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据；
• AOF：将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。

表现为：

8.1、RDB

原理是redis会单独创建（fork）一个与当前进程一模一样的子进程来进行持久化，这个子线程的所有数据（变量。环境变量，程序程序计数器等）都和原进程一模一样，会先将数据写入到一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何的io操作，这就确保了极高的性能。但是这也引出了RDB的缺点，就是**最后一次持久化后的数据可能丢失**。

8.1.1、fork

• Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
• 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”。
• 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

创建快照的方法

• BGSAVE命令：客户端向Redis发送 BGSAVE命令 来创建一个快照。对于支持BGSAVE命令的平台来说（基本上所有平台支持，除了Windows平台），Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。
  • 这个子进程和原进程数据一模一样，会先将数据写入到一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件
  • 整个过程中，主进程不进程任何的IO操作，这就确保了极高的性能
• SAVE命令： 客户端还可以向Redis发送 SAVE命令 来创建一个快照，接到SAVE命令的Redis服务器在快照创建完毕之前不会再响应任何其他命令。SAVE命令不常用，我们通常只会在没有足够内存去执行BGSAVE命令的情况下，又或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令。
• **save选项(配置文件中修改)：**如果用户设置了save选项（一般会默认设置），比如 save 60 10000，那么从Redis最近一次创建快照之后开始算起，当“60秒之内有10000次写入”这个条件被满足时，Redis就会自动触发BGSAVE命令。
• SHUTDOWN命令： 当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在SAVE命令执行完毕之后关闭服务器。
• 一个Redis服务器连接到另一个Redis服务器： 当一个Redis服务器连接到另一个Redis服务器，并向对方发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令

8.1.2、save

save #手动执行一次保存操作，会阻塞
bgsave # redis会在后台异步进行快照操作，同时可以响应客户端的请求
shutdown # 如果没有开启aof，会触发持久化
执行flushall命令，但是里面是空的，无意义

# 在redis.conf中配置
save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

客户端执行save命令，该命令强制redis执行快照，这时候redis处于阻塞状态，不会响应任何其他客户端发来的请求，直到RDB快照文件执行完毕，所以请慎用。

save指令操作配置：需要在conf文件中配置

• dbfilename dump.rdb
  • 说明：设置持久化后文件名（本地数据库文件名），默认值为 dump.rdb
  • 经验：通常设置为dump-端口号.rdb
• dir
  • 说明：设置存储.rdb、log等文件的路径。加载位置也是这个位置
  • 经验：通常设置成存储空间较大的目录中，目录名称data
  • 保存时间分3种
• stop-writes-on-bgsave-error
  • 说明：当Redis无法写入磁盘的话，直接关掉Redis的写操作
  • 经验：推荐yes
• rdbcompression yes
  • 说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩
  • 经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）
• rdbchecksum yes
  • 说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
  • 经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

rdb的备份

先通过config get dir 查询rdb文件的目录

将*.rdb的文件拷贝到别的地方

rdb的恢复

• u 关闭Redis
• u 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
• u 启动Redis, 备份数据会直接加载

RDB的工作原理：

如图，4个客户端分别输入指令，redis是单线程的，所以需要排序。

有个问题是如果save是第三个，save执行时间很长，所以后面的get需要等待很长时间。就会阻塞。所以线上不建议使用save指令，会很拖慢性能。

注意： save指令的执行会阻塞当前Redis服务器， 直到当前RDB过程完成为止， 有可能会造成长时间阻塞， 线上环境不建议使用。

其他

# 查看最近一次持久化时间：
info Persistence

# 查看存储文件位置
CONFIG GET dir

8.1.3、bgsave

bgsave # 后台save#手动启动后台保存操作，但不是立即执行  

bgsave-fork原理：

Redis的单线程的，那如果主线程去做这种耗时的IO同步操作时，Redis整体的性能会被拖垮的。

fork()它是一个系统调用，一般用它来创建一个和当前进程一模一样的子进程。当在程序中调用它时，系统为新的进程分配存储、资源，将原程序中的值也复制给他。

fork()函数调用一次会返回两次，在父进程得到的返回值是子进程的pid，在子进程中得到的是0，出错则返回负数。

Redis的实现是通过fork()系统调用创建一个子进程。由这个子进程去负责执行这些耗时的IO操作，父子进程会共享内存，然后被共享的这块内存不可写，新的数据写入到新的内存文件中（COW）。

1. 客户端执行bgsave命令，redis主进程收到指令并判断此时是否在执行bgrewriteaof(AOF文件重写过程，后续会讲解)，如果此时正好在执行则bgsave直接返回，不fork子进程，如果没有执行bgrewriteaof重写AOF文件，则进入下一个阶段；
2. 主进程调用fork方法创建子进程，在创建子进程过程中redis主进程阻塞，所以不能响应客户端请求；
3. 子进程创建完成以后，fork()函数返回0，bgsave命令返回“Background saving started”，此时标志着redis可以响应客户端请求了；
4. 子进程根据主进程的内存副本创建临时快照文件，当快照文件完成以后对原快照文件进行替换；
5. 子进程发送信号给redis主进程完成快照操作，主进程更新统计信息（info Persistence可查看）,子进程退出；

Redis会通过系统调用fork()出一个子进程，父子进程是会共享内存的，父进程和子进程共享的这块内存就是在执行fork操作那个时刻的内存快照。由linux的copy on write机制将父子进程共享的这块内存标记为只读状态。

此时对子进程来说，它的任务就是将这块只读内存中的数据保存成RDB文件。

对父进程来说它是有可能收到写命令的，当父进程尝试往这个加了只读状态的内存地址写入数据时，就会触发保护异常，执行linux的 copy on write，也就是将原来内存对应的数据页复制出来一份后，然后对这个副本进行修改。

注意： bgsave命令是针对save阻塞问题做的优化。 Redis内部所有涉及到RDB操作都采用bgsave的方式， save命令可以弃用

bgsave命令可以理解为background save即：“后台保存”。当执行bgsave命令时，redis会fork出一个子进程来执行快照生成操作，需要注意的redis是在fork子进程这个简短的时间redis是阻塞的（此段时间不会响应客户端请求，），当子进程创建完成以后redis响应客户端请求。其实redis自动快照也是使用bgsave来完成的。

bgsave相关配置：

dbfilename dump.rdb
dir
rdbcompression yes
rdbchecksum yes
stop-writes-on-bgsave-error yes
说明：后台存储过程中如果出现错误现象，是否停止保存操作
经验：通常默认为开启状态

但是save和bgsave都需要手动保存，难免疏忽，使用需要自动执行。

conf文件配置持久化条件：

# 在配置文件中设置
格式：save 时间段 key修改次数
作用:满足限定时间范围内key的变化数量达到指定数量即进行持久化。即时间片内变化大才自动保存，是快照的思想。

 位置:在conf文件中进行配置，把3个都关掉就把RDB持久化关掉了。或者save "" # 但是集群环境下RDB是关不掉的
save 900 1 # 900s内变化一个就保存
save 300 10
save 60 10000

8.1.4、小总结

save VS bgsave：

命令	save	bgsave
IO类型	同步	异步
是否阻塞redis其他命令	是	否（在调用fork函数生成子进程时会有短暂阻塞）
复杂度	O(n)	O(n)
额外消耗内存	否	是
启动新进程	否	是

RDB优点：

RDB是一个紧凑压缩的二进制文件， 存储效率较高

• RDB内部存储的是redis在某个时间点的数据快照， 非常适合用于数据备份，全量复制等场景
• RDB恢复数据的速度要比AOF快很多

应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

RDB缺点：

RDB方式无论是执行指令还是配置，无法做到实时持久化，具有较大的可能性丢失数据。

• bgsave指令每次运行要执行fork操作创建子进程， 要牺牲掉一些性能
• Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

**动态停止RDB：**redis-cli config set save “”#save后给空值，表示禁用保存策略

8.2、AOF

AOF (Append only File)：以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF默认不开启：

​ 可以在redis.conf中配置文件名称，默认为 appendonly.aof

​ AOF文件的保存路径，同RDB的路径一致。

8.2.1、AOF持久化流程

1. 客户端的请求写命令会被append追加到AOF缓冲区内；
2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

AOF缓冲区：

​ AOF写数据过程：

​ 当客户端发出一条指令给服务器时，服务器收到并没有马上记录，而是放到临时区域：刷新缓存区，缓存区是最终存成文件时用的。

8.2.2、AOF持久化策略

AOF同步频率设置：

• appendfsync always

  始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

• appendfsync everysec

  每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

• appendfsync no

  redis不主动进行同步，把同步时机交给操作系统。

重写策略（rewrite压缩）

1. 是什么？

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

2. 重写原理，如何实现重写

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

这么说可能有点抽象，下面通过代码来增强下描述：

 # 假设服务器对键list执行了以下命令s;
127.0.0.1:6379> RPUSH list "A" "B"
(integer) 2
127.0.0.1:6379> RPUSH list "C"
(integer) 3
127.0.0.1:6379> RPUSH list "D" "E"
(integer) 5
127.0.0.1:6379> LPOP list
"A"
127.0.0.1:6379> LPOP list
"B"
127.0.0.1:6379> RPUSH list "F" "G"
(integer) 5
127.0.0.1:6379> LRANGE list 0 -1
1) "C"
2) "D"
3) "E"
4) "F"
5) "G"
127.0.0.1:6379> 

当前列表键list在数据库中的值就为["C", "D", "E", "F", "G"]。要使用尽量少的命令来记录list键的状态，最简单的方式不是去读取和分析现有AOF文件的内容，，而是直接读取list键在数据库中的当前值，然后用一条RPUSH list "C" "D" "E" "F" "G"代替前面的6条命令。

no-appendfsync-on-rewrite：

如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）

auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

3. 重写流程

   1. bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
   2. 主进程fork出子进程执行重写操作，保证主进程不会阻塞。
   3. 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
   4. 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
   5. 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

   

AOF写数据遇到的问题：

AOF重写过程(AOF 重写缓冲区)

在执行BGREWRITEAOF命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的AOF文件，以此来完成AOF文件重写操作。

8.2.3、AOF启动/修复/恢复

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

• 正常恢复

  • 修改默认的appendonly no，改为yes
  • 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
  • 恢复：重启redis然后重新加载

• 异常恢复

  • 修改默认的appendonly no，改为yes
  • 如遇到**AOF文件损坏，通过/usr/local/bin/redis-check-aof–fix appendonly.aof**进行恢复
  • 备份被写坏的AOF文件
  • 恢复：重启redis，然后重新加载

8.3、RDB+AOF混合持久化

开启混合持久化：

混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后再将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。

AOF工作流程：

• Always时，Set正常执行，另开一个子进程进行重写。
• Sec时会先放到缓存区。

AOF重写流程：

8.4、RDB和AOF比较

持久化方式	RDB	AOF
占用存储空间	小（数据级：压缩）	大（指令级：重写）
存储速度	慢	快
恢复速度	快	慢
数据安全性	同步时间间隔大	同步时间间隔小
资源消耗	高/重量级	低/轻量级
启动优先级	低	高

AOF和RDB同时开启，redis听谁的？

​ 官方建议 两种持久化机制同时开启，如果两个同时开启 优先使用aof

8.5、选用RDB或者AOF的场景

• 官方推荐两个都启用。
• 如果对数据不敏感，可以选单独用RDB
• 不建议单独用 AOF，因为可能会出现Bug。
• 如果只是做纯内存缓存，可以都不用
• 双保险策略， 同时开启 RDB 和 AOF， 重启后， Redis优先使用 AOF 来恢复数据，降低丢失数据的量

综合比对：

• RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
• 如不能承受数分钟以内的数据丢失，对业务数据非常敏感， 选用AOF
• 如能承受数分钟以内的数据丢失， 且追求大数据集的恢复速度， 选用RDB
• 灾难恢复选用RDB

8.6、开机加载持久化步骤

首先是优先加载aof文件

9、主从复制

9.1、是什么

主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

9.2、能干嘛

• 读写分离，性能扩展
• 容灾快速恢复

9.3、怎么用

1. 新建redis6379.conf，填写以下内容

   include /myredis/redis.conf

   pidfile /var/run/redis_6379.pid

   port 6379

   dbfilename dump6379.rdb

   

2. 新建redis6380.conf，填写以下内容

3. 新建redis6381.conf，填写以下内容

   

4. 启动三台redis服务器

5. 查看系统进程，看看三台服务器是否启动

6. 查看三台主机运行情况

info replication ：打印主从复制的相关信息

7. 配从(库)不配主(库)

slaveof <ip><port>

​ 成为某个实例的从服务器

​ （1）在6380和6381上执行: slaveof 127.0.0.1 6379

​ （2）在主机上写，在从机上可以读取数据

​ 在从机上写数据报错

​ （3）主机挂掉，重启就行，一切如初

​ （4）从机重启需重设：slaveof 127.0.0.1 6379

​ 可以将配置增加到文件中。永久生效。

9.4、常用三招

9.4.1、一主二仆

9.4.2、薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

slaveof

中途变更转向:会清除之前的数据，重新建立拷贝最新的

风险是一旦某个slave宕机，后面的slave都没法备份

主机挂了，从机还是从机，无法写数据了

9.4.3、反客为主

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。

用 slaveof no one将从机变为主机。

9.5、复制原理

9.5.1、粗略原理

1. 当Slave启动成功连接到Master后会发送一个sync命令
2. Master接到Slave发送过来的同步消息，把Master数据进行持久化，rbd文件，把rdb文件发送给Slave，Slave拿到rdb进行读取
3. 每次Master进行写操作之后，和Slave进行进行数据同步

9.5.2、详细原理（全量同步）

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：

1. 从服务器连接主服务器，发送SYNC命令；
2. 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
3. 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4. 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5. 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6. 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

9.6、哨兵模式

9.6.1、是什么

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

9.6.2、怎么用

1. 调整为一主二仆模式，6379带着6380、6381

2. **自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错**
3. **配置哨兵,填写内容**

sentinel monitor mymaster 127.0.0.1 6379 1

其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。

4. 启动哨兵

执行redis-sentinel /myredis/sentinel.conf

5. ** 当主机挂掉，从机选举中产生新的主机

(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)

哪个从机会被选举为主机呢？根据优先级别：slave-priority

原主机重启后会变为从机。

9.6.3、复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

9.6.4、故障恢复

优先级在redis.conf中默认：replica-priority 100，值越小优先级越高

偏移量是指获得原主机数据最全的

每个redis实例启动后都会随机生成一个40位的runid

9.6.5、主从复制代码

private static JedisSentinelPool jedisSentinelPool=null;

public static  Jedis getJedisFromSentinel(){
if(jedisSentinelPool==null){
            Set<String> sentinelSet=new HashSet<>();
            sentinelSet.add("192.168.11.103:26379");

            JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
            jedisPoolConfig.setMaxTotal(10); //最大可用连接数
jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
jedisPoolConfig.setMinIdle(5); //最小闲置连接数
jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong

jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
return jedisSentinelPool.getResource();
        }else{
return jedisSentinelPool.getResource();
        }
}

10、Redis集群

10.1、问题

容量不够，redis如何进行扩容？

并发写操作， redis如何分摊？

另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。

之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。

10.2、什么是集群

Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

10.3、怎么用

1. 配置基本信息

   开启daemonize yes

   Pid文件名字

   指定端口

   Log文件名字

   Dump.rdb名字

   Appendonly 关掉或者换名字

2. redis cluster配置修改

   cluster-enabled yes 打开集群模式

   cluster-config-file nodes-6379.conf 设定节点配置文件名

   cluster-node-timeout 15000 设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。

include /home/bigdata/redis.conf
port 6379
pidfile "/var/run/redis_6379.pid"
dbfilename "dump6379.rdb"
dir "/home/bigdata/redis_cluster"
logfile "/home/bigdata/redis_cluster/redis_err_6379.log"
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000

3. 修改好redis6379.conf文件，拷贝多个redis.conf文件

4. 使用查找替换修改另外5个文件

   例如：:%s/6379/6380

5. 启动6个redis服务

6. 将六个节点合成一个集群

   组合之前，请确保所有redis实例启动后，nodes-xxxx.conf文件都生成正常。

   

• 合体：

  cd /redis-6.2.1/src

  redis-cli --cluster create --cluster-replicas 1 192.168.11.101:6379 192.168.11.101:6380 192.168.11.101:6381 192.168.11.101:6389 192.168.11.101:6390 192.168.11.101:6391
  

  此处不要用127.0.0.1， 请用真实IP地址

  –replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。一台主机，一台从机，正好三组。

• l 普通方式登录

  可能直接进入读主机，存储数据时，会出现MOVED重定向操作。所以，应该以集群方式登录。

  

  7. -c 以集群方式登录，设置数据会自动切换到相应的写主机**

  

  8. 通过 cluster nodes 命令查看集群信息
  
  9. redis cluster 如何分配这六个节点?

  一个集群至少要有三个主节点。

  选项 --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

  分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。

10.4、什么是slots

一个 Redis 集群包含 16384 个插槽（hash slot）， 数据库中的每个键都属于这 16384 个插槽的其中一个，

集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

集群中的每个节点负责处理一部分插槽。 举个例子， 如果一个集群可以有主节点， 其中：

节点 A 负责处理 0 号至 5460 号插槽。

节点 B 负责处理 5461 号至 10922 号插槽。

节点 C 负责处理 10923 号至 16383 号插槽。

10.5、在集群中录入值

在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。

redis-cli客户端提供了 –c 参数实现自动重定向。

如 redis-cli -c –p 6379 登入后，再录入、查询键值对可以自动重定向。

不在一个slot下的键值，是不能使用mget,mset等多键操作。

可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去。

10.6、查询集群中的值

CLUSTER GETKEYSINSLOT <slot><count> 返回 count 个 slot 槽中的键。

10.7、故障恢复

如果主节点下线？从节点能否自动升为主节点？注意：15秒超时

主节点恢复后，主从关系会如何？主节点回来变成从机。

如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续?

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么 ，整个集群都挂掉

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。

redis.conf中的参数 cluster-require-full-coverage

10.8、集群的Jedis开发

即使连接的不是主机，集群会自动切换主机存储。主机写，从机读。

无中心化主从集群。无论从哪台主机写的数据，其他主机上都能读到数据。

public class JedisClusterTest {
  public static void main(String[] args) { 
     Set<HostAndPort>set =new HashSet<HostAndPort>();
     set.add(new HostAndPort("192.168.31.211",6379));
     JedisCluster jedisCluster=new JedisCluster(set);
     jedisCluster.set("k1", "v1");
     System.out.println(jedisCluster.get("k1"));
  }
}

10.9、优势与不足

优势如下：

• 实现扩容
• 分摊压力
• 无中心配置相对简单

不足如下：

• 多键操作是不被支持的
• 多键的Redis事务是不被支持的。lua脚本不被支持
• 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

11、Redis应用问题解决

11.1、缓存穿透

11.1.1、问题描述

key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

11.1.2、解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

解决方案：

1. **对空值缓存：**如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟

2. 设置可访问的名单（白名单）：

   使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

3. 采用布隆过滤器：(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。

   布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)

   将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

4. **进行实时监控：**当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

11.2、缓存击穿

11.2.1、问题描述

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

11.2.2、解决方案

key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

解决方案：

1. 预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长

2. 实时调整：现场监控哪些数据热门，实时调整key的过期时长

3. 使用锁：

   （1）就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。

   （2）先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key

   （3）当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；

   （4）当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

   

11.3、缓存雪崩

11.3.1、问题描述

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key。

正常访问：

缓存失效瞬间：

11.3.2、解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕！

解决方案：

1. 构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）

2. 使用锁或队列：

   用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况

3. 设置过期标志更新缓存：

   记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。

4. 将缓存失效时间分散开：

   比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

12、基于Redis实现分布式锁

12.1、实现原理

redis:命令

set sku:1:info “OK” NX PX 10000

EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。

PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。

NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。

XX ：只在键已经存在时，才对键进行设置操作。

1. 多个客户端同时获取锁（setnx）

2. 获取成功，执行业务逻辑{从db获取数据，放入缓存}，执行完成释放锁（del）

3. 其他客户端等待重试

12.2、代码实现

Redis: set num 0

@GetMapping("testLock")
public void testLock(){
    //1获取锁，setne
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111");
    //2获取锁成功、查询num的值
    if(lock){
        Object value = redisTemplate.opsForValue().get("num");
        //2.1判断num为空return
        if(StringUtils.isEmpty(value)){
            return;
        }
        //2.2有值就转成成int
        int num = Integer.parseInt(value+"");
        //2.3把redis的num加1
        redisTemplate.opsForValue().set("num", ++num);
        //2.4释放锁，del
        redisTemplate.delete("lock");

    }else{
        //3获取锁失败、每隔0.1秒再获取
        try {
            Thread.sleep(100);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

重启，服务集群，通过网关压力测试：

ab -n 1000 -c 100 http://192.168.140.1:8080/test/testLock

查看redis中num的值：

基本实现。

问题：setnx刚好获取到锁，业务逻辑出现异常，导致锁无法释放

解决：设置过期时间，自动释放锁。

12.3、优化之设置锁的过期时间

设置过期时间有两种方式：

1. 首先想到通过expire设置过期时间（缺乏原子性：如果在setnx和expire之间出现异常，锁也无法释放）

2. 在set时指定过期时间（推荐）

设置过期时间：

压力测试肯定也没有问题。自行测试

问题：可能会释放其他服务器的锁。

场景：如果业务逻辑的执行时间是7s。执行流程如下

1. index1业务逻辑没执行完，3秒后锁被自动释放。

2. index2获取到锁，执行业务逻辑，3秒后锁被自动释放。

3. index3获取到锁，执行业务逻辑

4. index1业务逻辑执行完成，开始调用del释放锁，这时释放的是index3的锁，导致index3的业务只执行1s就被别人释放。

最终等于没锁的情况。

解决：setnx获取锁时，设置一个指定的唯一值（例如：uuid）；释放前获取这个值，判断是否自己的锁

12.4、优化之UUID防误删

问题：删除操作缺乏原子性。

场景：

1. index1执行删除时，查询到的lock值确实和uuid相等

   uuid=v1

   set(lock,uuid)；

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5ioTxSqy-1633487969578)(C:/Users/%E7%88%B8%E7%88%B8/AppData/Roaming/Typora/typora-user-images/image-20211005203731678.png)]

2. index1执行删除前，lock刚好过期时间已到，被redis自动释放

   在redis中没有了lock，没有了锁。

   

3. index2获取了lock

   index2线程获取到了cpu的资源，开始执行方法

   uuid=v2

   set(lock,uuid)；

4. index1执行删除，此时会把index2的lock删除

   index1 因为已经在方法中了，所以不需要重新上锁。index1有执行的权限。index1已经比较完成了，这个时候，开始执行

   

   删除的index2的锁！

12.5、优化之LUA脚本保证删除的原子性

@GetMapping("testLockLua")
public void testLockLua() {
    //1 声明一个uuid ,将做为一个value 放入我们的key所对应的值中
    String uuid = UUID.randomUUID().toString();
    //2 定义一个锁：lua 脚本可以使用同一把锁，来实现删除！
    String skuId = "25"; // 访问skuId 为25号的商品 100008348542
    String locKey = "lock:" + skuId; // 锁住的是每个商品的数据

    // 3 获取锁
    Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid, 3, TimeUnit.SECONDS);

    // 第一种： lock 与过期时间中间不写任何的代码。
    // redisTemplate.expire("lock",10, TimeUnit.SECONDS);//设置过期时间
    // 如果true
    if (lock) {
        // 执行的业务逻辑开始
        // 获取缓存中的num 数据
        Object value = redisTemplate.opsForValue().get("num");
        // 如果是空直接返回
        if (StringUtils.isEmpty(value)) {
            return;
        }
        // 不是空 如果说在这出现了异常！ 那么delete 就删除失败！ 也就是说锁永远存在！
        int num = Integer.parseInt(value + "");
        // 使num 每次+1 放入缓存
        redisTemplate.opsForValue().set("num", String.valueOf(++num));
        /*使用lua脚本来锁*/
        // 定义lua 脚本
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        // 使用redis执行lua执行
        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptText(script);
        // 设置一下返回值类型 为Long
        // 因为删除判断的时候，返回的0,给其封装为数据类型。如果不封装那么默认返回String 类型，
        // 那么返回字符串与0 会有发生错误。
        redisScript.setResultType(Long.class);
        // 第一个要是script 脚本 ，第二个需要判断的key，第三个就是key所对应的值。
        redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);
    } else {
        // 其他线程等待
        try {
            // 睡眠
            Thread.sleep(1000);
            // 睡醒了之后，调用方法。
            testLockLua();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

Lua 脚本详解：

项目中正确使用：

1. 定义key，key应该是为每个sku定义的，也就是每个sku有一把锁。

String locKey ="lock:"+skuId; // 锁住的是每个商品的数据
Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid,3,TimeUnit.SECONDS);

12.6、总结

1、加锁

// 1. 从redis中获取锁,set k1 v1 px 20000 nx
String uuid = UUID.randomUUID().toString();
Boolean lock = this.redisTemplate.opsForValue()
      .setIfAbsent("lock", uuid, 2, TimeUnit.SECONDS);

2、使用lua释放锁

// 2. 释放锁 del
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
// 设置lua脚本返回的数据类型
DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
// 设置lua脚本返回类型为Long
redisScript.setResultType(Long.class);
redisScript.setScriptText(script);
redisTemplate.execute(redisScript, Arrays.asList("lock"),uuid);

3、重试

Thread.sleep(500);
testLock();

为了确保分布式锁可用，我们至少要确保锁的实现同时**满足以下四个条件**：

• 互斥性。在任意时刻，只有一个客户端能持有锁。
• 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
• 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。
• 加锁和解锁必须具有原子性。

13、Redis6.0新功能

13.1、ACL

13.1.1、简介

Redis ACL是Access Control List（访问控制列表）的缩写，该功能允许根据可以执行的命令和可以访问的键来限制某些连接。

在Redis 5版本之前，Redis 安全规则只有密码控制 还有通过rename 来调整高危命令比如 flushdb ， KEYS* ， shutdown 等。Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制 ：

（1）接入权限:用户名和密码

（2）可以执行的命令

（3）可以操作的 KEY

参考官网：https://redis.io/topics/acl

13.1.2、命令

1. 使用acl list命令展现用户权限列表

   （1）数据说明

   

2. 使用acl cat命令

   （1）查看添加权限指令类别

   

   （2）加参数类型名可以查看类型下具体命令

   

3. 使用acl whoami命令查看当前用户

4. 使用aclsetuser命令创建和编辑用户ACL

   （1）ACL规则

   下面是有效ACL规则的列表。某些规则只是用于激活或删除标志，或对用户ACL执行给定更改的单个单词。其他规则是字符前缀，它们与命令或类别名称、键模式等连接在一起。

   ACL规则
   类型	参数	说明
   启动和禁用用户	on	激活某用户账号
   	off	禁用某用户账号。注意，已验证的连接仍然可以工作。如果默认用户被标记为off，则新连接将在未进行身份验证的情况下启动，并要求用户使用AUTH选项发送AUTH或HELLO，以便以某种方式进行身份验证。
   权限的添加删除	+	将指令添加到用户可以调用的指令列表中
   	-	从用户可执行指令列表移除指令
   	+@	添加该类别中用户要调用的所有指令，有效类别为@admin、@set、@sortedset…等，通过调用ACL CAT命令查看完整列表。特殊类别@all表示所有命令，包括当前存在于服务器中的命令，以及将来将通过模块加载的命令。
   	-@	从用户可调用指令中移除类别
   	allcommands	+@all的别名
   	nocommand	-@all的别名
   可操作键的添加或删除	~	添加可作为用户可操作的键的模式。例如~*允许所有的键

   （2）通过命令创建新用户默认权限

   ​ acl setuser user1

   

   ​ 在上面的示例中，我根本没有指定任何规则。如果用户不存在，这将使用just created的默认属性来创建用 户。如果用户已经存在，则上面的命令将不执行任何操作。

   （3）设置有用户名、密码、ACL权限、并启用的用户

   ​ acl setuser user2 on >password ~cached:* +get

   

   (4)切换用户，验证权限

   

13.2、IO多线程

13.2.1、简介

Redis6终于支撑多线程了，告别单线程了吗？

IO多线程其实指客户端交互部分的网络IO交互处理模块多线程，而非执行命令多线程。Redis6执行命令依然是单线程。

13.2.2、原理架构

Redis 6 加入多线程,但跟 Memcached 这种从 IO处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂，需要去控制 key、lua、事务，LPUSH/LPOP 等等的并发问题。整体的设计大体如下:

另外，多线程IO默认也是不开启的，需要再配置文件中配置

io-threads-do-reads yes

io-threads 4

13.3、工具支持Cluster

之前老版Redis想要搭集群需要单独安装ruby环境，Redis 5 将 redis-trib.rb 的功能集成到 redis-cli 。另外官方 redis-benchmark 工具开始支持 cluster 模式了，通过多线程的方式对多个分片进行压测。

13.4、Redis新功能持续关注

Redis6新功能还有：

1. RESP3新的 Redis 通信协议：优化服务端与客户端之间通信

2. Client side caching客户端缓存：基于 RESP3 协议实现的客户端缓存功能。为了进一步提升缓存的性能，将客户端经常访问的数据cache到客户端。减少TCP网络交互。

3. Proxy集群代理模式：Proxy 功能，让 Cluster 拥有像单实例一样的接入方式，降低大家使用cluster的门槛。不过需要注意的是代理不改变 Cluster 的功能限制，不支持的命令还是不会支持，比如跨 slot 的多Key操作。

4. Modules API

   Redis 6中模块API开发进展非常大，因为Redis Labs为了开发复杂的功能，从一开始就用上Redis模块。Redis可以变成一个框架，利用Modules来构建不同系统，而不需要从头开始写然后还要BSD许可。Redis一开始就是一个向编写各种系统开放的平台。
   辑用户ACL

   （1）ACL规则

   下面是有效ACL规则的列表。某些规则只是用于激活或删除标志，或对用户ACL执行给定更改的单个单词。其他规则是字符前缀，它们与命令或类别名称、键模式等连接在一起。

   ACL规则
   类型	参数	说明
   启动和禁用用户	on	激活某用户账号
   	off	禁用某用户账号。注意，已验证的连接仍然可以工作。如果默认用户被标记为off，则新连接将在未进行身份验证的情况下启动，并要求用户使用AUTH选项发送AUTH或HELLO，以便以某种方式进行身份验证。
   权限的添加删除	+	将指令添加到用户可以调用的指令列表中
   	-	从用户可执行指令列表移除指令
   	+@	添加该类别中用户要调用的所有指令，有效类别为@admin、@set、@sortedset…等，通过调用ACL CAT命令查看完整列表。特殊类别@all表示所有命令，包括当前存在于服务器中的命令，以及将来将通过模块加载的命令。
   	-@	从用户可调用指令中移除类别
   	allcommands	+@all的别名
   	nocommand	-@all的别名
   可操作键的添加或删除	~	添加可作为用户可操作的键的模式。例如~*允许所有的键

   （2）通过命令创建新用户默认权限

   ​ acl setuser user1

   [外链图片转存中…(img-vCBffL2g-1633487969582)]

   ​ 在上面的示例中，我根本没有指定任何规则。如果用户不存在，这将使用just created的默认属性来创建用 户。如果用户已经存在，则上面的命令将不执行任何操作。

   （3）设置有用户名、密码、ACL权限、并启用的用户

   ​ acl setuser user2 on >password ~cached:* +get

   [外链图片转存中…(img-thmo7Vhs-1633487969582)]

   (4)切换用户，验证权限

   [外链图片转存中…(img-nxelB0Wi-1633487969582)]

13.2、IO多线程

13.2.1、简介

Redis6终于支撑多线程了，告别单线程了吗？

IO多线程其实指客户端交互部分的网络IO交互处理模块多线程，而非执行命令多线程。Redis6执行命令依然是单线程。

13.2.2、原理架构

Redis 6 加入多线程,但跟 Memcached 这种从 IO处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂，需要去控制 key、lua、事务，LPUSH/LPOP 等等的并发问题。整体的设计大体如下:

另外，多线程IO默认也是不开启的，需要再配置文件中配置

io-threads-do-reads yes

io-threads 4

13.3、工具支持Cluster

之前老版Redis想要搭集群需要单独安装ruby环境，Redis 5 将 redis-trib.rb 的功能集成到 redis-cli 。另外官方 redis-benchmark 工具开始支持 cluster 模式了，通过多线程的方式对多个分片进行压测。

[外链图片转存中…(img-0T2SZlJp-1633487969583)]

13.4、Redis新功能持续关注

Redis6新功能还有：

1. RESP3新的 Redis 通信协议：优化服务端与客户端之间通信

2. Client side caching客户端缓存：基于 RESP3 协议实现的客户端缓存功能。为了进一步提升缓存的性能，将客户端经常访问的数据cache到客户端。减少TCP网络交互。

3. Proxy集群代理模式：Proxy 功能，让 Cluster 拥有像单实例一样的接入方式，降低大家使用cluster的门槛。不过需要注意的是代理不改变 Cluster 的功能限制，不支持的命令还是不会支持，比如跨 slot 的多Key操作。

4. Modules API

   Redis 6中模块API开发进展非常大，因为Redis Labs为了开发复杂的功能，从一开始就用上Redis模块。Redis可以变成一个框架，利用Modules来构建不同系统，而不需要从头开始写然后还要BSD许可。Redis一开始就是一个向编写各种系统开放的平台。