持续可用与CAP理论

  • 时间:
  • 浏览:1
  • 来源:大发5分6合_大发5分6合官网

小结

共享存储与硬件处理方案

持续可用

共享存储本质上是硬件处理方案,相比Paxos处理方案,优势是简单心智性成熟期期的句子图片 ,在商用数据库中广泛使用。问题报告 在于成本高,且依赖硬件一种生活生活高可靠和高性能,也无法跨IDC部署,非要容忍单台服务器故障,无法容忍单个IDC故障。

CAP理论的作者Eric Brewer之后其实也写过一篇文章来说明一种生活生活问题报告 :<<CAP twelve years later>>:当存在网络分区时,系统不能进入分区模式,将网络不通的节点从系统中剔除后分区恢复,系统继续运行。

与性能相关联的一个问题报告 是成本。前面不可能 提到,基于Paxos的持续可用方案大慨 还要一主两备,不可能 数据总是有三份,其实比较浪费。一个做到极致的系统应该不能只还要一个副本,第一个副本只存储redo日志即可。

CAP理论网上传了什么都版本,大致的意思是:一致性,可用性和分区可容忍性三者非要取其二,不可兼得。不可能 分区可容忍性是不可选者的,否则,系统设计时非要在一致性和可用性之间权衡。这就带来了一个很悲观的结论:持续可用无法实现。然而,事实是原先吗?

Paxos与持续可用 

Paxos是图灵奖获得者Lamport的经典之作,第一个版本的论文叫做:<<The Part-time Parliament>>。Lamport奠定了什么都分布式系统的理论基础,比如:<<Time, Clocks and the Ordering of Events in a Distributed System>>。据传(八卦,不确信)Lamport通过讲故事的最好的法子讲”拜占庭将军”问题报告 ,尝到了甜头,于是在最初的Paxos论文中也讲了一个考古的故事,不过论文提交上去这样能看懂,之后告诉我从哪个犄角旮旯后面 被人翻了出来。Lamport之后也意识到讲的故事不能自己懂,于是又采集了第3个版本叫做:<<Paxos Made Simple>>。一种生活生活版本的初始协议很容易理解,不过不可能 想深入理解,相似协议中最难理解的Multi-Paxos,难度相比第一个版本其他都这样降低。与Lamport一同期还有一篇相似的论文,叫做<<Viewstamped Replication>>,最近还有一篇<<Raft>>。建议理解Paxos遇到困难的看了面这两篇论文,尤其是Raft,在牺牲很少可用性的情况下,对Paxos做了极大的繁杂,称得上业界良心。

总而言之,在金融数据库中,不可能 强一致性是必选项,否则,要做到持续可用比较困难,但也并都是不让可能 ,CAP和持续可用无须矛盾。心智性成熟期期的句子图片 的商业数据库都是基于共享存储的,不过基于Paxos的持续可用方案之后结束了了不让 地应用到核心场景,相似Google Spanner,Microsoft SQL Server云版本,Amazon DynamoDB,而Aliababa OceanBase也在金融核心场景得到了验证。一同,笔者认为,采用Paxos协议,其实工程难度很高,否则,假如有一天在实现上做到极致,在同城的情况下,不能容忍单个IDC故障,且性能损耗非常小;而在异地的场景,考虑到光速不可突破,往往由业务在一致性和可用性之间权衡。不让 的云数据库不可能 采用Paxos来实现持续可用。

采用Paxos协议的持续可用系统有一种生活生活常见的部署最好的法子:

请读者会到CAP理论中关于A的定义:CAP中的A要求任何一个这样存在故障的节点还要在有限的时间内返回结果。然而,不可能 系统不能做到当某个节点存在网络分区后,将它从系统中剔除,由其它节点继续提供服务。其实这样满足CAP中A的要求,否则,假如有一天恢复时间足够快,也符合高可用的要求。而高可用才是系统设计的本质需求,CAP中的A可是个理论上的需求。

数据库的性能分为一个方面:

