记得在上一篇文章“Java集群--大型网站是怎样解决多用户高并发访问的”的结尾处本人阐述了数据库的高可用的一种方案----实现主从部署,那么今天,就让我聊聊本人关于数据库的一些所思所想吧!

  下面是本人对数据库的高可用性的一些看法:

    提出原因:当网站或运用为用户提供服务时,防止单点故障问题,并且通过一定的分发策略来提升数据库的安全性和可用性。

    问题注重点:架构的可拓展性,而常用的拓展手段有两种,分别是Scale-up和Scale-out。那么何为Scale-up和Scale-out呢?Scale-up即纵向拓展,通过替换为更好的机器和资源来实现伸缩,提升服务能力;Scale-out即横向拓展,通过加节点(机器)来实现伸缩,提升服务能力。然而对于互联网的高并发运用来说,无疑Scale-out才是出路,它的理想状态是一个服务,当面临更高的并发的时候,能够通过简单增加机器来提升服务支撑的并发度,且增加机器过程中对线上服务无影响。

  对于大部分的小型运用,我们经常会把所有的数据存放在一个服务器上的一个数据库上,以此来满足小型数据的读取和写入功能(架构图如下)。

  

  对于这种架构,它的瓶颈是:

    1.读写都在同一个数据库实体上,使得数据库的读写压力增大,响应用户的时间就会相应的加长

    2.而且随着数据量的增大,大到数据库的实体的容量已经放不下,那么这种架构拓展起来就非常麻烦了。看到这里千万别说“直接再加一台服务器不就行了吗?”

    3.所有的数据都放在同一个服务器上,如果这台服务器挂掉了,这个系统也瘫痪了,更坑的是,如果这台服务器已经被破坏的体无完肤了(可能是地震),那么之前的数据也就无法再次获取了,即系统的容灾性差。(PS:也许你很期盼某个网站出现这种情况,这样女朋友的账单就不用付了。。。别想太多,一般比较大型的网站,都会把数据备份到不同的服务器的数据库上,而且相邻两台服务器不止相隔甚远,连在同一个经度和纬度都是尽量避讳的)

  通过上面的分析可知,在单库中,运用的系统性能是比较低的,而且容灾性差,所以作为一名比较负责任的代码写手,怎么能够忍受这种响应速度慢且又不可靠的架构出现在自己的项目中呢?看到这里,也许你会想到把我们的数据放到多台的服务器上的数据库中,这样容灾性就好很多了,而且如果在数据库的前面再加上一个代理,实现数据库操作语句的分发策略,这样子每台服务器的数据库的操作的压力也就减少了,也就是程序响应用户的速度也相应加快了,恩恩,你的想法已经能解决上面的单机版的有些问题了,但你可知道你的这种架构有个很好听的名字吗?不绕弯子了,它就是负载均衡技术(这里就以数据库按垂直切分来讨论讨论这套架构吧!PS:另外一种数据库切分方案是水平切分)

  如何通过负载均衡技术来实现数据库的集群呢?先上总体架构图(这里的数据库暂时以mysql为例)

  

  实现原理:首先要有一个可以控制连接数据库的控制端(比如这里的mycat,mycat的前生是阿里巴巴的cobar,所以感觉不会太差),在这里,它截断了数据库与程序的直接连接,由所有的程序来访问这个中间层,然后再由中间层来访问数据库。这样我们就可以根据数据库的当前负载采取有效的均衡策略,来调整每次连接到哪个数据库。

  如果采用mycat来作为mysql集群的代理,我们可以比较容易的实现上图的总体架构,在正常的情况下,只有一台“写”节点(上图的Master1)负责数据库的所有写操作,其他的从(上图的slave1~5和Master2)或主从数据库来充当“读”的角色,一旦Master1挂掉之后,mycat会把它切换到Master2,且把Master1下的所有从节点(slave1~3)也同时从“读”节点剔除掉(PS:想想这样有什么好处),这样负责“读”的就有Slave4、5,一旦Master1心跳恢复,他就变成了“写”节点Master2的主从节点了。  

  当然,mycat是没有帮我们实现数据库之间数据的同步的问题的,但我们可以使用mysql自带的Master-Slave Replication方式来实现每个数据库的同步,但又很不幸,这种方式并不能完全的保证服务器上的数据都是实时同步的,如果你的程序没有做一些特殊的处理,那么这种方式只能说是“保证数据最终结果的一致性”。

  其实,针对mysql来说,这种架构其实还有一项非常重要的优化措施,不知读者有没有发现,我们在上面的第二个架构中使用了数据库的读写分离,我们都知道,mysql的数据库引擎主要是有两大类(Innodb和MyIsam),其中,我们知道MyIsam在查询时的性能会比较高,所以,在本次架构中,我们会把“写”节点的数据库引擎改为Innodb,而把“读”节点改为MyIsam引擎。

  一家之言,欢迎各位前辈的拍砖。

  最近在看“深入理解Java虚拟机”一书,所以后续会写一篇文章来简洁介绍关于Java GC的秘密。

