线程模型

1. 单线程为什么这么快？

  1. 完全基于内存，绝大部分请求是纯内存操作，非常快速；
  2. 数据结构简单，对数据操作也简单；
  3. 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

  4. 使用多路 I/O 复用模型，非阻塞 IO。

    2. 为什么要用单线程？redis的线程模型是什么？

    为什么？

    因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，采用多线程会有很多麻烦。

  5. Redisv4.0（引入多线程处理异步任务）

  6. Redis 6.0（在网络模型中实现多线程 I/O ）
    为什么说Redis的瓶颈不在CPU？
    Redis绝大部分操作是基于内存的，而且是纯kv（key-value）操作，所以命令执行速度非常快。单线程就可以完全搞定。
    redis线程模型
    Redis的线程模型包括Redis 6.0之前和Redis 6.0。
    6.0之前，Redis 内部使用文件事件处理器 file event handler，他是基于 reactor 模式开发的，而且是单线程的，所以 Redis 才叫做单线程的模型。采用 IO 多路复用机制同时监听多个 Socket，根据 socket 上的事件来选择对应的事件处理器来处理这个事件。
    image.png
    文件事件处理器的结构包含 4 个部分： 多个 socket 、IO多路复用程序 、文件事件分派器 、事件处理器。
    socket 会产生 AE_READABLE 和 AE_WRITABLE 事件；事件处理器包括：连接应答处理器、命令请求处理器、命令回复处理器，每个处理器对应不同的 socket 事件。
    IO 多路复用程序同时监听着这些 Socket，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。当这些 Socket 产生了事件，IO 多路复用程序会将这些事件放到一个队列中。通过这个队列，以有序、同步、每次一个事件的方式向文件事件分派器中传送。当事件处理器处理完一个事件后，IO 多路复用程序才会继续向文件分派器传送下一个事件。
    Redis6.0引入多线程I/O，只是用来处理网络数据的读写和协议的解析，而执行命令依旧是单线程。

    3. 为什么引入多线程？模型是什么？性能效果？线程安全问题？

    为什么？
    随着互联网的飞速发展，互联网业务系统所要处理的线上流量越来越大，Redis的单线程模式会导致系统消耗很多 CPU 时间在网络 I/O 上从而降低吞吐量，要提升 Redis的性能有两个方向：优化网络 I/O 模块、提高机器内存读写的速度。
    后者依赖于硬件的发展，暂时无解。所以只能从前者下手，网络 I/O 的优化又可以分为两个方向：零拷贝技术或者 DPDK 技术，利用多核优势。
    零拷贝技术有其局限性，无法完全适配 Redis这一类复杂的网络 I/O 场景，更多网络 I/O 对 CPU 时间的消耗和 Linux 零拷贝技术。而 DPDK 技术通过旁路网卡 I/O 绕过内核协议栈的方式又太过于复杂以及需要内核甚至是硬件的支持。
    总结起来，Redis支持多线程主要就是两个原因：
  • 可以充分利用服务器 CPU 资源，目前主线程只能利用一个核
  • 多线程任务可以分摊 Redis 同步 IO 读写负荷
    模型实现
    (1).流程如下：
  1. 主线程负责接收建立连接请求，获取 socket 放入全局等待读处理队列

2、主线程处理完读事件之后，通过 RR(Round Robin) 将这些连接分配给这些 IO 线程
3、主线程阻塞等待 IO 线程读取 socket 完毕
4、主线程通过单线程的方式执行请求命令，请求数据读取并解析完成，但并不执行
5、主线程阻塞等待 IO 线程将数据回写 socket 完毕
6、解除绑定，清空等待队列
(2).特点如下：

  • IO 线程要么同时在读 socket，要么同时在写，不会同时读或写
  • IO 线程只负责读写 socket 解析命令，不负责命令处理（主线程串行执行命令）
  • IO 线程数可自行配置

image.png

提升效果

Redis 作者 antirez 在 RedisConf 2019 分享时曾提到：Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上。
国内也有大牛曾使用 unstable 版本在阿里云 esc 进行过测试，GET/SET 命令在 4 线程 IO 时性能相比单线程是几乎是翻倍了

线程安全

从上面的实现机制可以看出，Redis的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行。所以我们不需要去考虑控制 key、lua、事务，LPUSH/LPOP 等等的并发及线程安全问题。

