像传统的数据库,让大家去排队,尽量利用性能,只能一定程度上缓解这个问题。业界上有2种操作,一个是采用云原生的架构,采用存储计算分离,像PolarDB可以做一写多读。现在PolarDB一个实例可以做一个大到接近100T的存储,上面可以做一写多读16个节点。按照当时并发的需求,尤其是对只读并发高的应用,就按量去弹出来的只读节点,一两分钟就弹出一个新的节点,峰值过去之后就可以释放了。
如果写的并发特别多可以采用PolarDB 2.0,所有的计算节点每一个计算节点都可以做写和读。
写和写的冲突问题可以在多写和多读的时候,就要想办法在共享状态这一层。
还有一种解决方法是用分布式,或者有些传统企业用的中间件分库分表或者分布式数据库。因为可以把并发并行的或者分布式放到多个节点上去。这里面也有挑战,挑战非常大,因为一旦对数据进行了分库以后,每个分区都非常容易被并行化。很多时候要做跨区域的查询,依赖两个或三个Partition或者Share上的数据,就需要做跨库的事务处理和查询,这个对系统性能影响非常非常大。但在很多应用场景上,可能并发是很高但做跨库的这种冲突事务的量可能不会太高。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。