原文地址：redis简析
一、Redis是什么？
Redis是一个基于C语言开发的开源的高性能内存数据库，一般用作缓存和消息中间件，属于NoSQL的一种。
作为内存数据库，其优势有：
1、性能强悍，数据存储在内存中，读写速度非常快，支持并发10W QPS
2、单进程单线程，是线程安全的，采用IO多路复用机制；
3、丰富的数据类型，支持字符串（Binary-safe strings），哈希（Hashes），列表（Lists），集合（Sets），有序集合（Sorted sets）等；
4、支持数据持久化。可将内存中的数据保存在磁盘中，重启时加载；
5、主从复制，哨兵，高可用；
6、可以用作分布式锁；
7、可以作为消息中间件使用，支持发布订阅。
二、常用的5种数据类型
redis使用redisObject对象来表示所有的key和value：
redisObject中type表示value对象具体是哪种数据类型，encoding是不同数据类型在redis中的存储方式。如type=string表示value存储的是一个普通字符串，那么encoding可以适raw或int。
1、string
string是redis是最基本、最常用的数据类型，和memcached的k-v结构类似。value不仅可以适字符串，也可以是数字。string类型是二进制安全的，就是说redis的string类型可以包含任何数据，比如图片或者序列化对象。string类型的value最大能存储512M。
2、hash
hash是一个键值（k-v）的集合。redis的hash是一个string类型的key和value的映射表，hash特别适合存储对象。常用的命令：hget，hset，hgetall等。
3、list
list列表是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或尾部（右边）。常用的命令：lpush，rpush，lpop，rpop，lrange（获取列表片段）等。
应用场景：list是Redis中最重要的数据结构之一，如社交网站的关注列表，粉丝列表等都可以用list来实现。
数据结构：list属于链表，可以用来做消息队列。Redis提供了list的push和pop操作，还提供了操作某一段的api，可以直接查询或删除某一段的元素。
实现方式：Redis list的实现是一个双向链表，支持反向查找和遍历。
4、set
set是string类型的无序集合。集合通过hash table实现，set中的元素无序不重复。常用的命令：sadd，spop，smembers、sunion等。
应用场景：Redis set对外提供的功能和list一样是一个列表，特别之处在于set是自动去重的，而且set提供了判断某个成员是否在一个set集合中的方法。
5、zset
zset和set一样是string类型元素的集合，且不允许重复的元素，通过score参数来排序，常用的命令：zadd，zrange，zrem，zcard等。
应用场景：有序集合sorted set通过用户提供的score参数来为成员排序，并且是插入有序的，即自动排序。当需要一个有序且不重复的集合列表时，可以选择有序集合结构。和set相比，sorted set关联了一个double类型权重的参数score，使得集合中的元素能够按照score进行有序排列，Redis正是通过分数来为集合中的成员进行从小到大的排序。
实现方式：Redis sorted set内部使用HashMap和跳跃表（SkipList）来保证数据的存储和有序，HashMap里存放的是成员到score的映射，而跳跃表中存放的是所有的成员，排序依据是HashMap里存的score，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
数据类型与应用场景总结：
| 类型 | 简介 | 特性 | 场景 |
|---|---|---|---|
| string（字符串） | 二进制安全 | 可以包含任何数据，如图片、序列化对象 | |
| hash（哈希字典） | 键值对集合 | 适合存储对象，并且可以像数据库中的update一样，只修改某一项属性值 | 存储，读取，修改用户属性 |
| list（列表） | 链表（双向链表） | 增删快，提供了操作某一元素的api | 最新消息排行；消息队列 |
| set（集合） | hash表实现，元素无序不重复 | 添加，删除，查找的复杂度都是O(1)，提供了求交集，并集，差集的操作 | 共同好友；利用唯一性，统计访问网站的所有ip |
| sort set（有序集合） | 将set中的元素增加一个权重参数score，元素按score有序排列 | 数据插入集合时，已经进行了天然排序 | 排行榜；带权重的消息队列 |
三、缓存问题
1、缓存和数据库数据一致性问题。
分布式环境下，不可避免的存在数据库和缓存数据不一致的问题，如果项目要求数据必须是强一致性的，那么就不要使用缓存。我们只能采取合理的策略去降低缓存和数据库间数据不一致的概率，而无法保证绝对一致。合理的策略包含合适的缓存更新策略，更新数据库后及时更新缓存、缓存失败时增加重试机制。
2、缓存雪崩
如果缓存在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，造成缓存雪崩。
由于原有缓存失效，所以新缓存未到期间，所有原本应该访问缓存的请求都去查询数据库了，对数据库的CPU和内存造成巨大压力，严重的会造成数据库宕机。
解决方案：
a、加锁排队：用mutex锁（互斥锁）解决，用Redis的setnx去设置一个key，当返回成功时，进行加载数据库的操作并设置缓存，否则就重试获取缓存。
b、缓存预热：缓存预热就是系统上线前，将相关的缓存数据直接加载到缓存系统中，这样可以避免在用户请求的时候直接查询数据库然后回写缓存的问题，用户直接可以查询到缓存。
c、双层缓存：C1为原始缓存，C2为拷贝缓存，C1失效时，可以访问C2，C2的缓存失效时间设置为长期。
d、定时更新缓存：对时效性要求不高的缓存，可以采用定时任务去更新或移除缓存。
e、设置不同的过期时间，避免同一时间点缓存集体失效。【此方式方便高效】
3、缓存击穿
在高并发的系统中，大量的请求同时查询一个key时，此时这个key正好失效了，就会导致请求全都打到数据库上面去，这种现象就是缓存击穿。
缓存击穿和缓存雪崩有点像，缓存雪崩是因为大面积的缓存失效，打崩了数据库，而缓存击穿则是指一个key非常热点，在不停的扛着大量的请求，当这个key失效的瞬间，持续的请求直接打到数据库上。
解决方案：
设置热点数据永不过期，或者加上互斥锁，请求击穿缓存要查询数据库时则获取锁然后去查，其他请求获取不到锁则等待，然后尝试请求缓存。
4、缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，却不断有请求想要获取。比如：不断有请求获取id<=0的数据，这样缓存没有，进入数据库查询，数据库虽然也没有，但是不断的去查询返回，导致数据库压力增大，可能导致数据库宕机。
解决方案：
a、基本校验：接口层增加校验，如用户鉴权，参数校验（如id是否大于0），不满足直接返回。
b、缓存空值：若查询返回为空（不论是数据真的不存在还是系统故障），我们仍然缓存空值，并设置其过期时间较短（一般不超过5分钟）。这样就避免每次请求都穿透缓存直达数据库。
c、采用布隆过滤器（BloomFilter）
原理是利用高效的数据结构和算法快速判断查询key是否存在数据库中，不存在则直接返回空，存在则去查数据库并刷新缓存。
四、Redis的单线程
Redis是单进程单线程的模型，因为Redis完全是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那么采用单线程的方案比多线程少很多麻烦（如各种锁）。
1、为何采用单线程还这么快？
a、Redis完全基于内存，绝大部分请求是纯粹的内存操作，非常迅速，数据存在内存中，类似于HashMap，而HashMap的优势就是查询和操作的时间复杂度是O(1)。
b、数据结构简单，对数据的操作也简单。
c、采用单线程，避免多线程导致的CPU切换和各种加锁释放锁的操作和死锁问题。
d、使用多路复用IO模型，非阻塞IO。四大点，搞懂Redis到底快在哪
五、Redis和Memcached的区别
1、存储方式上：memcached数据全部存在内存中，断电即丢失，数据不能超过内存大小。Redis有部分数据存在硬盘上，保证数据的持久性。
2、数据类型上：memcached只有k-v数据类型，Redis支持多种数据结构。
3、使用底层模型不同：它们之间底层实现方式以及与客户端之间通信的应用协议不一样。Redis直接自己构建了VM机制，因为一般的系统调用系统函数时，会浪费一定的时间去移动和请求。
4、value的大小：Redis可达1GB，memcached只有1MB。
六、Redis的淘汰策略
| 策略 | 描述 |
|---|---|
| volatile-lru | 从已设置过期时间的kv集合中，优先对最近少使用（less recently used）的数据淘汰 |
| volitile-ttl | 从已设置过期时间的kv集合中，优先对剩余时间短（time to live）的数据淘汰 |
| volitile-random | 从已设置过期时间的kv集合中，随机选择数据淘汰 |
| allkeys-lru | 从所有kv集合中，优先对最近最少使用（less recently used）的数据淘汰 |
| allkeys-random | 从所有kv集合中，随机算则数据淘汰 |
| noeviction | 不淘汰策略，若超过最大内存，返回错误信息 |
| volatitle-lfu | （4.0+）从已设置过期时间的kv集合中，优先对最近频率低（less frequency use）的数据淘汰 |
| allkeys-lfu | （4.0+）从所有的kv集合中，优先对最近频率低（less frequency use）的数据淘汰 |
七、Redis的持久化
1、持久化机制
Redis为了保证效率，数据缓存在内存中，但是会周期性的把更新的数据写入磁盘或者把修改的操作写入追加的记录文件中，以保证数据的持久化。
Redis的持久化策略有两种：
1、RDB：快照形式是直接把内存中的数据保存到一个dump的文件中，定时保存。
2、AOF：把所有的对Redis的服务器进行修改的命令集合都追加在一个文件中。
Redis默认是快照RDB的持久化方式。
当Redis重启时，它会优先使用AOF文件来还原数据集，因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。持久化详解
2、RDB
默认Redis是会以快照RDB的形式将数据持久化到磁盘的一个二进制文件dump.rdb中。
工作原理
当Redis需要做持久化时，Redis会fork一个子进程，子进程将数据写到磁盘上一个临时的RDB文件中，当子进程完成临时文件后，将原来的RDB替换掉，这样的好处是可以copy-on-write。
RDB的优缺点
优点：
RDB文件紧凑，适合用于备份。如可以根据业务情况在不同的时间点对Redis数据进行RDB备份，这样遇到问题时可以还原到不同时间版本的数据，非常适合容灾恢复。
缺点：
若需要尽量避免在服务器故障时丢失数据，那么RDB不合适。
3、AOF
使用AOF做持久化，每一个写命令都通过write函数追加写到appendonly.aof中。
appendonly yes
appendfsync always #每次有数据修改发生时都会写入AOF文件
appendfsync everysec #每秒同步一次，该策略为AOF的缺省策略AOF可以做到全程持久化，只需要在配置中开启appendonly yes。这样redis每执行一个修改数据的命令，都会把它添加到AOF文件中，当redis重启时，将会读取AOF文件进行重放，恢复到Redis关闭前的样子。
优点：
使用AOF的优点是会让Redis变得非常耐久，可以设置不同的fsync策略，AOF的默认策略是每秒fsync一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。
缺点：
缺点是对于相同的数据集来说，AOF的文件体积通常大于RDB文件的体积，根据所使用的fsync策略，AOF的速度可能慢于RDB。
4、该用AOF还是RDB呢？
若业务可以承受几分钟内数据的丢失，那么可以只使用RDB持久化数据。AOF将Redis执行的每一条命令追加到磁盘中，处理巨大的写入会降低Redis的性能。
定时生成RDB快照非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度快。
当然，Redis支持同时开启RDB和AOF，系统重启后，Redis会优先使用AOF来恢复数据，这样丢失的数据最少。
八、主从复制
Redis单节点存在单点故障问题，为了解决单点问题，一般都需要对Redis配置从节点，然后使用哨兵来监听主节点的存活状态，如果主节点挂掉，从节点能继续提供缓存功能。
1、Redis主从复制的原理
主从配置结合哨兵模式能解决单点故障问题，提高Redis可用性。从节点仅提供读操作，主节点提供写操作。对于读多写少的状况，可给主节点配置多个从节点，从而提高响应效率。
关于复制过程：
1、从节点执行slaveof[masterIP][masterPort]，保存主节点信息；
2、从节点的定时任务发现主节点信息，建立和主节点的socket连接；
3、从节点发送ping信号，主节点返回pong，两边互通；
4、建立连接后，主节点将所有数据发送给从节点（数据同步）；
5、主节点把当前数据同步给从节点，便完成了复制的建立过程。接下来，主节点就会持续的把命令发送给从节点，保证主从一致性。
2、主从数据同步过程
Redis2.8之前使用sync[runID][offset]同步命令，Redis2.8之后使用psync[runID][offset]命令。Redis集群和MySQL主从同步
两种方式的不同在于，sync命令仅支持全量复制过程，psync支持全量和复制。
其中：
runID：每个Redis节点启动都会生成唯一的uuid，每次Redis重启后，runID都会发生变化。
offset：主节点和从节点都各自维护自己的主从复制偏移量offset，当主节点有写入命令时，offset=offset+命令的字节长度。从节点在收到主节点发送的命令后，也会增加自己的offset，并把自己的offset发送给主节点，这样主节点同时保存自己的offset和从节点的offset，通过对比offset来判断主从节点数据是否一致。
repl_backlog：保存在主节点上的一个固定长度的先进先出队列，默认是1MB，名为复制积压缓冲区。（可设置）
Redis主从同步
主节点发送数据给从节点过程中，不仅会把写命令发送给从节点，还会降写命令入队到复制积压缓冲区内，主从服务器重连时，从服务器发送同步命令和offset，主服务器检测到offset在复制积压缓冲区内，则开始部分复制，否则全量复制。
主服务器发送写命令：
psync执行流程：
从节点发送psync[runID][offset]命令，主节点有三种响应：
1、fullresync：第一次连接，进行全量复制
2、continue：进行部分复制
3、err：不支持psync命令，进行全量复制