Redis缓存总结
Redis线程模型
1）文件事件处理器
redis基于reactor模式开发了网络事件处理器，这个处理器就称为事件处理器，这个事件处理器就是单线程的，采用I/O多路复用机制同时监听多个socket，根据socket上的事件来选择对应的时间处理器处理这个事件。
2）客户端与redis通信的一次流程
在redis启动初始化的时候，redis会将连接应答处理器跟AE_READABLE事件关联起来，接着如果一个客户端跟redis发起连接，此时会产生一个AE_READABLE事件，然后由连接应答处理器来处理跟客户端建立连接，创建客户端对应的socket，同时将这个socket的AE_READABLE事件跟命令请求处理器关联起来。
当客户端向redis发起请求的时候（不管是读请求还是写请求，都一样），首先就会在socket产生一个AE_READABLE事件，然后由对应的命令请求处理器来处理。这个命令请求处理器就会从socket中读取请求相关数据，然后进行执行和处理。
接着redis这边准备好了给客户端的响应数据之后，就会将socket的AE_WRITABLE事件跟命令回复处理器关联起来，当客户端这边准备好读取响应数据时，就会在socket上产生一个AE_WRITABLE事件，会由对应的命令回复处理器来处理，就是将准备好的响应数据写入socket，供客户端来读取。
命令回复处理器写完之后，就会删除这个socket的AE_WRITABLE事件和命令回复处理器的关联关系。
2）为啥redis单线程模型也能效率这么高？
基于纯内存操作
核心是基于非阻塞的IO多路复用机制
单线程反而避免了多线程的频繁上下文切换问题
Redis都有那些数据类型？分别在那些场景下使用？
（1）String
这是最基本的类型了，就是普通的get和set，做简单的kv缓存
（2）hash
这个类似于map的一种结构，这个一般就是可以将结构化的数据，比如一个对象(前提是这个对象没嵌套其他对象)给缓存在redis里，然后每次读写缓存的时候，可以就操作hash里的某个字段
（3）list
有序列表，如爬虫的链接存放，微博中某个人的粉丝列表，而且可以通过lrange命令，可以实现基于list的分页查询，基于redis实现简单的高性能分页，可以做出类似于微博的那种下拉不断分页的东西，性能高。
（4）set
无序集合，自动去重
直接基于set将系统里需要去重的数据扔进去，自动就给去重了，如果你需要对一些数据进行快速的全局去重，你当然也可以基于jvm内存里的HashSet进行去重，但是如果你的某个系统部署在多台机器上呢？
得基于redis进行全局的set去重。效率极高。
也可以基于set做一些交集、并集、差集等，可以把两个人的粉丝列表整一个交集，看看俩人的共同好友是谁。
（5）sorted set
排序的set，去重但是可以排序，写进去的时候给一个分数，自动根据分数排序，这个可以玩儿很多的花样，最大的特点是有个分数可以自定义排序规则
比如说你要是想根据时间对数据排序，那么可以写入进去的时候用某个时间作为分数，人家自动给你按照时间排序了
排行榜：将每个用户以及其对应的什么分数写入进去，zadd board score username，接着zrevrange board 0 99，就可以获取排名前100的用户；zrank board username，可以看到用户在排行榜里的排名
Redis的过期策略
（1）定时删除(基本没人使用)
在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时，对key进行删除
（2）惰性删除
key过期的时候不删除，每次从数据库获取key的时候，去检查是否过期，若过期，则删除
（3）定期删除
每隔一段时间进行一次删除过期可以操作
Redis采用的过期策略
惰性删除 + 定期删除
惰性删除流程
在进行get或setnx等操作时，先检查key是否过期，
若过期，删除key，然后执行相应操作；
若没过期，直接执行相应操作
定期删除流程（简单而言，对指定个数个库的每一个库随机删除小于等于指定个数个过期key）
遍历每个数据库（就是redis.conf中配置的"database"数量，默认为16）
检查当前库中的指定个数个key（默认是每个库检查20个key，注意相当于该循环执行20次，循环体时下边的描述）
如果当前库中没有一个key设置了过期时间，直接执行下一个库的遍历
随机获取一个设置了过期时间的key，检查该key是否过期，如果过期，删除key
判断定期删除操作是否已经达到指定时长，若已经达到，直接退出定期删除。
（4）内存淘汰
如果redis的内存占用过多的时候，此时会进行内存淘汰，存在如下一下策略
1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧。
2）allkeys-lru：当内存不足以容纳写入数据时，移除最近最少使用的key（这个时最常用的）
3）allkeys-random：随机删除key（基本不会使用）
4）volatile-lru：在设置了过期时间的键空间中，移除最近最少使用的key
5）volatile-lru：在设置了过期时间的键空间中，随机删除key
6）valatile-rrl：在设置了过期时间的键空间中，有更早过期的key优先删除
Redis如何保证高并发及高可用？
高并发：读写分离
高可用：哨兵模式
主从复制
复制完整流程
（1）slave node启动，仅仅保存master node的host和ip,这些信息时在redis.conf里面的slave of 配置的
（2）slave node内部有个定时任务，每秒检查事发后有新的master node要连接和复制，如果发信啊，就和master node建立socket网络连接
（3）slave node发送ping命令给master node
（4）口令认证，如果master设置了requirepass，那么salve node必须发送masterauth的口令过去进行认证
（5）master node第一次执行全量复制，将所有数据发给slave node
（6）master node后续持续将写命令，异步复制给slave node
数据同步的核心机制
指的就是第一次slave连接master的时候，执行全量复制，这个过程需要注意的一些细节
（1）master和slave都会维护一个offset
master会在自身不断累加offset，slave也会在自身不断累加offset
slave每秒都会上报自己的offset给master,同时master也会保存每个slave的offset.
这个并不一定只是用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况
（2）backlog
master node有一个backlog，默认是1MB大小
master node给slave node复制数据时，也会将数据在backlog中同步写一份
backlog主要是用来做全量复制中断后的增量复制的
（3）master run id
输入info server，可以看到master run id
如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制，如果需要不更改run id 重启redis，可以使用redis-cli debug reload命令
全量复制
（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中获取数据的
hearbeat
主从节点互相都会发送heartbeat信息
master默认每隔10秒发送一次heartbeat，salve node每隔1秒发送一个heartbeat
异步复制
master每次接收到写命令之后，现在内部写入数据，然后异步发送给slave node
哨兵模式
哨兵的功能
（1）集群监控：负责监控redis master和slave进程是否正常工作
（2）消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
（3）故障转移：如果master node挂掉了，会自动转移到slave node。
其中quorum =1 表示的是只要超过一台哨兵认为master node发生了故障，那么集群就认定master node挂了。
但是执行故障转移需要达到 majoriy的哨兵在正常运行才能执行故障转移。3台哨兵的marjority=2 ,2台哨兵的marority=2。
为什么redis哨兵集群只有2个节点无法正常工作？
哨兵集群必须部署2个以上节点
如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1
Configuration: quorum = 1
master宕机，
s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移同时这个时候，
需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的
majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行。
（4）如果故障转移发生了，通知client客户端新的master地址哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作
主从复制的数据丢失问题
异步复制导致数据丢失
异步复制导致的数据丢失是因为master->slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这部分还没及时复制到slave的数据就丢失了。
脑裂导致数据丢失
也就是说，某个master所在的机器突然脱离了正常的网络，跟其他的slave机器不能连接，但是实际上master还运行着，此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master，这个时候，集群里就会有两个master，也就是所谓的脑裂此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据。
解决数据丢失方案
min-slaves-to-write 1
min-slaves-max-lag 10
要求至少有1个slave，数据复制和同步的延迟不能超过10秒
如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了
上面两个配置可以减少异步复制和脑裂导致的数据丢失
（1）减少异步复制的数据丢失
有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数
据丢失降低的可控范围内
（2）减少脑裂的数据丢失
如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失
上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求
因此在脑裂场景下，最多就丢失10秒的数据
Redis持久化
RDB和AOF两种持久化机制
RDB持久化机制，对redis中的数据执行周期性的持久化。
AOF机制对每条修改的命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。
通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上，然后可以将这些数据备份到云服务器上，如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务器上拷贝回之前的数据，放置在指定的目录，然后重启redis。
RDB（默认）
fork一个子进程，然后写入一个临时文件中，写完了之后，临时文件再与rdb文件替换，主进程不会进行任何IO操作，保证了redis的高性能。
1）.rbd文件是经过压缩的二进制文件，所以我们是看不了的。
2）.如果禁用的话。直接把save 给注释掉
3）.对于异常退出的话，会丢失快照以后的数据，但是如果正常关闭的话，redis会自动自动添加至快照中。
redis在指定的情况下会触发快照
自己配置的快照策略
save或者bgsave
save：执行内存的数据同步到磁盘的操作，这个操作会阻塞客户端的请求
bgsave：在后台执行快照操作，这个操作不会阻塞客户端的请求
执行flushall的时候
清除内存的所有数据，只要快照的规则不为空，也就是第一个规则存在。那么redis会执行快照
执行复制的时候
AOF
也是fork一个子进程，主进程仍向外提供服务，子进程执行AOF持久化，与rdb不同的是，后台子进程持久化过程中，主进程会记录期间的所有数据变更（主进程还在服务），并存储在server.aof_rewrite_buf_blocks中；后台子进程结束后，redis更新缓存追加到AOF文件中。
AOF_REWRI触发条件
1）.被动：当AOF文件尺寸超过REDIS_AOF_REWRITE_MIN_SIZE & 达到一定增长比； 也就是上面配置的两个
2）.主动：调用BAREWRITEAOF命令
RDB持久化机制优缺点
优点：
（1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合坐冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去以预定好的备份策略来定期备份redis中的数据。
RDB也可以做冷备，生成多个文件，每个文件都代表了某一个时刻的完整的数据快照
AOF也可以做冷备，只有一个文件，但是你可以，每隔一定时间，去copy一份这个文件出来.
由redis去控制固定时长生成快照文件的事情，比较方便; AOF，还需要自己写一些脚本去做这个事情，各种定时RDB数据做冷备，在最坏的情况下，提供数据恢复的时候，速度比AOF快
（2）RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可，RDB，每次写，都是直接写redis内存，只是在一定的时候，才会将数据写入磁盘中AOF，每次都是要写文件的，虽然可以快速写入os cache中，但是还是有一定的时间开销的,速度肯定比RDB略慢一些
（3）相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速
缺点：
（1）如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据这个问题，也是rdb最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多
（2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的
AOF持久化机制优缺点
优点：
（1）AOF可以更好的保护数据不丢失，一般AOF会每隔一秒，通过一个后台线程执行一次fsync操作，对多丢失一秒的数据
（2）AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复
（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据
缺点：
（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
（2）AOF开启后，支持的些QPS会比RDB支持的些QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
（3）唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不太合适
RDB和AOF如何选择
（1）不要仅仅使用RDB，因为那样会导致你丢失很多数据
（2）也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug
（3）综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用
Redis雪崩和穿透
Redis雪崩现象
也就是redis的缓存失效，导致所有访问请求的压力都落在数据库中，从而导致数据库受不了，而宕机，并且即使数据库重启，由于reids中缓存并没有数据，即使重启数据库，也会立即挂掉。
解决方案：
事前：redis高可用，主从+哨兵，redis cluster等，避免redis缓存的全部宕机
事中：本地ehcache缓存+hystrix限流&降级，避免数据库一启动就会宕机
事后：利用redis持久化，快速恢复缓存数据
Redis穿透现象
系统遭到恶意攻击，一些请求是在数据库中没有的数据，然后每次都会去数据库中查找。
解决方案：
每次系统从数据库中只要没有查到，根据恶意请求的某个字段的特征，如set -999 unknow至redis中，这样的话可以避免每次都走数据库中去查询数据，从而避免数据库压力过大
如何保证缓存与数据库双写的数据一致性？
最经典的缓存+数据库读写的模式
（1）读的时候，先读缓存，缓存没有的话，那么就读数据库，然后取出数据后放入缓存，同时响应
（2）更新的时候，先删除缓存，然后再更新数据库
为什么是删除缓存，而不是更新缓存？
其实原因很简单，很多时候，因为缓存有的时候，不简单是数据库中直接取出来的值。
商品详情页的系统，修改库存，只是修改了某个表的某些字段，但是要真正把这个影响的最终的库存计算出来，可能还需要从其他表查询一些数据，然后进行一些复杂的运算，才能最终计算出现在最新的库存是多少，然后才能将库存更新到缓存中去比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据，并进行运算，才能计算出缓存最新的值的更新缓存的代价是很高的是不是说，每次修改数据库的时候，都一定要将其对应的缓存去更新一份？也许有的场景是这样的，但是对于比较复杂的缓存数据计算的场景，就不是这样了如果你频繁修改一个缓存涉及的多个表，那么这个缓存会被频繁的更新，频繁的更新缓存但是问题在于，这个缓存到底会不会被频繁访问到？？？
举个例子，一个缓存涉及的表的字段，在1分钟内就修改了20次，或者是100次，那么缓存更新20次，100次; 但是这个缓存在1分钟内就被读取了1次，有大量的冷数据28法则，黄金法则，20%的数据，占用了80%的访问量。实际上，如果你只是删除缓存的话，那么1分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低每次数据过来，就只是删除缓存，然后修改数据库，如果这个缓存，在1分钟内只是被访问了1次，那么只有那1次，缓存是要被重新计算的，用缓存才去算缓存其实删除缓存，而不是更新缓存，就是一个lazy计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算mybatis，hibernate，懒加载思想。查询一个部门，部门带了一个员工的list，没有必要说每次查询部门，都里面的1000个员工的数据也同时查出来啊80%的情况，查这个部门，就只是要访问这个部门的信息就可以了先查部门，同时要访问里面的员工，那么这个时候只有在你要访问里面的员工的时候，才会去数据库里面查询1000个员工。
初级的缓存不一致
问题：先修改数据库，再删除缓存，如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据出现不一致
解决思路：
先删除缓存，再修改数据库，如果删除缓存成功了，如果修改数据库失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中
复杂的数据不一致
数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没有修改，一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放入可缓冲中，数据变更的而程序完成了数据的修改，此时数据又不一致了。
解决思路：
更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个jvm内部的队列中读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个jvm内部的队列中一个队列对应一个工作线程每个工作线程串行拿到对应的操作，然后一条一条的执行这样的话，一个数据变更的操作，先执行，删除缓存，然后再去更新数据库，但是还没完成更新此时如果一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成这里有一个优化点，一个队列中，其实多个更新缓存请求串在一起是没意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可待那个队列对应的工作线程完成了上一个操作的数据库的修改之后，才会去执行下一个操作，也就是缓存更新的操作，此时会从数据库中读取最新的值，然后写入缓存中如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回; 如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值。