高并发的后台如何处理数据库的更新与插入操作

Question

今天忽然想到一个问题
对于高并发条件下，后台对数据的更新和实例化是怎么进行的？

1、直接插入数据库，然后更新缓存？
这样这个更新操作将会有IO阻塞风险吧、

2、直接更新缓存，然后使用消息队列更新数据库？
只能延缓IO阻塞，并不能避免

3、直接更新缓存，定时批量更新数据库
这样IO的问题是解决了，但是数据在缓存里感觉很慌。

也没实践过真正的高并发系统，这种情况怎么解决？

----------补充----------

总结一下

就是已知直接插入和更新数据库将面临IO阻塞的风险，那么将数据最终实例化到数据库的过程是怎么样的。

Answer 1

写操作时无法直接避免的，如果你总在考虑“极端情况”那么就会忽略问题的重点。

Answer 2

谢邀，但我对处理这个问题没啥经验，只能从理论上说说 首先，加缓存是必然的，缓存的目录就是将处理不过来的东西暂存起来，延长等待时间。比如突然10分钟的高并发，引起需要处理的问题堆积，通过缓存，可以让这10分钟的内容在半个小时处理完。当然这里有一个假设，就是10分钟高并发后的时间里，没有太多需要处理的问题流入。 那么问题来了，如果后面的流入速度仍然很高，根本处理不过来怎么办？最近刚好学了一个词，backpressure，背压，最到背压最直接的处理办法是丢弃一部分内容。当然对于数据来说，你肯定不想丢弃，那就只能从处理效率上去想办法，所以使用扩展、集群、分流等一大堆的并发处理技术 以上都是个人理解，用的口水话，不够专业，仅供参考

Answer 3

这问题比较大，不同场景下的高并发也是有不同的方案的。 例如微博是高并发，金融系统也是高并发，前者就算发生信息丢失也问题不大，后者则对信息持久化有严格的要求。 还有你这个是高并发读还是高并发写？ 是某时间段内高并发，还是持续性高并发？ 没有说明前提条件，让人怎么回答？