Linux服务器开发,Reids源码 主从同步与对象模型

────────────────────────────────────────────────────────────────
┌————————————┐
│▉▉♥♥♥♥♥♥♥♥ 99% │ ♥❤ 鱼沈雁杳天涯路,始信人间别离苦。
└————————————┘
对你的感情正在充电中，请稍侯…
────────────────────────────────────────────────────────────────

推荐一个零声学院免费公开课程，个人觉得老师讲得不错，分享给大家：Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等技术内容，立即学习

────────────────────────────────────────────────────────────────

一、持久化，以及持久化选择（重点）

redis的源码感觉还是要看，但是不是现在看，应该是在自己掌握了linux内核等相关知识后再看。

• appendonly：在文件中附加数据，选项改为yes即可开启aof

1、aof

• 策略怎么选择？
• aof占用逻辑主线程
• 不仅要开启aof，还要选择策略，关闭一些设置
• 我们平时时间循环会先处理读事件再处理写事件，当开启aof后会先处理写事件再处理读事件。为什么这样做呢，Mark老师讲在源码中有个事件调转，因为这样会先读完后做持久化，再处理写事件，最后发送对端。
  

aof策略

• always：每一个命令
• everysec：每秒钟

持久化什么内容？持久化的这条命令是协议数据

• pidfile:进程写在对应的位置
• logfile:日志存放的位置
• daemonize:yes 表示开启后台
• save “”：表示关闭rdb
• :x :表示保存，类似于wq！

关闭一组redis集群，awk的实际应用

• ps -aux| grep redis-server | awk ‘{print ‘$2’}’ | xargs kill -9
• tail appendonly.aof

具体原理

redis宕机后，将aof记录的命令重新执行命令。

aof 缺点

随着时间的推移，aof会逐渐的累计。重放aof会非常耗时，导致长时间无法对外提供。

2、补救措施 aof-rewrite

感觉有点像服务给做了一个简单的计算，把aof进行瘦身处理。
两个方式开启aof-rewrite：

• 命令的方式：bgrewrite command 输入命令后会立刻fork出一个子进程。当然，前提是要开启aof。
• 配置文件里进行设置。
  显然，这种精简的日志只会不断的增加。当fork子进程执行完成后，通过先前创建的管道将精简后的数据通过信号发送到主循环，aof记录的内容将附加到aof-rewarite之后。父记录一些统计状态和指标这个过程有一部分并没有精简，那该怎么办呢？我们继续往下说。
  

如何配置aof-rewrite

aof-rewrite策略

aof-rewrite缺点

aof复写的数量依然非常大，加载缓慢。

3、rdb快照持久化

rdb是通过fork出子进程，在子进程中将内存当中的数据键值对按照存储方式持久化到rdb文件中；rdb存储说的是经过压缩的二进制数据，是一种更快的方式。

rdb的配置

rdb相比较四种持久化方式非常特殊，所以必须要关闭aof，其他的都需要开启aof。根据内存状态进行持久的。redis下载完后，redis.conf文件默认是开启rdb的。下图的三个save，任意一个达成都会进行持久化。举例来说:“save 3600 1” 意思就是每隔3600秒进行一次修改。

rdb的策略

缺点

这个rdb的策略非常重要，遗漏丢失数据的原因主要和策略有关系。当实际情况无限接近于满足所有rdb策略的情况发生时，数据会发生丢失最大的东西，好吧，说的好有道理，不知道说的是否明白清楚。

4、混合持久化

• aof方式文件大且加载慢但丢失少。
• rdb文件小且加载快但丢失多。
• aof复写的时候持久化的内容是rdb，等持久化后，持久化期间修改的数据以aof的形式附加到文件的尾部。
• 混合持久化是吸取rdb和aof两者优点的持久化方案，实际是在aof复写的基础上进行优化，所以需要开启aof-rewrite。
  

混合持久化配置

5、应用指导

