Redis架构第一天：持久化机制、主从架构理论、压测
龙果学院高并发与高性能大型缓存架构学习第二天：第一讲：摘要
学习的意义：
掌握缓存架构的人屈指可数
阻碍：高并发+高性能场景---->系统崩溃 技术多而不精
这套课程很牛逼 似的
qps：服务器处理流量的衡量标准
面临的问题：烦恼
访问量大+数据量大+数据备份恢复问题
缓存失效问题
缓存穿透，给Mysql巨大压力
恐怖的缓存雪崩？what？
服务高可用？避免多层服务依赖因为少量故障导致系统崩溃？waht？一脸懵逼
热点缓存导致单机负载瞬间超高？
高并发场景下：缓存冷启动Mysql瞬间打死缓存重建的分布式并发重建的冲突问题数据库和缓存双写不一致
大value缓存全量更新效率低下的问题
缓存命中率提升到极致
课程流程：
学好这套课程是成为架构师的必经之路
亿级流量电商网站的商品详情页：
各种个样高并发场景--->对应着各种技术
商品详情页系统架构--->缓存架构--->高并发技术+解决方案+架构--->高可用技术+解决方案
第二讲：RDB持久化机制
先安装一个redis图形化界面压压惊...
1.配置RDB持久化：redis.conf文件，也就是/etc/redis/6379.conf，去配置持久化
save 例如：save 60 1000 每隔60秒、1000个key限制 可以设置多个 生成一个dump.rdb 快照
手动save bgsave，同步或者异步执行rdb的生成
mac下redis开机自启动、后台运行：https://blog.csdn.net/langzi7758521/article/details/51684413
停止redis服务
lsof -i :端口号
kill -9 PID
2.RDB持久化机制的工作流程（So easy!）
(1)根据配置文件尝试去生成rdb文件
(2)fork一个子进程出来
(3)将数据dump到一个临时的rdb快照文件中
(4)完成rdb快照文件之后，替换旧的老快照
3.redis持久化实践总结：shutdown之前会把redis缓存中的信息持久化可以尝试kill进程
问题：
save写了没起作用啊？redis-conf文件没找到，就会使用一个默认的配置文件，汗死
Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
权限受限啊，终于成功了：
Failed opening the RDB file dump.rdb (in server root dir /) for saving: Permission denied
819:M 09 May 15:54:43.164 # Background saving error
success
其他配置：
dbfilename dump.rdb 定义文件的名称
dir ./ 定义文件存放的目录
rdbcompression yes rdb文件是否压缩
第三讲：AOF持久化机制
1.AOF持久化配置（AOF更加细致化操作，更加完整） appendonly yes
fsync策略：always（和mysql有啥子区别啊,考虑到吞吐量qps，不建议使用） everysec:常规，QPS上万 no（擦，不管你了，爱咋的咋的）
2.又到了游戏实验环节了
appendfilename "pnada.aof" 文件名称
pnada.aof 看到了成功
问题来了：只是将aof中的信息进行了回复，rdb中的信息没有回复啊？稍后解决 ，似的
3.AOF rewrite
问题：redis数据有限，总是不断翻新变化的
redis 2.4之前需要手动添加脚本 redis 2.4之后自动执行rewrite操作 当前redis版本：Redis 4.0.6
rewrite策略：
auto-aof-rewrite-percentage 100 超出之前的100%
auto-aof-rewrite-min-size 64mb 同时满足大于64mb，才会触发rewrite
过程如下：达到的效果就是数据的完整性
（1）redis fork一个子进程
（2）子进程基于当前内存中的数据，重构日志，向临时aof文件写日志
。。。动动脑子也就知道怎么一个过程了
4.AOF破损文件的修复
用redis-check-aof --fix 命令来修复破损的AOF文件
swap file "*.swp" already exists!的解决方法
参考网址：https://blog.csdn.net/zhengxiangwen/article/details/50631720
5.aof和rdb同时工作
快照和aof rewrite依次执行。可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。
问题：如何让rdb和aof的信息都恢复到redis里面呢？
第四节：企业级持久化配置策略
配置和前面无差异
RDB作冷备
数据备份方案：
（1）crontab定时调度脚本去做数据备份
（2）每小时copy一份到一个目录下，作为24小时最新备份
（3）每天保留一份rdb备份，保留最近一个月的备份
（4）可以考虑发送一份到远程云服务上
crontab的使用：
https://blog.csdn.net/xiyuan1999/article/details/8160998
数据恢复方案：找到最新的备份进行恢复即可
实验：aof和rdb双开不同步问题。。。。。rdb读取到内存、热修改配置内存读取到aof中，再次停止redis，手动修改配置(config get set )打开aof命令、BGREWRITEAOF,再次重启redis
第五节：通过读写分离qps超过10万+
redis缓存架构是提高高并发的重要一环
写请求qps几千、读请求qps几十万
主从架构--->读写分离--->支撑10万+读qps架构 redis replication
一主多从、主负责写、并将数据复制到其他slave节点、从节点负责读取，从节点可以横向扩展
redis replication的核心机制
（1）异步复制数据到slave节点
（2）slave node可以连接其他slave node
（3）复制过程中不会block其他节点和本节点的操作，旧数据覆盖新数据的时候，暂停对外服务
master持久化对主动架构的安全意义：动动脑子。。。不能使用slave node作为master node的热备
高可用机制：slave node可以直接接管master node，但是原先的主节点也要做好备份
主从架构的核心原理：
slave不会过期key（只负责同步数据，和数据的读请求，废话）
无磁盘化复制：repl-diskless-sync no repl-diskless-sync-delay经过一定时常开始复制
主从复制断点续传：如果复制过程网络连接断开、接着上次复制的地方接着复制 根据offset判断
主从架构核心原理：第一次连接fullresynchronization全量同步。 其他resynchronization 部分同步rdb快照
复制的完整流程：
（1）slave node启动，仅仅保存master node的信息，包括host和ip，redis.conf里面的slaveof配置的
（2）slave node定时任务，和master建立socket网络连接
（3）口令认证，matser requirepass，slave node必须发送masterauth
（4）第一次全量复制
（5）后续写命令
数据同步相关的核心机制：全量复制的细节
（1）master和slave都会维护一个offset 得知道还有那些没有复制啊
（2）backlog在master，主要做全量复制后的增量复制
（3）mater run> （4）psync runid offset
全量复制细节：
（1）master执行bgsave，在本地生成一份rdb快照文件
（2）master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数
（3）对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
（4）master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node
（5）client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
（6）slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
增量复制细节：
（1）如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制
（2）master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB
（3）msater就是根据slave发送的psync中的offset来从backlog中获取数据的
其他：主从节点互相都会发送heartbeat信息 master默认10秒发送一次 slave node每隔1秒发送一个hearbeat、异步复制
第六讲：实践.压测
./redis-benchmark -h 192.168.31.187 -c连接数 -n访问数 -d set/get的数据的大小
前面操作，水平扩容redis读节点，提高吞吐量
QPS两个杀手：复杂的操作 大数据
压测结果：
====== PING_INLINE ======
100000 requests completed in 0.84 seconds
50 parallel clients
3 bytes payload
keep alive: 1
99.99%
页:
[1]