CAP理论

引入选举的难点

第一种生活生活部署最好的法子比较简单,也最为常见。兩个全局Paxos服务,相似Zookeeper,它和其它机器之间保持租约。Master和一个Slave之间保持强同步,事务大慨 要写入到Master和其中一个Slave才不能返回成功。同一时刻对于同一份数据非要一个Master,全局Paxos服务负责选举,当Master总是总出 故障时,选举日志号最大的Slave接替原先的Master继续提供服务。

本文主要针对金融数据库,认为金融数据库的持续可用涵盖两点:一个是强一致性;另外一个是高可用性。

理想的系统应该是一个全异步的系统,处理强同步占用应用应用程序/应用应用应用程序等执行资源,且不应该带来额外的上下文切换。日志同步的优化有其他关键点,相似:组提交(Group Commit),减少日志缓冲区的锁冲突,异步化,处理无还要的上下文切换,数据库提前解行锁处理热点。具体不能参考论文:<<Aether:A Scalable Approach to Logging>>。我参与实现的OceanBase系统强同步对单个事务带来的额外延时可是一次网络同步,同一个机房内在0.5ms左右,同城的多个机房之间非要1ms左右,对系统吞吐量的影响也非要5% ~ 10%左右。也可是说,不可能 实现做到极致,强同步的性能不让是问题报告 。当然,这就要求将持续可用看成数据库架构的核心目标,针对一种生活生活需求重构数据库的执行引擎。

数据库领域总是采用共享存储来处理强一致性问题报告 ,主库将redo日志持久化到共享存储,不可能 主库故障,假设共享存储是持续可用的,备库不能从共享存储中读取日志恢复系统。共享存储与share-nothing架构的强同步有何区别呢?共享存储模式下只还要部署一个主库和一个备库,而share-nothing架构下强同步大慨 还要一个主库加一个备库。为那些呢?假设share-nothing架构只部署了一个主库和一个备库,假如有一天任何一台机器,即使是备库宕机,为了保证强一致性,整个系统都无法提供服务。显然,原先的系统在互联网业务中几乎这样应用场景。

强同步性能

首先,亲戚亲戚亲戚.我歌词 回到CAP理论的原始定义:

假设在关系数据库的基础上引入全局Paxos服务,与否不能处理高可用问题报告 呢?理论上其实是不能的,不过实施起来难度可是小。这是不可能 ,即使是Zookeeper原先心智性成熟期期的句子图片 的选举服务,使用过程中总是会遇到各种各样的问题报告 ,不可能 期望应用到核心业务,还要对Zookeeper系统详细的掌控力。也可是说,假设Zookeeper原先的服务总是总出 问题报告 ,还要不能Fix Bug,而都是简单重启处理。另外,也还要做一套模拟各种异常的测试系统,确保不让在异常的情况下总是总出 其他严重的问题报告 ,相似Zookeeper选出双主原困数据不一致。总而言之,做一个持续可用的选举服务并都是简单地使用开源软件,这是一个全局服务,要么不做,要么就深入下去做到详细掌控。

CAP中的A与高可用的HA

CAP理论一种生活生活毋庸置疑,证明不能参考Gilbert和Lynch合著的论文。

对于异地场景,不可能 网络延时较大,相似1000ms左右,业务往往不可接受。否则,无法做到跨地域持续可用,整个地区故障时,要么牺牲一致性,要么牺牲可用性,不可能 选者可用性时不可能 会丢失最后几秒内的数据。当然,实际上业务上往往会组合使用各种柔性处理方案,相似涉及到钱的业务停服务,其它业务容忍极端情况下的数据丢失;不可能 在组织组织结构系统中记录其他信息,相似记录那些用户的数据不一致,总是总出 问题报告 是禁止那些用户的写服务,其它用户正常提供服务;不可能 DBA采用各种最好的法子补数据,等等。

