Redis:常用命令&事务&发布与订阅&持久化机制&主从复制介绍

本文使用的工具是：redis-desktop-manager

具体地址是：https://download.csdn.net/download/fenghuoliuxing990124/10848838

OK，接下来是正文

Redis常用命令

1. 返回满足的所有键 keys * (可以模糊查询)

注：该命令在服务端一定要禁用，顺丰的那位删库跑路的兄弟就是在服务器上敲了这个命令导致服务器产生了雪崩效应

2.del 删除一个key

3.exists 是否存在指定key

4.expire 设置某个key的过期时间（秒为单位），使用ttl命令查看剩余时间

persist 取消过期时间

select 选择数据库 数据库为0到15(一共16个数据库) 默认进入的是0数据库

这里的特点是各自数据库之间是隔离的，默认是0号数据库

move [key] [数据库下标] 将当前数据中的key转移到其他数据库中

randomkey 随机返回数据库里的一个key

rename重命名key

echo 打印名

dbsize 查看数据库的key数量

info 获取数据库信息

config get * 返回所有配置信息

config get 返回指定的配置信息

比如我们这里要去查询当前当前Redis使用的文件夹

或者查询当前从Redis的读取权限

很危险的两个命令，这里就不演示了，下面两个命令应该在生产环境中禁止使用

flushdb 清空当前数据库

flushall清空所有数据库

Redis中的事务

redis可以把一组操作包装在一个事务块中，让这些语句的执行具有原子性

multi：相当于开启事务，这时对redis所有的数据操作都会放到队列里进行保存

exec：相当于提交事务，依次执行队列中的操作

discard：相当于回滚事务，在队列中保存的操作被销毁，不会执行

事务例子

模拟场景：转账

id为100的用户有100元

id为101的用户有10元

id为100的用户转500元给id为101的用户

set user?account 1000

exec

get user?account

set user:101:account 10

get user:101:account

multi

decrby user?account 500

discard //回滚

get user?account

再来转一次

multi

decrby user?account 500

incrby user:101:account 500

exec

Redis中的事务原理：就是以multi为起点，在提交之前，先把所有的语句都放在一个队列中，直到exec才做事务的提交

Redis的发布与订阅

redis提供了一个订阅和发布消息的功能，在这个功能中，redis扮演了一个消息路由服务的功能

使用subscribe [channel…] 进行订阅监听，可同时监听多个频道

使用publish [channel] [message] 发送消息到指定的频道

使用unsubscribe [channel…]取消监听，可同时取消多个频道

redis的订阅/发布性能非常高，可以达到15000/秒次；非常适合用于完成实时消息通知、消息队列等场景；

模拟场景：给id为91的贴点赞，模拟朋友圈

//设计消息中心
post:91:good:message

设定消息订阅（监听模式）

消息的发布：这里通过建立消息渠道发布"good"

最后收到消息

Redis的持久化机制

Redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到硬盘来保证数据的持久化。

Redis数据持久化的目录可以在redis.conf文件指定，属性名为dir，默认值为./，（当前目录的意思）

所以在默认情况下，在哪个目录下执行redis-server启动redis实例，就在哪个目录下生产数据持久化文件。所以我们应该修改dir属性，指定一个数据持久化的目录，避免出现数据丢失的问题。

Redis持久化的两种方式：RDB和AOF

RDB

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。

redis默认打开这种持久化方式，保存的文件名为dump.rdb.可以配置设置自动做快照持久化方式.我们可以配置redis在n秒时如果超过m个key被修改就自动做快照.

保存设置:

save 900 1 #在900秒时如果超过1个Key被修改则发起快照保存

save 300 10 #在300秒时如果超过10个key被修改,则发起快照保存

save 60 10000 #在60秒时如果超过10000个key被修改,则发起快照保存

关闭方式：三条代码都注释掉就OK了，默认情况下RDB是自动开启的

AOF

为了解决RDB的key非要到达多少才去做保存而有了AOF的方式保存数据

append-only file (缩写aof)的方式,由于快照方式是在一定时间间隔做一次,所以可能发生reids意外down的情况就会丢失最后一次快照后的所有修改的数据.aof比快照方式有更好的持久化性,是由于在使用aof时,redis会将每一个收到的写命令都通过write函数追加到命令中,当redis重新启动时会重新执行文件中保存的写命令来在内存中重建这个数据库的内容.这个文件名为:appendonly.aof

（有点像MySQL中的binlog）

aof设置:
appendonly yes //启动aof，默认为no

持久化方式有三种修改方式：
#appendfsync always//收到命令就立即写到磁盘,效率最慢.但是能保证完全的持久化
#appendfsync everysec//每秒写入磁盘一次,在性能和持久化方面做了很好的折中
#appendfsync no //完全以依赖os 性能最好,持久化没保证

在对应redis.conf去做修改，之后重启redis即可

测试是否生效？

原本Redis在重启后，原有保存在Redis中的数据是会失效的，比如你连15分钟都没有凑够（RDB原则）就退出了Redis

现在重启后，查询keys * 是能够重新查询到keys值的

主从复制

主从复制(Redis2.0就有的功能,主要实现读写分离的):
特点：

1.master可以拥有多个slave

2.slave也可以成为其他slave的master（选举机制）

3.主从复制是异步的过程，不会产生master和slave的阻塞（这点很优秀）

4.在redis中，要实现主从配置非常简单，只需要修改slave的配置，不需要修改master的配置

主从复制过程：

1.slave与master建立连接,发送sync同步命令

2.Master会开启一个后台进程,将数据库快照保存到文件中.同时master主进程会执行新的写命令并缓存

3.后台完成保存后,就将文件发给slave

4.Slave将文件保存到硬盘上

主从复制配置:（只需要修改slave的redis.conf）

1.如果在同一台服务器做 redis主从，则只需要copy一份redis.conf文件

2.使用vi编辑器打开slave的配置文件/path/to/redis.conf

（两者内容其实是一样的）

3.进入vi后首先配置读取配置文件和备份文件的地址

其次是修改端口，不能与Master重复

4.修改属性 slaveof

5.修改属性 masterauth

注意大前提：

1.确定是否修改了bind 0.0.0.0 和 protected-mode no

只能bind本机一定要注释掉和保护模式一定要关掉

2.如果开启了Redis主从，那么slave就只能读不能写，如果需要slave也能做写操作，那么需要把slave-read-only改为no

之后就是重启服务做测试了

连接从数据库：（如果你也是阿里云ECS，记得修改安全组策略，开放端口）

在Master处添加一条数据

在Slave处查询

只读权限验证

Jedis

Jedis的简单使用：https://blog.csdn.net/fenghuoliuxing990124/article/details/85108967