纯内存设计，并与 Redis/Valkey 的 wire protocol 完全兼容（RESP2/RESP3、PSYNC、Cluster/Sentinel）。
通过紧凑的元数据与对象编码降低单 key 开销；HybridLog 使用日志结构化的不可变 block，实现透明的内存压缩。
前台请求维持亚毫秒级延迟；后台维护任务细粒度、可中断，以保障尾延迟。
在互联网类生产负载上的实践结果：在保持 Redis 行为一致的前提下，全量规模可实现约 40–60% 的内存降低。
存储引擎：Engula 用更紧凑、可压缩的引擎替换 Redis/Valkey 的内存对象存储，同时保持命令行为与协议一致。
权衡：用可控的 CPU 开销做实时压缩/解压以节省内存；读写仍发生在内存中并保持亚毫秒级延迟。
恢复：日志结构化的内存布局更契合快照流程，可显著提升冷启动与全量同步速度。
运维与演进：模块化集成点使 Engula 能快速对齐新的 Valkey 版本发布，而无需修改客户端。
是的。Engula 的后台保存进程总是在服务器不处于命令执行期间进行 fork，因此在内存中被视为原子的命令，从磁盘快照视角也同样是原子的。
Engula 在多核扩展方式上与 Redis/Valkey 非常接近：
网络卸载的 I/O 线程：Engula 复用 Redis/Valkey 的线程模型。通过启用并扩展 I/O 线程，可将客户端读写工作卸载到独立线程，使主线程聚焦命令执行。io-threads 的配置方式与 Redis/Valkey 一致。
每个线程内的协程：在主线程与各 I/O 线程内部，Engula 增加了轻量、可中断的协程。后台任务（例如对 Immutable Zone 中的 block 周期性压缩与替换）会拆分为小协程，运行在既有 Redis/Valkey 线程中，并按优先级调度；在可能的情况下，会优先派发到非主 I/O 线程以降低对前台延迟的影响。
配置兼容：Engula 的多核使用方式与 Redis/Valkey 的配置一致。启用并调优 io-threads，Engula 通过 I/O 线程与协程化后台工作来利用更多 CPU 核心。
Engula 可支持最多 2^32 个 key，并已在单实例至少 2.5 亿 key 的规模上完成测试。
每个 Hash、List、Set 与 Sorted Set 均可支持最多 2^32 个元素。
实际可用上限通常由可用内存决定。
如果您使用了带 TTL（expire）的 key，这是正常现象：
第一次与副本同步时，主实例会生成 RDB 文件。
RDB 不会包含那些在主实例上已过期（逻辑过期）但仍暂存于内存中的 key。
这些 key 即便逻辑上已过期，仍可能暂时留在主实例内存中；它们不再被视为“存在”，其内存会在后续增量回收或在访问时触发回收。尽管它们不属于逻辑数据集，但在 INFO 与 DBSIZE 中仍可能被计入统计。
副本加载主实例生成的 RDB 时，这部分逻辑过期 key 不会被加载。
因此，当存在大量 TTL key 时，副本侧常会看到更少的 key 数量。逻辑上主副数据集是一致的，这种差异主要是统计口径与回收时机造成的短暂现象。
说明： 本 FAQ 会持续更新。如有未覆盖的问题，请联系 support@engula.cn。