转载

基于MySQL的高可用可扩展架构探讨

注:原文已发表于《程序员》杂志关系型数据库60周年特刊

随着信息量飞涨,信息的存储成为了这个时代至关重要的一项技术。如何来保证数据存储技术能够适应信息量的增长速度和我们对信息的高度依赖,成为一个非常重要的课题。本文将从数据库架构的层面,通过以开源的数据存储软件来构建分布式数据层的思路,期望实现一个低成本的高可用可扩展的数据层架构。

传统数据库架构

纵观各传统商业数据库软件,多以集中式架构为主,鲜有以分布式为设计理念的架构。这些传统数据库软件的最大特点就是将所有的数据都集中在一个数据库中,依靠大型高端设备来提供高处理能力和扩展性。

集中式数据库架构在扩展性方面主要依赖于主机和存放数据的存储设备的扩展能力,也就是说依赖硬件本身的纵向扩展能力,很难做到较好的横向扩展。而其可靠性也同样是以硬件设备为依托,主要通过Share Storage的方式来实现。如大家所熟知的传统商业数据库代表厂商Oracle的RAC,就是一个非常典型的Share Everything 的集中式架构。

我们可以通过图1来简单地描绘一下传统数据库的典型架构:传统架构在主机端大多通过两台主机共享存储设备,平时其中一台主机使用存储通过数据库软件来管理。这样的架构只能有一台主机(RAC除外)上的数据库能够提供服务,另一台主机只能是作为热备冗余,不能启动数据库实例提供服务。所以,其处理能力就完全取决于这台主机的最大扩展能力,很难通过增加主机数量来增加处理能力。而单台主机的扩展能力毕竟是有限的,即使是某些厂商的大型机,同样也有其扩展限制。此外,传统架构对高端设备的依赖,无疑将直接导致系统成本的大幅度增加,甚至可能会导致系统被主机和硬件厂商所“绑架”,不得不持续增加投入成本。

基于MySQL的高可用可扩展架构探讨

图1 传统数据库的典型架构

基于MySQL的可扩展和高可靠

MySQL 作为开源数据库的佼佼者,无论是软件本身的设计思想,还是推崇给广大使用者们常用的架构思路都和传统的商业数据库软件大相径庭。MySQL弃用了传统的 Share-Everything的思想,而采用了Share-Nothing的思想。MySQL的Replication实现机制,以及 MySQL Cluster的架构设计,都体现了这一思想。也正因如此,给MySQL在可扩展性和高可靠性方面带来了非常灵活的架构设计思路,也让我们的数据库可以摆脱对高端设备的依赖,使用上性价比高很多的PC Server。

可扩展性

在提升扩展性方面,最为常用的是通过MySQL自身的Replication功能,将同一份MySQL的数据以异步的方式同时复制到另外的一台或多台 MySQL主机上,并让这些MySQL主机同时对外提供查询服务。每增加一个复制的节点,查询处理能力也得到相应的增加,新增节点的处理能力就是整个系统增加的处理能力。由于MySQL Replication主要是逻辑方式,同一个集群中可有多家厂商的硬件,也可以使用不同的OS,所以可以做到完全不受任何软/硬件平台限制,摆脱对单一平台的依赖。

人们可能会对MySQL Replication的功能特性不满意,进而通过第三方开源软件,甚至是通过解析其开源的通信协议自行开发出来的复制软件来进行数据实时(或者异步)复制来达到 Replication完全相同甚至更好的效果。传统数据库可能也具有某项功能实现数据的复制,但与MySQL相比,由于只依靠数据库本身特性来完成,在架构的灵活性和可控性方面存在一些不足。

最后,在提升扩展性方面不得不说的数据切分(横向/纵向)的思想,同样可以在MySQL数据库上得到灵活的发挥,无论是以功能模块的方式进行纵向的切分,还是以某个特定键(字段)的类HASH分段的方式进行横向的切分,抑或是通过数据库本身的Partition功能进行切分,都可以在MySQL上得到很好的实现。当然,无论是切分前的数据分散,还是切分后的数据路由和合并都离不开应用层的协作与配合,除非通过MySQL Cluster来实现。对于提升扩展性的架构,通过图2会有一个更为直观的展现。

基于MySQL的高可用可扩展架构探讨

图2 能够提升扩展性的架构

图中以“Master”为核心,通过不同的方式以三条“路线”将数据复制到相应的 MySQL 集群中对外提供服务。实际的架构中,Master就是一个数据写入点,复制出去的集群则可以对外提供相应的查询请求。常见的Web应用系统中,查询请求远远大于写入请求,所以非常适合通过MySQL 数据库使用类似的架构思想来解决实际的扩展性问题。

高可靠性

在保证高可靠性方面,同样可以通过MySQL的 Replication 为基础,加以应用层架构的简单配合或一些开源的第三方HA管理软件来设计出多种非常灵活的高可靠架构。

