比如一个 Redis 实例,假设请求并发量很高,可能这台 Redis 撑不住了,那么两个问题:
1.Redis 并发量支撑大概是多少,如何评估
2.如果一个 Redis 实例支撑不住,有什么解决方案
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 ”的错误。 |