此文纯属个人笔记
redis知识点：
- 5种数据结构
- 主从复制
- 哨兵模式
- 持久化
1. 5种数据结构：
(1)String(字符串)：
应用场景：微博数，粉丝数；set key value; get key
(2)Hash(哈希)；应用场景：存储部分变更的数据，如用户信息等。
我们可以将hashes 类型看成具有string key 和string value的map容器;
(3)list（列表）：应用场景 消息队列系统，比如sina微博。
list类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其头部和尾部添加新的元素。在插入时，如果该键并不存在，redis将为该键创建一个新的链表。 rpush key [value]
(4)set(无序集合)：应用场景：在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合；redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜欢、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存到一个新的集合中；
sadd key number1 number2
smembers key 返回key 中所有元素
sismember key number 判断number是否是集合key的成员
sdiff key1 key2 获取集合的差集
sinter key1 key2 返回两集合的交集
sunion key1 key2 返回两集合的并集
(5)sorted-sets (有序集合)：sorted-sets中的每一个成员都会有一个分数与之关联，redis正是通过分数来为集合中的成员进行从小到大的排序，成员是唯一的，但是分数却是可以重复的；集合是通过哈希表 实现的，所以添加，删除，查找的复杂度都是O(1)，集合中最大的成员数为232-1
2. 主从复制
主从：主对于数据可读可写，从默认只读不写。当从连接上主时，主会将数据同步到从上；
redis是怎么实现主从的数据同步的？
全量同步
1）从服务器连接到主服务器，发送SYNC命令；
2）主服务器接收到sync命名后，开始执行bgsave命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
3）主服务器bgsave执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照对载入，开始接收命令请求，并执行来自主服务器缓冲区对写命令；
增量同步：
假设发送网络抖动或者别的情况，暂时失去了连接，等slave重新连上的时候，slave向master发送自己的offset和runid主服务器把自己挤压缓冲区里面偏移量在offset之后的数据全部同步给从服务器。
3.哨兵模式:监控redis系统的运行状况；
redis的哨兵系统用于管理多个redis服务器，该系统执行以下三个任务：
a.监控：哨兵会不断检查你的Master和slave是否运作正常；
b.提醒：当被监控的某个redis出现问题时，哨兵可以通过API向管理员或者其他应用程序发送通知
c.自动故障迁移，当一个master不能正常工作时，哨兵会开始一次自动故障迁移操作，它会将失效, master的其中一个slave升级为新的master，并让失效master的其他撒略改为复制新的master。当客户端试图连接失效的master时，集群也会向客户端返回新的master的地址，使得集群可以使用新的master；
4.redis持久化
redis 提供了多种不同级别的持久化方式：一种是RDB，另一种是AOF
A. RDB持久化：
可以在指定的时间间隔内生成数据集的时间点快照，RDB是一个非常紧凑的文件，它保存另redis在某个时间点上的数据集，这种文件非常适合用于进行备份，比如说，你可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个RDB文件。RDB非常适用于灾难恢复：它只有一个文件，并且内容非常紧凑，可以（在加密后）将它传到别的数据中。RDB可以最大化redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来所有保存工作，父进程无须执行任何磁盘I/O操作；RDB 在恢复大数据集时的速度比AOF的恢复速度快
B. AOF持久化
（1）使用AOF会让你的redis更加耐久，你可以使用不同的fsync策略，无fsync，每秒fsync，每次写的时候fsync，使用默认的每秒fsync策略，redis的性能依然会好（fsync是由后台线程进行处理的，主线程会尽力处理客户端请求），一旦出现故障，最多丢失1秒的数据。
（2）redis可以在aof文件体积变得过大时，自动的在后台对AOF进行重写：重写后的新AOF文件包含另恢复当前数据所需的最小命令集合，整个重写操作是绝对安全的因为redis在创建新AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写过程中发生停机，现有AOF文件也不会丢失,一旦新AOF文件创建完毕，redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作。AOF文件有序的保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松，导出aof文件也非常简单。
当redis启动时，如果rdb持久化和aof持久化都被打开了，那么程序会优先使用AOF,因为aof保存当数据通常是最完整的；
缺点：对于相同对数据集来说，AOF文件的体积通常要大于RDB文件的体积
- 什么是缓存穿透、缓存击穿、缓存雪崩 以及他们的解决方式？
（1）缓存穿透：大量请求中的key不存在redis中，会造成大量请求访问数据库，造成数据库崩溃
解决方法：做参数校验，将一些请求不合法的请求参数抛出异常返回给前端；如果请求的key不频繁变化的话，第一次在缓存和数据库中都查不到的话，就存到redis中，设置value为null; 布隆过滤器
（2）缓存雪崩 ：缓存在同一时间失效，致使全部请求落到数据库上
解决方法：随机设置过期时间
