每秒1w+分布式事務(wù)--dtm的Redis存儲(chǔ)性能測(cè)試分析
作者：葉東富
來(lái)源：SegmentFault 思否社區(qū)
概述
之前dtm給出了Mysql作為存儲(chǔ)引擎的性能測(cè)試報(bào)告，在一個(gè)普通配置的機(jī)器上，2.68w IOPS，4核8G機(jī)器上，能夠支持大約每秒900+分布式事務(wù)，能夠滿足大部分公司的業(yè)務(wù)需求。
此次帶來(lái)的是Redis存儲(chǔ)引擎的測(cè)試報(bào)告，在一個(gè)普通配置的機(jī)器上，能夠達(dá)到大約10800每秒的分布式事務(wù)能力，對(duì)比Mysql存儲(chǔ)，有10倍左右的性能提升，滿足絕大部分公司的業(yè)務(wù)需求。
下面我們來(lái)詳細(xì)說(shuō)明測(cè)試的步驟，并分析其中影影響性能的各個(gè)因素。
測(cè)試環(huán)境
下面的服務(wù)器都來(lái)自阿里云，地區(qū)為東京（外網(wǎng)訪問(wèn)比較方便）
Redis服務(wù)器：ecs.hfc6 4核8G CPU主頻為3.1 GHz/3.5 GHz 內(nèi)網(wǎng)收發(fā)包50萬(wàn)PPS ubuntu 20.04
兩臺(tái)應(yīng)用服務(wù)器：ecs.hfc6 8核16G CPU主頻為3.1 GHz/3.5 GHz 內(nèi)網(wǎng)收發(fā)包80萬(wàn)PPS ubuntu 20.04 redis5.x
測(cè)試步驟：
準(zhǔn)備好Redis
注意：涉及應(yīng)用服務(wù)器的，那么兩臺(tái)服務(wù)器都需要進(jìn)行相關(guān)操作
在應(yīng)用服務(wù)器上面準(zhǔn)備好Redis，這次因?yàn)榭紤]到極限性能，因此不采用docker安裝，而是采用apt install 安裝，運(yùn)行如下命令
apt update
apt install -y redis
# 修改/etc/redis/redis.conf，找到其中的bind，改為bind 0.0.0.0
systemctl restart redis-server
配置應(yīng)用服務(wù)器
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里面的配置刪除，因?yàn)槲覀儧](méi)有安裝mysql
啟動(dòng)bench服務(wù)器
`
LOG_LEVEL=warn go run bench/main.go redis
`
啟動(dòng)測(cè)試
`
ab -n 1000000 -c 10 "http://127.0.0.1:8083/api/busi_bench/benchEmptyUrl"
`
獲得結(jié)果
我這看到ab的結(jié)果顯示，每秒完成的操作數(shù)量?jī)膳_(tái)應(yīng)用服務(wù)器加總為10875
Redis性能分析
我們首先來(lái)看Redis本身的性能，影響它的因素是哪些，先看下面的這些測(cè)試數(shù)據(jù)：
`
redis-benchmark -n 300000 SET 'abcdefg' 'ddddddd'
`
每秒完成的請(qǐng)求數(shù)10w
`
redis-benchmark -h 內(nèi)網(wǎng)其他主機(jī)IP -p 6379 -n 300000 SET 'abcdefg' 'ddddddd'
`
每秒完成的請(qǐng)求數(shù)10w
從這上面的兩個(gè)結(jié)果看，本地Redis測(cè)試和遠(yuǎn)程Redis測(cè)試，性能差異并不明顯。我也測(cè)試過(guò)其他更多的命令，也未發(fā)現(xiàn)明顯差異，因此下面主要就測(cè)試本地Redis性能，不再比較本地和遠(yuǎn)程的差別。
`
redis-benchmark -n 300000 EVAL "redis.call('SET', 'abcdedf', 'ddddddd')" 0
`
Lua腳本每秒完成的請(qǐng)求數(shù)10w
`
redis-benchmark -n 300000 EVAL "redis.call('SET', KEYS[1], ARGS[1])" 1 'aaaaaaaaa' 'bbbbbbbbbb'
`
Lua腳本每秒完成的請(qǐng)求數(shù)10w
`
redis-benchmark -n 3000000 -P 50 SET 'abcdefg' 'ddddddd'
`
走Pipeline的話，每秒完成的請(qǐng)求數(shù)150w，這個(gè)性能對(duì)比單個(gè)Set操作有大幅提升。從這個(gè)數(shù)據(jù)和單個(gè)操作的對(duì)比看，Redis本身內(nèi)存操作開(kāi)銷不大，很多的開(kāi)銷花在了網(wǎng)絡(luò)IO上，因此批量任務(wù)能夠大幅提升吞吐量
`
redis-benchmark -n 300000 EVAL "for k=1, 10 do; redis.call('SET', KEYS[1], ARGS[1]); end" 1 'aaaaaaaaa' 'bbbbbbbbbb'
`
我們?cè)贚ua內(nèi)部，連續(xù)執(zhí)行10次Set，每秒完成的請(qǐng)求數(shù)6.1w，和只執(zhí)行1次Set差別沒(méi)有很大。這個(gè)結(jié)果在我們的預(yù)期之內(nèi)，因?yàn)榍懊鍼ipeline的結(jié)果顯示Redis的內(nèi)存操作開(kāi)銷大幅小于網(wǎng)絡(luò)。
dtm性能分析
dtm需要跟蹤全局分布式事務(wù)的進(jìn)度，我們以Saga舉例，大概涉及以下操作：
保存事務(wù)信息，含全局事務(wù)、事務(wù)分支、還有查找過(guò)期事務(wù)的索引，dtm用一個(gè)Lua腳本來(lái)完成這些操作
每個(gè)事務(wù)分支完成時(shí)，修改事務(wù)分支狀態(tài)。由于修改狀態(tài)時(shí)，需要確認(rèn)全局事務(wù)未回滾，避免回滾中的事務(wù)還往前執(zhí)行，因此dtm也用一個(gè)Lua腳本來(lái)完成
全局事務(wù)完成，修改全局事務(wù)為成功，此時(shí)也需要避免已超時(shí)回滾中的事務(wù)被覆蓋，也是一個(gè)Lua腳本
展望
