1、Redis的由来
(1)文件存储? ? ? 问题是全量扫描，当存储文件过多时出现i/o的全量扫描将会消耗大量内存和i/o
(2)关系型数据库? ? 分而治之，数据库的内部模型都是分块的内存，避免全量扫描
(3)Nosql， 直接连接内存，结构简单，通过key来获取内存，速度极快，但是只能解决部分问题，相比较SAP 的 HANA，他是一个折中的解决方案
2、Redis的特性
(1)Worker 单线程（计算单线程）
(2)相比较memcache，他是计算向数据移动的方案
(3)工作线程单线程，是串行化处理的最好方式
(4)Redis 的性能来自于多路复用epoll，当然不同操作系统的多路复用不一样，多路复用的根本也是连接池技术。多路复用的流程大致为，客户端访问操作系统kernel，根绝epool对应带redis，redis串行化计算出结果后再返回给操作系统。
3、Redis的value类型
(1)String ： 字符串、数值、对象、甚至图片、bitmap
①支持多语言， spring data api 包含了high level 和low level 的api
②基本操作：set get append strlen incr
③Bitmap 的实质是存储二进制，通过对二进制位数的操作
(2)List ：有序的，放入顺序有序并不会排序
①基本操作 ： lpush、rpush、lpop、lindex
②双向链表可以实现同向：栈，异向：队列，数组
③如果将程序中的数据结构迁出至redis，如此实现服务无状态。
④场景：数据共享，迁出
(3)Hash
①基本操作：hset、hget、hgetall、hkeys、hvals、hincrby
②减少网络通信和操作步骤
③场景：商品详情页、聚合场景（缓存某些数据，拼凑在一起）
(4)Set
①基本操作：sadd 、sunion、sinter、sdiff
②去重无序
③场景：随机事件
(5)Zset ：zadd、zrange、zrevrange（反转排序）
①场景：排行榜、评论加分页
4、Redis的持久化
(1)如果数据过多，就会存储为Skiplist
(2)持久化就是把内存的数据写到磁盘中去，防止服务宕机内存丢失，redis提供两种方式：
①RDB
1)Redis database
2)快照，阻塞式的，九点，十点拍一个，mysql也是一样的工作原理
3)快照没有i/o所以比较快，但是丢失的数据比较多
4)功能核心函数是rdbsave（生成rdb文件）和rdbload（从文件加载内存）两个函数
②AOF（Append-only file）
1)日志，有三种级别
a.每次操作，完整型好。
b.每秒钟，os缓冲，丢失一个buffer，内核参数决定的，这是默认的级别。
a)这是因为我们通常只使用redis做缓存。
b)如果我们不使用任何缓存，可能出现雪崩穿透
c.更小的时间片去刷新数据
2)每当服务器定时任务或者函数flushappendonlydile函数被调用时，这个函数就执行以下工作
a.Write：根据条件将aof——buf中缓存的文件写入到aof
b.Save ： 根绝条件，调用fsync或者fdatasync函数将aof文件保存到磁盘中
(3)比较
①Aof稳价比rdb更新频率高，优先使用aof还原数据
②Aof比rdb高峰安全更大
③Rdb性能好，aof冗余比较多，大量重写导致慢
④如果两个都配置了优先加载aof文件
⑤4.8版本之前，二选一。是因为二者会存在重叠
⑥重写操作定准logfile，然后清楚重复操作
5、通过redis来学习AKF和CAP定理
(1)单机版
①单点故障
1)主从主备集群，相当于镜像数据，所以需要同步
2)同步机制
a.强一致性备份，变慢，由于备份导致失败。由于过分强调一致性而破坏了可用性。
b.弱一致性
②压力比较大，资源受限，频繁宕机
1)分片集群，一变多，不需要同步。
(2)AKF
①x轴，一主三备保证高可用
②切分功能，不同功能存储不同服务器
③Xy整合使用
④数据倾斜，z轴基于订单系统做shareding 分层
(3)CAP
(4)代理层实现的数据同步算法。Redis内部3.x以后实现了crc算法的同步，采用去中心化，省掉了代理。采用算法找到槽位对应映射，解决了并发的负载均衡，又解决了数据的切片和服务的动态扩缩容。自由集群。
6、Redis锁的探索
(1)内部采用redisson，getlock，lock，unlock
(2)先拿setnx来争抢锁，抢到以后，再用expire加一个国企的时间防止忘记释放。
7、集群部署
8、面试题
1、使用过redis做过一部队列么？如何使用？
一般使用list结构作为队列，rpush生产消息，lpop消费消息.
2、雪崩
当缓存系统宕机后，原先由缓存系统负担的请求处理瞬间落在了系统DB上，过高的并发量导致系统宕机。这便是缓存雪崩。
解决方案
1、事前 搭建高可用Redis环境，主从+哨兵，多节点，避免全盘崩溃
2、事中 本地ehcache缓存 + hystrix限流&降级，避免DB被高并发打死
3、事后 Redis持久化，一旦重启机器，自动从磁盘恢复数据，快速恢复缓存数据
3、击穿
过多且频繁的请求缓存中不存在的数据，将会导致直接请求DB，这便是缓存击穿。
解决方案
1、单一线程处理key值
2、互斥锁是业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法