Redis 简介
开源，使用ANSI C 编写，高性能的Key-Value的NoSQL数据库。内存数据库，读写速度非常快，主要应用方向如缓存、分布式锁(如Redisson)、消息的发布订阅(topic)、数据过滤(布隆过滤器)等。redis 提供5中数据类型(String、Hash、List、Set、ZSet)来支持不同的业务场景。除此之外，redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。
为什么要用缓存
目标：高并发、高可用、高性能 架构的艺术
redis与map/guava的区别
缓存分为本地缓存和分布式缓存，以 Java 为例， map/guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性；redis / memcached 称分布式缓存，在多实例下，各实例共用一份缓存数据，缓存具有一致性。缺点是架构较为复杂。
redis 的线程模型
redis 内部使用文件事件处理器 file event handler，文件事件处理器是单线程的，所以 redis 是单线程的模型。
文件事件处理器包含 4 个部分：
- 多个 socket
- IO 多路复用程序
- 文件事件分派器
- 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）
并发 可能产生多个socket，每个socket对应不同的文件事件，此时 IO 多路复用程序会监听多个 socket，并将产生的文件事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。
redis 和 memcached 的区别
1. redis提供String, list，set，zset，hash数据结构； memcache支持简单的数据类型，String。
2. redis支持持久化，重启可再次加载使用； Memecache不支持持久化。
3. redis 支持原生cluster；memcached没有原生的集群模式，需要依靠客户端将数据写入集群的分片中。
4. redis使用单线程的多路 IO 复用模型；memcached是多线程，非阻塞IO复用网络模型
对比图:
redis 常见命令与使用场景
1.String
简单的key-value类型；常见命令：set,get,decr,incr,mget 等； 应用场景 常规计数：微博数，粉丝数等
2.Hash
string 类型的 field 和 value 的映射表; 常见命令: hget,hset,hmset,hgetall,等； 应用场景 适合用于存储对象
3.List
list 是一个双向链表，支持反向查找和遍历，支持反向查找和遍历； 常见命令: lpush,rpush,lpop,rpop,lrange等；应用场景 如微博的关注列表，粉丝列表，消息列表，高性能分页(lrange)等功能
4.Set
set是一个可以去重的集合，可以轻易实现交集、并集、差集的操作；常见命令: sadd,spop,smembers,sunion等; 应用场景 可以非常方便的实现如共同关注、共同粉丝、共同喜好等功能
sinterstore key1 key2 key3 将交集存在key1内
5.ZSet
sorted set增加了一个权重参数score，集合中元素能够按score进行有序排列； 常见命令: zadd,zrange,zrem,zcard等； 应用场景 实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息
redis是怎么删除已经过期的key
定期删除+惰性删除
- 定期删除：redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载！
- 惰性删除 ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。
redis 持久化机制 ：RDB AOF
持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据）
快照（snapshotting）持久化（RDB）
通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），还可以将快照留在原地以便重启服务器的时候使用。
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。 save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。 save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
AOF（append only file）持久化
与快照持久化相比，AOF持久化 的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启AOF方式的持久化，可以通过appendonly参数开启：
appendonly yes
开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。
三种不同的 AOF 持久化方式：
appendfsync always #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度 appendfsync everysec #每秒钟同步一次，显示地将多个写命令同步到硬盘 appendfsync no #让操作系统决定何时进行同步