redis总结：

1.介绍下redis：

  redis是一个key-value数据库，属于非关系型数据库，可以存储多种数据类型作为value，比如：string（字符串），set（集合），zset（有序集合），list（链表），Hash（哈希类型的映射表）。这些数据类型都支持push/pop、add/remove及取交集并集，和差集及更丰富的操作。这些操作都是原子性的。其中redis的数据都是缓存在内存中，同时redis会周期性的把更新的数据写入到磁盘中或者把修改操作写入到追加的记录文件中，并且在此基础上实现了主从（master-slave）同步。

2.redis的特性：

  (1)速度快（1.数据存储在内存中；2.单线程数据模型；）
  (2)持久化
  (3)多种数据结构
  (4)支持多种编辑语言
  (5)功能丰富
  (6)简单
  (7)主从复制

3.redis是单线程，为什么这么快？

  1.纯内存操作；
  2.非阻塞IO；
  3.避免线程切换和竞态消耗。

4.如何使用redis命令？

  1.拒绝长(慢)命令(keys,flushall)；
  2.一次只运行一个命令

5.redis的存储机制？

  1.redis的存储机制分为快照(SnapShot)和添加到指定文件中（AOF）；
  2.SnapShot工作原理：
    (1)先将数据存储到内存中，当数据累计到某些设定的伐值的时候，就会触发到一次DUMP操作，将变化的数据一次性写入到数据文件中（RDB文件）比如save 900 1（900秒内有一次更新）save 300 10(300秒内有10次更新) save 60 10000(60秒内有10000次更新)就会将变化的数据一次性写入到数据文件中。
  3.AOF工作原理：
    (1)先将数据存储到内存中，但是在存储的时候会调用async异步操作来完成对本次写操作的日志记录，该日志记录文件就是AOF文件。AOF最关键的配置就是关于调用fsync追加日志文件的频率，有两种频率一种就是appendfsync always（每次记录都添加到AOF文件中去），另外一种就是appendfsync everysec（每秒添加一次）。
  4.存储模式性能和安全比较：
    (1)SnapShot方式的性能是远大于aof的，因为snapShot采用二进制方式存储数据，数据文件比较小，加载速度快；
    (2)snapshot方式是当数据累计到某些设定的伐值的时候才将数据写入到RDB文件中，因此存储的频率比较低但是效率比较高，而AOF的存储的频率比较高，效率比较低。
    (3)从安全性来进行考虑的话：aof的数据安全是大于snapshot的，因为snapshot数据存储的方式是基于累计批量的思想，也就是说在允许的情况下，累计的数量越多，那么他的存储效率就越高，但数据的累计是靠时间进行累计的，如果在累计的过程中数据库系统发生崩溃的话，那么在这一段时间累计的数据就会丢失，但是AOF的方式就恰恰相反了，根据AOF配置的存储频率的策略可以做到最少的数据丢失和较高的数据恢复能力。
    (4)说完了性能和安全，还得提下redis的rewrite功能，当数据写入到日志文件中去（AOF方式），当日志文件达到一定的程度（扩大到）的时候就会触发rewrite操作，所谓的rewrite操作就是将日志文件中的所有数据都重新写到新的日志文件中去，但是不同的是，对于老日志文件中key的多次操作，只保留最终的值的那次操作记录到日志文件中，从而缩写日志文件的大小。这里有两个配置需要注意下：
    1.auto-aof-rewrite-percentage 100 (当前写入日志文件的大小占到初始日志文件大小的百分之100的时候触发rewrite操作)
    2.auto-aof-rewrite-min-size 64mb (本次Rewrite最小写入的数据量)
    3.当两个条件都满足的时候才会触发rewrite操作。

6.redis的数据结构及应用场景：

![image](https://img.haomeiwen.com/i8949604/36ff1705e6c40526.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
  1.字符串：缓存，计数器；
  2.哈希结构的映射表：用户信息；
  3.链表；
  4.集合；
  5.有序集合：排行榜；

7.redis的主从配置及哨兵机制：

  1.一主二从三哨兵；
  2.哨兵机制就是：
    1.多个sentinel发现master出现问题；
    2.选举出一个sentinel作为领导者；
    3.选出一个slave作为master；
    4.通知其他slave作为新的master的slave；
    5.通知客户端主从发生变化；
    6.等待老的master恢复过来变成新的master的slave；

1.领导者选举：

  作用：选举出一个sentinel节点作为领导者去做故障转移；
  过程：
    1.每个做主观下线的sentinel节点都会向其他sentinel节点发送请求，请求它们选举自己作为领导者；
    2.如果其他sentinel还没收到其他的sentinel的请求的话，就会同意该sentinel作为领导者，否则拒绝。
    3.如果该sentinel的投票结果大于一半的话就作为领导者；
    4.如果在这个过程中出现多个领导者的话，就会过一段时间再重新选举领导者。

2.选出新的master：

  redis中的sentinel会选择slave-priority最高的slave节点（默认是相同的），或者选择复制的偏移量最大的作为master，如果上述两个条件都不满足的话，就选择启动最早的。

3.更改slave节点的master：

  将其它slave节点的master修改为更改后的master节点，同时将原master节点修复后再将其作为新的master节点的slave节点。

4.通知客户端：

  当所有的slave节点都配置完成后，sentinel节点会通知客户端节点变更信息。

5.客户端变更信息之后连接新的master：

  客户端收到信息后，会连接新的master节点。

8.redis是如何发现master挂掉的：

   3个定时任务：
    1.每隔10秒sentinel会对master和slave发送info命令，目的是发现slave节点，确定主从关系，因为redis的sentinel节点启动的时候默认是发现master节点的，只是没有配置slave节点的信息。
    2.每隔两秒，sentinel都会通过master节点内部的channel来交换信息（基于发布订阅模式），作用是通过master节点的频道来交互每个sentinel对master节点的判断信息
    3.每隔1秒每个sentinel会对其他redis节点（slave，master，sentinel）进行ping命令，对于master来说，如果超过30秒没有回复的话，就对该master进行主观下线并询问其他的sentinel节点是否可以进行客观下线。
参考引用：来自Java思维导图公众号，侵删！