共计 2590 个字符，预计需要花费 7 分钟才能阅读完成。
概述
之前 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
关注【分布式事务】公众号，获取更多分布式事务相干常识，同时能够退出咱们的社群
