redis详解

Redis优势

速度快：读写性能达到10万/秒

所有数据存放在内存 使用C语言实现，距离操作系统更近 单线程架构，避免多线程产生的竞争问题，以及多线程切换性能问题

支持多种数据结构

支持字符串、哈希、列表、集合、有序集合，并演变出了Bitmaps、HyperLogLog、GEO结构

功能丰富

提供了键过期功能，可以用来实现缓存 提供了发布订阅功能，可以用来实现消息系统 支持Lua脚本功能，可以利用Lua创造出新的Redis命令 提供了简单的事务功能，能在一定程度上保证事务特性 提供了流水线（Pipeline）功能，这样客户端能将一批命令一次性传到Redis，减少了网络的开销。

提供多种客户端语言实现

提供了简单的TCP通信协议，许多编程语言可以便捷接入Redis，如Java、PHP、C、C++、Nodejs等

持久化

将数据放在内存中是不安全的，断电或故障数据可能会丢失。Redis提供了RDB和AOF两种将数据保存到硬盘中的策略

主从复制

Redis实现了复制功能，实现了多个相同数据的Redis副本

高可用和分布式

提供了高可用实现RedisSentinel、Redis Cluster

Redis常用数据结构及使用场景

Redis中5种基本数据结构分别是string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合），每种数据结构都有自己底层的内部编码实现，而且是多种实现，这样Redis会在合适的场景会选择合适的内部编码，Redis的设计者实现了数据结构与命令的解耦，可以在改进内部编码而对外的数据结构和命令没有影响 String 字符串类型的值实际可以是字符串、Json、数字（整数、浮点数），甚至是二进制编码等，最大值不能超过512MB。

内部编码：

int：8个字节的长整型。embstr：小于等于39个字节的字符串。raw：大于39个字节的字符串。

Redis会根据当前值的类型和长度决定使用哪种内部编码实现

使用场景:

String是Redis缓存最常用的key/value数据结构，通常在一些场景中，会将一些热点数据进行缓存，一个请求进来先请求缓存，缓存不存在再查询DB，再写入缓存，返回 计数器，使用INCR命令将Key值对应的value加1,可用于统计视频播放量，系统限流等

List list是有序的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部或者尾部，也可以修改删除list中的元素，一个列表最多可以包含 2的32次方 - 1 个元素

内部编码：

·ziplist（压缩列表）：当列表的元素个数小于list-max-ziplist-entries配置（默认512个），同时列表中每个元素的值都小于list-max-ziplist-value配置时（默认64字节），Redis会选用ziplist来作为列表的内部实现来减少内存的使用。·linkedlist（链表）：当列表类型无法满足ziplist的条件时，Redis会使用linkedlist作为列表的内部实现 使用场景：

分页，基于list的有序，最常见的场景是使用lrange 命令实现高性能分页，类似一些网站里展示的不断下拉分页功能

消息队列，因为list是有序的，所以可以使用lpush、brpop命令插入或弹出元素，实现消息队列的功能

Hash hash 是一个 string 类型的 field（字段，注意不是key） 和 value（值） 的映射表，hash 特别适合用于存储对象。最多可以包含 2的32次方 - 1 个元素

内部编码：

ziplist（压缩列表）：当哈希类型元素个数小于hash-max-ziplist-entries配置（默认512个）、同时所有值都小于hash-max-ziplist-value配置（默认64字节）时，Redis会使用ziplist作为哈希的内部实现，ziplist使用更加紧凑的结构实现多个元素的连续存储，所以在节省内存方面比hashtable更加优秀。hashtable（哈希表）：当哈希类型无法满足ziplist的条件时，Redis会使用hashtable作为哈希的内部实现，因为此时ziplist的读写效率会下降，而hashtable的读写时间复杂度为O（1

使用场景：目前想到的是，对象需要序列化并持久化到数据库是，可以考虑使用Redis Hash的结构替换

Set set可以用来保存多个的字符串元素，但和列表类型不一样的是，集合中不允许有重复元素，并且集合中的元素是无序的

内部编码：

intset（整数集合）：当集合中的元素都是整数且元素个数小于set-max-intset-entries配置（默认512个）时，Redis会选用intset来作为集合的内部实现，从而减少内存的使用。hashtable（哈希表）：当集合类型无法满足intset的条件时，Redis会使用hashtable作为集合的内部实现。

使用场景：可以基于多个 set集合，进行一些交集、并集、差集的数据统计

Sorted Set Sorted Set是一种有序集合结构，同样不允许重复数据，元素可以排序，但是它和列表使用索引下标作为排序依据不同的是，它给每个元素设置一个分数（score）作为排序的依据