对于数据写入点,可以通过MySQL的Replication功能,将两台MySQL主机设置成双A的状态,并通过HA管理软件,对MySQL的状态检测,来判定MySQL的状态,并对外提供供单一的服务 IP 地址,以确保在任何时候有一台MySQL崩溃后马上切换到另外一台MySQL上提供服务。这样自动的方式非常方便地让我们的写入点拥有高可靠性。如果我们的应用程序也可以自动判断当一个点失效后马上自动切换到另外一个点就更好,基本上可以做到对外部完全透明的切换,对可用性的影响之小,比现在一些知名厂商的专业HA管理都要好很多。

对于数据查询点,高可靠性的实现就更容易了,可从双A的两台Master端中的任意一台上通过数据复制搭建多个具有完全相同数据拷贝的MySQL节点,来保证任何时刻都可以有多台MySQL对外提供数据查询服务。当一台MySQL崩溃,系统马上将该节点从可以服务的节点中剔除出去。通过应用架构的帮助这是非常容易做到的事情。

图 3是高可靠性实例图。1描绘了基本架构,2、3和4分别描绘了当读节点失效以及写节点中的任何一个失效后的高可靠性实现。在高可靠性方面,除了自行控制将数据复制到多个MySQL主机上的方式之外,MySQL还提供了更为高级的方案――MySQL Cluster,一个完全的分布式数据库集群,而且是一个非常典型的Share-Nothing的分布式数据库架构。数据层和SQL层分离,每份数据都以两份或更多份拷贝存放在不同的数据节点上,整个数据层的所有节点以分布式计算的思想共同处理整个数据库的数据,在保证高并发的处理能力的同时,以数据冗余的方式保证了高可靠性。

基于MySQL的高可用可扩展架构探讨

图3 高可靠性实例图

构建基于MySQL、Cache 和Search的数据层

随着Web应用系统负载的增速越来越快,常让系统不堪重压,数据库系统尤甚。而随着对用户体验关注度的提高,响应速度和使用的便利性则成为不可避免的话题。无论如何优化都不可能避免磁盘物理I/O的响应速度与内存中的I/O速度不匹配的问题,所以很自然地想到了通过内存Cache的方式来提高响应速度。

在使用的便利性方面最为典型的就是数据搜索。关系型数据库的特性,决定了它很难提供类似于Google那样的可以全文检索的搜索系统。我们再次以借助“外力”的方式来完善服务,将数据库中的数据通过利用Lucene或者Egothor等类似的搜索引擎系统,或者是利用Sphinx之类的软件和数据库集成,为数据库增加全文检索的能力。

可以设计出一个以数据库(My-SQL)来完成持久化和常规的数据访问功能,以分布式内存Cache系统来提供对响应速度和并发能力极高的数据的访问,以第三方或者自行研发的分布式全文搜索系统来提供全文检索服务的全方位的分布式数据服务层,中间则通过应用架构的帮助实现一个统一的数据访问层,来控制数据的读取写入检索等操作,如图4所示:让MySQL中的数据同步(或异步)写入到Cache和Search系统的实现方式很多,如对实时性要求不是很高,也不希望Data Proxy Layer中有太多的控制逻辑,完全可以通过队列的方式以异步的方式实现;如对实时性要求较高,也可以通过 Data Proxy Layer这一层应用来控制Cache和Search中的数据更新;甚至还可以通过MySQL的用户自定义函数,以 Trigger的方式将数据实时地更新到Cache集群。类似的方式可以想出很多,关键是要根据应用场景,来选择最合适、最简单的方式来实现。

基于MySQL的高可用可扩展架构探讨

图4 数据写入Cache和Search系统的实现方式

架构无所谓最好的,只有最合适的。任何架构都有其适用的场景,也有其相应的生命周期。应用场景或业务量的变化,都可能导致架构不足以应对的现象。引用一句电影台词:“出来混,迟早要还的!”

觉得文章有用?立即:和朋友一起 共学习 共进步!

建议继续学习:

  1. MySQL数据库在实际应用一些方面的介绍    (阅读:34800)
  2. 我对技术方向的一些反思    (阅读:9142)
  3. Using MySQL as a NoSQL    (阅读:5047)
  4. 可扩展的分布式数据库架构    (阅读:4123)
  5. MySQL协议分析    (阅读:3837)
  6. MySQL和MongoDB设计实例对比    (阅读:3213)
  7. Oracle or MySQL ?    (阅读:2926)
  8. 用Mysql来搭建可扩展的SNS网站    (阅读:2862)
  9. 利用MySQL Cluster 7.0 + LVS 搭建高可用环境    (阅读:2859)
  10. cacti 增加 Mysql 监控    (阅读:2815)

QQ技术交流群:445447336,欢迎加入!

扫一扫订阅我的微信号:IT技术博客大学习

原文  https://blogread.cn/it/article/2347?f=hot1
正文到此结束
Loading...