Redis进阶之发布订阅及事务机制（干货满满）

前言

各位伙伴们，大家好！由于篇幅较长，所以笔者将采用多篇Blog发布的形式来方便大家阅读，整篇Blog全程干货满满，给大家带来不便敬请谅解！
最后附上前篇Blog链接：Redis基础之概述安装及五大数据类型（干货满满），如有需要的小伙伴可点击查看哦~

Redis

1 Redis配置文件介绍

默认目录：/usr/software/redis-6.2.1/redis.conf

自定义目录：/usr/myredis/redis.conf

1.1 Units单位

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

大小写不敏感

1.2 INCLUDES包含

• 配置文件特性：后面的内容将覆盖前面的内容

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

1.3 网络相关配置

1.3.1 bind!!

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

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

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

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

1.3.2 protected-mode!!

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

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

1.3.3 Port!!

端口号，默认 6379

1.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）两个值来达到想要的效果

1.3.5 timeout

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

单位：秒

1.3.6 tcp-keepalive

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

单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60

1.4 General通用

1.4.1 daemonize!!

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

守护进程，后台启动

1.4.2 pidfile

1.进程文件及路径设置。当Redis在后台运行的时候，Redis默认会把pid文件放在/var/run/redis.pid，你可以配置到其他地址。当一台server同时运行多个redis实例时，需要指定不同的pid文件和端口。

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

1.4.3 loglevel

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

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

1.4.4 logfile

日志文件名称：设置日志文件的输出路径

“/usr/myredis/redis.log”

将标准输出(stdout)重定向到/dev/null(linux黑洞)，表示丢弃对应的内容 。而标准错误(stderr)没有设置，会打印错误信息

1.4.5 databases 16

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

1.5 SECURITY安全–设置密码

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

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

1.6 LIMITS限制

1.6.1 maxclients

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

1.6.2 maxmemory !!

• 建议必须设置，否则，将内存占满，造成服务器宕机

• 设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。

• 如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。

• 但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。

1.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：不进行移除。针对写操作，只是返回错误信息

1.6.4 maxmemory-samples

• 设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。

• 一般设置3到7的数字，数值越小样本越不准确，但性能消耗越小。

2 Redis的发布和订阅(了解)

2.1 什么是发布和订阅

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

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

2.2 Redis的发布和订阅

1、下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

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

2.3 订阅命令行实现

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

SUBSCRIBE channel1

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

publish channel1 hello

返回的1是订阅者数量

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

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

3 Redis_事务_机制

3.1 Redis的事务定义

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

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

3.2 Multi、Exec、discard

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

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

【案例一】：组队成功，执行成功

【案例二】：组队阶段报错，提交失败

【案例三】：组队成功，提交有成功有失败

3.3 事务的错误处理

1. 组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。（语法错误可以回滚）
2. 如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。（语义错误无法回滚）

3.4 为什么要做成事务

想想一个场景：有很多人用你的账户，同时去参加双十一抢购

事务冲突的问题

3.4.1 例子

一个请求想给金额减8000

一个请求想给金额减5000

一个请求想给金额减1000

3.4.2 悲观锁

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

3.4.3 乐观锁

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

3.4.4 WATCH key [key …]

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

3.4.5 unwatch

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

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

http://doc.redisfans.com/transaction/exec.html

3.5 Redis事务三特性

1. 单独的隔离操作

   事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

​ 2.没有隔离级别的概念

​ 队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

​ 3.不保证原子性

​ 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

=========================================================

后记

好啦，以上就是本期全部内容，能看到这里的人呀，都是能人。

十年修得同船渡，大家一起点关注。

我是♚焕蓝·未来，感谢各位【能人】的：点赞、收藏和评论，我们下期见！

各位能人们的支持就是♚焕蓝·未来前进的巨大动力~

注：如果本篇Blog有任何错误和建议，欢迎能人们留言！