数据库集群的相关名词解释
1.同步
数据库客户端发出数据更新请求后,要等集群的每个节点全部更新后,才给客户端返回结果。
2.异步
数据库客户端发出数据更新请求后,接受请求的节点(这里往往是主数据库)立马给客户端返回结果,被更新的数据则会在接下来的某个时间里被复制传输到集群的其它节点上。
3.基于连接的负载均衡
此种负载均衡实现技术比较简单,就是在客户端发起登陆的时候,按照某种负载均衡算法,选择登陆到集群某台数据库,此后所有客户端的请求全部会发送到此数据库上。
4.基于请求的负载均衡
此种负载均衡实现技术比较复杂,但是功能强大,就是在客户端发起登陆的时候,集群网关会同时登录到集群各节点数据库,此后所有的客户端请求,经过集群网关的分析被分成两类,查询请求根据负载均衡算法挑选一个节点执行,数据更新请求则有主机执行并实时同步数据到集群各节点。
数据库集群的形式
数据库的集群和扩展不像应用程序扩展那样容易,因为从数据库端来说,一旦涉及到了集群,往往会涉及到数据库层面的同步,因此从是否存在数据冗余这个角度来讲,我们可以从大面上把数据库集群分为以下两种形式:
Share-Disk架构
Share-Disk架构是通过多个服务器节点共享一个存储来实现数据库集群,两台机器最简单的Share-Disk架构如图1所示。
图1.简单的Share-Disk架构
在此基础之上,Share-Disk架构又分为单活和双活,双活即为集群中的每一个节点都可以同时对外提供服务,而单活为集群中只有一个节点可对外提供服务,集群中的其他服务器作为冗余在“活”的节点出现故障时接替该服务器成为对外提供服务的节点。该类架构最典型的产品就是SQL Server Failover Cluster(SQL Server故障转移集群)、NEC的EXPRESSCLUSTER、ROSE的ROSE HA。这种方式的弊端也是显而易见的,如下:
- 硬件资源的严重浪费,同一时间集群中只有一台服务器活着,其他服务器只能作为冗余服务器。
- 集群无法提升性能,因为只有一台服务器可用
- 存储方面存在单点故障,除非在存储层级保证高可用,通常需要昂贵的SAN存储。
因此该类方案仅仅可以做到服务器层面的高可用,无法带来性能的提升,也无法解决存储单点故障的问题。因此如果不搭配其他高可用或负载均衡的技术,存在的意义并不是很大。
另一类技术是Share-Disk中的双活的技术,与单活技术不同的是,双活的技术虽然也是共享磁盘,但集群中的所有节点都可以对外提供服务,典型的产品就是Oracle的RAC。RAC的技术性非常的高,因此需要水平比较高的人来运维系统。RAC设计的初衷并不是为了性能,而是为了高可用和可扩展性,如果应用程序不是针对RAC架构设计和开发的,则将应用程序迁移到RAC上由于block contention (block busy waits)可能会导致性能的急剧下降,并且节点越多性能下降越明显。
Share-Nothing架构
Share-Nothing架构又分为两种,首先是分布式架构。将数据库中的数据按照某一标准分布到多台机器中,查询或插入时按照条件查询或插入对应的分区。
另一种是每一个节点完全独立,节点之间通过网络连接,通常是通过光钎等专用网络。如图2所示。
图2.Share-Nothing冗余架构
在Share-Nothing架构中,每一个节点都拥有自己的内存和存储,都保留数据的完整副本。通常来说,又可以分为两种,可以负载均衡和不可以负载均衡。
首先谈谈不可负载均衡的集群,在不可负载均衡的技术中,集群中的节点会被分为主节点和辅助节点,主节点向外提供服务,辅助节点作为热备(二阶段事务提交)或暖备(不需要保证事务同步),同时有可能使得辅助节点提供只读的服务。使用这个架构的技术包括:SQL Server AlwaysOn,SQL Server Mirror,Oracle Data Guard这种架构带来的好处包括:
- 辅助节点数据和主节点保持同步或准同步,当搭配第三方仲裁后,可以实现自动的故障转移,从而实现了高可用
- 辅助节点由于和主节点完全独立且数据同步或准同步,因此主节点出现数据损坏后,可以从辅助节点恢复数据(自动或手动)
- 由于Share-Nothing架构使用了本地存储(或SAN),相较于Share-Disk架构在慢速网络时有非常大的性能优势
当然,弊端也显而易见,因为辅助节点无法对外提供服务或只能提供只读服务,因此该类集群的弊端包括:
- 扩展能力非常有限
- 对性能没有提升,因为涉及到各节点的数据同步,甚至带来性能的下降
- 辅助节点如果可读,虽然提升性能,但需要修改前端应用程序,对应用程序不透明
另一类Share-Nothing架构中,是允许负载均衡的。所谓负载均衡就是将对数据库的负载分布到集群中的多个节点上,在集群中的每一个节点都可以对外提供服务,从而达到更高的吞吐量,更好的资源利用率和更低的响应时间。前端通过代理进行调度。使用该类架构的技术包括:MySQL上的Amoeba(架构如图3,摘自MySQL大师陈畅亮的博客:http://www.cnblogs.com/gaizai/archive/2012/06/12/2546755.html),MySQL上的HA Proxy(如图4所示),格瑞趋势在SQL Server上的Moebius集群(如图5所示)。
图3.Amoeba
图4.HA Proxy
图5.Moebius集群
可负载均衡的Share-Nothing架构的好处是每台服务器都能提供服务,能充分利用现有资源,达到更高的吞吐量。其中Amoeba中可能会涉及到数据分片,数据分片的好处是对于海量数据的处理更加高效,但同时也引入了其他问题,比如说需要应用程序端对应数据分片进行调整、跨分片节点查询的处理问题、每一个数据分片节点是否能够承受各自业务负载的高峰问题等。该类架构需要实施的人员水平比较高,且需要应用层面做调整,因此更适合于互联网企业。
另一类不涉及到数据分片的架构,比如一类可以使用组合方案,比如说Oracle RAC+F5。另一类是使用单个厂商提供的方案,比如说SQL Server上的Moebius。这类方案集群中的每个节点都会对外提供服务,因此有如下好处:
由于每一个节点都可以对外提供服务,因此可以提升性能
扩展性得到提升,可以通过向集群添加节点直接进行Scale-Out扩充
由于前端应用通过代理连接到集群,而集群中的每一个节点都保持完整的数据集,因此不存在分片不到位反而造成性能下降的问题,因此对应用程序端完全透明
但相比较于MySQL的数据分片,该类方案的弊端也显而易见,因为每一个节点都需要完整的数据集,因此需要占用更多的存储空间。
转载:http://www.youkuaiyun.com/article/2014-05-15/2819786-Cloud-BigData-Database