缓存是什么，为什么需要缓存

很多朋友对缓存是什么，为什么需要缓存不是很了解，每日小编刚好整理了这方面的知识，今天就来带大家一探究竟。

后台缓存是软件开发中非常有用的概念，数据库缓存是项目中不可避免的场景。缓存一致性的保证在面试中被反复问到。下面总结一下，根据不同的需求，选择合适的一致性方案。缓存是什么？存储的速度是有区别的。缓存是一种将低速存储的结果临时保存在高速中的技术。

如图所示，金字塔上方的存储可以作为下方存储的缓存。我们这次的讨论，主要针对数据库缓存场景，将以redis作为mysql缓存为例。为什么需要缓存？

存储，比如mysql，通常支持完整的ACID特性，因为可靠性、持久性等因素，性能一般不高，高并发查询会给mysql带来压力，造成数据库系统的不稳定。同时也容易出现延迟。根据本地化原则，80%的请求将落在20%的热数据上。在多读少写的场景下，增加一层缓存对提高系统的吞吐量和健壮性非常有帮助。存在问题

存储的数据可能会随着时间的推移而改变，缓存中的数据将会不一致。具体可容忍的不一致时间需要具体业务分析，但通常业务需要最终一致。作为mysql缓存通常的开发模式，redis会使用mysql作为存储，而redis会作为缓存来加速和保护mysql。但是，mysql数据更新时，redis如何保持同步？

强一致性同步的成本太高。如果追求强一致性，就不需要使用缓存，可以直接使用mysql。通常考虑的是最终的一致性。只要解决方案过了key的过期时间，mysql更新的时候，redis就不会更新了。这种方法实现简单，但是不一致的时间会很长。如果读请求非常频繁，过期时间很长，就会产生大量的长期脏数据。优点：开发成本低，易于实现；管理成本低，出问题的概率会比较小。不足：

完全依赖到期时间，太短容易缓存频繁失效，太长容易有很长的更新延迟。方案2是在方案1的基础上扩展的，底部是key的到期时间，mysql更新时，redis也更新。优点：与第一种方案相比，更新延迟更小。不足：如果mysql更新成功，但redis失败，则退化为方案1；

在高并发场景下，业务服务器需要同时连接mysql和redis。这样会成倍的损失连接资源，容易导致连接过多的问题。第三种方案优化了第二种方案中redis的同步写入，增加了消息队列，将redis的更新操作交给kafka，消息队列保证了可靠性，然后构建一个消费者服务来异步更新redis。优势：

消息队列可以使用一个句柄，很多消息队列客户端也支持本地缓存发送，有效解决了方案中连接过多的问题。消息队列用于实现逻辑解耦；消息队列本身是可靠的，通过手动提交的方式至少可以消耗一次。不足：

还是解决不了计时问题，如果多个业务服务器处理同一行数据的两个请求，比如a=1；a=5；如果在mysql中第一项先执行，第二项按照进入kafka的顺序先执行，那么数据就会不一致。引入了消息队列，同时增加了服务消费消息，成本较高。方案4

通过订阅binlog来更新redis，把我们的消费者服务作为mysql的奴隶，订阅binlog，分析更新的内容，然后更新到redis。优点：在mysql压力不大的情况下，延迟低；服务完全解耦；时机问题解决了。缺点：单独构建一个同步服务，引入binlog同步机制，开销很大。总结方案选择，首先确认产品的延时要求。如果要求极高，数据可能发生变化，就不要使用缓存。

总的来说，方案一就够了。我咨询过4、5个团队，基本都用方案一，因为我们可以用缓存方案，通常是多读少写场景，同时业务对延迟容忍。方案1没有开发成本，但实际上更实用。如果想增加更新的即时性，可以选择方案二，但是不需要做重试保证之类的。

方案3和方案4是针对高延迟要求的业务，一个是推模式，一个是拉模式，而方案4的可靠性更强。既然两人都愿意下功夫处理消息，不如一步到位用方案4。结论总的来说，方案1是足够的。如果延迟要求高，直接选择方案4。如果是面试场景，从简单到复杂，面试官一步一步提问，我们一点点演绎，宾主尽欢。

以上知识分享希望能够帮助到大家！