无底洞优化

2010年，Facebook的Memcache节点已经达到了3000个，承载着TB级别的缓存数据。但开发和运维人员发现了一个问题，为了满足业务要求添加了大量新Memcache节点，但是发现性能不但没有好转反而下降了，当时将这种现象称为缓存的“无底洞”现象。

那么为什么会产生这种现象呢，通常来说添加节点使得Memcache集群性能应该更强了，但事实并非如此。键值数据库由于通常采用哈希函数将key映射到各个节点上，造成key的分布于业务无关，但是由于数据量和访问量的持续增长，造成需要添加大量节点做水平扩容，导致键值分布到更多的节点上，所以无论是Memcache还是Redis的分布式，批量操作通常需要从不同节点上获取，相比于单机批量操作只涉及一次网络操作，分布式批量操作会涉及多次网络时间。

下图展示了在分布式条件下，一次mget操作需要访问多个Redis节点，需要多次网络时间。

2019-05-19-16-45-51.png

而当一个节点存储批量操作只需要一次网络时间，由于所有键值都集中在一个节点上，所以一次批量操作只需要一次网络时间。无底洞问题分析：

• 客户端一次批量操作会设计多次网络操作，也就意味着批量操作会随着节点的争夺，耗时会不断增大。

• 网络连接数变多，对节点的性能也有一定影响。

用一句通俗的话总结就是，更多的节点不代表更高的性能，所谓“无底洞”就是说投入越多不一定产出越多。但是分布式又是不可以避免的，因为访问量和数据量越来越大，一个节点根本扛不住，所以如何高效地在分布式缓存中批量操作是一个难点。

下面介绍如何在分布式条件下优化批量操作。在介绍具体的方法之前，我们来看一下常见的IO优化思虑：

• 命令本身的优化，例如优化SQL语句等。

• 减少网络通信次数。

• 降低接入成本，例如客户端使用长连/连接池、NIO等。

这里我们假设命令、客户端连接已经为最优，重点讨论减少网络操作次数。以Redis批量获取n个字符串为例，有三种实现方法：

• 客户端n次get：n次网络+n次get命令本身。

• 客户端1次pipeline get：1次网络+n次get命令本身。

• 客户端1次mget：1次网络+1次mget命令本身。

上面已经给出了IO的优化思路以及单个节点的批量操作优化方式，下面我们将结合Redis Cluster的一些特性对四中分布式的批量操作方式进行说明。

1. 串行命令

   由于n个key是比较均匀地分布在Redis Cluster的各个节点上，因此无法使用mget命令一次性获取，所以通常来讲要获取n个key的值，最简单的方法就是逐次执行n个get命令，这种操作时间复杂度较高，它的操作时间=n次网络时间+n次命令时间，网络次数是n。很显然这种方案不是最优的，但是实现起来比较简单。

2. 串行IO

   Redis Cluster使用CRC16算法计算出散列值，再取对16383的余数就可以算出slot值，同时10.5节我们提到过Smart客户端会保存slot和节点的对应关系，有了这两个数据就可以将属于同一个节点的key进行归档，得到每个节点的key字列表，之后对每个节点执行mget或者Pipeline操作，它的操作时间=node次网络时间+n次命令时间，网络次数是node的个数，这种方案比第一种要好很多，但是如果节点数太多，还是有一定的性能问题。

3. 并行IO

   此方案是将方案2中的最后一步改为多线程执行，网络次数虽然还是节点个数，但由于使用多线程网络时间变为O(1)，这种方案会增加编程的复杂度。它的操作时间为：

   max_slow(node网络时间)+n次命令时间

4. hash_tag实现

   10.5节介绍了Redis Cluster的hash_tag功能，他可以将多个key强制分配到一个节点上，它的操作时间=1次网络时间+n次命令时间。

上面已经对批量操作的四中方案进行了介绍，最后通过下表来对四种方案的优缺点、网络IO次数进行一个总结。