日期：2016年6月25日

Redis 分区实现原理

摘要

Redis Partitioning即Redis分区，简单的说就是将数据分布到不同的redis实例中，因此对于每个redis实例所存储的内容仅仅是所有内容的一个子集。分区（Partitioning）不仅仅是Redis中的概念，几乎是所有数据存储系统都会涉及到的概念，这篇文章将会在理解分区基本概念的基础之上进一步了解Redis对分区的支持。

我们为什么要分区

我们为什么要分区？分区的动机是什么？通常来说，Redis分区的好处大致有如下两个方面：

  1. 性能的提升，单机Redis的网络I/O能力和计算资源是有限的，将请求分散到多台机器，充分利用多台机器的计算能力可网络带宽，有助于提高Redis总体的服务能力。
  2. 存储的横向扩展，即使Redis的服务能力能够满足应用需求，但是随着存储数据的增加，单台机器受限于机器本身的存储容量，将数据分散到多台机器上存储使得Redis服务可以横向扩展。

总的来说，分区使得我们本来受限于单台计算机硬件资源的问题不再是问题，存储不够？计算资源不够？带宽不够？我们都可以通过增加机器来解决这些问题。

Redis分区基础

实际应用中有很多分区的具体策略，举个例子，假设我们已经有了一组四个Redis实例分别为R0、R1、R2、R3，另外我们有一批代表用户的键，如：user:1，user:2，……等等，其中“user:”后面的数字代表的是用户的ID，我们要做的事情是把这些键分散存储在这四个不同的Redis实例上。怎么做呢？最简单的一种方式是范围分区(range partitioning)，下面我们来看看基于范围分区怎么做。

范围分区

所谓范围分区，就是将一个范围内的key都映射到同一个Redis实例中，加入数据集还是上面提到的用户数据，具体做法如下：

我们可以将用户ID从0到10000的用户数据映射到R0实例，而将用户ID从10001到20000的对象映射到R1实例，依次类推。

这种方法虽然简单，但是在实际应用中是很有效的，不过还是有问题：

  • 我们需要一张表，这张表用来存储用户ID范围到Redis实例的映射关系，比如用户ID0-10000的是映射到R0实例……。
  • 我们不仅需要对这张表进行维护，而且对于每种对象类型我们都需要一个这样的表，比如我们当前存储的是用户信息，如果存储的是订单信息，我们就需要再建一张映射关系表。
  • 如果我们想要存储的数据的key并不能按照范围划分怎么办，比如我们的key是一组uuid，这个时候就不好用范围分区了。

因此，在实际应用中，范围分区并不是很好的选择，不用担心，我们还有更好的方法，接下来认识下哈希分区。

哈希分区

哈希分区跟范围分区相比一个明显的优点是哈希分区适合任何形式的key，而不像范围分区一样需要key的形式为object_name:<id>，而且分区方法也很简单，一个公式就可以表达：

id=hash(key)%N

其中id代表Redis实例的编号，公式描述的是首先根据key和一个hash函数（如crc32函数）计算出一个数值型的值。接着上面的例子，我们的第一个要处理的key是user:1，hash（user:1）的结果是93024922。

然后哈希结果进行取模，取模的目的是计算出一个介于0到3之间的值，因此这个值才可以被映射到我们的一台Redis实例上面。比如93024922%4结果是2，我们就会知道foobar将要被存储在R2上面。

当然除了上面提到的两种分区方法，还有很多其他的方法。比如一种从哈希分区演进而来的consistent hashing分区，相信信息可以参考我的另一篇文章《memcached分布式实现原理》，其已经被redis client和proxies实现了。

不同的分区实现

分区可以在redis软件栈的不同部分被实现，我们来看看下面几种：

客户端实现

客户端实现即key在redis客户端就决定了要被存储在那台Redis实例中，见下图：

客户端实现分区示意图

上面为客户端实现Redis分区的示意图。

代理实现

代理实现即客户端将请求发往代理服务器，代理服务器实现了Redis协议，因此代理服务器可以代理客户端和Redis服务器通信。代理服务器通过配置的分区schema来将客户端的请求转发到正确的Redis实例中，同时将反馈消息返回给客户端。代理实现Redis分区示意图如下：

代理实现Redis分区示意图

Redis和Memcached代理Twemoroxy都实现了代理分区。

查询路由