MYSQL高可用(HA)随想的更多相关文章

  1. Mysql高可用(HA)

    MySQL特点: 1) 开放的源代码的关系型数据库 2) 适应于所有平台 3) 支持多线程,充分利用CPU资源,性能很出色 4) 价格便宜 5) 大数据库能处理5000万条记录. ACID 事务 一组 ...

  2. MySQL高可用HA——keepalived配置

    0. Keepalived介绍   Keepalived是基于VRRP(Virtual Router Redundancy Protocol,虚拟路由器冗余协议)协议的一款高可用软件.Keepaili ...

  3. MySQL高可用解决方案(MySQL HA Solution)

    http://blog.sina.com.cn/s/blog_7e89c3f501012vtr.html 什么是高可用性?很多公司的服务都是24小时*365天不间断的.比如Call Center.这就 ...

  4. Corosync+Pacemaker+DRBD+MySQL 实现高可用(HA)的MySQL集群

    大纲一.前言二.环境准备三.Corosync 安装与配置四.Pacemaker 安装与配置五.DRBD 安装与配置六.MySQL 安装与配置七.crmsh 资源管理 推荐阅读: Linux 高可用(H ...

  5. MySQL高可用架构之MHA

    简介: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是 ...

  6. Heartbeat+DRBD+MySQL高可用方案

    1.方案简介 本方案采用Heartbeat双机热备软件来保证数据库的高稳定性和连续性,数据的一致性由DRBD这个工具来保证.默认情况下只有一台mysql在工作,当主mysql服务器出现问题后,系统将自 ...

  7. MySQL高可用读写分离方案预研

    目前公司有需求做MySQL高可用读写分离,网上搜集了不少方案,都不尽人意,下面是我结合现有组件拼凑的实现方案,亲测已满足要求,希望各位多提建议 :) 一.    网上方案整理(搜集地址不详...) 1 ...

  8. MySQL高可用之MHA的搭建 转

     http://www.cnblogs.com/muhu/p/4045780.html http://www.cnblogs.com/gomysql/p/3675429.html http://www ...

  9. MySQL高可用基础之keepalived+双主复制【转】

    环境:MySQL-VIP:192.168.1.3MySQL-master1:192.168.1.1MySQL-master2:192.168.1.2 OS版本:CentOS release 6.4 ( ...

随机推荐

  1. ubuntu环境ceph配置入门(一)

    环境:ubuntu server 14.04 64bit,安装ceph版本号0.79 正常情况下应有多个主机,这里为了高速入门以一台主机为例,多台主机配置方式类似. 1. 配置静态IP及主机名 静态I ...

  2. alv 显示 汇总数据

    alv中有 字段设置 gs_fieldcat-do_sum = ‘1’.字段  用于控制汇总

  3. 如何设置Java虚拟机内存以适应大程序的装载

    Java虚拟机对于运行时的程序所占内存是有限制的,当我们的项目或者程序很大时,往往会照成内存溢出. 举个例子: public class SmallTest1 { public static void ...

  4. Lucene.Net 2.3.1开发介绍 —— 三、索引(五)

    原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(五) 话接上篇,继续来说权重对排序的影响.从上面的4个测试,只能说是有个直观的理解了.“哦,是!调整权重是能影响排序了,但是好像没办法来 ...

  5. address_space 从哪里来

    address_space 从哪里来 这两天想弄清楚linux的内存分配,忽然看到了address_space,就想弄明白. 整个内核就见到 address_space(1)和address_spac ...

  6. Android自己定义控件——3D画廊和图像矩阵

    转载请注明出处:http://blog.csdn.net/allen315410/article/details/39932689 1.3D画廊的实现 我们知道android系统已经为我们提供好了一个 ...

  7. 深入探讨:LBS是一种工具而非一种模式

    移动互联网的快速发展,带动着移动互联网应用的不断创新.从2010起,LBS的概念就在中国迅速兴起,但到了2011年底提供LBS服务的企业从最多50家已经降至仅剩15家.投行在看好移动互联网的同时又对L ...

  8. 数字雨Shopex 4.8.5 SQL Injection Exp

    # -*- coding:utf-8 -* #Author:MXi4oyu #Email:798033502@qq.com #Shopex 4.8.5 SQL Injection Exp #转载请说明 ...

  9. hdu 3832 Earth Hour (最短路变形)

    Earth Hour Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 125536/65536 K (Java/Others) Tota ...

  10. TR90眼镜_百度百科

    TR90眼镜_百度百科 TR90眼镜