虽然大量用户使用了大型Redis节点集群，从项目本身到角度来看，Redis仍然是一个单实例业务。
关于项目的分布式化我有一个想法，可以不需要再评估Redis的任何多线程版本：我认为从Redis的角度一个CPU核心就像一台计算机，因此在多核心上扩展与在一个多计算机集群上扩展是同样到概念。多实例是无共享的体系机构。只要我们有一个*可靠的*方式进行分片， 任何事都是合理的 :-)
这是为什么Redis Cluster将成为2013年Redis的主要焦点的原因，现在Redis 2.6已经发布并且显示出非常好到稳定性和成熟度，正是合适的机会来专注于Redis Cluster，Redis Sentinel和其它期待已久的改进（局部重新同步）。
然而事实是Redis Cluster还不适应于生产环境，仍需要几个月到工作要做。用户需要在多个实例上做数据分片，以分担负载，特别是使用很多计算机来为数据提供大量的RAM——这个需求依然存在。
目前惟一的选择是客户端分片。客户端分片有一个优势：由于没有客户端和节点之间的中间层，不需要对请求进行路由，所以是一个可扩展的配置（主要是线性扩展）。然而要稳定的实现（客户端分片）需要进行一些优化，需要一个同步客户端配置的方式，也需要客户端支持一致性哈希或其它分区算法。
有一个重大消息来自Twitter，世界最大的Redis集群之一部署在Twitter用于为用户提供时间轴数据。所以毫不奇怪这篇文章讨论的项目来自Twitter Open Source部门。
Twemproxy
---
Twemproxy是一个快速的单线程代理程序，支持Memcached ASCII协议和更新的Redis协议：
它全部用C写成，使用Apache 2.0 License授权。
项目在Linux上可以工作，而在OSX上无法编译，因为它依赖了epoll API.
我的测试环境为Ubuntu 12.04桌面版。
好吧，闲话少叙。twemproxy到底做了什么？（注：我将关注Redis到部分，但是该项目也可以对memcached做相同到事情）
1) 在客户端和众多Redis实例间作为代理。
2) 在配置的Redis实例之间进行自动到数据分片。
3) 支持一致性哈希，支持不同到策略和哈希方法。
Twemproxy最了不起的地方就在于它能在节点失败的时候卸载它，然后可以在一段时间以后重新尝试（随即）连接，又或者可以严格按照配置文件中写的键与服务器之间对应关系进行连接。这意味着Twemproxy能胜任把Redis当做数据存储（不能容忍节点未命中）的场景，也能够胜任当做缓存来使用，那些允许（它意味着少量，不是说低质量）未命中且高可用的场景。
总结来说就是：如果你能容忍未命中，那么当有节点失败你的数据也许会存储到其他节点，所以它会是弱一致性的。另一方面，如果你不能容忍未命中，那么你需要一个拥有高可用的实例的方案，例如使用Redis监控的失败自动切换功能。