Lavik
精选 · 深度解读
将 300 节点 Redis 集群迁移到仅 3 个 Lavik 节点
为何不断为内存购买服务器？Lavik 将 NVMe SSD 容量与超过 DRAM 上 Redis 的吞吐结合，深入解析从 300 节点整合到三节点的架构、实测与成本。
阅读全文LAVIK / BLOG
架构
探索 Lavik 的架构。
更多文章
评估那个停止读取响应的客户端
NVMe 上的活动历史可以超过内存容量，而 API 仍然只返回小页面。从响应边界评估 Redis 客户端兼容性：解码、范围语义、取消请求与慢消费者。
Stream 很短，待确认列表却未必
通过一个假设的图像处理队列，理解为什么重放保留期、待确认投递和物理存储需要分别规划，以及 Lavik 的 NVMe Stream 如何支撑这种设计。
让商品目录缓存能够完整替换一条记录
目录刷新既要更新值，也要移除过时字段。以这一应用约定组织首次 Lavik 评估，让软件包和存储路径选择服务于具体设计。
缓存对象变大，读取窗口可以保持很小
以定长记录组成的时间线缓存为例，说明如何利用 Lavik 的 NVMe 值存储与 String 分段机制，在保留更多内容的同时，让局部读取和更新只涉及所需片段。
Lavik 0.1.0 正式发布：值存于 NVMe SSD，性能超越 DRAM 上的 Redis
首个稳定版本带来基于 NVMe SSD 的 Redis 兼容存储、大字符串 8 KiB 分段、集合优化、内置 Lavik Admin，以及更完善的托管部署能力。
在 Lavik 0.1.0 中使用 Redis 连接池
保留 Redis 客户端，将值容量移到 NVMe SSD。选择正确路由模式、一致初始化池内连接，并根据应用需求规划并发。
服务器还有空闲内存，缓存为何已无法继续增长
规划 Lavik 缓存增长，既要计算整台服务器的容量，也要计算每个工作线程的预算。一个假设的键分布案例说明：NVMe 仍有空间、总内存仍有余量，并不保证下一个键能被接纳。
为能够持续提供服务的容量核算成本
存储报价只有计入副本、物理开销、索引内存和重建余量，才具有决策价值。比较部署成本前，先确认各方案满足相同的运行要求。
先选 Lavik 软件包，再确定 I/O 实验
Minimal 与 Standard 对部署环境的要求不同。先选择能回答首轮评估问题的软件包，再把 SPDK 作为独立实验。
会话上下文容量规划：过期之后，还剩下什么
把可重建的会话上下文放到 SSD 上，会改变容量预算。TTL 可见性、索引删除、物理空间回收和权威登录状态，仍需分别评估。
缓存还是一千万个键，值却变大了
缓存对象变大，变化的不只是容量。通过一个假设场景，分析 Lavik 如何将压力转移到响应字节量、替换写入和存储空间回收。
评估 Redis 客户端的第二次尝试
一份面向 Lavik 的实用兼容性清单：验证响应、连接状态、错误，以及首次请求结果不明时客户端的行为。
规划缓存增长，既要算容量，也要数键
通过一个假设容量模型，说明将值移到 NVMe 后，如何分别核算索引内存、空间回收余量与服务器共享成本。
Lavik 为什么将内存索引与 SSD 值数据分开
沿着所有权、追加、读取与空间回收四个环节，理解 Lavik 如何让值数据容量超越 DRAM。
Lavik 如何跨分区协调多键操作
键所有权让本地操作更高效，而多键命令还需要独立设计调度、锁生命周期、命令错误与持久完成过程。
为什么 Lua 函数目录也是一个存储问题
函数库需要在工作线程之间保持一致、跨重启保留，并经由复制传播。Lavik 先构建完整候选目录，再将其变为可见。
分组集合如何改变大 Redis 值的存储代价
大型哈希、列表、集合与有序集合，需要的不只是存放一个巨大值的位置。Lavik 使用按集合类型设计的路由与原子图发布。
复制进度，不能只看一个偏移量
Lavik 按历史与逻辑流跟踪原生复制。理解确认能够证明什么、重启会丢弃什么，以及故障转移为什么还需要额外证据。
存储等待时，Lavik 如何继续推进请求
支持 SSD 的 Redis 接口需要的不只是异步读取。沿着连接状态、准入、分区所有权与响应背压，理解 Lavik 的请求处理路径。
快速重启，首先要知道索引何时已经过期
Lavik 将关机检查点视为一次性恢复加速器。真正重要的是它的发布、消费与回退规则。
故障转移需要意图、权威与证据
Lavik 控制面的决策区分计划交接与所有者失效。沿着状态转换，理解它如何防止过期准备状态或观测值成为新的服务权威。