V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
tanteng
V2EX  ›  Redis

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

  •  1
     
  •   tanteng ·
    tanteng · 2016-03-05 16:10:32 +08:00 · 30241 次点击
    这是一个创建于 3170 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    第 1 条附言  ·  2016-03-05 17:10:25 +08:00
    如果同时操作一个 key ,如 set,get ,会有什么问题吗
    9 条回复    2016-03-06 10:21:58 +08:00
    line
        1
    line  
       2016-03-05 17:03:53 +08:00
    可以集群啊
    axb
        2
    axb  
       2016-03-05 17:22:12 +08:00
    1. 自带 benchmark 工具
    2. 读多加从,写多分多实例
    3. redis 本身不会有并发问题,但应用层如果不做并发控制会有数据不一致情况。
    wikimore
        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 最该考虑的我觉得还是容量问题,毕竟内存资源还是比较宝贵的
    realpg
        4
    realpg  
       2016-03-05 18:58:41 +08:00
    @wikimore
    内存可以很廉价的搞……
    1366 平台的双路主板三百多就能收到,一般都是 12 个内存插槽的。
    4G REG 内存基本已经 30~35 一根了,两颗 L5630 的低功耗 CPU 打包 50 元,多便宜……
    Infernalzero
        5
    Infernalzero  
       2016-03-05 19:06:09 +08:00
    redis 是流水线模式的
    publicAdmin
        6
    publicAdmin  
       2016-03-05 19:37:30 +08:00
    @tanteng “如果同时操作一个 key ,如 set,get ,会有什么问题吗”

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

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

    改用 Redis 客户端对象池,单个 Redis 客户端对多线程,容易出现问题。
    sagnitude
        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 一样
    sagnitude
        8
    sagnitude  
       2016-03-05 20:20:17 +08:00
    @sagnitude 修正一下,我目前在跑的 redis 集群服务器,测出来的是每核心 50K 左右(没跑满 CPU), 100K 是理论极限,估计不能达到, 85K 是估算的极限。我们认为继续优化意义不大,不如买服务器,就没继续研究了…
    Zoa
        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 ”的错误。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2816 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 13:27 · PVG 21:27 · LAX 05:27 · JFK 08:27
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.