Redis3.0集群方案分析

在Redis3.0集群出来之前，大家都对作者antirez寄予厚望，因为Redis从来没有让我们失望过。现在Redis3.0集群出来了，网上出了很多评论文章，都说他的功能多么强大，包括下面这张图是彻底把我欺骗了。

    

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

: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。