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

每秒 1w+分布式事务--dtm 的 Redis 存储性能测试分析

  •  
  •   dongfuye1 · 149 天前 · 457 次点击
    这是一个创建于 149 天前的主题,其中的信息可能已经有所发展或是发生改变。

    概述

    之前 dtm 给出了 Mysql 作为存储引擎的性能测试报告,在一个普通配置的机器上,2.68w IOPS ,4 核 8G 机器上,能够支持大约每秒 900+分布式事务,能够满足大部分公司的业务需求。

    此次带来的是 Redis 存储引擎的测试报告,在一个普通配置的机器上,能够达到大约 10800 每秒的分布式事务能力,对比 Mysql 存储,有 10 倍左右的性能提升,满足绝大部分公司的业务需求。

    下面我们来详细说明测试的步骤,并分析其中影影响性能的各个因素。

    测试环境

    下面的服务器都来自阿里云,地区为东京(外网访问比较方便)

    Redis 服务器:ecs.hfc6 4 核 8G CPU 主频为 3.1 GHz/3.5 GHz 内网收发包 50 万 PPS ubuntu 20.04

    两台应用服务器:ecs.hfc6 8 核 16G CPU 主频为 3.1 GHz/3.5 GHz 内网收发包 80 万 PPS ubuntu 20.04 redis5.x

    测试步骤:

    准备好 Redis

    注意:涉及应用服务器的,那么两台服务器都需要进行相关操作

    在应用服务器上面准备好 Redis ,这次因为考虑到极限性能,因此不采用 docker 安装,而是采用 apt install 安装,运行如下命令

    apt update
    apt install -y redis
    # 修改 /etc/redis/redis.conf ,找到其中的 bind ,改为 bind 0.0.0.0
    systemctl restart redis-server
    

    配置应用服务器

    apt update
    apt install -y git
    git clone https://github.com/dtm-labs/dtm.git && cd dtm && git checkout 5907f99 && cd bench && make
    

    配置 dtm

    修改 dtm 目录下的 conf.sample.yml ,配置使用 Redis ,例如:

    Store:
      Driver: 'redis'
    	Host: 'redis ip'
    	Port: 6379
    	
    # 另外再把 ExamplesDB 里面的配置删除,因为我们没有安装 mysql
    

    启动 bench 服务器

    LOG_LEVEL=warn go run bench/main.go redis

    启动测试

    ab -n 1000000 -c 10 "http://127.0.0.1:8083/api/busi_bench/benchEmptyUrl"

    获得结果

    我这看到 ab 的结果显示,每秒完成的操作数量两台应用服务器加总为 10875

    Redis 性能分析

    我们首先来看 Redis 本身的性能,影响它的因素是哪些,先看下面的这些测试数据:

    redis-benchmark -n 300000 SET 'abcdefg' 'ddddddd'

    每秒完成的请求数 10w

    redis-benchmark -h 内网其他主机 IP -p 6379 -n 300000 SET 'abcdefg' 'ddddddd'

    每秒完成的请求数 10w

    从这上面的两个结果看,本地 Redis 测试和远程 Redis 测试,性能差异并不明显。我也测试过其他更多的命令,也未发现明显差异,因此下面主要就测试本地 Redis 性能,不再比较本地和远程的差别。

    redis-benchmark -n 300000 EVAL "redis.call('SET', 'abcdedf', 'ddddddd')" 0

    Lua 脚本每秒完成的请求数 10w

    redis-benchmark -n 300000 EVAL "redis.call('SET', KEYS[1], ARGS[1])" 1 'aaaaaaaaa' 'bbbbbbbbbb'

    Lua 脚本每秒完成的请求数 10w

    redis-benchmark -n 3000000 -P 50 SET 'abcdefg' 'ddddddd'

    走 Pipeline 的话,每秒完成的请求数 150w ,这个性能对比单个 Set 操作有大幅提升。从这个数据和单个操作的对比看,Redis 本身内存操作开销不大,很多的开销花在了网络 IO 上,因此批量任务能够大幅提升吞吐量

    redis-benchmark -n 300000 EVAL "for k=1, 10 do; redis.call('SET', KEYS[1], ARGS[1]); end" 1 'aaaaaaaaa' 'bbbbbbbbbb'

    我们在 Lua 内部,连续执行 10 次 Set ,每秒完成的请求数 6.1w ,和只执行 1 次 Set 差别没有很大。这个结果在我们的预期之内,因为前面 Pipeline 的结果显示 Redis 的内存操作开销大幅小于网络。

    dtm 性能分析

    dtm 需要跟踪全局分布式事务的进度,我们以 Saga 举例,大概涉及以下操作:

    • 保存事务信息,含全局事务、事务分支、还有查找过期事务的索引,dtm 用一个 Lua 脚本来完成这些操作
    • 每个事务分支完成时,修改事务分支状态。由于修改状态时,需要确认全局事务未回滚,避免回滚中的事务还往前执行,因此 dtm 也用一个 Lua 脚本来完成
    • 全局事务完成,修改全局事务为成功,此时也需要避免已超时回滚中的事务被覆盖,也是一个 Lua 脚本

    那么一个具备两个事务分支的全局事务在 Redis 上的理论开销大约是 4 个 Lua 脚本的开销,那么从前面每秒能够完成大约 6w 个简单 Lua 脚本来看,每秒最理想能够完成 1.5w 个分布式事务。由于实际的 Lua 脚本比我们测试的更复杂,传输的数据量更大,因此最终每秒完成 1.08w 个事务,已经是差不多的性能极限值。当达到 1.08w 每秒的事务性能时,观测到 Redis 的 CPU 已经是 100%,到了性能瓶颈。

    展望

    每秒 1w 事务已经是非常高的性能,足够应对绝大多数的场景。包括消息队列、秒杀等。

    当 Redis 能够支撑这么大的事务量时,如果是长时间这么大的事务量,那么 redis 的存储空间很快就不够了,后续可能添加选项,允许及时清理掉已完成的事务

    未来 dtm 的性能是否还能提高?我们可以从两方面看:

    一个是在目前单进程的情况下,dtm 能够达到 1w 事务每秒,在 redis6.0 上,官方的数据显示,4CPU 性能大约提升 150%,这样的话 dtm 预计能够支撑 2.5w 事务每秒。

    另一个是 dtm 往集群的方向发展,提供集群能力,允许动态扩容等。这方面需要看未来的使用情况,再做相关规划。

    项目地址

    关于分布式事务更多的理论知识与实践,可以访问以下项目和公众号:

    https://github.com/dtm-labs/dtm

    关注 [分布式事务] 公众号,获取更多分布式事务相关知识,同时可以加入我们的社群

    目前尚无回复
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4203 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 591ms · UTC 02:25 · PVG 10:25 · LAX 19:25 · JFK 22:25
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.