redis

应用场景：
1.缓存功能：String字符串是最常用的数据类型，不仅仅是Redis，各个语言都是最基本类型，因此，利用Redis作为缓存，配合其它数据库作为存储层，利用Redis支持高并发的特点，可以大大加快系统的读写速度、以及降低后端数据库的压力。
2.计数器：许多系统都会使用Redis作为系统的实时计数器，可以快速实现计数和查询的功能。而且最终的数据结果可以按照特定的时间落地到数据库或者其它存储介质当中进行永久保存。
3.共享用户Session：用户重新刷新一次界面，可能需要访问一下数据进行重新登录，或者访问页面缓存Cookie，但是可以利用Redis将用户的Session集中管理，在这种模式只需要保证Redis的高可用，每次用户Session的更新和获取都可以快速完成。大大提高效率。

应用场景：
Redis中的Hashes类型可以看成具有String Key和String Value的map容器

应用场景：
List 存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的东西。
比如，我们常用的博客网站的文章列表，当用户量越来越多时，而且每一个用户都有自己的文章列表，而且当文章多时，都需要分页展示，这时可以考虑使用Redis的列表，列表不但有序同时还支持按照范围内获取元素，可以完美解决分页查询功能。大大提高查询效率

应用场景：
Set 是无序集合，会自动去重，有需要去重的功能可以直接放进set，自动就完成了去重
你当然也可以基于 JVM 内存里的 HashSet 进行去重，但是如果你的某个系统部署在多台机器上呢？得基于Redis进行全局的 Set 去重。
可以基于 Set 玩儿交集、并集、差集的操作，比如交集吧，我们可以把两个人的好友列表整一个交集，看看俩人的共同好友是谁？对吧

应用场景：
Sorted set 是排序的 Set，去重但可以排序
排行榜：有序集合经典使用场景。例如视频网站需要对用户上传的视频做排行榜，榜单维护可能是多方面：按照时间、按照播放量、按照获得的赞数等

可能原因：
命令可能存在语法错误（参数数量错误，错误的命令名称…）；或者可能存在某些关键条件，如内存不足的情况（如果服务器使用maxmemory指令做了内存限制）。
redis的结果：
此时redis会返回错误，中止事务并清除命令队列

可能原因：
使用错误的值对某个key进行操作，比如使用list操作命令操作string
redis的结果：
此时redis会执行完剩余的正确命令。错误的命令报错

MULTI 命令的执行标记着事务的开始：这个命令唯一做的就是， 将客户端的 REDIS_MULTI 选项打开， 让客户端从非事务状态切换到事务状态

当客户端进入事务状态之后， 服务器在收到来自客户端的命令时， 不会立即执行命令， 而是将这些命令全部放进一个事务队列里， 然后返回 QUEUED ， 表示命令已入队：

EXEC命令执行，事务队列中的所有命令会被执行，客户端会从事务状态返回非事务状态，事务执行完成

概念：以日志形式记录每一次对redis的写命令，可以通过重复执行记录的命令来进行数据恢复

AOF的重写机制:AOF提供了重写机制，去除无用指令以及合并多条指令达到压缩的目的。
更小的文件也意味着更快的加载速率，重写不会阻塞redis

优点：
1.AOF默认一秒钟执行一次fsync操作，即使发生故障，也最多丢失那一秒钟没来得及写入日志的命令数据。
2.AOF对误操作有更强的容错性。由于AOF是逐条命令的记录，因此当发生灾难性的数据误操作时（比如清库），只要这个时候AOF还没有被重写（重写机制），先把redis停掉，然后把AOF文件拷贝出来，将最后的误操作命令删除（比如清库的FLUSHALL），然后用修改过的AOF做数据恢复即可。

缺点：
1.AOF文件记录的更详尽，意味着文件占用空间大
2.AOF数据恢复的速度相对于RDB更慢

概念：生成某个时刻的redis数据快照，恢复时，直接加载快照即可

优点：
数据恢复速度相当AOF更快

缺点：
1.因为是某个时刻的快照，在这个时刻和下一个备份点之间插入的数据会丢失，不适用于对数据敏感的场景
2.RDB经常需要fork子进程来保存快照，创建的过程是阻塞的重量级操作。如果数据量过大，可能造成线上服务卡顿

复制ID：master节点的数据集的一个随机字符串ID，标记了某个master节点的数据集，当一个master节点重启或者一个slave节点升级为master节点时，复制ID会重新生成