内部编码：

ziplist（压缩列表）：当有序集合的元素个数小于zset-max-ziplistentries配置（默认128个），同时每个元素的值都小于zset-max-ziplist-value配置（默认64字节）时，Redis会用ziplist来作为有序集合的内部实现，ziplist可以有效减少内存的使用。skiplist（跳跃表）：当ziplist条件不满足时，有序集合会使用skiplist作为内部实现，因为此时ziplist的读写效率会下降。

使用场景：

排行榜

Redis缓存雪崩、穿透、击穿、并发竞争

Redis缓存雪崩

场景描述 ：假设某系统每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机，缓存挂了，此时 5000 个请求全部落数据库。缓存在某一瞬间全部失效，大量请求全部打到数据库上，这就是缓存雪崩 解决方案：

Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃 系统限流 对于设定了同一过期时间的缓存，可以在过期时间中加入随机数，避免缓存同时失效造成数据库压力过大

Redis穿透

场景描述 ：正常的使用缓存流程是对数据查询先进行缓存查询，如果 key 不存在或者key 过期，再对数据库进行查询，并把查询到的对象，放进缓存，如果数据库查询对象为空，则不放进缓存。大批量恶意查询一个数据库中一定不存在的数据，压力就会穿透缓存，打到数据库上。解决方案：

在接口层增加校验。不合法的参数直接返回 缓存空对象。缓存查不到，DB 中也没有的情况，可以将对应的 key 的 value 写为 null 。此方案使适用于数据频繁变化实时性高的场景，同时会导致一定时间内数据的一致性问题，可能存储层有但缓存中却为null 使用高级用户布隆过滤器（Bloom Filter)。将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力，Bloom Filter能够利用高效的数据结构和算法快速判断出你这个 Key 是否在 DB 中存在，不存在则返回，存在则查询DB刷新KV再返回，此方案适用于数据固定实时性相对低的场景

Redis击穿

场景描述 ：热点数据缓存在某个时间点过期，恰好在这个时间点有大量并发请求这个key，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，大量请求会造成数据库压力剧增。解决方案：

互斥锁：可使用Redis的SETNX去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法

Redis并发竞争

场景描述 ：多系统实例短时间内需要按顺序操作Redis中同一个key，可能因为网络抖动等原因导致Redis写数据顺序错误 解决方案：

分布式锁：在业务层进行控制，每个系统在操作Redis前获取分布式锁，拿到锁才能操作，确保同一时间，只有一个系统在操作某个key 时间戳：在写入时保存一个时间戳，写入前先比较自己的时间戳是不是早于现有记录的时间戳，如果早于，就不写入 消息队列：使用消息队列进行串行处理

Redis 持久化策略之RDB与AOF 持久化主要用做灾难恢复、数据恢复。Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复 RDB RDB持久化是把当前进程数据生成快照保存到硬盘的过程，通常通过bgsave命令对Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束

RDB的优点：

RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景 ·Redis加载RDB恢复数据远远快于AOF的方式 RDB 对 Redis 对外提供的读写服务，影响非常小，可以让 Redis 保持高性能，因为 Redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。

RDB的缺点：

RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高 RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题

AOF

以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）

AOF 优点

AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次 fsync 操作，最多丢失 1 秒钟的数据。AOF 日志文件以 append-only 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。在创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。AOF 日志文件的命令通过可读较强的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用 flushall 命令清空了所有数据，只要这个时候后台 rewrite 还没有发生，那么就可以立即拷贝 AOF 文件，将最后一条 flushall 命令给删了，然后再将该 AOF 文件放回去，就可以通过恢复机制，自动恢复所有数据。

AOF缺点

对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大。AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 fsync 一次日志文件，当然，每秒一次 fsync ，性能也还是很高的。（如果实时写入，那么 QPS 会大降，Redis 性能会大大降低） 以前 AOF 发生过 bug，就是通过 AOF 记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似 AOF 这种较为复杂的基于命令日志 merge 回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug，因此每次 rewrite 并不是基于旧的指令日志进行 merge 的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

Redis 数据过期策略

Redis 过期策略是：定期删除+惰性删除。

定期删除，指的是 Redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。惰性删除，在获取某个 key 的时候，Redis 会检查这个 key 如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西

当定期删除漏掉了很多过期 key，然后你也没及时去查，也也未发生惰性删除时，大量过期 key 堆积在内存里，导致 Redis 内存块耗尽，此时会触发内存淘汰机制

内存淘汰机制

noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了。allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的 key 给干掉啊。volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key（这个一般不太合适）。volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key。volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除。