4. 和memcached的多线程模型对比？

相同点：都采用了 Master 线程 -Worker 线程的模型。
不同点：Memcached 执行主逻辑也是在 Worker 线程里，模型更加简单，实现了真正的线程隔离，符合我们对线程隔离的常规理解。
而 Redis 把处理逻辑交还给 Master 线程，虽然一定程度上增加了模型复杂度，但也解决了线程并发安全等问题。

5. Redis对于大量的请求，是怎样处理的？

Redis是一个单线程程序，也就说同一时刻它只能处理一个客户端请求；
但Redis是通过IO多路复用（select，epoll，kqueue，依据不同的平台，采取不同的实现）来处理多个客
户端请求。

分布式锁

Redlock：全名叫做 Redis Distributed Lock;即使用redis实现的分布式锁；

1、什么是分布式锁? 为什么要有？特点？

分布式锁，就是分布式项目开发中用到的锁，可以用来控制分布式系统之间同步访问共享资源。
分布式系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机并发控制锁策略失效，为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁的由来。
特性：
1、互斥性：在任何时刻，对于同一条数据，只有一台应用可以获取到分布式锁；
2、高可用性：在分布式场景下，一小部分服务器宕机不影响正常使用，这种情况就需要将提供分布式锁的服务以集群的方式部署；
3、防止锁超时：如果客户端没有主动释放锁，服务器会在一段时间之后自动释放锁，防止客户端宕机或者网络不可达时产生死锁；
4、独占性：加锁解锁必须由同一台服务器进行，也就是锁的持有者才可以释放锁，不能出现你加的锁，别人给你解锁了。

2、常见的分布式锁有哪些解决方案？

  • 数据库乐观锁；
  • 基于ZooKeeper的分布式锁;

  • 基于Redis的分布式锁；

    基于关系型数据库，如MySQL

    基于关系型数据库实现分布式锁，是依赖数据库的唯一性来实现资源锁定，比如主键和唯一索引等。
    缺点：

  • 这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

  • 这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
  • 这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。

  • 这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

    基于Redis实现

    优点：
    Redis 锁实现简单，理解逻辑简单，性能好，可以支撑高并发的获取、释放锁操作。
    缺点：

  • Redis 容易单点故障，集群部署，并不是强一致性的，锁的不够健壮；

  • key 的过期时间设置多少不明确，只能根据实际情况调整；
  • 需要自己不断去尝试获取锁，比较消耗性能。

基于Redis命令：SET key value NX EX max-lock-time
从2.6.12版本后, 就可以使用set来获取锁, Lua 脚本来释放锁。setnx是老黄历了，set命令nx,xx等参数, 是为了实现 setnx 的功能。
三个核心要素

  • 加锁 setnx key test
  • 解锁 del key
  • 锁超时 expire key 30

锁超时指如果一个得到锁的线程在执行任务的过程中挂掉，来不及显式地释放锁，这块资源将会永远被锁住，别的线程永远不能进来。
存在问题
1、SETNX 和 EXPIRE 非原子性
假设一个场景中，某一个线程刚执行setnx，成功得到了锁。此时setnx刚执行成功，还未来得及执行expire命令，节点就挂掉了。此时这把锁就没有设置过期时间，别的线程就再也无法获得该锁。
解决措施:
由于setnx指令本身是不支持传入超时时间的，而在Redis2.6.12版本上为set指令增加了可选参数, 用法如下：
SET key value [EX seconds][PX milliseconds][NX|XX]

  • NX：只在键不存在时，才对键进行设置操作；
  • XX：只在键已经存在时，才对键进行设置操作；

