Skip to content

Redis.md

Latest commit

 

History

History
290 lines (170 loc) · 25.3 KB

Redis.md

File metadata and controls

290 lines (170 loc) · 25.3 KB

Redis设计实现和实践

设计原理

  1. 启动流程

    1. 初始化server变量，设置redis相关的默认值
    2. 读入配置文件，同时接收命令行中传入的参数，替换服务器设置的默认值
    3. 初始化服务器功能模块。在这一步初始化了包括进程信号处理、客户端链表、共享对象、初始化数据、初始化网络连接等
    4. 从RDB或AOF重载数据
    5. 网络监听服务启动前的准备工作
    6. 开启事件监听，开始接受客户端的请求

  2. 数据的持久化 在使用redis时不少人都说一个问题，就是说redis宕机了怎么办？会不会数据丢失等等的问题。 现在来看看Redis提供的数据持久化解决方案，并通过原理分析优缺点。最终能得出Redis适合使用的应用场景。

    1. RDB持久化方案 在Redis运行时，RDB程序将当前内存中的数据库快照保存到磁盘中，当Redis需要重启时，RDB程序会通过重载RDB文件来还原数据库。 从上述描述可以看出，RDB主要包括两个功能： 关于rdb的实现可以见src/rdb.c

      • 保存(rdbSave)

        rdbSave负责将内存中的数据库数据以RDB格式保存到磁盘中，如果RDB文件已经存在将会替换已有的RDB文件。保存RDB文件期间会阻塞主进程，这段时间期间将不能处理新的客户端请求，直到保存完成为止。 为避免主进程阻塞，Redis提供了rdbSaveBackground函数。在新建的子进程中调用rdbSave，保存完成后会向主进程发送信号，同时主进程可以继续处理新的客户端请求。

      • 读取(rdbLoad)

        当Redis启动时，会根据配置的持久化模式，决定是否读取RDB文件,并将其中的对象保存到内存中。 载入RDB过程中，每载入1000个键就处理一次已经等待处理的客户端请求，但是目前仅处理订阅功能的命令(PUBLISH 、 SUBSCRIBE 、 PSUBSCRIBE 、 UNSUBSCRIBE 、 PUNSUBSCRIBE)，其他一律返回错误信息。因为发布订阅功能是不写入数据库的，也就是不保存在Redis数据库的。

      • RDB的缺点：

        再说RDB缺点时，需要提到的是RDB有保存点的概念。在默认的redis.conf中可以看到这样的默认配置：

        save
        save 900 1 #如果15分钟内，有1个键被修改
        save 300 10 #如果6分钟内，有10个键被修改
        save 60 10000 #如果60秒内有10000个键被修改

        意思是当满足上面任意一个条件时，将会进行快照保存。为了保证IO读写性能不会成为Redis的瓶颈，一般都会创建一个比较大的值来作为保存点。

          1. 此时如果保存点设置过大，就会导致宕机丢失的数据过多。保存点设置过小，又会造成IO瓶颈
  2. 当对数据进行保存时，可能会由于数据集过大导致操作耗时，这会导致Redis可能在短时间内无法处理客户端请求。

    2. AOF持久化方案

      以协议文本的方式，将所有对数据库进行的写入命令记录到AOF文件，达到记录数据库状态的目的。

      • 保存

        1. 将客户端请求的命令转换为网络协议格式
        2. 将协议内容字符串追加到变量server.aof_buf中
        3. 当AOF系统达到设定的条件时，会调用aof_fsync(文件描述符号)将数据写入磁盘

        其中第三步提到的设定条件，就是AOF性能的关键点。目前Redis支持三种保存条件机制：

        1. AOF_FSYNC_NO：不保存 此模式下，每执行一条客户端的命令，都会将协议字符串追加到server.aof_buf中，但不会执行写入磁盘。 写入只发生在：

          1. Redis被正常关闭
          2. Aof功能关闭
          3. 系统写缓存已满，或后台定时保存操作被执行

        上面三种情况都会阻塞主进程，导致客户端请求失败。

        1. AOF_FSYNC_EVERYSECS：每一秒保存一次

        由后台子进程调用写入保存，不会阻塞主进程。如果发生宕机，那么最大丢失数据会在2s以内的数据。这也是默认的设置选项

        1. AOF_FSYNC_ALWAYS：每执行一个命令都保存一次

        这种模式下，可以保证每一条客户端指令都被保存，保证数据不会丢失。但缺点就是性能大大下降，因为每一次操作都是独占性的，需要阻塞主进程。

      • 读取

        AOF保存的是数据协议格式的数据，所以只要将AOF中的数据转换为命令，模拟客户端重新执行一遍，就可以还 原所有数据库状态。读取的过程是： 1. 创建模拟的客户端 2. 读取AOF保存的文本，还原数据为原命令和原参数。然后使用模拟的客户端发出这个命令请求。 3. 继续执行第二步，直到读取完AOF文件

        AOF需要将所有的命令都保存到磁盘，那么这个文件会随着时间变得越来越大。读取也会变得很慢。 Redis提供了AOF的重写机制，帮助减少文件的大小。实现的思路是：

        同时，考虑到为了在AOF重写时，不影响AOF的写入增加了AOF重写缓存的概念。 也就是说Redis在开启AOF时，除了将命令格式数据写入到AOF文件，同时也会写入到AOF重写缓存。这样AOF的写入、重写就做到了隔离，保证了重写时不会阻塞写入。

        • AOF重写流程

          1. AOF重写完成会向主进程发送一个完成的信号
          2. 会将AOF重写缓存中的数据全部写入到文件中
          3. 用新的AOF文件，覆盖原有的AOF文件。

        • AOF缺点

          1. AOF文件通常会大于相同数据集的RDB文件
          2. AOF模式下性能与RDB模式下性能高低，主要取决于AOF选用的fsync模式

  3. 数据存储结构 redis底层数据存储的结构是一个hashTable，既hash桶

  4. 缓存淘汰机制：

