聊一聊读写分离
前言
我司在618、双11等各种大促活动的时候,系统都要面对大量的访问量,数据节点的吞吐量也成为整个系统的瓶颈。
所以为了提升数据节点的吞吐量和可用性,我们不仅仅要做数据分片,还需要分析一下同一时刻的读写操作比,对于读多写少的系统来讲,可以把数据节点拆分为主节点和从节点,主节点负责处理事务性的增删改操作,从节点负责处理查询操作(就像公司的产品负责谈跟业务谈需求、聊业务,而开发人员负责具体的业务实现),能够有效的避免由数据更新导致的行锁,使得整个系统的查询性能得到提升。

一主多从
通过一主多从的方式,我们可以将查询请求均匀地分散到多个从数据节点上,来提升系统的查询能力(这里有个小技巧,从数据节点太多的话,可以从主数据节点先同步到一个从数据节点,再从这个从数据节点同步到其他的从数据节点)。

多主多从
使用多主多从的方式,不但能够提升系统的吞吐量,还能够提升系统的可用性,可以做到在任何一个数据节点宕机(主数据节点或者从数据节点),甚至所在的服务器的磁盘物理损坏的情况下系统仍正常运行。

与将数据根据分片键规则存放到各个数据节点的水平分片不同,读写分离则是根据SQL语义的分析,将读操作和写操作分别路由至主数据节点与从数据节点(这种处理相对来说简单些)。

读写分离的数据节点中的数据是一致的,而水平分片的每个数据节点的数据并不相同(因为数据是根据分片策略处理的,如果一直的话那就叫做读写分离)。将读写分离和水平分片一起使用,能够有效地提升系统性能。
问题
读写分离虽然可以提升系统的吞吐量和可用性,但同时也带来了数据不一致的问题。这包括主节点与主节点之间的数据一致性,以及主节点与从节点之间的数据一致性的问题。
读写分离也带来了与数据分片同样的问题,它同样会使得开发人员和运维人员对数据库的操作和运维变得更加复杂。
想想看,数据节点经过数据分片,然后再经过读写分离,在单数据节点的时候,你执行一条SQL,有问题的时候只要看这个数据节点就可以;但现在这么复杂的数据环境,你需要知道分片规则,还要确定主节点和从节点数据是否一致等等。

写在最后
好兄弟可以点赞并关注我的公众号“javaAnswer”,全部都是干货。
