记得在上一篇文章“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的秘密。
http://www.cnblogs.com/wanggangjia/p/5400353.html