|
一个应用中决定加缓存（Redis,memcached）之前，要考虑的第一个问题就是，引进了缓存之后，会带来哪些收益（利），付出哪些代价，引起哪些额外的问题（弊）？
任何新的中间件引进，收益和成本都是伴随的，只有当利大于弊的情况下，能够容忍其弊端（彻底解决？没有额外代价又没有负面影响，是不可能的，那就是不用就行了），才值得引进。
以Redis作为缓存为例，引进之后，其利和弊也是伴随的。
带来的收益：加速读写，提高并发性，降低后端持久化层数据库的负载
付出的代价：增加代码复杂，缓存本身的运维，潜在的数据不一致造成的影响。
数据不一致的存在
引进Redis（或者其他缓存）之后，应用程序和数据持久化层多了一个中间层，部分数据存储由原来的单一持久化层，变为缓存层和持久化层两份。
这两部分数据在相互同步的过程中，在某些时间点上的维度来看，可能会潜在不一致的情况。
其中，潜在的数据不一致，是任何一个引进缓存层之后最面临的最大的一个问题（当然两者最终的数据是要保持一致的，这一点是底线）。
首先需要衡量的就是，这种潜在的不一致，会引发什么样的问题，带来的问题是否可以接受范围之内，或者是否会对应用程序逻辑引起致命的问题。
缓存和持久化层存储可能会不一致，往往是缓存和持久化层未同步刷新引起的，
具体举例说明： 第一种情况，比如点赞次数，浏览次数等等（读多写少的场景，写MySQL，读Redis，写入了数据库但是尚未同步到缓存层这个间隙）。
不会对业务产生严重的逻辑错误，这种暂时性的数据不一致是可以忍受的，另外就是，通过刷新等手段，两者数据最终会达成一致。
第二种情况，比如银行卡取款取超，导致余额为负数，缓存和持久化层存储的不一致造成严重的逻辑错误，这种是无法忍受的。
就需要考虑这种缓存层本身的设计是否合理？ 轻量级做法，代码逻辑实现
如果对于缓存的合理性没有问题，且业务逻辑上要求缓存和持久化层强一致，那么久要实现数据库的一致性操作。
对于缓存和持久化层数据的一致性实现，个人的话，思路有以下两种，
轻量级的做法如下：
对于引起数据变化的逻辑，一般都是“写操作”，比如对数据的update或者delete，
1，首先去delete缓存中对应的数据（而不是去对应的update、delete，为什么？因为只要delete成功，缓存被清理之后，就消除了不一致的可能性，或者并发造成的数据覆盖错误（update），而非update就做不到），如果执行成功，再去操作持久化层的数据库。
2，对于insert操作，保证写持久化库成功，异步写缓存（而不用刻意关注是否写成功）。 重量级分布式锁实现，双写实现强一致 如果是分布式锁，任何写入性操作，比如update，delete等，如下：
1，直接锁定相关key值
2，依次操作缓存层和持久化层，同时做好每一层的回滚操作，一旦任何一步失败，都要回滚
3，最终不管成功或者失败，都释放Key
分布式锁这种方式的话，实现起来，原代码中业务侵入性较多，比较复杂
重量级队列化请求
如果是使用队列，将可能导致不一致性的访问，队列化执行，其实这种方式，也是比分布式锁更加重量级的，基本上会颠覆原始的逻辑实现，一般很少采用。
但是不管怎么样，缓存层和持久化层，最终的数据是要保持一致的，这一点是底线。 |
|
|
