重学Redis笔记

红太狼 2021-09-24 17:04 221阅读 0赞

Redis安装：

(1)下载Redis安装包并上传到服务器

(2)解压Redis，命令：tar -zxvf xxx.tar.gz

(3)切换到Redis解压目录，编译Redis。命令：cd Redis解压目录, make 编译Redis.。这时候会报错找不到gcc

(4)安装gcc依赖，命令：yum install gcc-c++。安装完成gcc后再次执行make命令。

(5)报致命错误：jemalloc/jemalloc.h：没有那个文件或目录。执行make distclean命令后再次执行make命令

(6)执行make install检查redis安装的完整性

(7)切换到redis解压目录拷贝redis.conf到etc目录下，执行命令:cp redis.conf /etc/redis.conf

(8)修改redis.conf文件，把 daemonize no 改为 daemonize yes

(9)切换到usr/local/bin目录，执行命令：  
redis-server /etc/redis.conf

(10)执行命令：  
redis-cli -p 6379

(11)在命令行输入ping测试启动连接是否成功

(12)设置密码：  
a.config set requirepass 密码  
b.修改redis.conf文件，修改\# requirepass foobared

(13)开放Redis端口：  
firewall-cmd --zone=public --add-port=6379/tcp --permanent  
firewall-cmd --reload

(14)redis客户端工具连接测试

切换库：  
select 库名编号

查询当前库的key数量：  
Dbsize

清空当前库：  
FLUSHDB

清空所有库：  
FLUSHALL

Redis索引从0开始

Redis持久化2种方式：

RDB:  
a.在指定的时间间隔内将内存中的数据集快照写入磁盘。也就是Snapshot快照，它恢复时是将快照文件直接读到内存里

b.Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件，待持久化进程都结束了，再用临时文件替换上次持久化好的文件  
整个过程中，主进程不进行任何IO操作，确保了极高的性能。

c.如果需要更行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，RDB比AOF更加高效，RDB的缺点是最后一次持久化后的数据可能丢失

触发RDB快照：  
(1)修改redis.conf配置(save 秒钟 写操作次数)  
默认:  
save 900 1   15分钟修改1次  
save 300 10  5分钟修改10次  
save 60 10000 1分钟修改10000次

(2)save或bgsave  
a.save只管保存，不管其它，全部阻塞  
b.bgsave后台异步进行  
c.手动触发备份当前

(3)FLUSHALL也会备份，也会产生dump.rdb文件，但是会覆盖之前的备份，就一个空文件  
当FLUSHALL之后再Shutdown是无法备份数据

优点：  
a.适合大规模的数据恢复  
b.对数据完整性和一致性不高

缺点：  
a.在一定间隔时间做一次备份，如果主机意外down，就会丢失最后一次数据的修改  
b.fork的时候，内存的数据被克隆一份，大致2倍的膨胀性需要考虑

停止：  
修改redis.conf配置，save ""

修复dump文件：  
redis-ckeck-dump --fix  dump.aof

AOF:  
a.将redis所有完蛋操作记录下来，只许追加文件不可以改写文件  
b.set数据的时候，当执行FLUSHALL命令后也会被记录在appendonly.aof文件里  
c.dump.rdb和appendonly.aof文件同时存在时，优先加载aof文件

修复aof文件：  
redis-ckeck-aof --fix  appendonly.aof

Appendfsync：  
a.Always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但是数据完整性比较好  
b.Everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失  
c.No

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

优点：  
a.Appendfsync Always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但是数据完整性比较好  
b.Appendfsync Everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失  
c.Appendfsync No 从不同步

缺点：  
a.aof文件比rdb文件大，恢复速度慢于rdb  
b.aof运行效率慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

事务：

正常执行：MULTI -> SET -> EXEC

放弃事务：MULTI -> SET -> DISCARD

全体连坐：MULTI -> SET -> getset -> EXEC

冤头债主：MULTI -> SET -> value是字符串的执行:incr  -> EXEC

watch监控：SET -> WATCH -> MULTI -> 对数据decrby/incrby操作 -> EXEC  
会话A监控着数据，其它会话修改了会话A监控的数据，提交事务是失败的  
一旦执行了exec，之前加的监控锁都会被取消掉

a.乐观锁：提交的版本必须大于记录当前版本才能执行更新  
b.悲观锁：整个记录都锁定

redis部分支持事务

主从复制：

一主二仆：  
1.在redis解压目录拷贝redis.conf文件到etc目录，命令如下:  
cp redis.conf /etc/redis6379.conf  
cp redis.conf /etc/redis6380.conf  
cp redis.conf /etc/redis6381.conf

2.配置redis6379.conf/redis6380.conf/redis6381.conf如下：  
daemonize yes

pidfile "/var/run/redis.pid"  修改redis对应端口(6379/6380/6381)

port 端口  修改对应端口6379/6380/6381

logfile "xxx.log"   修改对应端口(6379/6380/6381).log文件

dbfilename "dump.rdb"  修改dump对应端口(6379/6380/6381).rdb文件

requirepass 密码

3.配置从机  
(1)方式一：在slave的redis.conf文件里REPLICATION下配置如下：  
slaveof master主机IP  端口  
masterauth 密码

(2)方式二：在slave的命令行里执行：  
slaveof master主机IP  端口

薪火相传：

配置从机  
(1)方式一：在第一台slave主机的redis.conf文件里REPLICATION下配置如下：  
slaveof master主机IP  端口  
masterauth 密码

在第二台slave主机的redis.conf文件里REPLICATION下配置如下：  
slaveof 第一台slave主机IP  端口  
masterauth 密码

(2)方式二：在第一台slave主机的命令行里执行：  
slaveof master主机IP  端口  
slaveof 第一台slave主机IP  端口

反客为主：  
在一主二仆的情况下，当master主机宕机后，在slave主机上执行 slaveof no one命令，就会从剩下的slave主机中选出master，在slave主机中重新指定master即可

哨兵模式：  
1.在/etc目录下新建文件sentinel.conf

2.sentinel.conf配置如下：  
daemonize yes

sentinel monitor 主机名称 master主机 端口 选举票数

3.启动哨兵模式  
redis-sentinel /etc/sentinel.conf

复制原理：  
1.slave启动成功连接到master后会发发送一个sync命令  
2.master接收命令启动后台的存盘进程，同时收集所有收到的用于修改数据集命令;  
在后台进程执行完成之后，master将传送整个数据到slave，以完成一次完全同步  
3.全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中  
4.增量复制：master继续将新的所有收到到的修改命令依次传给slave完成同步  
5.但是只要是重新连接master，首次完全同步(全量复制)将自动执行

复制的缺点：  
1.IO剧增  
每次slave断开以后(无论是主动断开，还是网路故障)再连接master都要将master全部dump出来rdb，在aof，即同步的过程都要重新执行一遍；所以要记住多台slave不要一下都启动起来，否则master可能IO剧增（间隔1-2分）

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

3.可用性不高  
当有主节点发生异常情况，就会导致不能写入，导致业务出错