Redis3.0集群方案分析

时间 2019-11-17

标签 redis3.0 redis 集群方案分析栏目 Redis 繁體版

原文原文链接

在Redis3.0集群出来以前，你们都对做者antirez寄予厚望，由于Redis历来没有让咱们失望过。如今Redis3.0集群出来了，网上出了不少评论文章，都说他的功能多么强大，包括下面这张图是完全把我欺骗了。html

等到我把Redis3.0客户端库hiredis编译好集成到公司系统，访问其中一台Redis3.0服务器竟然返回"MOVED 2318 10.12.8.156redis

:6379"，这才了解到访问其余Redis3.0服务器的Key须要二次定位，这就是Redis3.0所谓的ASK 转向/MOVED 转向机制，这绝对数据库

是一个大坑，网上既然没有人说出来，若是我不站出来，会有人继续掉进这个大坑。缓存

Redis最初的使命是用高效的内存取代复杂繁重的数据库，若是从缓存服务器获取一个Key要通过二次定位，访问时间是原来单机服务器

缓存服务器的两倍，那样咱们还不如直接用数据库呢。并发

鉴于Redis3.0所谓的ASK 转向/MOVED 转向机制，网上推出了JAVA版的Redis3.0客户端库jedis、C++版的Redis3.0客户端框架

库ACL，他们都支持根据Redis服务器居返回"MOVED"信息进行二次定位数据访问，并且还有在主备切换的状况下访问备机的功能，分布式

正常状况下Redis3.0集群要部署3台主机和3台备机，这样客户端就要同时维持这6台服务器的长链接，像咱们公司的系统有上百个性能

进程，一个线程就要维持6台缓存服务器的长链接，一个进程拥有多个线程，总的算起来差很少上千个缓存服务器的长链接，这无异测试

于饮鸩止渴。

最理想的方案就是Redis3.0 Cluster加入集群代理功能，实现客户端经过任何一台缓存服务器一次性定位全部的Key，固然这要等待

antirez发力，短时间看彷佛不大可能；客户端优化方案就是加入计算Key的哈希槽值的逻辑，加载服务器端的哈希槽存储逻辑，来实现一次

性定位访问缓存服务器，这样作的缺陷仍是避免不了多台缓存服务器的长链接，同时一旦缓存服务器发生数据迁移和主备切换的状况，客

户端就得变动哈希槽存储逻辑。

俗话说，自力更生，丰衣足食。咱们为什么不本身开发一个Redis缓存集群代理服务器系统，取名为RedisClusterProxy，多牛B啊！

系统构思：系统并发接收客户端请求，计算Key的哈希槽值，加载服务器端的哈希槽存储逻辑，转发到对应的缓存服务器，并将缓存服

务器的返回值回传给客户端，这样客户端只要访问集群代理系统，实现一次性定位访问，效率与单台缓存服务器相差无几，协议仍是采

用Redis3.0客户端和服务端的通讯协议，这样不用对Redis3.0的客户端和服务器源码作任何改动，另外将服务器端的哈希槽存储逻辑

定时动态加载到系统，一旦缓存服务器发生数据迁移和主备切换的状况就不会发生访问定位不许确的问题，就算antirez将集群代理功能

加入Redis3.0，咱们的客户端系统也不用作任何更改。

RedisClusterProxy(http://download.csdn.net/detail/g55395162/8844927)系统初步开发花了一个星期时间，相关功能和框架已经实现，能够编译测试，后续进一步优化。

上面链接为试用版，正式版解决了试用版的全部BUG，稳定性和并发性能更高，并实现缓存服务器主备切换同步更新链接，采用多进程，分布式部署，什么Codis,twemproxy等均可以比下去，有须要的能够联系我13640963760。