Redis 性能评估及一台 Redis 承受不住并发量怎么办？
tanteng · tanteng · 2016-03-05 16:10:32 +08:00 · 30286 次点击这是一个创建于 3210 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如一个 Redis 实例，假设请求并发量很高，可能这台 Redis 撑不住了，那么两个问题：
1.Redis 并发量支撑大概是多少，如何评估
2.如果一个 Redis 实例支撑不住，有什么解决方案
第 1 条附言 · 2016-03-05 17:10:25 +08:00
如果同时操作一个 key ，如 set,get ，会有什么问题吗
 |
1
line 2016-03-05 17:03:53 +08:00
可以集群啊
|
 |
2
axb 2016-03-05 17:22:12 +08:00
1. 自带 benchmark 工具
2. 读多加从，写多分多实例 3. redis 本身不会有并发问题，但应用层如果不做并发控制会有数据不一致情况。 |
 |
3
wikimore 2016-03-05 18:07:13 +08:00  1
1.评估光用 benchmark 不可靠，得具体根据你的业务使用场景，如使用 string 还是 list ，或者是 zset ， list 和 zset 长度不同有些操作的单次耗时是不同的，你得预估你的数据量，然后自己写测试代码，这样最靠谱
2.一个 redis 撑不住可以用多个，具体两种策略，一个是客户端路由，一个是服务端加代理层，由服务端路由，如 codis 3.redis 内部是单线程的，所以不会有并发问题，即使你业务代码是并发的，但是到 redis 那里，你可以理解成一个队列，先到先做，顺序执行 PS:redis 最该考虑的我觉得还是容量问题，毕竟内存资源还是比较宝贵的 |
 |
4
realpg 2016-03-05 18:58:41 +08:00
@wikimore
内存可以很廉价的搞…… 1366 平台的双路主板三百多就能收到，一般都是 12 个内存插槽的。 4G REG 内存基本已经 30~35 一根了，两颗 L5630 的低功耗 CPU 打包 50 元，多便宜…… |
 |
5
Infernalzero 2016-03-05 19:06:09 +08:00
redis 是流水线模式的
|
 |
6
publicAdmin 2016-03-05 19:37:30 +08:00
@tanteng “如果同时操作一个 key ，如 set,get ，会有什么问题吗”
多线程对同一个 Key 操作时， Redis 服务是根据先到先作的原则，其他排队（可设置为直接丢弃），因为是单线程。 修改默认的超时时间，默认 2 秒。但是大部份的操作都在 30ms 以内。 改用 Redis 客户端对象池，单个 Redis 客户端对多线程，容易出现问题。 |
 |
7
sagnitude 2016-03-05 20:08:45 +08:00 1
有很大的需求的话，可以用集群，或者代理层
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 一样 |
|
8
sagnitude 2016-03-05 20:20:17 +08:00
@sagnitude 修正一下，我目前在跑的 redis 集群服务器，测出来的是每核心 50K 左右(没跑满 CPU)， 100K 是理论极限，估计不能达到， 85K 是估算的极限。我们认为继续优化意义不大，不如买服务器，就没继续研究了…
|
 |
9
Zoa 2016-03-06 10:21:58 +08:00
@publicAdmin 根据这里（ http://www.redis.cn/topics/clients.html ）的文档说法：“该顺序是由客户端 socket 文件描述符的数字大小及核心报告客户端事件的顺序决定的，因此顺序可以看成不确定的。”，顺序在大体上会呈“先到先作的原则”，但小处上呈现的应该是无序性。
@tanteng 如果考虑“ TCP 的 TIME_WAIT ”问题，我在 MBP 上测试的结果是 17000 左右的请求数就会出现“ Can't assign requested address ”的错误。 |
Select Language