对RDB的影响 持久化到RDB：在生成RDB文件是会先检查key是否过期，如过期则不会进入RDB 从RDB文件恢复：先对key先进行过期检查，如果过期，不导入数据库（主库情况）。对AOF的影响 持久化数据到AOF：当key过期后，还没有被删除，此时进行执行持久化操作（该key是不会进入aof文件的，因为没有发生修改命令） 当key过期后，在发生删除操作时，程序会向aof文件追加一条del命令（在将来的以aof文件恢复数据的时候该过期的键就会被删掉） AOF重写：重写时，会先判断key是否过期，已过期的key不会重写到aof文件 Redis高可用方案 Redis 主从 Redis主从的结构中，主节点可以进行读、写操作，而从节点只能进行读操作。由于主节点可以写，数据会发生变化，当主节点的数据发生变化时，会将变化的数据同步给从节点，这样从节点的数据就可以和主节点的数据保持一致了(基于Redis提供的replication功能)。一个主节点可以有多个从节点，但是一个从节点会只会有一个主节点。Redis主从会先尝试进行增量同步，如不成功，会进行全量同步 系统运行时，如果master挂掉了，可以在一个从库（如slave1）上手动执行命令slaveof no one，将slave1变成新的master；在其他从节点分别执行slaveof IP:PORT 将这机器的主节点指向的这个新的master；同时，挂掉的原master启动后作为新的slave也指向新的master上。

优点

支持主从复制，主机会自动将数据同步到从机，可以进行读写分离; 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务依然必须由Master来完成; Slave同样可以接受其他Slaves的连接和同步请求，这样可以有效地分载Master的同步压力; Master是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求; Slave同样是以阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。

缺点

Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复; 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性; 如果多个Slave断线了，需要重启的时候，尽量不要在同一时间段进行重启。因为只要Slave启动，就会发送sync请求和主机全量同步，当多个Slave重启的时候，可能会导致Master IO剧增从而宕机。Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂; Redis的主节点和从节点中的数据是一样的，降低的内存的可用性

Redis Sentinel（哨兵） 主从模式下，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这种方式并不推荐，实际生产中，我们优先考虑哨兵模式。这种模式下，master宕机，哨兵会自动选举master并将其他的slave指向新的master 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器;当哨兵监测到master宕机，会自动将slave切换到master，然后通过发布订阅模式通过其他的从服务器，修改配置文件，让它们切换主机;然而一个哨兵进程对Redis服务器进行监控，也可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

优点

哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。主从可以自动切换，系统更健壮，可用性更高。

缺点

具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低。Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis Cluster Redis 的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，对数据进行分片，也就是说每台 Redis 节点上存储不同的内容，对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个node进行操作，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node。集群部署至少要 3 台以上的master节点，最好使用 3 主 3 从六个节点的模式 redis-cluster把所有的物理节点映射到[0-16383]slot上（不一定是平均分配）,cluster 负责维护node<->slot<->value。每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。当数据写入到对应的master节点后，这个数据会同步给这个master对应的所有slave节点。为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点。当其它主节点ping主节点master 1时，如果半数以上的主节点与master 1通信超时，那么认为master 1宕机了，就会启用master 1的从节点slave 1，将slave 1变成主节点继续提供服务。如果master 1和它的从节点slave 1都宕机了，整个集群就会进入fail状态，因为集群的slot映射不完整。如果集群超过半数以上的master挂掉，无论是否有slave，集群都会进入fail状态。redis-cluster采用去中心化的思想，没有中心节点的说法，客户端与Redis节点直连，不需要中间代理层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

优点

采用去中心化思想，数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布; 可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除; 高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升; 降低运维成本，提高系统的扩展性和可用性。

缺点

Redis Cluster是无中心节点的集群架构，依靠Goss协议(谣言传播)协同自动化修复集群的状态 但 GosSIp有消息延时和消息冗余的问题，在集群节点数量过多的时候，节点之间需要不断进行 PING/PANG通讯，不必须要的流量占用了大量的网络资源。虽然Reds4.0对此进行了优化，但这个问题仍然存在。数据迁移问题 Redis Cluster可以进行节点的动态扩容缩容，这一过程，在目前实现中，还处于半自动状态，需要人工介入。在扩缩容的时候，需要进行数据迁移。而 Redis为了保证迁移的一致性，迁移所有操作都是同步操作，执行迁移时，两端的 Redis均会进入时长不等的阻塞状态，对于小Key，该时间可以忽略不计，但如果一旦Key的内存使用过大，严重的时候会接触发集群内的故障转移，造成不必要的切换。