Consistency缓存一致性是指缓存中的数据与数据库中的数据是否一致。可以理解为数据的快照是否等于实时数据，实时数据变化和数据快照同步过程中出现的问题，即Cache一致性问题（也可以归类为如数据双写问题）在业务场景的生产中面对数据的高频读取，为了减轻数据库的压力，可以考虑将数据放入缓存，缓存分为本地缓存和分布式缓存CacheLocalCache&DistributedCache本地缓存是指机器上的缓存，比如Guava、Ehcache。这种类型的缓存主要受限于机器内存和分布式部署同步困难的问题。分布式缓存是指数据存储在服务器上，用户访问的数据相同，比如Redis和MemCache。此类缓存存在数据丢失、数据延迟、服务宕机等问题。本地缓存一致性问题。如果要比较本地缓存和分布式缓存的优缺点，那么本地缓存最大的优势就是不需要和云端缓存服务器进行交互，减少了网络和IO的消耗。但是，按照我目前的认知，差距其实很小；而本地缓存最大的问题是如何实现不同实例之间的连接。同步，现有的方法是使用MQ或者RPC广播方式。一个实例更新数据库后，通知其他实例刷新，但是解决不了的是通知过程中新启动的实例，通知失败。在强一致性场景下，这样的异常是不可接受的分布式缓存一致性问题。综上所述，分布式缓存的本质就是将数据库的数据写入缓存服务器。当数据库发生变化时，变化会同步到缓存服务器，缓存中的数据和数据库不一致，这就涉及到缓存一致性的问题。下面继续讲解缓存一致性的解决方案。当读取数据面临强一致性场景时，可以考虑将数据放入缓存中（过期或永不过期均可），服务器只能从缓存中读取数据，当发现没有数据时在缓存中，服务器锁定并读取数据库。此时只有一个请求可以访问数据库。查询完成后，将结果写入缓存，其他请求Block，直到缓存写入完成，再从缓存中读取数据。服务器处理查询请求并尝试从缓存中查询数据。如果缓存中有数据，则直接返回缓存中没有数据，然后锁定查询数据库。查询完成后，它会将数据放入缓存中。其他请求直接读取缓存并写入数据。写入数据时，可以先修改数据库，再更新或删除缓存（删除时，直到下一个查询请求到来，新数据才会写入缓存）。该方案在数据写入缓存更新的过程中，其他查询请求仍然会访问旧数据，无法保证绝对一致性。如果需要强一致性方案，可以直接删除缓存，阻塞所有读请求，然后加锁写数据，再把数据放入缓存，类似读写锁的概念，read-写互斥，由于强一致性约束，该方案的性能会比上述方案差，需要结合具体场景使用
