今天忽然想到一个问题
对于高并发条件下，后台对数据的更新和实例化是怎么进行的？
1、直接插入数据库，然后更新缓存？
这样这个更新操作将会有IO阻塞风险吧、
2、直接更新缓存，然后使用消息队列更新数据库？
只能延缓IO阻塞，并不能避免
3、直接更新缓存，定时批量更新数据库
这样IO的问题是解决了，但是数据在缓存里感觉很慌。
也没实践过真正的高并发系统，这种情况怎么解决？
----------补充----------
总结一下
就是已知直接插入和更新数据库将面临IO阻塞的风险，那么将数据最终实例化到数据库的过程是怎么样的。
Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
7
1726
收藏
写操作时无法直接避免的，如果你总在考虑“极端情况”那么就会忽略问题的重点。
先写入缓存，然后再持久化到磁盘中，楼主是担心缓存服务器挂了导致数据丢失？
一般生产环境下无论是应用服务器、数据库服务器还是缓存服务器，都不会是也不应该是单机的，至少都是主从的结构，一台挂了还有另一台顶着，在负载正常的情况下，单台挂的是几率本身就不是很高，更何况是两台同时挂了，而类似Redis可以做集群，所以如果部署正常的话，这个问题出现的可能性相当低。
楼主可以去了解一下
CAP理论，根据你的描述你想要达到的效果和CAP阐述的是差不多的，没有绝对完美的方案。谢邀，但我对处理这个问题没啥经验，只能从理论上说说
首先，加缓存是必然的，缓存的目录就是将处理不过来的东西暂存起来，延长等待时间。比如突然10分钟的高并发，引起需要处理的问题堆积，通过缓存，可以让这10分钟的内容在半个小时处理完。当然这里有一个假设，就是10分钟高并发后的时间里，没有太多需要处理的问题流入。
那么问题来了，如果后面的流入速度仍然很高，根本处理不过来怎么办？最近刚好学了一个词，backpressure，背压，最到背压最直接的处理办法是丢弃一部分内容。当然对于数据来说，你肯定不想丢弃，那就只能从处理效率上去想办法，所以使用扩展、集群、分流等一大堆的并发处理技术
以上都是个人理解，用的口水话，不够专业，仅供参考
这问题比较大，不同场景下的高并发也是有不同的方案的。
例如微博是高并发，金融系统也是高并发，前者就算发生信息丢失也问题不大，后者则对信息持久化有严格的要求。
还有你这个是高并发读还是高并发写？
是某时间段内高并发，还是持续性高并发？
没有说明前提条件，让人怎么回答？
楼主的这个问题,普遍存在大部分的应用,并且这个和系统是否高并发关系不是很大,我以前也有思考过类似的问题
浅谈缓存(二)
首先说一下缓存,我们的程序在绝大部分情况下,对缓存其实应该是"弱依赖”的,怎么去理解这个“弱依赖”呢?
我的理解是,我们的程序的数据的正确性在大部分情况下,都不会由缓存中的数据来判断,比如说"商品详情页商品的价格"其实就是缓存中的数据,但是我们在生成订单的时候的总价,必须要去数据库里面在查一遍.当然我说的是大部分情况,但是还有极少数情况下对数据正确性没那么严格(比如说抽象,安慰奖数量可以事先加载到缓存,后续业务需求可以直接通过缓存中的奖品数量来计算,因为根据一般业务,安慰奖都是一些对商家有利的附加比如说满100减5元,这个时候就算缓存挂掉,重新刷一遍对商家影响也是很小)
那有没有办法,能保证数据库和缓存强一致性呢?在这个过程中就涉及到分布式事务,双方实现X/Open XA协议,但是
redis目前还为实现该协议,并且由于在整个分布式中需要长时间锁资源,所以这种方式并不推荐使用(最终一致性还会有可能出现一段时间内数据不一致,这样会大大增加redis的复杂度)所以常用情况下,我们一般都是先保证数据库数据正确的情况下,同步/失效/异步去更新缓存