Redis+TwemProxy(nutcracker)集群方案部署记录

原文链接：http://www.cnblogs.com/kevingrace/p/5685401.html

参考链接：http://blog.itpub.net/20625855/viewspace-1678566/

参考链接：http://www.cnblogs.com/haoxinyue/p/redis.html

参考链接：http://www.cnblogs.com/gomysql/p/4413922.html

参考链接：http://os.51cto.com/art/201408/447247_all.htm

Twemproxy 又称nutcracker ，是一个memcache、Redis协议的轻量级代理，一个用于sharding 的中间件。有了Twemproxy，客户端不直接访问Redis服务器，而是通过twemproxy 代理中间件间接访问。 Twemproxy 为 Twitter 开源产品，简单来说，Twemproxy是Twitter开发的一个redis代理proxy，类似于nginx的反向代理或者mysql的代理工具，如amoeba。Twemproxy通过引入一个代理层，可以将其后端的多台Redis或Memcached实例进行统一管理与分配，使应用程序只需要在Twemproxy上进行操作，而不用关心后面具体有多少个真实的Redis或Memcached存储。

Twemproxy的特性

举个小例子：

通过Twemproxy可以使用多台服务器来水平扩张redis服务，可以有效的避免单点故障问题。虽然使用Twemproxy需要更多的硬件资源和在redis性能有一定的损失（twitter测试约20%），但是能够提高整个系统的HA也是相当划算的。比如我所在的公司，只使用一台redis
server进行读写，但是还有一台slave server一直在同步这台生产服务器的数据。这样做就是为了防止这台单一的生产服务器出现故障时能够有一个"备胎"，可以把前端的redis数据读写请求切换到从服务器上,web程序因而不需要直接去访问mysql数据库。再借助于haproxy(又是proxy)或者VIP技术可以实现一个简单的HA方案，可以避免单点故障。但是这种简单的Master-Slave"备胎"方案不能扩张整个redis的容量（如果用系统内存大小衡量，且不考虑内存不足时把数据swap到磁盘上），最大容量由所有的redis
servers中最小内存决定的【木桶的短板】。

Twemproxy可以把数据sharding（碎片，这里是分散的意思）到多台服务器的上，每台服务器存储着整个数据集的一部分。因而，当某一台redis服务器宕机了，那么也就失去了一部分数据。如果借助于redis的master-slave replication，能保证在任何一台redis不能工作情况下，仍然能够保证能够存在一个整个数据集的完全覆盖，那么整个redis
group（或者称作cluster）仍然能够正常工作。

需要注意的是：

Twemproxy不会增加Redis的性能指标数据，据业界测算，使用twemproxy相比直接使用Redis会带来大约10%的性能下降。但是单个Redis进程的内存管理能力有限。据测算，单个Redis进程内存超过20G之后，效率会急剧下降。目前，建议单个Redis最好配置在8G以内；8G以上的Redis缓存需求，通过Twemproxy来提供支持。

-----------------------------------------------------------------------------------------------------------------------------------------------------

下面记录下Redis+Twemproxy(nutcracker)集群部署过程：

先简单看下集群架构



Twemproxy可以把多台redis server当作一台使用，扩大整个redis的容量，开发人员通过twemproxy访问这些redis servers 的时候不用关心到底去哪一台redis server读取k-v数据或者把k-v数据更新到数据集中。