maxmemory

我们可以通过配置redis.conf中的maxmemory这个值来开启内存淘汰功能，至于这个值有什么意义，我们可以通过了解内存淘汰的过程来理解它的意义：

1. 客户端发起了需要申请更多内存的命令（如set）。

2. Redis检查内存使用情况，如果已使用的内存大于maxmemory则开始根据用户配置的不同淘汰策略来淘汰内存（key），从而换取一定的内存。

3. 如果上面都没问题，则这个命令执行成功。

maxmemory为0的时候表示我们对Redis的内存使用没有限制。

Redis提供了下面几种淘汰策略供用户选择，其中默认的策略为noeviction策略：

· noeviction：当内存使用达到阈值的时候，所有引起申请内存的命令会报错。

· allkeys-lru：在主键空间中，优先移除最近未使用的key。

· volatile-lru：在设置了过期时间的键空间中，优先移除最近未使用的key。

· allkeys-random：在主键空间中，随机移除某个key。

· volatile-random：在设置了过期时间的键空间中，随机移除某个key。

· volatile-ttl：在设置了过期时间的键空间中，具有更早过期时间的key优先移除。
  1. 分布式锁：

在描述我们的设计之前，我们想先提出三个属性，这三个属性在我们看来，是实现高效分布式锁的基础。

  1. 安全属性：互斥，不管任何时候，只有一个客户端能持有同一个锁。
  2. 效率属性A：不会死锁，最终一定会得到锁，就算一个持有锁的客户端宕掉或者发生网络分区。
  3. 效率属性B：容错，只要大多数Redis节点正常工作，客户端应该都能获取和释放锁。

安全性的论证