数据库系统还可是强一致性的系统,这是不可能 数据库系统有事务ACID的基本要求,而弱一致系统无法做到。业内都是其他流行的NOSQL系统,相似各种类Dynamo系统,如开源的Cassandra,对同一个最小数据单位(同一行数据)允其他台服务器一同写入,其实采用NWR机制处理冲突,否则不可能 不让可能 处理多台服务器之间的时序问题报告 ,而非要支持弱一致语义。弱一致语义的问题报告 什么都,相似无法支持繁杂功能,无法构建严谨的测试体系,无法应用到核心场景。其实弱一致性系统都是一定的应用场景,但本文认为其不符合核心业务持续可用的要求,不予讨论。

CAP理论的证明也比较直观,如下:

跨机房问题报告 分为两类:同城以及异地。前面不可能 提到,无论怎样才能实现,强同步方案中单个事务大慨 增加一次网络同步延时。对于同城场景,不可能 网络环境比较好,相似公司的数据库服务有专用的光纤不可能 速率单位比较高,这样,增加的延时在1~2ms(光折射传播的时间 + 交换机处理时间),业务是详细不能接受的。否则,不能做到同城持续可用,单个IDC故障时,不能在保证强一致的前提下变慢恢复服务。

强一致性是数据库的长项,做法可是强同步,Oracle,MySQL 5.7,国内的MySQL定制版本,相似阿里、网易的MySQL版本都支持强一致性。强同步的问题报告 在于性能损耗,相似传统数据库的执行模型(非应用应用程序池模型)一般为一个连接对应一个工作应用应用程序/应用应用应用程序,采用强同步模式后事务的延时必然延长,从而原困工作应用应用程序/应用应用应用程序数增多,高并发情况下日志应用应用程序唤醒工作应用应用程序原困的上下文切换开销也非常大。另外,为了实现高可用,还要同步大慨 一个备库,使得情况进一步恶化。

左图中,假设兩个节点N1和N2,N1和N2之间存在了网络分区(P),N1写入新值y,N2总是是老值x,为了保证一致性(C),读取N2总是返回失败,违反了可用性(A)要求:任何一个这样存在故障的节点还要在有限时间内返回结果,不允许为Error不可能 Timeout,系统非要保证CP。

第二种部署最好的法子比较纯粹,只总是总出 在少许的分布式数据库中,相似Google Spanner,OceanBase 1.0。Leader(大慨 Master)和Follower(大慨 Slave)之间直接采用Paxos协议进行数据同步和选举,相比第一种生活生活方案,一种生活生活最好的法子实现繁杂度要高什么都,换来的好处是宕机恢复时间更短,系统更优雅。

跨机房问题报告

高可用性不能有什么都种解释,实践中最常见的解释为:在一台服务器,一个交换机,一个机房,不可能 一个地区整体故障后,系统不能在多长时间内恢复服务。当然,这里的恢复服务是以保证强一致性作为前提条件的。不可能 不能在秒级(10秒左右)恢复服务,本文认为一种生活生活系统是高可用的,绝大每种应用系统都不能容忍硬件故障原困的秒级不可用。

右图中,从另外一个宽度看,假设总是要保证可用性(A),这样,读到N2中的老值x,不可能 x和最新写入的y不同,违反了一致性(C)的要求,系统非要保证AP。

八卦完了Paxos,下面进入正题。Lamport和Jim Gray分别是分布式系统和数据库领域的代表任务,同属微软研究院,不过也是共事多年才坐在一同聊一个领域的问题报告 。高可用是分布式系统的长项,为了实现高可用,首先还要大慨 写三份数据(一主两备)。这是不可能 ,不可能 只写两份数据,当一份数据总是总出 故障的之后,另外一份数据永远无法证明此人 是对,也无法证明此人 是错。这可是选举的价值,类Paxos选举协议允许在超过半数(Majority)节点正常的情况下提供服务。否则,当某台服务器,某个交换机,某个IDC甚至某个地区整体故障的之后,假如有一天不超过整个系统的半数,系统都不能变慢从错误中恢复过来,否则详细自动,不让人工干预。