0 測(cè)試環(huán)境

測(cè)試機(jī)器配置

• mem: 128G
• disk: 800G ssd
• cpu: 32 core
• net: 10Gbps

版本

• redis: 3.2.11
• pika: 2.2.6

1 pika worker 線程數(shù)測(cè)試

pika 和 redis 不一樣，底層采用了 rocksdb 作為存儲(chǔ)引擎，線程數(shù)對(duì) pika 的性能影響較大

• 5 thread，100 client
• ops: GET SET
• value payload: 128 bytes

image

說(shuō)明：其中線程數(shù)為 0 的是 redis 的測(cè)試數(shù)據(jù)。

結(jié)論：pika 的 qps 基本是符合預(yù)期的，get 和 set 性能與線程數(shù)成正相關(guān)關(guān)系，當(dāng)線程數(shù)到達(dá) 8 時(shí)，再增加線程數(shù)，對(duì) get 性能提升幾乎沒(méi)有太多影響，同時(shí)對(duì) set 性能的增益也衰減較大；與 redis 相比，qps再線程數(shù)足夠的情況下可以做到比 redis 還要好，特別是 get 性能，可以達(dá)到 redis 的 2 倍以上。

2 pika redis get set 不同 payload 延時(shí)及 qps 對(duì)比

環(huán)境：

• 5 thread，100 client
• ops: GET SET
• pika workers：8 thread
• 1000000 次

image

結(jié)論： pika get 性能受 payload 影響較小，99.9% 的請(qǐng)求都能再 1ms 內(nèi)返回，且 qps 不受影響，set 性能受 palyload 影響較大，再 512 bytes 之前都能保持和redis 相當(dāng)?shù)男阅埽?9.9% 的請(qǐng)求能再 2-3 ms內(nèi)返回，和 redis 性能相當(dāng)；超過(guò) 512 bytes 后，性能下降較大，10k 的數(shù)據(jù)需要 300ms 左右才能完成 set 操作；而 redis 在 10 k 內(nèi)都能維持較好的性能，100k 以后 set 性能才會(huì)有較大的衰減。

3 不同操作與 redis 對(duì)比測(cè)試

• 5 thread，100 client
• pika workers：8 thread
• payload: 128 bytes

image

結(jié)論：大部分strings 相關(guān)的操作可以和redis 持平甚至更優(yōu)，list 相關(guān)操作性能較 redis差，hash 相關(guān)操作稍弱于 redis

4 持續(xù)寫(xiě)入測(cè)試

持續(xù)寫(xiě)入測(cè)試用于測(cè)試寫(xiě)入數(shù)據(jù)量大小對(duì)寫(xiě)入的性能衰減影響，測(cè)試過(guò)程中將 compact 操作調(diào)整至 凌晨 2-4 點(diǎn)。

• golang 協(xié)程數(shù)量: 50
• client 數(shù)量: 50
• ops: SET
• pika workers：8 thread
• payload: 128 bytes
• 持續(xù)寫(xiě)入數(shù)量: 7 * 10^9 次

結(jié)論：寫(xiě)入非常穩(wěn)定，基本都能穩(wěn)定再 每秒 10w-15w 條之間，寫(xiě)入數(shù)據(jù)量達(dá)到 700GB 以上，未發(fā)生寫(xiě)入性能衰減情況；需要注意的是，compact 對(duì)性能影響較大，compact 期間寫(xiě)入速度衰減到 2k-1w /s，每次持續(xù)大概 20-40s, 2-4 點(diǎn)過(guò)程中共發(fā)生 4 次 compact；

5 結(jié)論

5.1 優(yōu)點(diǎn)

• 節(jié)約成本，占用內(nèi)存較小，寫(xiě)入數(shù)據(jù)達(dá)到 700 GB 后，占用內(nèi)存在 7GB 左右
• 采用 snappy 壓縮數(shù)據(jù)，數(shù)據(jù)壓縮比較大，寫(xiě)入數(shù)據(jù)達(dá)到 700GB 后，占用磁盤(pán)約為 110 GB 左右
• 重新啟動(dòng)后恢復(fù)數(shù)據(jù)的過(guò)程很快，沒(méi)有redis 將數(shù)據(jù)加載到內(nèi)存的過(guò)程
• 多線程，不會(huì)像redis 一樣由于某個(gè)耗時(shí)操作導(dǎo)致后面操作阻塞的現(xiàn)象
• 自帶持久化
• 官方支持 docker 部署

5.2 缺點(diǎn)

• 嚴(yán)重依賴磁盤(pán) io 性能，注意不同實(shí)例寫(xiě)入同一塊盤(pán)時(shí)的影響
• lsm tree 普遍存在的 io 放大問(wèn)題
• 不支持 multi exec 的事務(wù)操作
• list 相關(guān)操作性能比 redis 差
• compact 時(shí)較大的影響寫(xiě)入性能
• 極限性能下對(duì) cpu 的壓力較大

5.3 結(jié)論

• 并不能完全替代 redis，與 redis 可以形成互補(bǔ)關(guān)系。
• 對(duì)延時(shí)及延時(shí)穩(wěn)定性要求高，或者用作 隊(duì)列等場(chǎng)景，還需使用redis
• 對(duì)于大部分?jǐn)?shù)據(jù)量較大，沒(méi)有復(fù)雜的 鏈表等集合操作的場(chǎng)景，可使用 pika

5.4 其他注意事項(xiàng)

• 關(guān)閉 slotmigrate (用于 codis slot 遷移)，對(duì)性能有部分提升
• compact 對(duì)寫(xiě)入性能影響較大，需要根據(jù)業(yè)務(wù)情況調(diào)整寫(xiě)入策略
• 讀取性能依賴系統(tǒng) cache 和 buffer
• 同步采用 binlog，官方提供 redis 向 pika 遷移工具
• 必須使用 ssd，hdd 性能太差