Write Back / Write Behind / Lazy Write Pattern
一些了解Linux操作系统内核的同学对write back应该非常熟悉，这不就是Linux文件系统的Page Cache的算法吗？是的，你看基础这玩意全都是相通的。
Initially, writing is done only to the cache. The write to the backing store is postponed until the modified content is about to be replaced by another cache block.
Write Back套路，一句说就是，在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操作飞快无比（因为直接操作内存嘛），因为异步，write backg还可以合并对同一个数据的多次操作，所以性能的提高是相当可观的。
A write-back cache is more complex to implement, since it needs to track which of its locations have been written over, and mark them as dirty for later writing to the backing store.
The data in these locations are written back to the backing store only when they are evicted from the cache, an effect referred to as a lazy write.
For this reason, a read miss in a write-back cache (which requires a block to be replaced by another) will often require two memory accesses to service: one to write the replaced data from the cache back to the store, and then one to retrieve the needed data.
Extremely High Read/Write Performance
Since we could just directly read the latest data from cache, the read performance is extremely high.
And similarly, since cache is much faster than DB, thus the write performance is extremely high as well.
Data in the cache is never stale
- Because the data in the cache is updated every time it’s written to the database, the data in the cache is always current.
- Suitable for read heavy systems which can’t much tolerate staleness.
Stale Data in DB
- Eventual consistency between database & caching system. So any direct operation on database or joining operation may use stale data.
- But normally it won’t be an issue, since we always know the data in cache is up-of-date, and thus we access DB to get the latest data
Possible to Lost Data (Consistent Issue)
- If cache is suddenly down, may not be able to bring back to the eventual consistency state, and even not able to bring back to a consistent state.