Cache-Aside模式一种常用的缓存方式，通常是把数据从主存储加载到KV缓存中，加速后续的访问。在存在重复度的场景，Cache-Aside可以提升服务性能，降低底层存储的压力，缺点是缓存和底层存储会存在不一致。
业务场景和面临问题
在开发应用时，使用缓存被多次访问的数据是常见的操作。但是，缓存和底层存储的数据完全一致是一种不切实际的想法。我们需要一种策略，来保证缓存里的数据尽量及时更新，同时也要能够检测并应对缓存数据过期的情况。
解决方案
很多商业化的缓存访问提供了 read-throgh 和write-through/write-behind 的操作。这种模式下，读写都要先经过缓存，操作流程是这样的：
- 读取数据：如果缓存miss，应用层就从底层存储读取数据，然后写入缓存。
- 更新数据：涉及数据修改时，直接修改缓存里的数据即可，缓存服务会自动将修改同步到底层存储。
如果缓存不提供数据同步能力，应用层就要负责数据在缓存和底层存储的同步。
使用cache-aside策略，应用层能够模拟read-through缓存的能力。这种策略会要求应用层按需把数据加载进缓存，下图给出了存储数据的过程：
如果应用层更新了数据，就可以采用write-through策略。做法也比较简单：1）修改底层存储的数据；2）将缓存里的这条数据置为失效（删除/过期）。
下一次这条数据被请求时，使用cache-aside策略：1）应用层从底层存储获取更新后的数据；2）写入缓存。
存在问题和注意事项
在此用这个模式时，需要考虑以下几点：
缓存数据的生命周期。很多缓存实现方案会设置过期时间，如果数据在一段时间内没有被访问，缓存中置为失效并逐出这条数据。为了保证cache-aside模式有效，需要保证缓存失效机制与数据的访问模式是一致的。如果缓存失效时间太短，可能会导致应用层反复从底层存储获取数据写入缓存。如果缓存过期时间太长，缓存的数据很可能是过期的，与底层存储不一致。对于半静态的数据（更新频次低）或读取频繁的数据进行缓存，能达到最好的效果。
逐出数据。相对于底层存储，缓存的容量一般是有限的，必须要是需要逐出数据。很多缓存采用LRU机制，当然我们也可以自己定制逐出机制。通常为了保证缓存的性价比，所有数据都会被配置一个全局的缓存过期属性。有个别例外的情况，比如从底层存储中获取一份数据项效率非常低（读取频率一般），另一份数据项从底层存储获取效率高（读取频率也高），那么缓存获取效率低的数据收益可能更大。
服务启动时填充缓存。一些场景下，服务启动时，会把存量数据加载到缓存里。这种情况下如果有数据过期或被逐出的情况，同样可以采用cache-aside模式。
数据一致性。cache-aside模式并不能保证缓存和底层存储的数据一致性。存储里的数据任何时候都可能被更改，如果是外部服务，缓存可能感知不到数据更新。如果一个系统中，多个存储都存了数据的备份，频繁发生数据同步的情况下，数据不一致的情况会更严重。
本地缓存，也叫内存缓存。数据缓存在服务实例的内存中，是有该实例能访问。如果服务实例频繁访问同样的数据，也可以使用Cache-Aside模式。但是本地缓存是允许本服务实例访问，不同的服务实例都在本地内存存储了一份数据。不同实例的缓存很快变得不一致，这就需要更频繁地刷新缓存中的数据。在这类场景中，可以考虑使用分片或分布式缓存方案。
应用场景
适用场景：
- 缓存并不提供原生的 read-through 或 write-through 的能力。
- 资源需求无法预估的场景。cache-aside模式允许应用按需加载数据到缓存，不需要提前对数据的需求量进行评估。
不适用场景：
- 缓存数据是静态的。如果缓存空间能容纳这些数据，可以在服务启动时填充缓存，并采用一些策略避免其过期。
- Web农场托管的大量Web应用，如果Web应用支持亲和性调度（client倾向于找上次服务过的server），client/server之间尽量不要引入额外依赖，比如session信息缓存。
