引入缓存竟然会带来这么多问题？( 五 ) _缓存

当第二次消费删除该缓存的消息时，如果删除成功就把该消息消费掉，并返回；如果没有删除成功就继续放回消息队列中，每个消息都有消费次数的上限，超出就报错告警

文章插图
图片
另外一般将更新数据库的模块和同时发生删除缓存消息的模块放在同一个服务里，因为这样后期维护起来，才不会发现莫名奇妙，不然就是给排查和维护上强度~~
当然再引入mq ，也要额外考虑mq的高可用性，所以需要根据实际情况，考虑是否有必要引入mq，如果不引入怎么办？最简单的我们可以通过内存队列、线程池等方式实现，性能更高，毕竟在本地没有网络延迟，代价就是更考验程序员的心智，啥都要操心~
基于binlog来删除缓存还有一种比较有意思的方式，我们上面需要在程序中显式去发送消息，讲人话就是程序需要额外承担发送消息的压力，而通过订阅数据库比如MySQL的binlog ，来监听数据的真实变化来直接去处理有关的缓存，让程序专心地去操作数据库

【引入缓存竟然会带来这么多问题？】binlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由Server层进行记录，使用任何存储引擎的mysql数据库都会记录binlog日志。可通过解析binlog文件来查看数据库的操作历史记录

业内比较成熟的有中间件Canal，我司也用的这个， Canal会模拟MySQL主从复制的交互协议，把自己伪装成一个 MySQL 的从节点，向MySQL主节点发送dump请求，MySQL收到请求后，就会开始推送Binlog给Canal，Canal解析Binlog字节流，解析出其中有关数据库中数据更新的日志，解析日志并执行对应数据的删除缓存操作，然后再引入MQ，通过消息队列的ACK机制，来确保这条消息的执行成功

文章插图
图片
关注我，小牛呼噜噜，我再说几句：
希望大家通过这些方案的学习，能够领悟为什么只能满足AP？
为什么缓存的数据一致性问题是无法避免的挑战？
引入缓存后，我们该如何监控起来呢？进一步分析过期时间是否合适，缓存的命中率
或者是否必需引入缓存？不引入缓存可就没有缓存的数据一致性，这些都需要数据分析作为支撑
或者引入缓存如何进一步优化，缓存的key如何花式设置，缓存预热有讲究，还有团队如何规范使用缓存等等，有太多可以深究