大型网站架构设计-MySQL 大数据大并发支持

2014-11-22 14:02:33     64 人阅读    

随着互联网行业的高速发展,使得采用诸如IOE等商用存储解决方案的成本不断攀升,越来越难以满足企业高速发展的需要;因此,开源的存储解决方案开始逐渐受到青睐,并成为互 联网企业数据存储的首选方案。

MySQL为例,它作为开源关系型数据库的典范,正越来越广泛地被互联网企业所使用。企业可以根据业务规模的不同的阶段,选择采用不同的系统架构,以应对逐渐增长的访问压力 和数据量;并且随着业务的发展,需要提前做好系统的容量规划,在系统的处理能力还未达到极限时,对系统进行扩容,以免带来损失。

1.             业务拆分

业务发展初期为了便于快速迭代,很多应用都采用集中式的架构。随着业务规模的扩展,使系统变得越来越复杂,越来越难以维护,开发效率越来越低,并且系统的资源消耗也越来越 大,通过硬件提升性能的成本也越来越高。因此,系统业务的拆分是难以避免的。


举例来说,假设某门户网站,它包含了新闻、用户、帖子、评论等几大块内容,对于数据 库来说,它可能包含这样几张表,如newsuserspostcomment,如图2-5所示。

2-5 single DB的拆分


 

随着业务的不断发展,单个库的访问量越来越大,因此,不得不对业务进行拆分。每一块 业务都使用单独的数据库来进行存储,前端不同的业务访问不同的数据库,这样原本依赖单库的服务,变成4个库同时承担压力,吞吐能力自然就提高了。

顺带说一句,业务拆分不仅仅提高了系统的可扩展性,也带来了开发工作效率的提升。原来一次简单修改,工程启动和部署可能都需要很长时间,更别说开发测试了。随着系统的拆分, 单个系统复杂度降低,减轻了应用多个分支开发带来的分支合并冲突解决的麻烦,不仅大大提高了开发测试的效率,同时也提升了系统的稳定性。

2.              复制策略

架构变化的同时,业务也在不断地发展,可能很快就会发现,随着访问量的不断增加,拆分后的某个库压力越来越大,马上就要达到能力的瓶颈,数据库的架构不得不再次进行变更, 这时可以使用MySQLreplication (复制策略来对系统进行扩展。

通过数据库的复制策略,可以将一台MySQL数据库服务器中的数据复制到其他MySQL 数据库服务器上。当各台数据库服务器上都包含相同数据时,前端应用通过访问MySQL集群 中任意一台服务器,都能够读取到相同的数据,这样每台MySQL服务器所需要承担的负载就会大大降低,从而提高整个系统的承载能力,达到系统扩展的目的。

如图2-6所示,要实现数据库的复制,需要开启Master服务器端的Binary log数据复制的


过程实际上就是Slavemaster获取binaiy log然后再在本地镜像的执行日志中记录的操作。 由于复制过程是异步的,因此MasterSlave之间的数据有可能存在延迟的现象,此时只能够 保证数据最终的一致性。


 

MySQL的复制可以基于一条语句(statement level),也可以基于一条记录(row level)。通

row level的复制,可以不记录执行的SQL语句相关联的上下文信息,只需要记录数据变更 的内容即可。但由于每行的变更都会被记录,这样可能会产生大量的日志内容,而使用statement level则只是记录修改数据的SQL语句,减少了 binary log的日志量,节约了 I/O成本。但是, 为了让SQL语句在Slave端也能够正确地执行,它还需要记录SQL执行的上下文信息,以保证所有语句在Slave端执行时能够得到在Master端执行时的相同结果。

在实际的应用场景中,MySQLMasterSlave之间的复制架构有可能是这样的,如图 2-7所示。

前端服务器通过Master来执行数据写入的操作,数据的更新通过Binary log同步到Slave 集群而对于数据读取的请求则交由Slave来处理这样Slave集群可以分担数据库读的压力, 并且读、写分离还保障了数据能够达到最终一致性。一般而言,大多数站点的读数据库操作要比写数据库操作更为密集。如果读的压力较大,还可以通过新增Slave来进行系统的扩展,因 此Master-Slave的架构能够显著地减轻前面所提到的单库读的压力。毕竟在大多数应用中,读的压力要比写的压力大得多。 [1]

2-7 Master-Slaves 复制架构


 

Master-Slaves复制架构存在一个问题,即所谓的单点故障。当Master宕机时,系统将无法 写入,而在某些特定的场景下,也可能需要Master停机,以便进行系统维护、优化或者升级。 同样的道理,Master停机将导致整个系统都无法写入,直到Master恢复,大部分情况下这显然是难以接受的。为了尽可能地降低系统停止写入的时间,最佳的方式就是采用Dual-Master架构, 即Master-Master架构,如图2-8所示。


 

2-8 MySQL Dual-Master 架构

所谓的Dual Master实际上就是两台MySQL服务器互相将对方作为自己的Master自己作为对方的Slave这样任何一台服务器上的数据变更,都会通过MySQL的复制机制同步到另 一台服务器。当然,有的读者可能会担心,这样不会导致两台互为MasterMySQL之间循环 复制吗?当然不会这是由于MySQL在记录Binary log日志时记录了当前的server-idserver-id 在我们配置MySQL复制时就已经设置好了。一旦有了 server-idMySQL就很容易判断最初的 写入是在哪台服务器上发生的,MySQL不会将复制所产生的变更记录到Binary log这样就避 免了服务器间数据的循环复制。

当然,我们搭建Dual-Master架构,并不是为了让两个Master能够同时提供写入服务,这样会导致很多问题。举例来说,假如Master AMasterB几乎同时对一条数据进行了更新,对 Master A的更新比对Master B的更新早,当对Master A的更新最终被同步到Master B时,老版 本的数据将会把版本更新的数据覆盖,并且不会抛出任何异常,从而导致数据不一致的现象发生。在通常情况下,我们仅开启一台Master的写入,另一台Master仅仅standby或者作为读库开放,这样可以避免数据写入的冲突,防止数据不一致的情况发生。

在正常情况下,如需进行停机维护,可按如下步骤执行Master的切换操作:

(1)  停止当前Master的所有写入操作。

(2)  Master上执行set global read_only=1,同时更新MySQL配置文件中相应的配置,

避免重启时失效。

(3)  Master 上执行 show Master status,以记录 Binary log 坐标。

(4)  使用 Master 上的 Binary log坐标,在 standby Master 上执行 select Master_pos_wait(), 等待 stand by Master Binary log 跟上 Master Binary log

(5)  stand by Master 开启写入时,设置 read_only=0

(6)  修改应用程序的配置,使其写入到新的Master

假如Master意外宕机,处理过程要稍微复杂一点,因为此时Masterstandby Master上的 数据并不一定同步,需要将Master上没有同步到standby MasterBinary log复制到Master上 进行replay,直到stand by Master与原Master上的Binary log同步,才能够开启写入;否则,

这一部分不同步的数据就有可能导致数据不一致。


原文地址:http://www.itmmd.com/201411/206.html
该文章由 萌萌的IT人 整理发布,转载须标明出处。

大型网站架构设计-mysql分表与分库   上一篇
下一篇  大型网站架构设计-持久化存储介绍

精彩回复
发表评论
姓名:       

《程序员app》专门为程序员量身定做!