查询路由是Redis Cluster实现的一种Redis分区方式：

查询路由Redis分区示意图

查询路由的过程中，我们可以将查询请求随机的发送到任意一个Redis实例，这个Redis实例负责将请求转发至正确的Redis实例中。Redis集群实现了一个通过和客户端协作的hybrid来做查询路由。

Redis分区的缺点

尽管Redis分区到现在为止，so far so good，但是Redis分区有一些致命的缺点，这导致一些Redis功能在分区的环境下并不能很好地工作，我们来看看：

  • 多键操作是不被支持的，比如我们将要批量操作的键被映射到了不同的Redis实例中。
  • 多键的Redis事务是不被支持的。
  • 分区的最小粒度是键，因此我们不能将关联到一个键的很大的数据集映射到不同的实例。
  • 当应用分区的时候，数据的处理是非常复杂的，比如我们需要处理多个rdb/aof文件，将分布在不同实例的文件聚集到一起备份。
  • 添加和删除机器是很复杂的，例如Redis集群支持几乎运行时透明的因为增加或减少机器而需要做的rebalancing,然而像客户端和代理分区这种方式是不支持这种功能的。

既然有问题，那么就需要解决方案，这个时候Pre-sharding来了，后面我们会介绍Pre-Sharding。

持久存储用还是缓存

尽管数据分区对于Redis来说无论是数据持久化存储还是缓存，在概念上都是一样的，然而对于数据持久化存储还是有一个很大的限制。当我们使用Redis来作为持久化存储的时候，每一个key必须一直被映射到同一个Redis实例。而当Redis被当做缓存使用的时候，对于这个key，如果一个实例不能用了，这个key还可以被映射到其他的实例中。

Consistent hashing实现通常使得当一个key被映射到的实例不能用的时候将这个key映射到其他实例成为可能。类似，如果增加了一台机器，一部分的key将会被映射到这台新的机器上，我们需要了解的两点如下：

  1. 如果Redis被用来当做缓存，且要求容易增加或删除机器，使用consistent hashing是非常简单的。
  2. 如果Redis被用来当做（持久）存储，一个固定的key到实例的映射是需要的，因此我们不能够再灵活的添加或删除机器。否则，我们需要在增加或删除机器的时候系统能够rebalace，当前Redis Cluster已经支持。

Pre-Sharding

通过上面的介绍，我们知道Redis分区应用起来是有问题的，除非我们只是使用Redis当做缓存，否则对于增加机器或删除机器是非常麻烦的。

然而，通常我们Redis容量变动在实际应用中是非常常见的，比如今天我需要10台Redis机器，明天可能就需要50台机器了。

鉴于Redis是很轻量级的服务（每个实例仅仅占用1M），对于上面的问题一种简单的解决办法是：

我们可以开启多个Redis实例，尽管是一台物理机器，我们在刚开始的时候也可以开启多个实例。我们可以从中选择一些实例，比如32或64个实例来作为我们的工作集群。当一台物理机器存储不够的时候，我们可以将一般的实例移动到我们的第二台物理机上，依次类对，我们可以保证集群中Redis的实例数不变，又可以达到扩充机器的目的。

怎么移动Redis实例呢？当需要将Redis实例移动到独立的机器上的时候，我们可以通过下面步骤实现：

  1. 在新的物理机上启动一个新的Redis实例。
  2. 将新的物理机作为要移动的那台的slave机器。
  3. 停止客户端。
  4. 更新将要被移动的那台Redis实例的IP地址。
  5. 对于slave机器发送SLAVEOF ON ONE命令。
  6. 使用新的IP启动Redis客户端。
  7. 关闭不再使用的那个Redis实例。

总结

这篇文章在理解Redis分区概念的基础之上又介绍了Redis分区常见的几种实现方式及原理，最后根据实现中遇到的问题引入了Pre-Sharding解决方案。

缓存穿透、并发和失效，来自一线架构师的解决方案

本文作者是易宝支付的架构师程超，他介绍了我们在使用缓存过程中经常会出现的几个问题以及解决方案，包括缓存穿透、缓存并发和缓存失效，内容比较基础，但也很实在，推荐阅读。另外，如果你有其它更好的解决方案，欢迎留言讨论。

我们在用缓存的时候，不管是Redis或者Memcached，基本上会通用遇到以下三个问题：

  • 缓存穿透
  • 缓存并发
  • 缓存失效