• 通常redis不开启持久化，只缓存热点数据，数据来源于mysql。若某些数据经常访问需要开启持久化，此时可以选择rdb持久化方案，允许丢失一段时间数据。
• 对数据要求可靠性较高，在机器性能，内存也安全（fork 写时复制 最差的情况下 96G）的情况下，可以让redis同时开启aof和rdb。值得注意额时，此时并不是混合持久化。redis重启优先从aof数据加载，理论上aof包含更多的最新数据；如果只开启一种，那么使用混合持久化。
• 在允许丢失的情况下，亦可采用主redis不持久化（96G 90G），从持久化。
• 伪装从库。
  
  
  

二、主从复制

拷贝持久化文件是否安全？

是安全的。持久化文件一旦被创建，就不会进行任何修改。当服务器创建新持久化文件时，它先将文件的内容保存到一个临时文件里面，当临时文件写入完毕时，程序才使用renanem(2)原子地用临时文件替换原来的持久化文件。
数据安全要考虑以下两个方面：

节点宕机（redis是内存数据库，宕机数据会丢失）

磁盘故障

• 创建一个定期任务(cron job)，每小时将一个RDB文件备份到一个文件夹，并且每天将一个RDB文件备份到另一个文件夹。
• 确保快照的备份都带有相应的日期和时间信息，每次执行定期任务脚本时，使用find命令来删除过期的快照：比如说，可以保留48小时内的每小时快照，还可以保留最近一两个月的每日快照。
• 至少每天一次，将RDB备份到阁下的书库中心之外，或者至少是备份到阁下运行的redis服务器的物理机器之外。

redis主从复制解决了单点故障的问题

命令：redis-server --replicaof 127.0.0.1 7002

意思是把7002的redis作为一个主redis数据库

数据同步

全量数据同步

• 从先连接主，后发送ping命令保证主未阻塞。
• 就算主采用aof持久化，也会通过rdb去同步数据到从。主从都是通过rdb的方式进行同步。

增量数据同步

• 从发送数据到主，当网路抖动时，允许有主从数据间并非实时同步，故引入环形缓冲区的概念。主将抖动数据写入主的环形缓冲区，而从记录偏移值，与主比较，核对是否发生偏移，如果在环形缓冲区就就去主拿到数据。
• runid的作用：仅仅通过ip:port这种方式记录主从关系有所欠缺，而runid时master的唯一标识，从去确认谁时主。
• 环形缓冲区的大小为2的64次方，可以放心用5000年，所以不会出现回绕的低级错误。

三、哨兵（cap）

高可用有两个衡量值：响应时间和功能上的缺失。

c all nodes see the same data at the same time

• 强一致性（效率非常低，工匠精神应该去研究）
• 最终一致性（redis，mysql）

a read and writes always succes

• 合理时间内返回合理的值
  什么是合理的时间发回合理的值？
  个人理解是当主发生宕机，从可以快速接替成为主。整个redis系统在非常短的时间内能返回一个正确的值，而非一个空值。

p in order to model partition tolerance, the network will be allowed to lose arbitrarily many messages sent from one node to another.

当网络分区故障时仍然能够提供一致性或可用的服务。一般都会先考虑p，再考虑a c。

四、哨兵cluster（重点）

期望所有的从都同意选举结果再返回，但是raft算法认为半数通过就可以返回。
clent客户端先访问哨兵集群，拿到主redis的信息。当主redis发生宕机后，client客户端就会再次访问哨兵集群，而哨兵集群通过选举会再次告诉client客户端主正常的redis的信息
因为redis集群采用最终一致性原则，所以主从redis之间的数据会有差异，哨兵系统根据各个从数据库的偏移值进行推荐新的主redis，偏移值越大说明该redis的值越新。

一致性算法

• paxos zk(比较难看懂，可以研究)
• raft （后端开发必须掌握的）

配置（用到的概率低）

Codis集群

分布式定时器

cluster集群（去中心化）

从任意节点出发，通过key去算槽位找真实节点。

应用

• redis-cli -c ：表示以cluster的方式启动
• cluster info：查看集群信息
• cluster nodes：查看节点信息
• 因为redis是异步的，从数据库不认为自己数据是最新的，所以会跳转到主数据库拿数据。