背景
Redis 作为一款纯内存的 Key-Value 存储，以其低延迟、高吞吐的特点，广泛应用于实时数据处理场景。然而，在实际使用中，Redis 存在两个主要痛点：
内存成本高：在数据存在冷热分布，对延迟要求在个位数毫秒级的应用，纯内存存储的成本非常高。
单实例容量受限：通常 Redis 单实例的内存配置不超过 32GB。这是由于 Redis 采用单工作线程模型，配置过大的内存会造成 CPU 资源浪费。此外，Redis 的 RDB 快照机制需要 fork 全量内存，大内存环境下会导致业务卡顿。
为了解决这些问题，市场上出现了很多持久化 Redis 的替代产品，例如 Pika、Kvrocks，云厂商也推出了类似产品，如阿里 Tair 和华为 Gemini。这些产品通常使用 RocksDB 等持久化 KV 存储作为底层存储，同时封装了与 Redis 兼容的计算引擎，来将 Redis 命令映射为 KV 接口。通过支持 SSD 存储，这类产品有效地降低了大内存的成本。但与此同时，由于持久化 Redis 需要与底层 KV 进行同步交互，受限于底层 KV 读写放大及合并压缩 (Compaction) 的影响，相比于 Redis，性能有所下降，延迟波动较大。
晨章KV是一款全新架构的Redis兼容，支持事务的分布式Key-Value数据库，不同于Pika等产品，晨章KV采用数据基层架构，实现了和底层RocksDB等KV存储的异步交互。这一方面降低了读写延时，因为数据基层是纯内存的，晨章KV可以像Redis一样，直接操作内存对象。另一方面增加了灵活性，用户可以自由选择底层KV存储的类型：RocksDB，分布式Cassandra和云原生的KV Serverless服务。用户也可以自由控制晨章KV内存层和底层KV存储的交互频率，可以每10秒做一次checkpoint，也可以每分钟做一次，所有的checkpoint都是增量的，只有变化的数据需要写入KV存储，如果同一个Key在checkpoint周期被更改了多次，只有最后一次需要写入到KV存储。这些优点，使得晨章KV在兼具热数据高性能读写的同时，支持将冷数据存储在SSD，实现降本增效。
接下来，我们通过商品库存场景，进行晨章KV和Pika的性能评测。
实验
软硬件资源
服务器：1台 32Core虚机。
测试机：1台 32Core虚机。
操作系统：Ubuntu 24
晨章KV版本：0.7.4
Pika版本：3.5.4
测试工具：memtier-benchmark
参数调整
晨章KV支持参数的自适应，用户可以基于{部署文档](https://www.eloqdata.com/晨章KV/install-from-binary)，配置晨章KV。注意，持久化Redis模式，需要打开`enable_data_store`选项，同时关闭WAL(Write-Ahead Logging)。
#config.ini# set it to none to turn off persistent storage for all databasesenable_data_store=on# set it to none to turn off WAL for all databasesenable_wal=off
基于Pika最佳实践调整Pika参数。其中，Pika的网络通信在thread-num
对应线程中执行，而数据写入和删除操作由配置文件中thread-pool-size
控制的线程池中执行，用户可以根据自己的场景对这两个参数进行调整，如果客户端执行的是一些比较重的操作，可以适量将thread-pool-size
调大，一般情况下我们建议thread-pool-size = 2 * thread-num
。
#pike.conf# The number of threads for running Pika.# It's not recommended to set this value exceeds# the number of CPU cores on the deployment server.thread-num : 10# Size of the thread pool, The threads within this pool# are dedicated to handling user requests.thread-pool-size : 20# write_binlog [yes | no]write-binlog : no
实验设计I 库存增删的性能测试
首先，我们通过 Python 脚本初始化 1,000,000 条商品库存数据，包含产品描述、名称、价格和库存信息。脚本如下：
import redisimport randomimport string# ConfigurationHOST = '172.31.35.24' # Replace with your server's hostPORT = 6379 # Replace with your server's portDB = 0 # Database numberPASSWORD = None # If your server requires a passwordNUM_PRODUCTS = 1000000# Connect to Redis-compatible serverdef get_redis_connection(): return redis.Redis(host=HOST, port=PORT, db=DB, password=PASSWORD)def generate_random_string(length=10): return ''.join(random.choices(string.ascii_letters + string.digits, k=length))def initialize_products(): r = get_redis_connection() pipeline = r.pipeline() batch_size = 1000 # Adjust based on available memory for i in range(1, NUM_PRODUCTS + 1): product_key = f'product:{i}' product_data = { 'name': f'Product {i}', 'description': generate_random_string(50), 'price': f"{random.uniform(10, 1000):.2f}", 'quantity': str(random.randint(1, 100)) } pipeline.hmset(product_key, product_data) # Execute the pipeline every 'batch_size' commands if i % batch_size == 0: pipeline.execute() print(f'Inserted {i} products') # Execute any remaining commands if NUM_PRODUCTS % batch_size != 0: pipeline.execute() print(f'Inserted {NUM_PRODUCTS} products') print('Initialization complete.')if __name__ == "__main__": initialize_products()
在晨章KV和Pika中，每个产品使用Hash进行存储，包含产品描述，名称，价格和库存信息。
HGETALL product:21) "description"2) "5YDbvUZAMmKKyHLyBYrQt9gOvglRdVJ5psQQKUMs0NvZn7IxqX"3) "name"4) "Product 2"5) "price"6) "211.73"7) "quantity"8) "487"
接下来使用memtier_benchmark
对库存增删操作进行模拟，增删通过HINCRBY
实现。实验输出包括吞吐量和不同分位延时（P50、P99、P999）的对比。我们分别测试 晨章KV 和 Pika 的性能。
需要指出的是，库存增删的实际场景并不能简单使用HINCRBY
,其无法保证原子性，也无法做库存量检查，比如购买的机票只剩3张，但是订单一次性购买4张机票，是应该被拒绝的。该逻辑可以在Redis中使用Lua脚本实现，但很遗憾，Pika并不支持加载Lua脚本(SCRIPT LOAD
)。晨章KV原生支持Lua脚本，我们会在第二个实验基于Lua实现库存增删，并对比晨章KV和Redis的性能。
结果
晨章KV：在 128 并发下，QPS 达到 93 万，P999 延时为 310 微秒。
memtier_benchmark --key-minimum=1 --key-maximum=1000000 -t 16 -c 8 --test-time=10 --hide-histogram -h 172.31.35.24 --key-prefix="product:" -p 6389 --command "HINCRBY __key__ quantity 1" --command-ratio 1 --command "HINCRBY __key__ quantity -1" --command-ratio 1ALL STATS===================================================================================================Type Ops/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec---------------------------------------------------------------------------------------------------Hincrbys 466653.20 0.13709 0.13500 0.23900 0.31100 29551.92Hincrbys 466647.70 0.13717 0.13500 0.23900 0.31100 30448.13Totals 933300.90 0.13713 0.13500 0.23900 0.31100 120000.11
Pika：在 128 并发下，QPS 为 41 万，P999 延时为 720 微秒。
memtier_benchmark --key-minimum=1 --key-maximum=1000000 -t 16 -c 8 --test-time=10 --hide-histogram -h 172.31.35.24 --key-prefix="product:" -p 9221 --command "HINCRBY __key__ quantity 1" --command-ratio 1 --command "HINCRBY __key__ quantity -1" --command-ratio 1ALL STATS===================================================================================================Type Ops/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec---------------------------------------------------------------------------------------------------Hincrbys 206581.93 0.30976 0.31100 0.43100 0.71900 13092.11Hincrbys 206576.93 0.30977 0.31100 0.43100 0.72700 13485.06Totals 413158.85 0.30977 0.31100 0.43100 0.72700 53154.33
从结果可以看出，晨章KV 在处理大规模并发下的库存增删操作时，性能显著优于 Pika，尤其在长尾延迟 (P999) 方面，晨章KV 的表现更加稳定，在高吞吐的同时仍保持较低的延迟。
上面的实验中，Pika 和 晨章KV 均未开启 fsync，因此在极端情况下存在丢失数据的风险。笔者未能找到 Pika 开启 fsync 的相关配置参数，但 Kvrocks 支持此选项。针对需要数据零丢失的场景，感兴趣的读者可以参考: https://www.eloqdata.com/blog/2024/08/25/benchmark-txlog，其中详细介绍了 晨章KV 和 Kvrocks 在开启 fsync 参数后的性能对比。
实验设计II 复杂业务逻辑的 Lua 脚本支持
本实验中，我们通过 Lua 脚本实现了更加复杂的库存增删逻辑。当库存量不足以满足订单请求时，拒绝该操作。
由于Pika不支持Lua Script Load
操作，我们选取Redis和晨章KV进行性能评测。
如下是 Lua 脚本：
-- adjust_stock.lua-- KEYS[1]: The product key (e.g., "product:1")-- ARGV[1]: The quantity to adjust (negative for decrement, positive for increment)local stock = tonumber(redis.call('HGET', KEYS[1], 'quantity'))local order_qty = tonumber(ARGV[1])if not stock then return {err = "Product not found"}endif (stock + order_qty) < 0 then return -1 -- Indicate insufficient stockelse local new_stock = redis.call('HINCRBY', KEYS[1], 'quantity', order_qty) return new_stockend
首先，同实验I，执行python init.py
加载数据。
接下来将adjust_stock.lua
加载到晨章KV和Redis中
redis-cli -h 172.31.35.24 -p 6379 SCRIPT LOAD "$(cat adjust_stock.lua)""760b9086bca7fe8923163f284c917f71e572c3b9"
最后分别执行memtier_benchmark
, 使用EVALSHA
执行LUA脚本，分别执行增删库存。
memtier_benchmark --distinct-client-seed --randomize --key-minimum=1 --key-maximum=1000000 -t 32 -c 1 --test-time=30 --hide-histogram -h 172.31.35.24 --key-prefix="product:" -p 6379 --command "EVALSHA 760b9086bca7fe8923163f284c917f71e572c3b9 1 __key__ 1" --command-ratio 1 --command "EVALSHA 760b9086bca7fe8923163f284c917f71e572c3b9 1 __key__ -1" --command-ratio 1
结果
晨章KV的结果如下：32 并发下，QPS 超过 10 万，P999 延时小于 1 毫秒。
ALL STATS===================================================================================================Type Ops/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec---------------------------------------------------------------------------------------------------Evalshas 54326.68 0.24149 0.22300 0.60700 0.84700 5508.59Evalshas 54323.08 0.24102 0.22300 0.60700 0.85500 5559.17Totals 108649.75 0.24126 0.22300 0.60700 0.85500 22135.51
Redis的结果如下：32 并发下，吞吐量仅为 8 千 QPS，延时显著高于晨章KV。
ALL STATS===================================================================================================Type Ops/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec---------------------------------------------------------------------------------------------------Evalshas 4060.63 3.93665 4.12700 14.27100 15.80700 411.73Evalshas 4058.03 3.94788 4.12700 14.20700 15.80700 415.28Totals 8118.66 3.94227 4.12700 14.20700 15.80700 1654.04
从结果来看，晨章KV的多线程架构能够在复杂业务逻辑场景下，显著提升吞吐量并减少延迟，而 Redis 的单线程模型限制了其处理复杂 Lua 脚本的能力，尤其在高并发场景中，吞吐量显著下降。
结论
通过本次评测，晨章KV在多个核心性能指标上展现了优异的表现：
在高并发的商品库存增删场景下，晨章KV显著优于 Pika，尤其是在长尾延迟 (P999) 方面表现稳定，适合需要低延迟的高吞吐场景。
在复杂业务逻辑支持方面，晨章KV 的多线程架构使其在执行 Lua 脚本时表现更好，而 Redis 的单线程模型在高并发环境下存在明显的性能瓶颈。（Pika不支持Lua Load Script）
晨章KV 凭借其灵活的架构设计和高性能表现，特别适合处理对实时性、低延迟、高吞吐量要求严格的应用场景，如电商平台、库存管理等高频业务。
如果您对晨章KV感兴趣，欢迎访问晨章KV官网 https://www.eloqdata.com/download ,了解更多详情并下载试用。您可以根据官方文档进行部署，体验其在高并发、低延迟场景中的卓越表现。
本文转载自“帅萌的杂谈铺”
