深入缓存的原理与设计

一般情况下数据是存在数据库中，如果访问量过大的话，就会增加数据库的压力，当然我们一般数据库会做设计，例如读写分离、分库分表，然后对数据库集群做主从架构，但是这远远不够，我们要把流量洪峰数据先转移到缓存中。

传统的 session 是由 tomcat 自己进行维护和管理，集群或分布式环境，不同的 tomcat 管理各自的 session。

这样子会造成一个问题：一般是集群部署应用，如果用户登录了，先跳转 A 机子页面，后面又跳转到 B 机子的页面，这样子会造成会话丢失，即用户需要重新登陆，所以这样会大大降低用户的体验的。

所以我们一般将登录成功后的Session信息，存放在Redis中，这样多个服务器(Tomcat)可以共享Session信息，用户跳转时，也不需要重新进行登录。

现在在分布式环境下，多个JVM在并发时会产生问题，需要控制时序性，所以需要用到分布式锁。

举几个场景：部署多个定时任务时，例如自动扣款定时任务，这样子同时多个扣款服务在运行，要避免重复扣款，所以需要用到分布式锁。

有三种方式，常用的有两种，另外一种了解即可，一般不使用。

最常见的一种方式。在这种模式下可以尽可能的保证缓存的一致性，适合对一致性要求较高的场景。

Read：读的时候，先读缓存，缓存没有的话，就读数据库，然后从数据库中取出数据放入缓存中，同时返回响应。

Write：更新的时候，先更新数据库，后删除缓存。

为什么要删除缓存

首先删除缓存比更新缓存更高效，由于Redis更新数据时，需要遍历，其二是懒加载，使用的时候才更新缓存

在Read/Write Through模式下，存储服务封装了所有的数据处理细节（cache + DB），业务应用端代码只用关注业务逻辑本身，系统的隔离性更佳。

存储服务收到业务应用的写请求时，会首先查 cache，如果数据在 cache 中不存在，则只更新 DB，如果数据在 cache 中存在，则先更新 cache，然后更新 DB。

而存储服务收到读请求时，如果命中 cache 直接返回，否则先从 DB 加载，然后更新 cache 后返回响应。

备注：这种方式开发比较复杂，需要提供数据库的 Handler，不推荐使用这种方式，了解一下即可。

在该模式下，更新数据时只更新缓存，不直接更新DB，通过异步的方式将缓存结果批量的或合并后再更新到DB。
这种方式的特点是效率非常高，但不是强一致，甚至会丢失数据，适用于访问量、点赞数等对于性能要求高，但一致性要求不高的场景。

缓存与数据库无法做到数据的实时同步，Redis 的主从架构也是无法做到实时数据同步。