学习笔记-Redis（三）

上节介绍了Redis的发布和订阅、事务机制、持久化操作，这节主要介绍Redis的主从复制、集群以及Redis应用存在的问题

一.Redis的主从复制

        Redis的主从复制是指，将多个Redis分配不同类型的任务，分别问主机、从机即master/slaver机制。其中主机master以写操作为主，从机slaver以读操作为主。

其作用为：

• 读写分离，性能扩展
• 容灾快速恢复

 1.复制原理

• Slave 启动成功连接到 master 后会发送一个 sync 命令；
• Master 接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master 将传送整个数据文件到 slave，以完成一次完全同步。
• 全量复制：slave 服务器在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量复制：Master 继续将新的所有收集到的修改命令依次传给 slave，完成同步。
• 但是只要是重新连接 master，一次完全同步（全量复制) 将被自动执行。

 2.哨兵模式（sentinel）

        在介绍哨兵模式前，首先介绍反客为主：

        一个master宕机后，如果不进行设置，slave时不能升为master的。但如果对某一个slave设置了slaveof no one，那么该从机就会升为主机。但这样的操作过于麻烦，需要手动的去给某个从机执行指令。故衍生出了哨兵模式。

        哨兵模式是将上述从机升为主机的自动操作，其能够后台监控主机是否故障，如果故障了就根据投票数自动从从机转换为主机。

• 哪个从机会被选举为主机呢？根据优先级别：slave-priority 。
• 原主机重启后会变为从机。

缺点：复制延时

        由于所有的写操作都是先在 Master 上操作，然后同步更新到 Slave 上，所以从 Master 同步到 Slave 机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave 机器数量的增加也会使这个问题更加严重。

二.Redis集群

        Redis 集群（包括很多小集群）实现了对 Redis 的水平扩容，即启动 N 个 redis 节点，将整个数据库分布存储在这 N 个节点中，每个节点存储总数据的 1/N，即一个小集群存储 1/N 的数据，每个小集群里面维护好自己的 1/N 的数据。

        Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

该模式的 redis 集群特点是：分治、分片。

优点：

• 实现扩容
• 分摊压力
• 无中心配置相对简单

缺点:

• 多键操作是不被支持的。
• 多键的 Redis 事务是不被支持的，lua 脚本不被支持。
• 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至 redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

三.Redis应用产生的问题

1.用作缓存

（1）缓存穿透

问题描述：当查询数据库时，一般都会经由Redis缓存查询，如果Redis缓存中没有，才会去数据库进行查询。但如果查询某个一定不会存在的数据，则会直接绕开缓存，直接对数据库进行查询，数据库查出来也没有，故不会有结果放入缓存。若大量高并发的查询不存在的数据，就会造成缓存穿透问题，造成服务器压力过大。

 解决方案：

• 对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。
• 设置可访问的名单（白名单）：使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmap 里面的 id 进行比较，如果访问 id 不在 bitmaps 里面，进行拦截，不允许访问。
• 采用布隆过滤器：布隆过滤器（Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制向量 (位图) 和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
• 进行实时监控：当发现 Redis 的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。

（2）缓存击穿

问题描述：若某一瞬间，有大量的请求同时请求查询一个即将在Redis过期的数据，此时因为Redis已经不存在该数据，所以大量的请求会同时访问数据库，造成后端数据库的崩溃。一般发生在热门key

 

 解决方案：

key 可能会在某些时间点被超高并发地访问，是一种非常 “热点” 的数据。

• 预先设置热门数据：在 redis 高峰访问之前，把一些热门数据提前存入到 redis 里面，加大这些热门数据 key 的时长。
• 实时调整：现场监控哪些数据热门，实时调整 key 的过期时长。
• 使用锁

• 就是在缓存失效的时候（判断拿出来的值为空），不是立即去 load db。
• 先使用缓存工具的某些带成功操作返回值的操作（比如 Redis 的 SETNX）去 set 一个 mutex key。
• 当操作返回成功时，再进行 load db 的操作，并回设缓存，最后删除 mutex key；
• 当操作返回失败，证明有线程在 load db，当前线程睡眠一段时间再重试整个 get 缓存的方法。

（3）缓存雪崩

问题描述：若某一瞬间，有大量的请求请求查询数据，而此时Redis的批量数据到达了过期时间，从而失效。此时这些大量请求就会访问数据库，造成数据库的瘫痪，这就是缓存雪崩现象。

 解决方案：

• 构建多级缓存架构：nginx 缓存 + redis 缓存 + 其他缓存（ehcache 等）。
• 使用锁或队列：用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上，该方法不适用高并发情况。
• 设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际 key 的缓存。
• 将缓存失效时间分散开：比如可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

2.用作分布式锁

        随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程的特点以及分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的 Java API 并不能提供分布式锁的能力。为了解决这个问题就需要一种跨 JVM 的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

分布式锁主流的实现方案：

• 基于数据库实现分布式锁
• 基于缓存（Redis 等）
• 基于 Zookeeper

根据实现方式，分布式锁还可以分为类 CAS 自旋式分布式锁以及 event 事件类型分布式锁：

• 类 CAS 自旋式分布式锁：询问的方式，类似 java 并发编程中的线程获询问的方式尝试加锁，如 mysql、redis。
• 另外一类是 event 事件通知进程后续锁的变化，轮询向外的过程，如 zookeeper、etcd。

每一种分布式锁解决方案都有各自的优缺点：

• 性能：redis 最高
• 可靠性：zookeeper 最高

解决方案：使用Redis实现分布式锁(占坑思想)

 

• setnx：通过该命令尝试获得锁，没有获得锁的线程会不断等待尝试。
• set key ex 3000nx：设置过期时间，自动释放锁，解决当某一个业务异常而导致锁无法释放的问题。但是当业务运行超过过期时间时，开辟监控线程增加该业务的运行时间，直到运行结束，释放锁。
• uuid：设置 uuid，释放前获取这个值，判断是否自己的锁，防止误删锁，造成没锁的情况。

RedLock:

Redlock 是一种算法，Redlock 也就是 Redis Distributed Lock，可用实现多节点 redis 的分布式锁。RedLock 官方推荐，Redisson 完成了对 Redlock 算法封装。

此种方式具有以下特性：

• 互斥访问：即永远只有一个 client 能拿到锁。
• 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使锁定资源的服务崩溃或者分区，仍然能释放锁。
• 容错性：只要大部分 Redis 节点存活（一半以上），就可以正常提供服务

RedLock 原理：

• 获取当前 Unix 时间，以毫秒为单位。
• 依次尝试从 N 个实例，使用相同的 key 和随机值获取锁。在步骤 2，当向 Redis 设置锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为 10 秒，则超时时间应该在 5-50 毫秒之间。这样可以避免服务器端 Redis 已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试另外一个 Redis 实例。
• 客户端使用当前时间减去开始获取锁时间（步骤 1 记录的时间）就得到获取锁使用的时间。当且仅当从大多数（这里是 3 个节点）的 Redis 节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。
• 如果取到了锁，key 的真正有效时间等于有效时间减去获取锁所使用的时间（步骤 3 计算的结果）。
• 如果因为某些原因，获取锁失败（没有在至少 N/2+1 个 Redis 实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的 Redis 实例上进行解锁（即便某些 Redis 实例根本就没有加锁成功）。