13缓存的使用姿势（一）如何选择缓存的读写策略？

　　今天讲讲缓存的读写策略，你可能觉得很简单啊，查询缓存，不存在则查询数据库，然后回种缓存。实际上针对不同的业务场景缓存的读写策略是不同的。
　　选择读写策略的时候，需要考虑如下因素：缓存中是否可能写入脏数据，策略的读写性能，是否存在缓存命中率下降。下面我们就以标准的缓存数据库的场景带你剖析读写策略以及适用的场景。CacheAside（旁路缓存）策略
　　先考虑最简单的业务场景，更新数据，比如更加id更新年龄信息。
　　你可能会产生以下思路：
　　这个思路会造成缓存和数据库中的数据不一致。
　　为什么会产生这个问题呢？因为变更数据和变更缓存是两个独立操作，没有做任何的并发控制，当两个线程并发的去更新时，就会出现因为顺序不同而导致不同的更新结果。
　　那么要如何解决这个问题呢？其实，我们可以在更新数据库的同时，不更新缓存，而是删除缓存中的数据，在读取缓存时发现没有数据，再从数据库中读取，更新到缓存中。
　　这个就是我们常见的CacheAside策略（也叫旁路缓存策略），这个以数据库为准，缓存中的按需加载。它可以分为读策略和写策略
　　读策略步骤：从缓存中读取数据如果缓存命中则直接返回如果缓存不命中，则从数据库查询数据查询到数据后将数据回种缓存，返回用户数据
　　写策略步骤：更新数据库中的数据删除缓存记录
　　那么问题来了，写策略的时候，是否可以先删除缓存，再更新数据库呢？不行，这样会导致缓存跟数据库的数据不一致
　　那么CacheAside策略这样先更新数据库，删除缓存就没有问题了吗？其实理论上还是有的，如下图：
　　不过这种问题出现的概率很低，因为就是缓存的写入远远快于数据库的写入，所以在实际中很难出现请求b已经操作完数据库并且写入缓存了前面请求还未写入缓存。
　　CacheAside策略是我们日常开发中最经常使用的缓存策略，存在问题就是当数据写入比较频繁时，缓存中数据会被频繁的清理，这样会对缓存的命中率产品一定影响。可以考虑两种解决方案：更新数据同时更新缓存，更新缓存的时候加一个分布式锁，这样同一时间只允许一个线程更新，但是这样会对写入性能有影响。另一种做法同样更新数据更新缓存，只是缓存加一个极短过期时间，这样即使出现不一致，对业务的影响也较小（视具体的业务场景抉择）
　　当然除了这个策略，在计算机领域还有几种经典的缓存策略，他们也有自己各自的适用场景。
　　这个策略的核心原则是只与缓存打交道，由缓存跟数据库通信，写入或者读取数据。
　　writethrough策略是这样的：先查询要写入的数据在缓存中是否存在，如果已经存在则更新缓存中的数据，并且由缓存组件同步更新到数据库，如果缓存中数据不存在我们把这种情况叫做写失效，writemissWriteBack（写回）策
　　这个策略的核心是写入数据时只写入缓存，并且把缓存块标记为脏的，而脏块儿只有被再次使用时才会将其中的数据写入数据库中。
　　划重点CacheAside是我们在使用分布式缓存时最常用的策略，可以在实际业务中直接拿来使用。ReadWriteThrough和WriteBack策略需要缓存组件的支持，所以比较适合你在实现本地缓存组件的时候使用；WriteBack策略是计算机体系结构中的策略，不过写入策略中的只写缓存，异步写入后端存储的策略倒是有很多的应用场景。而且，你还需要了解，我们今天提到的策略都是标准的