大家好：

我们在总结一下redis缓存技术的常用技术。

什么是redis 呢？

        redis是内存中的数据结构存储系统，它可以作数据库、缓存和消息代理。它支持多种类型的数据结构：字符串strings、列表lists、散列 hashes、集合sets、有序集合sorted sets（zset）。它可以持久化数据到磁盘中，也可以通过主从复制的特性，提高访问速度。使用redis进行数据缓存可以极大的提高系统的响应速度。它是key-value型的数据库。

redis类型有哪几个呢？

字符串String ： 可以存储字节串、整数、浮点数。可以对数值进行自增、自减等。

          主要命令：get set del  incr(自增)、decr(自减)

 列表list：一个列表结构可以有序的存储多个字符串，一个键对应多个值

          主要命令： lpush rpush lpop rpop lindex(根据索引获取单个元素) lrange(获取该范围上的所有值)

 集合 set：列表中存储多个字符串，并且字符串不重复

          主要命令： sadd、spop、srem、semembers(返回集合包含的所有元素)、sismember(检查给定元素是否存在在集合 中)

散列hash ： 可以存储多个键值对之间的映射

          主要命令：hset、hget、hgetAll、hdel、hlen

有序集合zset： 存储着成员与分值之间的映射。根据分值进行排序

         主要命令： zadd、zrem、zrank(获取排名)

redis有哪几个事物？

redis的事务基于 multi、exec、watch、unwatch、discard。这五个命令可以让用户在不被打断的情况下执行多个操作。

被multi和exec包裹的所有命令一个接一个地执行，直到所有命令执行完毕为止，是串行化执行

redis的应用场景是那些呢？

                缓存（数据查询、短连接、新闻内容、商品内容等等）。（最多使用）

　　　　分布式集群架构中的session分离。

　　　　聊天室的在线好友列表。

　　　　任务队列。（秒杀、抢购、12306等等）

　　　　应用排行榜。

　　　　网站访问统计。

　　　　数据过期处理（可以精确到毫秒）

redis 的策略有那些呢？

redis采用的是定期删除+惰性删除策略。

为什么不用定时删除策略?

定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.

定期删除+惰性删除是如何工作的呢?

定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。

于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。

redis 的淘汰策略。6种

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错

ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

redis 为什么持久？

持久化是数据安全的一种保证。它使得redis重启后仍然存在。持久化的方式有：快照和只追加文件。根据自己的时间情况选择其中一个或者全选。

持久化方式：

  （1） 快照： 它可以将存在与某一时刻的所有数据都写入硬盘里。

          使用命令bgsave创建快照，将会创建一个子进程

         save命令创建快照：快照创建完毕之前不会再响应任何其他命令。阻塞当前线程。不常用

         缺点： 如果只用快照持久化来保存数据，如果系统崩溃，将会丢失最近一次生成快照之后更改的所有数据

                     如果redis占用的内存越来越多，bgsave在创建子进程时耗费的时间也会越来越长。所以可以考虑关闭自动保存，通过手动发送bgsave或save进行持久化

  (2)    AOF（只追加文件）

         aop：该持久化将被执行的写命令写到AOF文件的末尾。 同步的选项有always、everysec、no。

                  always ：每个redis写命令都要同步写入硬盘，会严重降低redis速度。

                  everysec： 每秒执行一次同步，显式地将多个写命令同步到硬盘。用户最多和丢失一秒之内产生的数据

                  no：让操作系统来决定应该何时进行同步。系统崩溃时会丢失不定的数据。

         问题： 体积不断增大的AOF文件会占据磁盘大量空间。而且执行还原操作时的时间可能会很长

                   解决办法：发送bgrewriteAOF命令，通过移除冗余命令来重写aof文件

redis的集群方式是什么样的？

redis有三种集群方式：主从复制，哨兵模式和集群。
1.主从复制

主从复制原理：

从服务器连接主服务器，发送SYNC命令； 

主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 

主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 

从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 

主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 

从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）

主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操作）

主从复制优缺点：

优点：

支持主从复制，主机会自动将数据同步到从机，可以进行读写分离

为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成

Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。

Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

缺点：

Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

哨兵

主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

（1）监控主服务器和从服务器是否正常运行。

（2）主服务器出现故障时自动将从服务器转换为主服务器。

哨兵的工作方式：

每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。

如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）

如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态

当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）

在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。

当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。

若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

哨兵模式的优缺点

优点：

哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。

主从可以自动切换，系统更健壮，可用性更高。

缺点：

Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis-Cluster集群

redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。

 Redis-Cluster采用无中心结构,它的特点如下：

所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。

节点的fail是通过集群中超过半数的节点检测失效时才生效。

客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

工作方式：

在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。