Redis 性能评估及一台 Redis 承受不住并发量怎么办？

[tanteng]

比如一个 Redis 实例，假设请求并发量很高，可能这台 Redis 撑不住了，那么两个问题：

1.Redis 并发量支撑大概是多少，如何评估

2.如果一个 Redis 实例支撑不住，有什么解决方案

[line]

可以集群啊

[axb]

1. 自带 benchmark 工具
2. 读多加从，写多分多实例
3. redis 本身不会有并发问题，但应用层如果不做并发控制会有数据不一致情况。

[wikimore]

1.评估光用 benchmark 不可靠，得具体根据你的业务使用场景，如使用 string 还是 list ，或者是 zset ， list 和 zset 长度不同有些操作的单次耗时是不同的，你得预估你的数据量，然后自己写测试代码，这样最靠谱
2.一个 redis 撑不住可以用多个，具体两种策略，一个是客户端路由，一个是服务端加代理层，由服务端路由，如 codis
3.redis 内部是单线程的，所以不会有并发问题，即使你业务代码是并发的，但是到 redis 那里，你可以理解成一个队列，先到先做，顺序执行

PS:redis 最该考虑的我觉得还是容量问题，毕竟内存资源还是比较宝贵的

[realpg]

@wikimore
内存可以很廉价的搞……
1366 平台的双路主板三百多就能收到，一般都是 12 个内存插槽的。
4G REG 内存基本已经 30~35 一根了，两颗 L5630 的低功耗 CPU 打包 50 元，多便宜……

[Infernalzero]

redis 是流水线模式的

[publicAdmin]

@tanteng “如果同时操作一个 key ，如 set,get ，会有什么问题吗”

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

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

改用 Redis 客户端对象池，单个 Redis 客户端对多线程，容易出现问题。

[sagnitude]

有很大的需求的话，可以用集群，或者代理层

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%这个水平

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

3. redis 的话，是单线程的，你的同时操作总会有一个先后顺序，所以没有问题

如果是 redis-cluster ，它只提供最终一致性，也就是说你在 A 服务器上 SET ，你立刻在 B 服务器上 GET 有可能拿不到这个值，但是它保证最后你的 GET 和 SET 请求会和普通的 redis 一样，按照时间顺序被处理，最后的结果和使用单实例 Redis 一样

[sagnitude]

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

[Zoa]

@publicAdmin 根据这里（ http://www.redis.cn/topics/clients.html ）的文档说法：“该顺序是由客户端 socket 文件描述符的数字大小及核心报告客户端事件的顺序决定的，因此顺序可以看成不确定的。”，顺序在大体上会呈“先到先作的原则”，但小处上呈现的应该是无序性。
@tanteng 如果考虑“ TCP 的 TIME_WAIT ”问题，我在 MBP 上测试的结果是 17000 左右的请求数就会出现“ Can't assign requested address ”的错误。