介绍下 TiKV 的资源管理模型。

内存

TiKV 的内存包含下面的部分：

Entry cache
主要包含 cache 和 trace 两部分。
- cache 主要包含了 proposed 之后的 entry，可以看做是 raft-engine 的缓存。这个缓存可以被 leader 用来 append entries。
- trace 主要包含了会被发送给 Apply 类，用来 apply 的 CachedEntries 对象。在 apply 结束后就可以被删除掉。
Block cache
Raft Message
主要是收到的 Raft Message 的占用内存。
Raft Entry
主要是收到的 Raft Entry 占用的内存。Raft Message 被 step 之后，对应的内存就会给到 Raft Entry。

Peer FSM
主要是和 Raft 的复制直接相关的。

pub struct PeerMemoryTrace {
    /// `ReadOnly` memory usage in Raft groups.
    pub read_only: usize,
    /// `Progress` memory usage in Raft groups.
    pub progress: usize,
    /// `Proposal` memory usage for peers.
    pub proposals: usize,
    pub rest: usize,
}

Apply FSM
这里主要包括等待 apply 的 cmd 以及对应的 entry。
Coprocessor

TiKV 默认的内存分配方案

系统内存的 75% 作为 high water 水位
- Block cache 占用 45%
- Write buffer 占用 20%
剩下来的 25% 是留给操作系统的 Page Cache

因为用户可以仅指定 Block cache 或者 write buffer 的期望大小，所以在计算 high water 的时候，会换算出各自的 high water 水位，选择其中的较大值。这个较大值不会大于内存的总大小，但可能大于 75%，这个时候会输出一个警告。

TiKV 使用 procinfo::pid::statm_self() 获取当前的系统内存。当超过 high water 后，有两个行动

reject msg append
计算 Raft Message + Raft Entry + Entry cache + Apply FSM 超过 reject_messages_on_memory_ratio 就会拒绝 raft message。
evict entry cache

内存

磁盘