偏移量：可以理解为数据的版本号，每次写数据，偏移量都会递增。偏移量一致，则表示数据同步一致

全量复制：顾名思义，使用RDB做master的完全拷贝。一般发生在新slave节点启动或者旧slave节点重连且无法满足增量数据复制条件的时候

增量复制：master向slave发送每一次写操作的命令，是主从复制优先尝试的方式

全量复制过程
1.master节点执行BGSAVE命令fork子进程，生成RDB快照。同时在缓存新进来的写命令
2.master将快照发送给slave
3.slave收到RDB加载并刷新数据
4.master将缓存的新命令以命令流的形式发送给slave

积压缓存区的判断过程
1.主从分别维护一个seq，主每次完成一个请求就seq加一，从每次同步完后就更新自己的seq
2.从每次打算同步时，都是携带自己的seq到主，主将自身的seq与从做差结果与挤压缓存区大小 比较，如果小于挤压缓存区大小，直接从挤压缓存区取相应的操作做部分重同步
3.否则说明挤压缓存区的数据不足以cover主从不一致的数据，即做全量同步

概念：最简单的模式，一个集群中有且只有一个主节点，主节点可读写，从节点只读。主节点下线，影响写服务，不影响读服务服务

数据同步机制：当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照和命令后，加载快照文件和缓存的执行命令。复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据的一致性

缺点：master挂掉后，不能继续提供写服务（slave不会自动升级为master），因此主从模式，只提供了读写分离的特性，不满足高可用

概念：基于主从模式，多了哨兵的角色。sentinal由一个或多个sentinal实例组成的sentinal系统可以监视任意多个主服务器，以及这些主服务器属下的从服务器，并在被监视的主服务器进入线下状态时，自动将下线主服务器属下的从服务器升级为新的主服务器

自动故障切换机制：
1.当一个master被大多数的sentinal标记为主观下线时，这个master从主观下线标记为客观下线，failover故障机制会被触发
2.投票产生领头sentinal，每个发现master客观下线的sentinal都会要求其他sentinal将自己选为领头去执行故障迁移；投票采用先到先得策略，已经给某个候选人投过票的sentinal，不再接受其他候选人的要求投票请求
3.选举slave升级为master，再淘汰已下线，超时，响应慢的slave之后，领头sentinal先后根据节点的优先级，复制的偏移量（标记slave复制了多少master数据），进程id，选择最优的slave升级为master。将原master和slave都归为新master的slave
4.更新节点配置信息

缺点：(其实是单master的缺陷)
1.每个节点保存的数据都一样，存在数据冗余，造成内存浪费
2.因为每个节点保存的数据都一样，master的最大存储容量决定了整个集群的容量，上限有限
3.如果数据量较多，故障恢复需要较长的时间

参考链接

概念：基于主从模式和哨兵模式，引入分片的设计。通过hash计算，将数据分开存储在对应节点的槽（slot）

分片hash算法

一致性hash算法

未使用一致性hash原因

集群新增和删除节点

优点：高可用，可扩展。横向扩容可支持海量数据

集群官方文档

优点：通过VIP的漂移实现主备切换，提供不间断的读写服务。实现简单，成本低

缺点：单机吞吐量有限

问题描述：缓存的某个热点key一直抗着大量并发查询。在这个key失效的瞬间，大量的查询击穿缓存，打到数据库（想象一个水桶底部破了一个洞）

解决办法：
1.设置热点数据永不过期
2.限流（牺牲部分用户体验保证系统可用性）    

问题描述：大量的热点key在同一时间失效，瞬间打崩数据库

解决方法：
1.设置热点数据永不过期，有更新操作就更新缓存就行了
2.存入数据时，设置失效时间上加一个随机值，保证热点key不在同一时间失效
3.redis是集群部署，把热点数据分布在不同的redis库中也能避免全部失效的问题

问题描述：大量查询缓存和数据库中都不存在的数据，导致数据库压力过大，可能挂掉。常被用来使用不存在的key进行恶意攻击

解决办法：
1.增加参数校验 
2.从nginx网关层进行配置，对于单个ip，每秒访问次数超过阙值都拉黑
3.布隆过滤器（Bloom Fliter）可以高效的判断，key是否存在于数据库，如果不存在就直接返回，如果存在就去查DB刷新KV然后return
4.如果从数据库查不到的数据可以直接缓存一个null，不过失效时间设置的不宜太长，比如1分钟

过期机制

常见的缓存淘汰策略

redis提供的缓存淘汰策略

关于淘汰策略的官方文档