redis cluster 性能探讨

一些总结：

1. 多线程对同一个 Key 操作时， Redis 服务是根据先到先作的原则，其他排队（可设置为直接丢弃），因为是单线程。 

2. 修改默认的超时时间，默认 2 秒。但是大部份的操作都在 30ms 以内。

3. 对集群来说，

3.1 一般来说普通的服务器都是 50K~100K 级别 GET 操作并发(每个核心)这个水平，根据具体的部署方法和配套工具，会有浮动 

对本机的普通 Redis （非集群）来说， GET 操作在 70K~120K 级别。

评估方法： Redis 官方提供了 C 的库；官方的 redis-benchmark 工具用的就是 C 的库， redis-benchmark 的结果大致可以当成 使用 C 语言开发可以获得的性能。 
复杂的操作，一个复杂操作，你可以大致认为是若干个 GET 操作的级别，你用 redis-benchmark 跑一下，大概按比例估算一下就行了。 
如果你用的是其他的语言，用官网推荐的 client library 写一个简单的 sample 跑一下，把 redis 服务器的 info 打出来。 
redis-cli info 里面有已处理命令的统计。 
就我的使用来说， Java 的 Jedis 连接 Redis 的性能（并发量）在 C 的 70%这个水平 

3.2 . 一个实例扛不住，就用集群，我目前在用官方的 redis-cluster ，目前平均下来每个核心可以提供 85K 的并发，极限在每核心 100K 左右(单位是一次 C 语言 GET) 

 一个观点： ” 我目前在跑的 redis 集群服务器，测出来的是每核心 50K 左右(没跑满 CPU)， 100K 是理论极限，估计不能达到， 85K 是估算的极限。我们认为继续优化意义不大，不如买服务器，就没继续研究了”

另外一篇关于 redis cluster百万QPS的挑战 ，里面讲了如何把redis实例帮到一个特定的CPU上，如何避免网卡软终端影响速度，如何分析gossip协议等，值得一看。

关于memcache和Redis的性能对比解释：

很多开发者都认为Redis不可能比Memcached快，Memcached完全基于内存，而Redis具有持久化保存特性，即使是异步的，Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因，目前想到的原因有这几方面。

• Libevent。和Memcached不同，Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis使用另外一个libevent高性能替代libev，但是作者还是坚持Redis应该小巧并去依赖的思路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。
• CAS问题。CAS是Memcached中比较方便的一种防止竞争修改资源的方法。CAS实现需要为每个cache key设置一个隐藏的cas token，cas相当value版本号，每次set会token需要递增，因此带来CPU和内存的双重开销，虽然这些开销很小，但是到单机10G+ cache以及QPS上万之后这些开销就会给双方相对带来一些细微性能差别(5)。

相关的技术文章：

1）Linux技巧:多核下绑定网卡中断到不同CPU（core）总结