V-xin:ruyuanhadeng获得600+页原创精品文章汇总PDF
前 言
读写分离方案上线后,订单sql查询时间再一次稳定在了300ms以下,此时对数据的增删改操作会走主库,而读请求会走从库,通过读写分离大大提升了数据读的处理能力,但遗憾的是没办法提升主库写数据的能力。
新的挑战
那么什么时候主库写数据的压力会过大呢?其实我们之前也聊过这个问题,那就是多个业务共用一个物理数据库的,比如商品相关的表、订单相关的表和用户相关的表等,所有表都放到了一个mysql数据库中,就像这样:
此时商品模块、订单模块、用户模块都部署在同一台物理数据库上,说白了就是主库上,那么此时这台物理数据库的CPU、内存和网络的负载能力,都是商品模块、订单模块、用户模块共用的。
这就很尴尬了,由于这3个模块是共用同一台数据库的资源,那么就势必会相互影响,比如某一天商品模块做了一些活动,尴尬的是商品模块并没有做读写分离,那么这个时候可能商品模块,会对这台物理数据库进行大量的读操作,此时这台物理数据库的CPU、内存和网络负载占用都很高。
而数据库的资源是有限的,既然商品模块占用了大量的数据库资源,那么留给订单模块可用的资源就非常少了,这个时候就会导致订单库写数据很慢,写入一条订单数据突增到了2s,对于订单来说,这个肯定是万万不能接受的
那么有没