Improve the RTC process of Read/Write model

[AlexStocks]

Which PikiwiDB functionalities are relevant/related to the feature request?

Pika 已经实现了混合存储：在内存 RedisCache 中缓存热数据，在磁盘中存储全量数据。现需要在这个基础之上，继续优化读写流程，提高吞吐，降低延时。

Description

from https://tech.meituan.com/2024/03/15/kv-squirrel-cellar.html

Proposed solution

process:

• 1 当网络线程收到一个请求之后，会先判断是否为一个读请求，如果是，就会直接去读内存引擎
• 2 我们服务的内存引擎会缓存硬盘引擎上的热点数据，如果内存引擎命中的话，网络线程就可以直接返回结果给客户端。这样在网络线程内就实现了请求的闭环处理，相比原来的模型可以去除所有因请求流转造成的 CPU 资源消耗。
• 3 对于写和读未命中内存引擎的请求，仍然需要经过原来的请求处理路径，去硬盘引擎读或者写数据。

Result:

新的线程模型，经实测在 80% 内存引擎命中率场景下，服务读吞吐可以提升 30%+。虽然新的线程队列模型只实现了读缓存命中请求的 RTC，但其实在线流量大多都是读多写少且热点数据明显、内存引擎命中率比较高的场景，所以，新模型上线后在大多数的业务集群都取得了明显的性能提升。

Alternatives considered

none

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Which PikiwiDB functionalities are relevant/related to the feature request?

Pika has implemented hybrid storage: it caches hot data in the in-memory RedisCache and stores full data on disk. Now, it is necessary to further optimize the read and write processes on this basis to increase throughput and reduce latency.

Description

from https://tech.meituan.com/2024/03/15/kv-squirrel-cellar.html

Proposed solution

process:

• 1 When the network thread receives a request, it will first determine whether it is a read request. If so, it will directly read the memory engine.
• 2 The memory engine of our service will cache the hotspot data on the hard disk engine. If the memory engine hits the target, the network thread can directly return the result to the client. In this way, closed-loop processing of requests is realized within the network thread, and compared with the original model, all CPU resource consumption caused by request flow can be eliminated.
• 3 For write and read requests that miss the memory engine, they still need to go through the original request processing path to the hard disk engine to read or write data.

Result:

The new thread model has been measured to increase service read throughput by 30%+ in a memory engine hit rate scenario of 80%. Although the new thread queue model only implements RTC for read cache hit requests, in fact, most of the online traffic is in scenarios where there are more reads and less writes, obvious hotspot data, and a relatively high memory engine hit rate. Therefore, after the new model goes online, most of the business clusters have achieved significant performance improvements.

Alternatives considered

none

[AlexStocks]

1 Pikiwidb 将是内存和磁盘混合存储模型
2 线程模型分为网络线程池和 worker 线程池
3 网络线程池处理客户端连接请求，和对内存的读请求
4 worker 线程池处理磁盘读写任务 以及对内存的写任务

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

1 Pikiwidb will be a hybrid memory and disk storage model
2 The thread model is divided into network thread pool and worker thread pool
3 The network thread pool handles client connection requests and memory read requests
4 worker thread pool handles disk read and write tasks and memory writing tasks

[AlexStocks]

RTC 对同一个连接读写顺序性的保证：假设 X = 2，有请求 "set X 3; get X“，原来顺序能够保证”get X“ 结果是 3。

RTC 改造后，redis client 能够保证在 "set X 3; " 这条指令没得到结果之前，不会执行 ”get X“，所以仍然能保证结果是 3。

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

RTC guarantees the order of reading and writing on the same connection: assuming X = 2, there is a request for "set X 3; get X", the original order can guarantee that the result of "get X" is 3.

After the RTC transformation, the redis client can guarantee that "get X" will not be executed before the "set