深入学习Redis之redis的高级特性

ゝ一纸荒年。 2021-11-26 13:14 316阅读 0赞

# redis高级特性 #

## 事务 ##

事务：有一个或者SQL语句（命令）有序组成  
事务的特性：一致性、隔离性、原子性、持久性

redis事务和mysql事务的对比：  
![在这里插入图片描述][2019072407565814.png]  
总结：

*  redis的事务原子通过将命令放在一个队列中，通过exec命令执行队列中的命令
 *  在失败情况下进行rollback会回滚所有的命令，但是discard不会回滚已经成功的命令
 *  exec时,报错, 所有语句得不到执行，Exec之后,会执行正确的语句,并跳过有不适当的语句，所以在取消时Redis不能保证其原子性。

**redis多进程下实现保证线程安全，redis使用的是乐观锁。**  
乐观锁与悲观锁 （上锁的的位置不同）  
悲观锁:一段执行逻辑加上悲观锁,不同线程同时执行时,只能有一个线程执行,其他的线程在入口处等待,直到锁被释放.  
乐观锁:一段执行逻辑加上乐观锁,不同线程同时执行时,可以同时进入执行,在最后更新数据的时候要检查这些数据是否被其他线程修改了(版本和执行初是否相同),没有修改则进行更新,否则放弃本次操作.

#使用watch来监控key是否变化
    watch key #当监视的key，因为事务发生变化时，自动取消事务
    unwatch key #取消监视状态

## Redis 频道发布与消息订阅 ##

#声明一个频道，并发布消息
    publish news "today is sunshine"
    
    #打开另一个窗口
    subscribe news #订阅news，这个窗口会进入监听状态
    psubscribe new* #利用通配符监听多个频道
    
    #发布号查看订阅自己的订阅者
    pubsub channels news

## Redis持久化 ##

mongoDB通过主从的方式来持久化，master放在内存中，cluster将数据存储到硬盘中。  
mysql通过日志的方式来存储日志。

**持久化及原理（原生持久化&结合mysql数据库持久化）**  
**方式一：快照**  
RDB（默认） 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。  
以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集：

save 60 1000  #save可以设置多个 会从时间少的先检测
    save 300 10   #300秒为一个间隔，如果中间出现异常，并不触发保存条件

在使用快照模式进行持久化时，如果发生硬盘已满，快照存储失败，而客户端依旧向redis服务器发送数据这样会导致数据不一致，在配置文件设置：

stop-writes-on-bgsave-error yes  #出错时，客户端禁止写入

更多快照的配置属性：

rdbcompression yes #使用LZF压缩rdb文件
    rdbchecksum yes #存储和加载rdb文件时校验
    dbfilename dump.rdb #设置rdb文件名
    dir ./ #设置工作目录，rdb文件会写入该目录

rdb：  
**弊端：在保存时间的间断中如果不满足保存条件，突然发生断电或者系统崩溃会导致数据丢失。  
优势：数据恢复十分快。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDk5MDgxOA_size_16_color_FFFFFF_t_70]

**方式二：同步到数据文件**  
AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。(经所有的指令存储到文本文件中)  
配置AOF:

appendonly yes #是否仅要日志
    
    appendfsync no # 系统缓冲,统一写,速度快
    appendfsync always # 系统不缓冲,直接写,慢,丢失数据少
    appendfsync everysec #折衷,每秒写1次

**弊端：每一条指令都记录到文本文件中会极大地拖垮redis的性能。  
优势：执行的周期比rdp短，能防止间隔异常导致数据丢失**

**方式三：使用虚拟内存的方式**  
补充：  
如何解决使用aof时同一个key被大量的过程操作，造成性能的浪费  
答：使用aof重写。

no-appendfsync-on-rewrite no #重写aof时同步最新数据
    auto-AOF-rewrite-percentage 100 当前aof文件是上次重写是大N%时重写
    auto-AOF-rewrite-min-size 64mb aof重写至少要达到的大小

在dump rdb过程中,aof如果停止同步,会不会丢失?  
答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作.

注: aof重写是指什么?  
答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里.  
以解决 aof日志过大的问题.

问: 如果rdb文件,和aof文件都存在,优先用谁来恢复数据?  
答: aof （aof的优先级高于rdb）

问: 2种是否可以同时用?  
答: 可以,而且推荐这么做

问: 恢复时rdb和aof哪个恢复的快  
答: rdb快,因为其是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行

## redis主从复制 ##

**redis实现集群的作用**

*  主从备份，防止主机宕机
 *  读写分离，分担master的任务
 *  任务分离，从服务器分担备份和计算的工作

在Redis中，用户可以通过执行SLAVEOF命令或者设置slaveof选项，让一个服务器去复制（replicate）另一个服务器，我们称呼被复制的服务器为主服务器（master），而对主服务器进行复制的服务器则被称为从服务器（slave），如图所示。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDk5MDgxOA_size_16_color_FFFFFF_t_70 1]

#从服务器默认都是只读模式  这是从服务器中复制master
    slaveof 127.0.0.1 6379
    #解除readonly 模式 存在数据不一致的风险
    slaveof no one

**主从复制的基本设置**  
在内网中不建议设置密码，这样会影响redis之间的传输速率

1. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
        slaveof <masterip> <masterport>
    2. 当master服务设置了密码保护时，slav服务连接master的密码
        masterauth <master-password>
    3. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
        requirepass foobared

*  主从服务器之间的通讯方式
 *  从服务器获取master的rdb镜像(旧的数据)和aof文件（新命令）来进行复制主服务器
 *  replicationFeedSlaves这个线程通知slave，master存在变化
 *  master开启aof功能关闭rdb,从服务器开启rdb功能关闭aof.这样配置使从服务器承接了主服务器的rdb备份任务，主服务器的aof更加全面，确保了数据的一致性。
 *  从服务器设置只读，每次slave断开后，再次连接master,都要求master先传输rdb，再传输aof，所以同一时间内尽量避免同时启动大量的slave。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDk5MDgxOA_size_16_color_FFFFFF_t_70 2]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDk5MDgxOA_size_16_color_FFFFFF_t_70_pic_center]

[2019072407565814.png]: /images/20211126/41a3c83ac06d42d49197a7548755c5ac.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDk5MDgxOA_size_16_color_FFFFFF_t_70]: /images/20211126/72daa2c2c6444f7d8a24bdc288a0d088.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDk5MDgxOA_size_16_color_FFFFFF_t_70 1]: /images/20211126/e9ce29a0d94e4bc9b19af91dbbd137d6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDk5MDgxOA_size_16_color_FFFFFF_t_70 2]: /images/20211126/16999ca86dfe4764a2483c16237c6513.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDk5MDgxOA_size_16_color_FFFFFF_t_70_pic_center]: /images/20211126/b3a2b98a1424427f8e4e33c4d6836d15.png