引言

上期说到redis扩展，我们可以通过在Client端增加取模、随机、一致性哈希算法去实现，我们来做个大胆的实践推论。

客户端实现有问题吗

了不起上期所画的原理图中，可以清晰的看到，我们所实现的算法都在客户端。

现在假设我们有2个redis实例。

在真正的项目中，我们的微服务Client一般都有多个，有的甚至几十个，我们这里不说多了，就拿4个客户端。

client01、client02、client03、client04，这4个客户端是不是都要和后面的redis进行连接。client01和redis01连接、redis02连接，02、03、04同样也需要连接。

那么势必造成redis端的连接成本维护，只要客户端一多，连接成本直线上升。

增加代理层

如果你用过Nginx反向代理，那么你应该很轻松的就能联想到用代理来解决这个连接的问题。

每个redis实例只需要和代理进行连接就可以了。

而在代理层，我们只需要关注它的性能即可。

当大量client并发过来的时候，1台代理也撑不住了。

我们可以将代理层也反向代理了，加多一层负载均衡器。

通过使用LVS这个负载均衡器，在结合keepailved对LVS做一个主备，并且能监控到后端代理的健康状况。

这不过仅仅是我们自己的想法，这样一来反而有点因为技术而技术的赶脚了。

Redis作者本身也没有把Redis搞成多线程的，也不希望我们搞得更加复杂，那么我们前面讲了那么多，就是找一个代理层就可以了。

代理层应该是什么样

上期我们说到client端是有拆分算法的，那么我们就应该将算法放到代理层。

并且这个代理是无状态的。

我们去回忆下nginx，它就是无状态的，不管你前边和后边有多么复杂，有怎么样的数据逻辑交互，它都不关心。

也不需要关心，就只管做好自己代理转发的这个事情。

代理层应该具备的算法是：

• modula
• random
• kemata

在kemata一致性哈希算法中，又有多个可以实现的方式：

• one_at_a_time
• md5
• crc16
• crc32 (crc32 implementation compatible with libmemcached)
• crc32a (correct crc32 implementation as per the spec)
• fnv1_64
• fnv1a_64 (default)
• fnv1_32
• fnv1a_32
• hsieh
• murmur
• jenkins

实现redis代理的有哪些

• twemproxy
• predixy
• cluster
• codis

预分区

那么我们在思考下，这三种代理层算法或者模式好像都会有一个问题。

那就是不能作为数据库使用。

还有一种情况就是在我们使用过程中，redis实例的数量会随着我们业务的变化增加或者减少。

比如现在5月份有2台redis实例，到了年底由于业务的增加我们要扩展一台redis。

这个时候势必我们要迁移数据，就会对代理层的算法带来挑战，比如你之前使用的是hash，那么此次肯定就要所有数据重新hash了，也就是大家常听的rehash，要将数据重新分片。

那我们是不是也可以解决这种问题，比如我一开始就计划分区10个，至少到我业务增加到10台redis实例的时候，我都不用去改动，这个就叫做预分区。

什么意思，我来举个例子。

比如我们使用的是取模算法，我就取10个节点，数据分片是0.1.2.3.4.5.6.7.8.9。 一开始我就只有2台，我的数据分片是redis1有0.1.2.3.4，redis2有5.6.7.8.9。当我新增一台redis3时，只需要将redis1中分片3.4和redis2中分片8.9迁移到redis3中，就可以了。 此时重新建立mapping映射关系即可，迁移分片数据这个redis官方有操作，非常简单可靠，这样数据迁移就很方便了。

这种方式就不会影响你之前的算法，就是说你之前的算法找到当前这个数据在哪个分片，它这个数据还是在哪个分片里边，不会因为redis实例变化而重新改变算法。

redis cluster

接着上边的映射关系，其实redis自身连代理层都给你省了，有一个自身实现的无主模型。

也就是说redis客户端连谁都不重要，每个redis服务端的实例都是主。

它每个都有一样的算法比如hash%10，然后每个节点都保存着所有实例的映射关系，如图所示。

假如客户端要来get一个k1这个key，而这个k1经过哈希取模后得知数据存在第4个槽位或者是第四个分片。

当前客户端连着的是中间的redis2，指令到达redis2后经过算法一算，发现数据在分片4，然后发现自己没有分片4，在查询所有映射关系，找到分片4在redis3中。

返回给客户端说你去连接redis3获取，随后客户端切换到redis3，经过一样的步骤拿到分片4中的数据，然后返回。

总结

不过上边给的代理模式还是redis自身的cluster来说，都有一个问题，其实也不是问题，技术必然有取舍。

比如在redis cluster中我想要聚合2个key，一个key在分片3中，一个key在分片1中，你怎么办。

所以数据分治想聚合（取交集、并集、差集等）很难实现，当然了事务也很难实现，所以这就是redis作者的取舍，让计算向数据移动。

redis的特点就是快，要的就是效率，所以有些功能它就不支持，这是合理的。

经过本文的探讨，相信你对redis代理层、算法、redis自身的cluster模式有了一定的了解，下期我们接着聊。