redis之作为缓存的使用（一）

对于一个分层的系统当中，如果不同层之间存在速度不一致的问题，就会用到缓存技术，可以把一些需要经常访问的数据放到缓存当中，这样就可以增加加快访问的速度

对于计算机系统中存在两种缓存

1：LLC缓存：cpu中的末级缓存，用来存放内存中的数据，避免每次从内存中存取数据。

2：内存中的高速页缓存，即page-cache，用来缓存内存中的数据，可以避免每次从磁盘中获取数据

对于互联网应用来说，就是redis是快速子系统，数据库时慢速子系统

但是对于缓存来说，它的容量总是有限的，也也可以说明缓存的所能够保存的数据量也很有限，所以对于互联网应用来说，缓冲中的数据也必然会按照一定规则淘汰出去，写会到后端子系统（为什么会写会？）

同时读取新的数据，再写入到缓存。

Redis 本身是支持按一定规则淘汰数据的，相当于实现了缓存的数据淘汰，这也是 Redis 适合用作缓存的一个重要原因。

Redis 用作缓存时，我们会把 Redis 部署在数据库的前端，业务应用在访问数据时，会先查询 Redis 中是否保存了相应的数据，

此时会有两种情况：缓存命中：则读取数据，返回成功

缓存确实：则需要读取数据库中的数据，并写入缓存（但是这里就会有数据不一致性的问题，写入缓存中的数据，如果进行修改操作，怎么通知缓存更新数据？）

 

redis是一个独立的软件，和业务应用程序是两个软件，当部署了 Redis 实例后，它只会被动地等待客户端发送请求，然后再进行处理。所以，如果应用程序想要使用 Redis 缓存，我们就要在程序中增加相应的缓存操作代码。所以，我们也把 Redis 称为旁路缓存，也就是说，读取缓存、读取数据库和更新缓存的操作都需要在应用程序中来完成。（引用）

通过在应用程序中加入 Redis 的操作代码，可以让应用程序使用 Redis 缓存数据了。除了可以从 Redis 缓存中查询，读取数据以外，应用程序还可能会对数据进行修改，对于我们来说就由两种选择，既可以在缓存中修改，也可以在后端数据库中进行修改。

所以这里提供了两种缓存实现方式：只读缓存和读写缓存。只读缓存能加速读请求，而读写缓存可以同时加速读写请求。而且，读写缓存又有两种数据写回策略，可以让我们根据业务需求，在保证性能和保证数据可靠性之间进行选择。

下面介绍只读缓存：
只读缓存：当应用程序调用get接口，会查询缓存中数据是否存在，而写请求则会发往数据库，在数据库中增删改，对于删改的数据来说，如果 Redis 已经缓存了相应的数据，应用需要把这些缓存的数据删除，Redis 中就没有这些数据了。当下次读取时会从数据库当中读，然后写回到缓存中（这样凡是修改过的数据下次必须要先从数据库读出，对于经常进行写操作的程序来说，降低了redis的使用性能）。

读写缓存：
对于读写缓存来说，除了读请求会发送到缓存进行处理（直接在缓存中查询数据是否存在)，所有的写请求也会发送到缓存，在缓存中直接对数据进行增删改操作。此时，得益于 Redis 的高性能访问特性，数据的增删改操作可以在缓存中快速完成，处理结果也会快速返回给业务应用，这就可以提升业务应用的响应速度。但是redis是内存性数据库，一旦出现掉电或宕机，内存中的数据就会丢失，应用的最新数据可能会丢失，给应用业务带来风险。

所以提供了两种将数据写入数据库的方式：
根据业务应用对数据可靠性和缓存性能的不同要求，我们会有同步直写和异步写回两种策略。其中，同步直写策略优先保证数据可靠性，而异步写回策略优先提供快速响应。

同步直写：写请求发给缓存时，也会发给后端数据库进行处理，等到缓存和数据库都写完数据（原子性），才给客户端返回。这样，即使缓存宕机或发生故障，最新的数据仍然保存在数据库中，这就提供了数据可靠性保证。

但是缺点就是同步直写会降低缓存的访问性能。这是因为缓存中处理写请求的速度是很快的，而数据库处理写请求的速度较慢。即使缓存很快地处理了写请求，也需要等待数据库处理完所有的写请求，才能给应用返回结果，这就增加了缓存的响应延迟。

异步写会策略：则将响应速度排在了第一位，此时，所有写请求都先在缓存中处理。等到这些增改的数据要被从缓存中淘汰出来时，缓存才将它们写回后端数据库。这样一来，处理这些数据的操作是在缓存中进行的，很快就能完成。只不过，如果发生了掉电，而它们还没有被写回数据库，就会有丢失的风险了。