这个算法到底是不是安全的呢？我们可以观察不同场景下的情况来理解这个算法为什么是安全的。 开始之前，让我们假设客户端可以在大多数节点都获取到锁，这样所有的节点都会包含一个有相同存活时间的key。但是需要注意的是，这个key是在不同时间点设置的，所以这些key也会在不同的时间超时，但是我们假设最坏情况下第一个key是在T1时间设置的（客户端连接到第一个服务器时的时间），最后一个key是在T2时间设置的（客户端收到最后一个服务器返回结果的时间），从T2时间开始，我们可以确认最早超时的key至少也会存在的时间为MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT，TTL是锁超时时间、（T2-T1）是最晚获取到的锁的耗时，CLOCK_DRIFT是不同进程间时钟差异，这个是用来补偿前面的(T2-T1）。其他的key都会在这个时间点之后才会超时，所以我们可以确定这些key在这个时间点之前至少都是同时存在的。

在大多数节点的key都set了的时间段内，其他客户端无法抢占这个锁，因为在N/2+1个客户端的key已经存在的情况下不可能再在N/2+1个客户端上获取锁成功，所以如果一个锁获取成功了，就不可能同时重新获取这个锁成功（不然就违反了分布式锁互斥原则），然后我们也要确保多个客户端同时尝试获取锁时不会都同时成功。 **如果一个客户端获取大多数节点锁的耗时接近甚至超过锁的最大有效时间时（就是我们为SET操作设置的TTL值），那么系统会认为这个锁是无效的同时会释放这些节点上的锁，所以我们仅仅需要考虑获取大多数节点锁的耗时小于有效时间的情况。**在这种情况下，根据我们前面的证明，在MIN_VALIDITY时间内，没有客户端能重新获取锁成功，所以多个客户端都能同时成功获取锁的结果，只会发生在多数节点获取锁的时间都大大超过TTL时间的情况下，实际上这种情况下这些锁都会失效 。 我们非常期待和欢迎有人能提供这个算法安全性的公式化证明，或者发现任何bug。

性能论证 这个系统的性能主要基于以下三个主要特征：

1.锁自动释放的特征（超时后会自动释放），一定时间后某个锁都能被再次获取。

2.客户端通常会在不再需要锁或者任务执行完成之后主动释放锁，这样我们就不用等到超时时间会再去获取这个锁。

3.当一个客户端需要重试获取锁时，这个客户端会等待一段时间，等待的时间相对来说会比我们重新获取大多数锁的时间要长一些，这样可以降低不同客户端竞争锁资源时发生死锁的概率。

然而，我们在网络分区时要损失TTL的可用性时间，所以如果网络分区持续发生，这个不可用会一直持续。这种情况在每次一个客户端获取到了锁并在释放锁之前被网络分区了时都会出现。

基本来说，如果持续的网络分区发生的话，系统也会在持续不可用。

性能、故障恢复和fsync 很多使用Redis做锁服务器的用户在获取锁和释放锁时不止要求低延时，同时要求高吞吐量，也即单位时间内可以获取和释放的锁数量。为了达到这个要求，一定会使用多路传输来和N个服务器进行通信以降低延时（或者也可以用假多路传输，也就是把socket设置成非阻塞模式，发送所有命令，然后再去读取返回的命令，假设说客户端和不同Redis服务节点的网络往返延时相差不大的话）。

然后如果我们想让系统可以自动故障恢复的话，我们还需要考虑一下信息持久化的问题。

为了更好的描述问题，我们先假设我们Redis都是配置成非持久化的，某个客户端拿到了总共5个节点中的3个锁，这三个已经获取到锁的节点中随后重启了，这样一来我们又有3个节点可以获取锁了（重启的那个加上另外两个），这样一来其他客户端又可以获得这个锁了，这样就违反了我们之前说的锁互斥原则了。

如果我们启用AOF持久化功能，情况会好很多。举例来说，我们可以发送SHUTDOWN命令来升级一个Redis服务器然后重启之，因为Redis超时时效是语义层面实现的，所以在服务器关掉期间时超时时间还是算在内的，我们所有要求还是满足了的。然后这个是基于我们做的是一次正常的shutdown，但是如果是断电这种意外停机呢？如果Redis是默认地配置成每秒在磁盘上执行一次fsync同步文件到磁盘操作，那就可能在一次重启后我们锁的key就丢失了。理论上如果我们想要在所有服务重启的情况下都确保锁的安全性，我们需要在持久化设置里设置成永远执行fsync操作，但是这个反过来又会造成性能远不如其他同级别的传统用来实现分布式锁的系统。 然后问题其实并不像我们第一眼看起来那么糟糕，基本上只要一个服务节点在宕机重启后不去参与现在所有仍在使用的锁，这样正在使用的锁集合在这个服务节点重启时，算法的安全性就可以维持，因为这样就可以保证正在使用的锁都被所有没重启的节点持有。 为了满足这个条件，我们只要让一个宕机重启后的实例，至少在我们使用的最大TTL时间内处于不可用状态，超过这个时间之后，所有在这期间活跃的锁都会自动释放掉。 使用延时重启的策略基本上可以在不适用任何Redis持久化特性情况下保证安全性，然后要注意这个也必然会影响到系统的可用性。举个例子，如果系统里大多数节点都宕机了，那在TTL时间内整个系统都处于全局不可用状态（全局不可用的意思就是在获取不到任何锁）。

实践

穿透

穿透：频繁查询一个不存在的数据，由于缓存不命中，每次都要查询持久层。从而失去缓存的意义。

解决办法：

  • ①用一个bitmap和n个hash函数做布隆过滤器过滤没有在缓存的键。
  • ②持久层查询不到就缓存空结果，有效时间为数分钟。

雪崩

雪崩：缓存大量失效的时候，引发大量查询数据库。

解决办法：

  • ①用锁/分布式锁或者队列串行访问
  • ②缓存失效时间均匀分布

热点key

热点key:某个key访问非常频繁，当key失效的时候有打量线程来构建缓存，导致负载增加，系统崩溃。

解决办法：

  • ①使用锁，单机用synchronized,lock等，分布式用分布式锁。

  • ②缓存过期时间不设置，而是设置在key对应的value里。如果检测到存的时间超过过期时间则异步更新缓存。

  • ③在value设置一个比过期时间t0小的过期时间值t1，当t1过期的时候，延长t1并做更新缓存操作。

集群方案

通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？

首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。

其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。

twemproxy codis redis cluster 3.0

方案:

  1. Redis官方集群方案 Redis Cluster

    Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。 Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类pre sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模。

    Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实现中，还处于半自动状态，需要人工介入。

    Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。

    为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似前篇文章提到的Redis Sharding场景下服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

    Redis Cluster的新节点识别能力、故障判断及故障转移能力是通过集群中的每个node都在和其它nodes进行通信，这被称为集群总线(cluster bus)。它们使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是16379。nodes之间的通信采用特殊的二进制协议。

    对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个node进行操作，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这有点儿像浏览器页面的302 redirect跳转。

    Redis Cluster是Redis 3.0以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

  2. Redis Sharding集群

    Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。

    多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。

    Redis Sharding可以说是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点操作数据。Sharding架构如图：

    庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。

    Jedis的Redis Sharding实现具有如下特点：

    1. 采用一致性哈希算法(consistent hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。

    2. 为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。

    3. ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。

    Redis Sharding采用客户端Sharding方式，服务端Redis还是一个个相对独立的Redis实例节点，没有做任何变动。同时，我们也不需要增加额外的中间处理组件，这是一种非常轻量、灵活的Redis多实例集群方法。

    当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。

    作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。有没有其它手段改善这种情况？

    Redis作者给出了一个比较讨巧的办法--presharding，即预先根据系统规模尽量部署好多个Redis实例，这些实例占用系统资源很小，一台物理机可部署多个，让他们都参与sharding，当需要扩容时，选中一个实例作为主节点，新加入的Redis节点作为从节点进行数据复制。数据同步后，修改sharding配置，让指向原实例的Shard指向新机器上扩容后的Redis节点，同时调整新Redis节点为主节点，原实例可不再使用。

    presharding是预先分配好足够的分片，扩容时只是将属于某一分片的原Redis实例替换成新的容量更大的Redis实例。参与sharding的分片没有改变，所以也就不存在key值从一个区转移到另一个分片区的现象，只是将属于同分片区的键值从原Redis实例同步到新Redis实例。 并不是只有增删Redis节点引起键值丢失问题，更大的障碍来自Redis节点突然宕机。在《Redis持久化》一文中已提到，为不影响Redis性能，尽量不开启AOF和RDB文件保存功能，可架构Redis主备模式，主Redis宕机，数据不会丢失，备Redis留有备份。

    这样，我们的架构模式变成一个Redis节点切片包含一个主Redis和一个备Redis。在主Redis宕机时，备Redis接管过来，上升为主Redis，继续提供服务。主备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性。则Sharding架构演变成： Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。

    高访问量下，即使采用Sharding分片，一个单独节点还是承担了很大的访问压力，这时我们还需要进一步分解。通常情况下，应用访问Redis读操作量和写操作量差异很大，读常常是写的数倍，这时我们可以将读写分离，而且读提供更多的实例数。

    可以利用主从模式实现读写分离，主负责写，从负责只读，同时一主挂多个从。在Sentinel监控下，还可以保障节点故障的自动监测。

  3. 利用代理中间件实现大规模Redis集群

    上面分别介绍了多Redis服务器集群的两种方式，它们是基于客户端sharding的Redis Sharding和基于服务端sharding的Redis Cluster。

    客户端sharding技术其优势在于服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。其不足之处在于：

    由于sharding处理放到客户端，规模进步扩大时给运维带来挑战。

    服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。

    连接不能共享，当应用规模增大时，资源浪费制约优化。

    服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时，客户端不需要感知，客户端像使用单Redis服务器一样使用Redis集群，运维管理也比较方便。

    不过Redis Cluster正式版推出时间不长，系统稳定性、性能等都需要时间检验，尤其在大规模使用场合。

    能不能结合二者优势？即能使服务端各实例彼此独立，支持线性可伸缩，同时sharding又能集中处理，方便统一管理？本篇介绍的Redis代理中间件twemproxy就是这样一种利用中间件做sharding的技术。

    twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后(如sharding)，再转发给后端真正的Redis服务器。也就是说，客户端不直接访问Redis服务器，而是通过twemproxy代理中间件间接访问。

    参照Redis Sharding架构，增加代理中间件的Redis集群架构如下：

    twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可避免单点压力或故障。

    twemproxy又叫nutcracker，起源于twitter系统中redis/memcached集群开发实践，运行效果良好，后代码奉献给开源社区。其轻量高效，采用C语言开发，工程网址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis

    twemproxy后端不仅支持redis，同时也支持memcached，这是twitter系统具体环境造成的。

    由于使用了中间件，twemproxy可以通过共享与后端系统的连接，降低客户端直接连接后端服务器的连接数量。同时，它也提供sharding功能，支持后端服务器集群水平扩展。统一运维管理也带来了方便。

    当然，也是由于使用了中间件代理，相比客户端直连服务器方式，性能上会有所损耗，实测结果大约降低了20%左右。