For those who may not know, over the past few months, I've been continuously developing and maintaining a hybrid cache library in Rust, Foyer[0].

However, from the very beginning until now, I haven’t had the chance to properly introduce this project through an article. On one hand, I’m not very skilled at writing in English, so I kept procrastinating. (Thanks to ChatGPT, I can focus more on the content rather than worrying about my limited English writing skill.) On the other hand, Foyer was evolving rapidly in its early stages, undergoing major refactoring almost every few months. As a result, it felt premature to formally introduce the project.

But now, Foyer has already gained more stars on Github than than the project it was originally inspired by — Facebook’s CacheLib[1]. This excites me and makes me worry even more about the future of Foyer. So, I think it's time to write a proper blog to introduce it.

[0]: https://github.com/foyer-rs/foyer

[1]: https://github.com/facebook/cachelib

Hi, foyer's author here. The "zero-copy in-memory abstraction" is compared to Facebook's CacheLib.

CacheLib requires entries to be copied to the CacheLib managed memory when it's inserted. It simplified some design trade-offs, but may affect the overall throughput when in-memory cache is involved more than nvm cache. FYI: https://cachelib.org/docs/Cache_Library_User_Guides/Write_da...

Foyer only requries entries to be serialized/deserialized when writing/reading from disk. The in-memory cache doesn't force a deep memory copy.

I see, thanks! I don't have much experience in Rust, aside from some pet projects. Which features of Rust's type system are needed to implement such behavior? (It's unclear to me why I wouldn't be able to do the same in, for example, C++.)

Hi, foyer's author here. Page cache and swap are indeed good general proposed strategies and continuously evoluting. There are several reasons why foyer manages memory and disk control by itself rather than directly utilizing these mechanisms:

1. Leverage asynchronous capabilities: Foyer exposes async interfaces so that while waiting for IO and other operations, the worker can still perform other tasks, thereby increasing overall throughput. If swap is used, a page fault will cause synchronous waiting, blocking the worker thread and resulting in performance degradation.

2. Fine-grained control: As a dedicated cache system, foyer has a better understanding than a general proposed system like the operating system's page cache of which data should be cached and which should not. This is also why foyer has supported direct I/O to avoid duplication of abilities with the page cache since day one. Foyer can use its own strategies to know earlier when data should be cached or evicted.

Agreed. Intrusive data structures are good for implementing multi-container data structures with lower allocation overhead. And they are widely used than expected. E.g. LRU is a classic multi-container problem.

While I was developing [foyer](https://github.com/foyer-rs/foyer), which is a hybrid in-memory and disk cache project in Rust. Some users asked for metrics system support for both the Prometheus ecosystem and OpenTelemetry ecosystem. After investigating and trying out some libs, I decided to develop a new lib that is lightweight, support both Prometheus and OpenTelemety, and even different version of `prometheus`, `prometheus-client` and `opentelemetry` crates for various users.

I'm drunk. No offense. Why our world ends up like this.

Well, it usually starts with one...socially, like.