为什么Codis比较慢，但我们还要用它呢？

Codis 追求简洁的实现，我们没有针对内存进行优化，所以会比 twemproxy 还要多一倍拷贝。

Go 虽然使用 epoll，但是 IO 都不是直接完成的，而是通过 IO thread，所以需要更多的线程间通信和线程切换。

所以单 CPU 情况下， Codis 吞吐能到 twemproxy 的 1/2，redis 的 1/4，说明我的实现还是可以的。

Codis 是 Go 开发的，底层 IO 本质也是通过 epoll 实现的。Go 为开发带来了方便，但是所有的便利都是以牺牲性能作为代价的。

单 twemproxy：方便调整，性能不行

多 twemproxy：调整需要技巧，可能需要停止服，看具体业务需求，无论如何都很痛苦。

Codis？

适当的 CPU 就可以获得比 twemproxy 更好的性能和可靠性，同时具备横向扩展的能力

可动态调整。这一点就足够了。

对 redis 集群而言，CPU 和 内存，哪个更贵？而且通常 redis 集群 CPU 都是空闲的

如果你的业务需要 10G：没必要用 twemproxy 或者 Codis，影响心情，给自己添麻烦。

如果你的业务需要 400G：你可以选择 单/多 twemproxy + 多 redis，毕竟在相同吞吐下，twemproxy 比 codis 有更好地 CPU 利用率。

但是一旦你的业务需要迁移数据，比如机器上下线，容量调整，怎么办？