2、锁误解除
如果线程 A 成功获取到了锁，并且设置了过期时间 30 秒，但线程 A 执行时间超过了 30 秒，锁过期自动释放，此时线程 B 获取到了锁；随后 A 执行完成，线程 A 使用 DEL 命令来释放锁，但此时线程 B 加的锁还没有执行完成，线程 A 实际释放的线程 B 加的锁。
解决办法：
在del释放锁之前加一个判断，验证当前的锁是不是自己加的锁。
具体在加锁的时候把当前线程的id当做value，可生成一个 UUID 标识当前线程，在删除之前验证key对应的value是不是自己线程的id。
还可以使用 lua 脚本做验证标识和解锁操作。
3、超时解锁导致并发
如果线程 A 成功获取锁并设置过期时间 30 秒，但线程 A 执行时间超过了 30 秒，锁过期自动释放，此时线程 B 获取到了锁，线程 A 和线程 B 并发执行。
A、B 两个线程发生并发显然是不被允许的，一般有两种方式解决该问题：

  • 将过期时间设置足够长，确保代码逻辑在锁释放之前能够执行完成。
  • 为获取锁的线程增加守护线程，为将要过期但未释放的锁增加有效时间。

4、不可重入
当线程在持有锁的情况下再次请求加锁，如果一个锁支持一个线程多次加锁，那么这个锁就是可重入的。如果一个不可重入锁被再次加锁，由于该锁已经被持有，再次加锁会失败。Redis 可通过对锁进行重入计数，加锁时加 1，解锁时减 1，当计数归 0 时释放锁。
5、无法等待锁释放
上述命令执行都是立即返回的，如果客户端可以等待锁释放就无法使用。

  • 可以通过客户端轮询的方式解决该问题，当未获取到锁时，等待一段时间重新获取锁，直到成功获取锁或等待超时。这种方式比较消耗服务器资源，当并发量比较大时，会影响服务器的效率。
  • 另一种方式是使用 Redis 的发布订阅功能，当获取锁失败时，订阅锁释放消息，获取锁成功后释放时，发送锁释放消息。
    基于zookeeper
    优点：
    zookeeper 天生设计定位就是分布式协调，强一致性，锁很健壮。如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。
    缺点：
    在高请求高并发下，系统疯狂的加锁释放锁，最后 zk 承受不住这么大的压力可能会存在宕机的风险。

    3、redlock红锁原理

    Redlock，此种方式比原先的单节点的方法更安全。它可以保证以下特性：
  1. 安全特性：互斥访问，即永远只有一个 client 能拿到锁
  2. 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
  3. 容错性：只要大部分 Redis 节点存活就可以正常提供服务。
    算法原理
    假设有5个完全独立的Redis主服务器
    1、获取当前时间戳
    2、client尝试按照顺序使用相同的key,value获取所有Redis服务的锁，在获取锁的过程中的获取时间比锁过期时间短很多，这是为了不要过长时间等待已经关闭的Redis服务。并且试着获取下一个Redis实例。
    比如：TTL为5s,设置获取锁最多用1s，所以如果一秒内无法获取锁，就放弃获取这个锁，从而尝试获取下个锁
    3、client通过获取所有能获取的锁后的时间减去第一步的时间，这个时间差要小于TTL时间并且至少有3个Redis实例成功获取锁，才算真正的获取锁成功
    4、如果成功获取锁，则锁的真正有效时间是 TTL减去第三步的时间差 的时间；比如：TTL 是5s,获取所有锁用了2s,则真正锁有效时间为3s(其实应该再减去时钟漂移);
    5、如果客户端由于某些原因获取锁失败，便会开始解锁所有Redis实例；因为可能已经获取了小于3个锁，必须释放，否则影响其他client获取锁
    失败重试
    如果一个 client 申请锁失败了，那么它需要稍等一会在重试避免多个 client 同时申请锁的情况.
    已经申请成功的要unlock
    性能、崩溃恢复和 fsync
    如果我们的节点没有持久化机制，client 从 5 个 master 中的 3 个处获得了锁，然后其中一个重启了，这是注意 整个环境中又出现了 3 个 master 可供另一个 client 申请同一把锁！ 违反了互斥性。
    如果我们开启了 AOF 持久化那么情况会稍微好转一些，因为 Redis 的过期机制是语义层面实现的，所以在 server 挂了的时候时间依旧在流逝，重启之后锁状态不会受到污染。
    但是考虑断电之后呢，AOF部分命令没来得及刷回磁盘直接丢失了，除非我们配置刷回策略为 fsnyc = always，但这会损伤性能。解决这个问题的方法是，当一个节点重启之后，我们规定在 max TTL 期间它是不可用的，这样它就不会干扰原本已经申请到的锁，等到它 crash 前的那部分锁都过期了，环境不存在历史锁了，那么再把这个节点加进来正常工作。