hello，我又来了，作为一个菜鸟，这几天我又重新学习了下，redis的一些知识点，其中包括持久化机制，主从复制，哨兵机制，淘汰策略，缓存穿透，击穿，雪崩。下来我们来依次介绍下。
持久化机制：
在学习持久化机制的时候我们必须了解两个概念：AOF和RDB
AOF:增量同步，我们可以理解为当我们监听到key发生变化时，数据就会做一次同步操作
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件，能够保证数据不丢失，但是效率非常低。
appendfsync everysec #每秒钟同步一次，可能会丢失1s内的数据，但是效率非常高。
appendfsync no #从不同步。高效但是数据不会被持久化。
直接修改redis.conf中 appendonly yes
在实际应用中建议用everysec 既能够保证数据的同步、效率也还可以
RDB：全量同步，我们可以理解为是一个定时任务，每天定时同步数据，已二进制存储，文件名为dump.rdb
Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照
当我们搭建好之后，我们默认开启rdb同步，如果想开启aof同步，可以去修改配置文件，这样持久化就好了。
区别：他们的区别就是增量同步耗内存，效率高，但是全量同步如果主节点挂掉，容易丢失数据，在redis中默认开启rdb同步
主动复制：
其实主从复制的概念很好理解，在Redis集群中，主节点的数据采用AOF或rdb的形式，同步到从节点。这样就可以实现，但是这样会有一个缺陷，如果主节点宕机，整个环境就变为不可写，需要我们人工修改配置文件，这样太不方便了，因此有了哨兵的出现。
现在的主从复制有两种情况：一种是一主多重，一种是多主多重；
一主多重是所有的从节点都指向主节点。
多主多重是类似于二叉树，子节点指向主节点，以此类推。
哨兵机制：
通俗点来讲一个哨兵就是一个具有选票的人，我们可以判断领导你的人做的事情是否正确，相当于监听，我们可以知道他每天做了什么，当我们不知道的时候，我们可以选择新的领导者。因次，在分布式中redis有多少我们的哨兵就建议有多少，这样是为了选举的公平性。
官方的来说就是哨兵监听主节点，怎么监听呢，在我们redis中可以找到sentinel.conf这个配置文件没这个就是关于哨兵的配置，我们要像启动redis一样，把他copy到bin的路径下，然后进入到里面找到sentinel monitor mymaster，后面的分别表示主节点的IP，端口号，后面那个我们根据哨兵的个数来设置，一般情况下设置为比哨兵个数少就可以，但必须大于1
sentinel monitor mymaster 192.168.212.160 6379 3
sentinel auth-pass mymaster 123456 密码我们可以设置可以不设置
当时我们每个哨兵都设置好之后，我们的哨兵集群相当于都订阅了相同的通道，如果有新的哨兵连接了主节点，那么该通道就会与新的哨兵建立长连接。
如何判断主节点发生故障：
每个哨兵都是向主节点发送ping命令，如果主节点没有相应，哨兵就会认为主节点为“主观不可用状态”，会发送其他哨兵确认主节点是否可用，如果不可用数大于刚刚的那个配置数的话，我们就认为主节点发生故障，重新选举。
后续有时间给大家更新redis的击穿，穿透，雪崩。