Redis浅谈

Posted 2021-04-07 卓尔不凡杂货铺

一、主从复制

在redis中，只能有一个主（Master），可以有多个从（Slave）。

将服务器分为主服务器和从服务器，主的服务器可以允许做读写操作，从服务器只允许做读的操作。

应用场景：

集群（多台服务器）、读写分离、日志备份、高可用。

过程：

1：当一个从数据库启动时，会向主数据库发送sync命令。

2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来。（一旦在主服务器有任何写操作，都会有快照文件记录）

3：当快照文件发生改变的时候，都通知给下面所有的从服务器。

4：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。

5：从数据库收到后，会载入快照文件并执行收到的缓存的命令。

二、哨兵机制

心跳检测，故障转移（选举策略）、监控。

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

·监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

·提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否“活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown)。

若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。

虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。

哨兵(sentinel) 的一些设计思路和zookeeper非常类似。

三、持久化

RDB：以二进制形式，以某个时间点存储。

优点：开启单独的进程去写的io操作，和当前的redis主线程没有任何关联。

缺点：非实时，突然断电数据可能会有部分丢失。

默认开启RDB（dump.rdb），当服务器宕机的时候，默认以RDB方式进行持久化。

#dbfilename：持久化数据存储在本地的文件dbfilename dump.rdb#dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下dir ./##snapshot触发的时机，save ##如下为900秒后，至少有一个变更操作，才会snapshot ##对于此值的设置，需要谨慎，评估系统的变更操作密集程度 ##可以通过“save “””来关闭snapshot功能 #save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个key60s进行存储。save 900 1save 300 10save 60 10000

AOF：实时日志方式记录增删改操作，效率不是很高，会影响到整体性能。

在 append 操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程；当 server 需要数据恢复时，可以直接 replay 此日志文件，即可还原所有的操作过程。AOF 相对可靠，它和 mysql 中 bin.log、apache.log、zookeeper 中 txn-log 简直异曲同工。AOF 文件内容是字符串，非常容易阅读和解析。

优点：可以保持更高的数据完整性，如果设置追加 file 的时间是 1s，如果 redis 发生故障，最多会丢失 1s 的数据；且如果日志写入不完整支持 redis-check-aof 来进行日志修复；AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）。

缺点：AOF 文件比 RDB 文件大，且恢复速度慢。

##此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能 ##只有在“yes”下，aof重写/文件同步等特性才会生效 appendonly yes  ##指定aof文件名称 appendfilename appendonly.aof  ##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec appendfsync everysec ##在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no” no-appendfsync-on-rewrite no  ##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb” auto-aof-rewrite-min-size 64mb  ##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。 ##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后 ##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。

四、发布订阅

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

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

当有新消息通过 PUBLISH 命令发送给频道时， 这个消息就会被发送给订阅它的客户端：

序号	命令及描述
1	PSUBSCRIBE pattern [pattern ...]  订阅一个或多个符合给定模式的频道。
2	PUBSUB subcommand [argument [argument ...]]  查看订阅与发布系统状态。
3	PUBLISH channel message  将信息发送到指定的频道。
4	PUNSUBSCRIBE [pattern [pattern ...]]  退订所有给定模式的频道。
5	SUBSCRIBE channel [channel ...]  订阅给定的一个或多个频道的信息。
6	UNSUBSCRIBE [channel [channel ...]]  指退订给定的频道。

订阅者继承JedisPubSub类，重写onMessage方法

五、事务相关

Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：

事务是一个单独的隔离操作：

事务中的所有命令都会序列化、按顺序地执行。

事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

事务是一个原子操作：

事务中的命令要么全部被执行，要么全部都不执行。

三个阶段：开始事务、命令入队、执行事务

MULTI 开启事务EXEC 执行事务，如事务被打断返回nilDISCARD 取消事务，放弃事务块中的命令操作WATCH key 监听某个key的值是否发生变化,如果发生变化, watch 之后的操作会失败UNWATCH 取消对所有key的监视。如果在执行WATCH命令后，EXEC或DISCARD命令被执行， 那么不需要执行UNWATCH了

语法错误导致的事务入队失败：

事务执行exec之前，入队命令错误，事务终止，取消，不执行。

语法正确，入队，执行失败：

在执行exec之后所产生的错误，即使事务中某个命令发生了错误，事务中的其他命令也会执行。

原则：

Redis命令只会因错误的语法而失败，在入队时不能发现的错误皆是编程错误，Redis认为在生产环境不会产生这样的错误而保证正确的命令一定会执行，不需要回滚支持，所有执行能够保证简单高效。

六、WATCH机制

使用WATCH监视一个或多个key，跟踪key的value修改情况，如果有key的value值在事务EXEC之前被修改了，整个事务被取消。EXEC返回提示信息，表示事务已经失败。本质乐观锁。

WATCH机制使事务EXEC变的有条件，事务只有在被WATCH的key没有被修改的前提下才能执行。不满足条件，事务被取消。使用WATCH监视一个带过期时间的key，那么即使这个key过期了，事务仍然可以正常执行。

①WATCH命令可以被调用多次，对key的监视从WATCH执行之后开始生效，直到调用EXEC为止。不管事务是否成功执行，对所有键的监视都会被取消。

②当客户端断开连接时，该客户端对键的监视也会被取消。

③UNWATCH命令可以手动取消对所有key的监视。