我们在之前的文章中提到过，一般人认为像Bluzelle这样的数据存储技术只能作为数据库使用，但其实这项技术同样可以作为缓存使用。今天这篇文章就来为大家科普一下和缓存有关的基础知识。
首先，我们要来认识一个应用程序的基础架构。
三层架构模型（Three tier architecture）是开发者在设计应用时最普遍使用的一种基础架构模型，这是由于这种模型具有很高的灵活性，不同的模组可以随时变更、重复使用。这三层架构包括表达层presentation layer（用户界面）、应用层application layer（业务逻辑）和数据层data layer（数据库和文件存储）。
表达层：用户与程序交互的界面，将服务器的指令和结果转换为用户可以理解的内容
应用层：应用程序的中间协调者，负责处理指令、作出逻辑决策和处理用户界面与数据库之间的传输数据
数据层：数据和文件实际存储的地方
通常情况下，开发者会选择把每一层部署在不同的服务器中，这样的好处是每一层的模块都可以被单独维护和扩展。然而，这其中也存在一定的弊端，每次应用层向数据库请求数据的时候，需要经过不同的服务器，因此请求的速度大大受到网络速度的限制。数据的请求速度几乎是所有商业应用的首要要求，因为这在提升用户体验方面有至关重要的作用。那这又如何解决呢？
缓存方案是解决多层架构数据读取性能痛点的一个很重要的方式。
缓存服务是一项数据缓冲技术，通过把频繁读取的数据存储在一个临时内存中，让数据更快速、容易读取，同时可以降低数据库的负荷。比如，你要读取一个微信朋友的个人资料，要经过不同的服务器到达数据库才能读取，但是读取了第一次之后，这些资料会临时存储在你的身边（你的手机内存或者离你相近的服务器），当你再次需要读取这些资料的时候，可以大大缩短读取的时间。
根据不同的用例，数据缓存可以设在三层架构的任意一层，或者单独设为一层。缓存方案也可以和任何的数据库兼容，比如：
关系型数据库（SQL)：Amazon RDS等
非关系型数据库（NoSQL)：MongoDB、Amazon DynamoDB、Azure CosmoDB和Apache Cassandra等
使用缓存服务有许多不同的优势：
性能：如上面提到，缓存可以让频繁使用的数据更容易被读取，同时降低数据库的负荷，因此大大提升数据读取的性能
可扩展性：后端读取的一部分工作量分配到了成本更低的缓存系统，而且数据处理的方式可以更加灵活
可用性：如果后端服务器发生暂时性故障，缓存仍然可以支持应用程序持续运行，让整个系统对故障更具有弹性。
不同的缓存策略适用于不同的案例
缓存策略是指，通过确定数据源与缓存系统之间的关系、以及数据访问的方式，来确定缓存系统在整个应用架构中的位置和任务。现实中有各种不同的策略，但每种都会对你的系统设计和最终性能产生不同的影响。最普遍的缓存模式包括：Cache Aside、Read Through、Write Through和Write back等。
在设计架构之前，了解数据访问的方式对决定缓存策略是很有必要的。
Cache Aside模式
在此架构中，缓存和数据库是并列在旁的，应用程序将优先从缓存中请求数据。如果数据存在（我们称之为“缓存命中”，cache hit），应用程序将直接从中读取数据。否则（我们称之为“缓存未命中”，cache miss），应用程序将从数据库请求数据并将其写入缓存，以便下次可以从缓存中读取数据。
优点：
· 适用于大部分读取任务繁重的应用程序
· 数据库发生临时故障时，缓存系统仍可以支持应用持续运行
· 易于配置（只需兼容应用层）
· 缓存系统可以采用比数据库更易读的数据模型
缺点：
· 缓存与数据库的数据可能不一致
· 第一次读取时一定会发生“未命中”的情况，造成读取延迟
Read Through模式
跟Cache Aside不同的是，这种模式下的缓存系统建立在应用和数据库之间。应用程序仅向缓存请求数据。若“缓存未命中”的情况出现时，缓存系统负责向数据库发出请求、更新缓存自身，然后返还数据给应用。
优点：
· 适用于大部分读取任务繁重的应用程序
· 应用层不需要兼顾数据库，应用层代码具有更高可读性
缺点：
· 需要为缓存和数据库之间编写更复杂的插件，以读取数据
· 第一次读取时一定会发生“未命中”的情况，造成读取延迟
Write Through模式
这和Read Through类似，缓存在应用和数据库之间，应用程序的每次“写”请求都必须经过缓存再到数据库。这种模式保证了任何写入的数据都存在于缓存系统中，不会出现读取“缓存未命中”的情况。
优点：
· 读取时“未命中”的情况一定不会发生，因为数据在写入数据库前一定先写入缓存
· 如果和“Read Through”模式配合使用，可保证数据库和缓存的数据一致性
缺点：
· 会造成“写入”延时
Write Back模式（也称为“Write Behind”）
这和Write Through有类似的架构，应用程序进行“写”请求也需经过缓存系统。不同的是，数据从应用到达缓存后，并不会直接写入数据库，而是进行间歇性一次性写入（比如每两分钟写入一次）。数据更新从应用程序到数据库会有一定的延时。
优点：
· 适用于“写入”任务繁重的应用程序
· 可以抵抗数据库中度故障
· 通过减少“写入”数据库的次数降低数据库成本和负荷
缺点：
· 若缓存系统发生故障，可能造成所有数据丢失
Write Around
Write Around是一种混合模式，应用永远直接向数据库“写入”数据，只在“读取”时使用缓存系统。一般与Cache Aside或Read Through配合使用。
小结
总的来说，使用缓存服务是提升应用性能同时最低限度对系统产生不良影响的策略，同时还能提高可扩展性和可用性。开发者们需要结合自己的用例和数据读取形式去选择适合自己的缓存策略。关于缓存的N种套路，你学会了吗？
