上面用了“几乎”这个词，因为有些命令，比如"keys *"就不支持
很快部署了好了twemproxy和后面跟着的四个Redis机器，压测发现，后面的四台Redis的CPU使用率降下来了，但新问题来了，twemproxy也是单进程的！性能瓶颈又跑到twemproxy上来了！
方案三：
对Redis的访问分为写和读，类似生产者和消费者， 再仔细分析，发现写的少，读的相对多些，这就可以将读写分离，写的往主的写，读的从备的读，遇到的情况恰好是读和写是两个服务，做到读写分离通过改下配置信息就可以很简单的做到，，这样分散了主Redis的压力。
这里对Redis的访问压力有好转，但不是长久之计，比如遇到举办活动， 数据量增大时，还是会有性能的风险。
最终采用的方法是综合方案二和三，如下图所示：
这种方法对现有的服务改动最小，可以有效缓解redis压力的问题
producer端和consumer端的twemproxy使用的hash算法要求一致，不然找不到key了。
如果把方案一也加进来，会比较复杂，暂时用不到。
以上就是redis怎么扩容的详细内容，更多文章请关注木庄网络博客！
相关阅读 >>
更多相关阅读请进入《redis扩容》频道 >>
数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