缓存穿透

注：上面三个图会有什么问题呢？

我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了。

那这种问题有什么好办法解决呢？

要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。有一个比较巧妙的作法是，可以将这个不存在的key预先设定一个值。比如，”key” , “&&”。

在返回这个&&值的时候，我们的应用就可以认为这是不存在的key，那我们的应用就可以决定是否继续等待继续访问，还是放弃掉这次操作。如果继续等待访问，过一个时间轮询点后，再次请求这个key，如果取到的值不再是&&，则可以认为这时候key有值了，从而避免了透传到数据库，从而把大量的类似请求挡在了缓存之中。

缓存并发

有时候如果网站并发访问高，一个缓存如果失效，可能出现多个进程同时查询DB，同时设置缓存的情况，如果并发确实很大，这也可能造成DB压力过大，还有缓存频繁更新的问题。

我现在的想法是对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询。

这种情况和刚才说的预先设定值问题有些类似，只不过利用锁的方式，会造成部分请求等待。

缓存失效

引起这个问题的主要原因还是高并发的时候，平时我们设定一个缓存的过期时间时，可能有一些会设置1分钟啊，5分钟这些，并发很高时可能会出在某一个时间同时生成了很多的缓存，并且过期时间都一样，这个时候就可能引发一当过期时间到后，这些缓存同时失效，请求全部转发到DB，DB可能会压力过重。

那如何解决这些问题呢？

其中的一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

我们讨论的第二个问题时针对同一个缓存，第三个问题时针对很多缓存。

总结

1、缓存穿透：查询一个必然不存在的数据。比如文章表，查询一个不存在的id，每次都会访问DB，如果有人恶意破坏，很可能直接对DB造成影响。

2、缓存失效：如果缓存集中在一段时间内失效，DB的压力凸显。这个没有完美解决办法，但可以分析用户行为，尽量让失效时间点均匀分布。

当发生大量的缓存穿透，例如对某个失效的缓存的大并发访问就造成了缓存雪崩。

精彩问答

问题：如何解决DB和缓存一致性问题？

当修改了数据库后，有没有及时修改缓存。这种问题，以前有过实践，修改数据库成功，而修改缓存失败的情况，最主要就是缓存服务器挂了。而因为网络问题引起的没有及时更新，可以通过重试机制来解决。而缓存服务器挂了，请求首先自然也就无法到达，从而直接访问到数据库。那么我们在修改数据库后，无法修改缓存，这时候可以将这条数据放到数据库中，同时启动一个异步任务定时去检测缓存服务器是否连接成功，一旦连接成功则从数据库中按顺序取出修改数据，依次进行缓存最新值的修改。

问题：问下缓存穿透那块！例如，一个用户查询文章，通过ID查询，按照之前说的，是将缓存的KEY预先设置一个值，，如果通过ID插过来，发现是预先设定的一个值，比如说是“&&”，那之后的继续等待访问是什么意思，这个ID什么时候会真正被附上用户所需要的值呢？

我刚说的主要是咱们常用的后面配置，前台获取的场景。前台无法获取相应的key，则等待，或者放弃。当在后台配置界面上配置了相关key和value之后，那么以前的key &&也自然会被替换掉。你说的那种情况，自然也应该会有一个进程会在某一个时刻，在缓存中设置这个ID，再有新的请求到达的时候，就会获取到最新的ID和value。

问题：其实用Redis的话，那天看到一个不错的例子，双key，有一个当时生成的一个附属key来标识数据修改到期时间，然后快到的时候去重新加载数据，如果觉得key多可以把结束时间放到主key中，附属key起到锁的功能。

这种方案，之前我们实践过。这种方案会产生双份数据，而且需要同时控制附属key与key之间的关系，操作上有一定复杂度。

问题：多级缓存是什么概念呢？

多级缓存就像我今天之前给大家发的文章里面提到了，将Ehcache与Redis做二级缓存，就像我之前写的文章 http://www.jianshu.com/p/2cd6ad416a5a 提到过的。但同样会存在一致性问题，如果我们需要强一致性的话，缓存与数据库同步是会存在时间差的，所以我们在具体开发的过程中，一定要根据场景来具体分析，二级缓存更多的解决是，缓存穿透与程序的健壮性，当集中式缓存出现问题的时候，我们的应用能够继续运行。