一致性

CAP理论：
Consistency
Availability
Partition tolerance
数据一致性要求越高，系统可用性越差
数据一致性要求一般可以分为强一致性、弱一致性、最终一次性

3种经典缓存模式

Cache-Aside. Cache-Aside是最广泛使用的缓存模式之一

读操作：先读cache，如果命中直接返回结果；没命中则去db查，然后写入缓存，并返回结果

写操作：

涉及cache和db的写操作，即双写。

最优解是，先update db，然后delete cache

• 双写，首先需要考虑先写后写的问题。如果先写cache，再写db，那么由于读比写快就可能导致数据不一致

例如这样一种情况：

1. a线程尝试写数据，delete cache

2. b线程尝试读数据，cache miss

3. b线程从db拉旧数据并set cache

4. a线程写db数据完成

这时cache和db的数据就不一致了

• 先后问题考虑完毕，则考虑cache是更新还是删除的问题。相比而言，删除是个更优解

1. 写入数据并非马上需要读取，删除可以减少cache内存占用。用时再读

2. 如果cache是更新，那么多线程并发双写同一目标数据，假设以a、b线程的顺序完成了对db数据的修改，但是因为网络原因以b、a线程的顺序完成了对cache的修改，这时db和cache产生数据不一致。直接删除cache没有这个问题

关于第2点的问题，出现的原因是，写db和写cache不是原子的而是割裂的。因此也是可以解决的——牺牲一定的可用性来换取数据的一致性：一次双写应该视为一个原子，只有一次双写完全完成后，才可以进行下一次的双写，即：[写db-写cache] -> [写db-写cache] ... 在这种模式下，【写db-写cache】而不是【写db-删cache】也是可行的

• 写db-删cache，删cache是最后一步。那么删cache删失败怎么办？

针对不同的数据一致性要求，有不同的解决方式：
解决方式1：数据一致性要求高——写db-删cache是一个原子，删cache删失败那么写db也会回滚。这样可用性下降。(当前om2写mysql和cmdb就是[写mysql-写cmdb] -> [写mysql-写cmdb]，为了保证om2db和cmdb的数据强一致，这其实就是下面将提到的write through模式；而对于om2与om的数据同步，则没有非常强的一致性要求，是在修改完om2db和cmdb后通过异步动作将改动同步到om的，这就是下面提到的write behind模式)

解决方式2：数据一致性要求不高，可用性倒是有更高的要求——删除缓存设置重试机制。删除失败的缓存放入MQ，设置最大重试次数。最终还是删失败的话可以告警。这样一致性下降，在多次删除cache这个时间段内cache和db的数据是不一致的

Read-Through/Write-through

读写穿透模式。这个名字是不太好懂，其实through指的是through cache，所有的读写都经过cache。大体上Read-Through/Write-through和Cache-Aside是类似的，只是在app和cache之间加了一个cache provider，把对数据的读写操作封装了一层，程序不需要再去管理从哪去读数据（缓存还是数据库）。app直接与cache provider打交道，不用自己在业务逻辑中实现【写db-删cache】的逻辑，而是交给cache provider处理

注意：
Read-Through模式和Cache-Aside的读操作是相同的
而write-through模式对db和cache的两个写操作都在一个事务中完成。只有两次都写成功了才是最终写成功了，这与Cache-Aside的写操作不同。这的确带来了一些写延迟但是它保证了数据一致性

In write-through, data is simultaneously updated to cache and memory/database. This process is simpler and more reliable. This is used when there are no frequent writes to the cache(The number of write operations is less).
In this case, when the application updates a piece of data in the cache (that is, calls put(...) to change a cache entry,) the operation will not complete (that is, the put will not return) until cache provider has gone through the CacheStore and successfully stored the data to the underlying data source. This does not improve write performance at all, since you are still dealing with the latency of the write to the data source. Improving the write performance is the purpose for the Write-Behind Cache functionality.

Write-behind

后写模式。和Read-Through/Write-through类似，Write-behind也通过cache provider与app交互，差异在于cache provider的写入逻辑不同：cache provider直接更新cache并返回，而对db的更新则是一个异步行为

finally

缓存系统其实非常常见，一台计算机，cpu寄存器-高速缓存-memory-外存就是一套成体系的缓存系统
真实系统中需求千差万别，应该根据CAP的需要灵活选择或组合几个模式来实现