【0-1 架构问题集合】

大数据量高并发情况下如何更新缓存

1. 首先是查询的时候，一般先查询缓存，在查询数据库，同步的去更新缓存
2. 但是都是异步去更新，引入消息队列MQ

   本质是个队列，FIFO先入先出，只不过队列中存放的内容是message而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中,MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了MQ之后，消息发送上游只需要依赖MQ，不用依赖其他服务

3. 异步修改完数据库之后，去更新缓存，可能出现数据不一致的情况，如果缓存设置的实践比较短，是可以接受的
4. 查询缓存，没有数据， 查询数据库，写一个MQ消息，异步的去更新（也可以用多线程异步去代替），可以加一个分布式锁来实现，但是锁效率很低。所以可以对数据库做限流，不能加锁
5. 可以对数据库分库分表，主从，数据库层面限流
6. 防止重复更新。可以做一个分布式锁，给mq消息加一个唯一ID，防止重复消费
7. 还有其它方法：监听数据库的binlog日志，有一个单独的程序监听，监听到了之后修改缓存，但是binlog流程是比较长的，代码量比较多
8. 查询查不到，然后查询数据库，写入缓存这个情况。不是每个公司都把数据写入到缓存中，只把活跃的用户的数据写入到缓存中

二级目录

三级目录