数据库应用与设计-大型数据库系统架构设计方法课件.ppt

1、第三章大型数据库系统应用设计方法可扩展性、高可用性及负载均衡基本概念可扩展性（Scalability|伸缩性）：在一些大的系统中，预测最终用户的数量和行为是非常困难的，可扩展性是指系统适应不断增长的用户数的能力。提高这种并发会话能力的一种最直观的方式就增加资源（CPU，内存，硬盘等），集群是解决这个问题的另一种方式，它允许一组服务器组在一起，像单个服务器一样分担处理一个繁重的任务。高可用性（High availability）：单一服务器的解决方案并不是一个健壮方式，因为容易出现单点失效。像银行、账单处理这样一些关键的应用程序是不能容忍哪怕是几分钟的死机。它们需要这样一些服务在任何时间都可以访

2、问并在可预期的合理的时间周期内有响应。集群方案通过在集群中增加的冗余的服务器，使得在其中一台服务器失效后仍能提供服务，从而获得高的可用性。负载均衡（Load balancing）：负载均衡是集群的一项关键技术，通过把请求分发给不同的服务器，从而获得高可用性和较好的性能。一个负载均衡器可以是从一个简单的Servlet或Plug-Ins（例如一个Linux box利用ipchains来实现），到昂贵的内置SSL加速器的硬件。除此之外，负载均衡器还需执行一些其他的重要任务，如“会话胶粘”让一个用户会话始终存在一个服务器上，“健康检查”用于防止将请求分发到已失效的服务器上。有些负载均衡器也会参与我们下

3、面将要谈到“失效转移”过程。基本概念容错（Fault tolerance）：高可用性意味着对数据正确性的要求不那么高。在J2EE集群中，当一个服务器实例失效后，服务仍然是有效的，这是因为新的请求将被冗余服务器处理。但是，当一个请求在一个正在失效的服务器中处理时，可能得到不正确的结果。不管有多少个错误，容错的服务应当能确保有严格的正确的行为。失效转移（Failover）：失效转移是集群中用来获取容错能力的另一项关键的技术。当一个结点失效后，通过选择集群中的另一个结点，处理将会继续而不会终止。转移到另一个结点可以被显式的编码，或是通过底层平台自动地透明地路由到另一个服务器。等幂方法（Idempot

4、ent methods）：等幂方法是指这样一些方法：重复用相同的参数调用都能得到相同的结果。这些方法不会影响系统状态，可以重复调用而不用担心改变系统。例如：getUsername()就是等幂的，而deleteFile就不是。当我们讨论HTTP Session失效转移和EJB失效转移时，它是一个重要的概念。讨论的背景主题数据库基本问题调查关系数据库的基本背景ACID基本概念解析范式问题解析（Normalization）数据库基本问题调查大家都使用过哪些数据库？哪些内容是数据库系统的关键点？常见的数据存储传统的数据库系统 Oracle DB2、SQL Server MySQL、PosgreSQL分

5、布式数据库 Google Spanner&BigTable&MegaStore OceanBase、Hbase缓存服务器 KeyValue Store Tair Memcached Redis数据库的主要特性ACID 原子性（Atomicity）完整性（Consistency）隔离性（Isolation）持久性（Durability）Relation SQL Structured Query Language（即SQL）A Relational Model of Data for Large Shared Data Banks（By Edgar Codd）RDBMS之前的数据库的问题不支持数据

6、独立性数据库与应用系统之间的强耦合应用系统的复杂度应用系统本身的规模较小（性价比？）关系数据库的主要业务场景Billing（记账类业务，电信、银行）Booking（订票类业务，航空）Inventory（库存管理，零售）这些业务的共同特征是什么？关系数据库的关系来自哪里？这是关系的一个来源另一个来源是NormalizationACID的基础概念Transaction的概念借自Contract Law 一手交钱、一手交货（Atomicity）不会出现库存为负，也不会出现资金为负的情况（Consistency）可同时与多人进行交易（Isolation）离柜概不负责（Durability）Atomic

7、ity 要么全部成功，要么全不成功Consistency 写入数据库的数据必须满足所有定义的约束规则（主键、唯一键、外键等约束）Isolation 确保并发执行的事务就如同串行执行的事务一样，保证系统状态（state）的一致性。Durability 一旦提交，哪怕出现掉电、Crash也不会丢数据几个基础概念Write-Ahead LogRedo Logical Physical PhysiologicalUndo事务槽事务标识SCN 系统变更统一时间戳（逻辑时钟）如何实现原子性一个简单购物场景A卖一件衣服给BA的衣服库存-1A的资金+NB的衣服库存+1B的资金-N如何实现原子性（2）事务槽为变

8、更入口，单一入口（原子）每个变更的记录都包含事务槽信息数据库中如何保证C通过Read Dirty与锁来解决PK/UK通过Ref检查来解决FK的问题（需要Index）通过PreCommit trigger来做Null以及Check数据库中如何保证I锁控制 不同粒度的锁（表级、块级、记录级）不同维度的锁（数据相关锁，内存相关锁）MVCC Snapshot Isolation Block Image+SCN+Undo Image 判断差别在于读取哪个时间点的Snapshot数据库中如何保证DLog before DataLGWR before DBWnFlush Log on Commit Dura

9、bility On CommitCheckpoint Before Redo Log File ReuseACID的代价不同的Isolation对应不同的代价 Serialiazability Read Committed(Through Snapshot)Read Dirty?（没有并发控制）不同的Durability级别 Flush on Commit Flush on Timeout(Time Range)Flush on Batch(commits count?)主题数据库基本问题调查关系数据库的基本背景ACID基本概念解析范式问题解析（Normalization）数据库的扩展性浅析常

10、见数据库系统回顾NORMALIZATION先做个小游戏用笔记录下 学生名单、老师姓名、讲师简介、课程名称、课程简介调整下 老师（黄晋汤庸）以及对应的老师简介再次调整下 课程（数据库概论分布式数据库原理）简介NORMALIZATION解决的问题更新一个源头不会出现异常每份数据只有一个源头 如何保证多份数据的一致性？一份数据有多少个源头？同一份数据被重复了多少次？对应的存储空间？为了存储耗费的其它资源？NORMALIZATION带来的问题表之间的依赖（关系依赖，耦合）表关联的成本（关联开销，可能的IO开销）系统扩展的复杂度（解耦合）如何权衡NORMALIZATION尽量不要对静态数据做Normal

11、ization 除非你希望节约存储空间考虑范式化 Vs 反范式化的投入产出为什么很多IT新人喜欢Normalization 那是因为他们的老师告诉他们需要建议 适度的使用 关键在于判断业务之间的耦合性主题数据库基本问题调查关系数据库的基本背景ACID基本概念解析范式问题解析（Normalization）数据库的扩展性浅析常见数据库系统回顾一个小实验如何将2个人从这里送到大学城？如何将5个人从这里送到大学城？如何将50个人从这里送到大学城？如何将500个人从这里送到大学城？如何将5000个人从这里送到大学城？如何将50000个人从这里送到大学城？数据库的扩展性问题数据库架构、系统架构在于：如何满

12、足如下的要求检索问题 Relation并发问题 Isolation Consistency(UK)一致性问题 Isolation速度问题 Performance,Durability+Isolation数据库检索问题如何从班级的联系方式中找到XX的电话号码？如何从公司的联系方式中找到XX的电话号码？如何从移动公司的系统中找到XX的电话号码？如何从移动、电信、联通的数据库找到XX的电话号码？数据库的并发问题同时有多个人要购买手机号？如何保证大家购买的不是同一个手机号？如何支持几百、几千、几万人同时购买手机号？数据库的一致性问题如何保证大家看到的库存有效？如何保证读取的信息是准确的？库存的变更如何

13、实时的提供给每一个人看到？数据库的性能问题？如何快速的让1个人买到号码？有多快？如何快速的让10个人买到号码？要不要排队？一个服务员？一个营业厅？PERFORMANCE VS SCALABILITY1.当只有一个人访问时，速度如何？2.当有很多人访问时，速度如何？大家都同样快？如果满足1 表示Performance很好？如何能较好的满足2 表示系统有较好的Scalability一致性问题再探讨新浪发的微薄需要强一致吗？ITPUB的论坛需要强一致吗？当当的图书描述信息需要强一致吗？12306的火车票库存信息需要强一致吗？支付宝/财付通的账户余额需要强一致吗？中行信用卡/招商银行卡的账户信息需要强

14、一致吗?讨论扩展性数据库系统的扩展性Scale（扩展）就是让我们的数据库能够提供更强的服务能力，更强的处理能力。Scalable（可扩展）则是表明数据库系统在通过相应升级（包括增加单机处理能力或者增加服务器数量）之后能够达到提供更强处理能力。在理论能上来说，任何数据库系统都是Scalable 的，只不过是所需要的实现方式不一样而已。Scalability（扩展性）则是指一个数据库系统通过相应的升级之后所带来处理能力提升的难易程度。虽然理论上任何系统都可以通过相应的升级来达到处理能力的提升，但是不同的系统提升相同的处理能力所需要的升级成本（资金和人力）是不一样的，这也就是我们所说的各个数据库应用

15、系统的 Scalability存在很大的差异。数据库系统的扩展性Scale Up 则是指纵向的扩展，向上扩展，也就是通过增加当前处理节点的处理能力来提高整体的处理能力，是通过升级现有服务器的配置，如增加内存，增加CPU，增加存储系统的硬件配置，或者是直接更换为处理能力更强的服务器和更为高端的存储系统。Scale Out 就是指横向的扩展，向外扩展，也就是通过增加处理节点的方式来提高整体处理能力，即通过增加机器来增加整体的处理能力。SCALE UP 优缺点Scale Up 优点：处理节点少，维护相对简单；所有数据都集中在一起，应用系统架构简单，开发相对容易；Scale Up 缺点高端设备成本高，

16、且竞争少，容易受到厂家限制；受到硬件设备发展速度限制，单台主机的处理能力总是有极限的，容易遇到最终无法解决的性能瓶颈；设备和数据集中，发生故障后的影响较大；SCALE OUT 优缺点Scale Out 优点成本低，很容易通过价格低廉的PC Server 搭建出一个处理能力非常强大的计算集群；不容易遇到瓶颈，因为很容易通过添加主机增加处理能力；单个节点故障对系统整体影响较小；也存在缺点，更多的计算节点，大部分时候都是服务器主机，这自然会带来整个系统维护复杂性的提高，在某些方面肯定会增加维护成本，而且对应用系统的架构要求也会比 Scale Up 更高，需要集群管理软件的配合。Scale Out 缺

17、点处理节点多，造成系统架构整体复杂度提高，应用程序复杂度提高；集群维护难以程度更高，维护成本更大；SCALABILITY很好的数据库应用系统遵循的原则 事务相关性最小化原则 数据一致性原则 高可用及数据安全原则事务相关性最小化原则分布式的架构带来分布式事务的问题在传统的集中式数据库架构中，事务的问题非常好解决，可以完全依赖数据库本身非常成熟的事务机制来保证。但是一旦我们的数据库作为分布式的架构之后，很多原来在单一数据库中所完成的事务现在可能需要跨多个数据库主机，这样原来单机事务可能就需要引入分布式事务的概念。分布式事务本身就是一个非常复杂的机制不管是商业的大型数据库系统还是各开源数据库系统，虽

18、然大多数数据库厂家基本上都实现了这个功能，但或多或少都存在各种各样的限制。而且也存在一些 Bug，可能造成某些事务并不能很好的保证，或者是不能顺利的完成。一些解决方案1.进行 Scale Out 设计的时候合理设计切分规则，尽可能保证事务所需数据在同一个 MySQL Server 上，避免分布式事务。2.大事务切分成多个小事务，数据库保证各个小事务的完整性，应用控制各个小事务之间的整体事务完整性。3.结合上述两种解决方案，整合各自的优势，避免各自的弊端。1.比如我们可以在保证部分核心事务所需数据在同一个MySQL Server 上，而其他并不是特别重要的事务，则通过分拆成小事务和应用系统结合来

19、保证。2.通过这样相互平衡设计的原则，我们既可以避免应用程序需要处理太多的小事务来保证其整体的完整性，同时也能够避免拆分规则太多复杂而带来后期维护难度的增加及扩展性受阻的情况数据一致性原则如何在 Scale Out 的同时又较好的保证数据一致性呢？BASE 模型。即：基本可用，柔性状态，基本一致和最终一致简单来说，应用系统通过相关的技术实现，让整个系统在满足用户使用的基础上，允许数据短时间内处于非一致状态，而通过后续技术来保证数据在最终保证处于一致状态。高可用及数据安全原则在支持可扩展性的同时，要注意高可用性和数据安全。基本方法SHARDINGREPLICATIONCLUSTERSHARDIN

20、GSHARE NOTHING并行数据库要求尽可能的去并行执行数据库操作，从而提高性能。在并行计算体系结构实现中有很多可选的体系结构。包括：Share-memory：多个cpu共享同一片内存，cpu之间通过内部通讯机制（interconnection network）进行通讯；Share-disk：每一个cpu使用自己的私有内存区域，通过内部通讯机制直接访问所有磁盘系统。Share-nothing：每一个cpu都有私有内存区域和私有磁盘空间，而且2个cpu不能访问相同磁盘空间，cpu之间的通讯通过网络连接。并行计算体系结构Share diskshare nothingshare memory并行

21、计算体系结构Shared memory 体系结构的cpu之间通过主存进行通讯，具有很高的效率；但当更多的cpu被添加到主机上时，内存竞争contection就成为瓶颈，cpu越多，瓶颈越厉害。Shared disk也存在同样问题，因为磁盘系统由 Interconnection Network 连接在一起。Shared memory和shared disk的基本问题是interference：当添加更多的cpu，系统反而减慢，因为增加了对内存访问（memroy access）和网络带宽（network bandwidth）的竞争。这样shared nothing体系得到了广泛的推广。Shared

22、 nothing体系是数据库稳定增长，当随着事务数量不断增加，增加额外的cpu和主存就可以保证每个事务处理时间不变。SHARED NOTHINGARCHITECTURE(SN)A shared nothing architecture(SN)is a distributedcomputing architecture in which each node is independent and self-sufficient,and there is no single point of contention across the system.More specifically,none of

23、 the nodes share memory or disk storage.People typically contrast SN with systems that keep a large amount ofcentrally-stored state information,whether in a database,an applicationserver,or any other similar single point of contention.While SN is bestknown in the context of web development,the conce

24、pt predates theweb:Michael Stonebraker at the University of California,Berkeley usedthe term in a 1986 database paper.1 In it he mentions existingcommercial implementations of the architecture(although none arenamed explicitly).Teradata,which delivered its first system in 1983,wasprobably one of tho

25、se commercial implementations.2 TandemComputers officially released NonStop SQL,a shared nothing database,in 1984.3SHARED NOTHINGARCHITECTURE(SN)Shared nothing is popular for web development because ofits scalability.As Google has demonstrated,a pure SN systemcan scale almost infinitely simply by ad

26、ding nodes in the form ofinexpensive computers,since there is no single bottleneck to slowthe system down.4 Google calls this sharding.A SN systemtypically partitions its data among many nodes on differentdatabases(assigning different computers to deal with differentusers or queries),or may require

27、every node to maintain its owncopy of the applications data,using some kind of coordinationprotocol.This is often referred to as database sharding.从 SHARD 到 SHARDING“Shard”这个词英文的意思是”碎片”，而作为数据库相关的技术用语，似乎最早见于大型多人在线角色扮演游戏(MMORPG)中。”Sharding”称之为”分片”。Sharding 不是一门新技术，而是一个相对简朴的软件理念。MySQL 5 之后才有了数据表分区功能，那么

28、在此之前，很多 MySQL 的潜在用户都对MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢?答案是：Sharding。Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。数据库扩展性目前的商业数据都有自己

29、的扩展性解决方案，在过去相对来说比较成熟，但是随着互联网的高速发展，不可避免的会带来一些计算模式上的演变，这样很多主流商业系统也难免暴露出一些不足之处。比如 Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 ScaleUp（向上扩展）类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Sharding 基本上是针对开源数据库的扩展性解决方案，很少有听说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱Scale Out，逐渐从 Scale Up 中解放出来。SHARDING 的应用场景任何技术都是在

30、合适的场合下能发挥应有的作用。Sharding 也一样。联机游戏、IM、BSP 都是比较适合 Sharding 的应用场景。其共性是抽象出来的数据对象之间的关联数据很小。IM，每个用户如果抽象成一个数据对象，完全可以独立存储在任何一个地方，数据对象是 Share Nothing 的；Blog 服务提供商的站点内容，基本为用户生成内容(UGC)，完全可以把不同的用户隔离到不同的存储集合，而对用户来说是透明的。“Share Nothing”是从数据库集群中借用的概念，有些类型的数据粒度之间就不是“Share Nothing”的，比如类似交易记录的历史表信息，如果一条记录中既包含卖家信息与买家信息，

31、如果随着时间推移，买、卖家会分别与其它用户继续进行交易，Sharding会可能导致两个买卖家的信息会分布到不同的 Sharding DB 上，而这时如果针对买卖家查询，就会跨越更多的 Sharding，开销就会比较大。Sharding 并不是数据库扩展方案的银弹，也有其不适合的场景，如处理事务型应用会非常复杂。对于跨不同DB的事务，很难保证完整性，得不偿失。所以，采用什么样的 Sharding 形式，不是生搬硬套的。SHARDING与数据库分区(PARTITION)的区别有的时候，Sharding 也被近似等同于水平分区(Horizontal Partitioning)，网上很多地方也用 水平

32、分区来指代 Sharding，但二者之间实际上还是有区别的。Sharding 的思想是从分区的思想而来，但数据库分区基本上是数据对象级别的处理，比如表和索引的分区，每个子数据集上能够有不同的物理存储属性，还是单个数据库范围内的操作，而 Sharding是能够跨数据库，甚至跨越物理机器的。SHARDING 策略Sharding根据切分规则类型，可分为两种切分模式：数据的垂直（纵向）切分是按照不同的表（或者 Schema）来切分到不同的数据库（主机）之上，这种切可以称之为；数据的水平（横向）切分是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为。

33、数据的垂直切分数据的垂直切分，也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”（表）组成，我们垂直的将这些“数据块”切开，然后将他们分散到多台数据库主机上面。这样的切分方法就是一个垂直（纵向）的数据切分。当我们的功能模块越清晰，耦合度越低，数据垂直切分的规则定义也就越容易。完全可以根据功能模块来进行数据的切分，不同功能模块的数据存放于不同的数据库主机中，可以很容易就避免掉跨数据库的 Join 存在，同时系统架构也非常的清晰。EXAMPLE 数据库-垂直划分系统功能可以基本分为四个功能模块：用户，群组消息，相册以及事件，分别对应为如下这些表：用户模块表：user,user_

34、profile,user_group,user_photo_album群组讨论表：groups,group_message,group_message_content,top_message相册相关表：photo,photo_album,photo_album_relation,photo_comment事件信息表：eventEXAMPLE 数据库-垂直划分群组讨论模块和用户模块之间主要存在通过用户或者是群组关系来进行关联。一般关联的时候都会是通过用户的 id 或者nick_name 以及 group 的 id 来进行关联，通过模块之间的接口实现不会带来太多麻烦；相册模块仅仅与用户模块存在通过

35、用户的关联。这两个模块之间的关联基本就有通过用户 id 关联的内容，简单清晰，接口明确；事件模块与各个模块可能都有关联，但是都只关注其各个模块中对象的ID信息，同样可以做到很容易分拆。EXAMPLE 数据库-垂直划分我们第一步可以将数据库按照功能模块相关的表进行一次垂直拆分，每个模块所涉及的表单独到一个数据库中，模块与模块之间的表关联都在应用系统端通过接口来处理。通过这样的垂直切分之后，之前只能通过一个数据库来提供的服务，就被分拆成四个数据库来提供服务，服务能力自然是增加几倍了。垂直切分的优缺点垂直切分的优点数据库的拆分简单明了，拆分规则明确；应用程序模块清晰明确，整合容易；数据维护方便易行，

36、容易定位；垂直切分的缺点部分表关联无法在数据库级别完成，需要在程序中完成；对于访问极其频繁且数据量超大的表仍然存在性能瓶颈，不一定能满足要求；事务处理相对更为复杂；切分达到一定程度之后，扩展性会遇到限制；过读切分可能会带来系统过渡复杂而难以维护。数据的水平切分水平切分可理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。为了能够比较容易的判定各行数据被切分到哪个数据库中了，切分总是都需要按照某种特定的规则来进行的。如根据某个数字类型字段基于特定数目取模，某个时间类型字段的范围，或者是某个字符类型字段的 hash 值。如EXAMPLE数据库，所有数

37、据都是和用户关联的，那么我们就可以根据用户来进行水平拆分，将不同用户的数据切分到不同的数据库中。唯一有点区别的是用户模块中的 groups 表和用户没有直接关系，所以 groups 不能根据用户来进行水平拆分。对于这种特殊情况下的表，则可以独立出来，单独放在一个数据库中。EXAMPLE数据库-水平划分大部分的表都可以根据用户 ID 来进行水平的切分。不同用户相关的数据进行切分之后存放在不同的数据库中。如将所有用户 ID 通过取模（模5）然后分别存放于两个不同的数据库中。每个和用户 ID 关联上的表都可以这样切分。这样，基本上每个用户相关的数据，都在同一个数据库中，即使是需要关联，也可以非常简单

38、的关联上。水平切分的优缺点水平切分的优点表关联基本能够在数据库端全部完成；不会存在某些超大型数据量和高负载的表遇到瓶颈的问题；应用程序端整体架构改动相对较少；事务处理相对简单；只要切分规则能够定义好，基本上较难遇到扩展性限制；水平切分的缺点切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则；后期数据的维护难度有所增加，人为手工定位数据更困难；应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。利用 MYSQL PROXY 实现数据切分及整合MySQL Proxy 是 MySQL 官方提供的一个数据库代理层产品，和 MySQL Server 一样，同样是一个基于 G

39、PL 开源协议的开源产品。可用来监视、分析或者传输他们之间的通讯信息。他的灵活性允许你最大限度的使用它，目前具备的功能主要有连接路由，Query 分析，Query 过滤和修改，负载均衡，以及基本的 HA 机制等。实际上，MySQL Proxy 本身并不具有上述所有的这些功能，而是提供了实现上述功能的基础。要实现这些功能，还需要通过我们自行编写 LUA脚本来实现。MySQL Proxy 实际上是在客户端请求与MySQL Server 之间建立了一个连接池。所有客户端请求都是发向 MySQL Proxy，然后经由MySQL Proxy进行相应的分析，判断出是读操作还是写操作，分发至对应的 MySQ

40、L Server上。对于多节点 Slave 集群，也可以起做到负载均衡的效果。高可用性HIGH AVAILABILITYSINGLE MYSQL SERVERWHY HA?Something can and will fail Service Maintenance Downtime is expensive Adding HA to an existing system is complex 墨菲定律（Murphys Law）Anything that can go wrong will go wrong高可用性HA-IBM定义业务连续性是指企业的一种能力，有了此能力，企业能够抵御中断，并根

41、据预定义的服务级别协议正常且连续不断地经营重要服务。要实现期望的给定级别业务连续性，必须选择一系列服务、软件、硬件和过程，用文档计划加以描述，付诸实现并定期实践。业务连续性解决方案必须解决有关数据、运营环境、应用程序、用于主管环境的应用程序以及最终用户接口的问题。所有这些都必须予以提供，才能交付完整的业务连续性解决方案。业务连续性包括灾难恢复(DR)和高可用性(HA)，是指抵御所有中断（预期中断、意外中断以及灾难），并为所有重要应用程序提供连续处理的能力。最终目标是让中断时间少于总服务时间的 0.001%。与灾难恢复方案相比，高可用性环境通常包括要求更为苛刻的恢复时间目标（数秒到数分钟）和恢复

42、点目标（零用户中断）。可用性级别90%95%99%99.9%99.99%99.999%每年的停机时间36.5 天18.25 天3.65 天8.76 小时50 分钟5 分钟需要 100%可用性的应用程序吗？在大多数情况下，可以通过实施合理的处理和系统管理实务来实现高级别的可用性。当所需要的越接近连续可用性，则必须作出的投资就越大。在作出这种投资之前，应该确信需要该级别的可用性。下列数字显示不同技术所能提高可用性的程度，但是需要付出的成本可能会随之增加。系统可用性的定义在特定时间内和特定条件下系统正常工作的相应程度。可用性的测量方式：系统的可用性(availability)，即利用率。可用性的平均

43、值即平均利用率，其计算方法为：A=MTBF/(MTBF+MTTR)MTBF(MeanTime Between Failures)故障间隔平均时间MTTR(MeanTime To Repair)系统平均修复时间A=uptime/(uptime+downtime)系统可用性的获得可用性容错性(fault tolerance)完美性(perfection)冗余技术硬件冗余(redundancy)软件冗余完美硬件整机完美性完美软件可信软件|时间冗余信息冗余部件完美性器件完美性|静态冗余（部件冗余）|可用硬件动态重组|-被动重组（后备 stand-by）|-主动重组（优美降级 graceful degr

44、adation)完美性与避错技术完美性追求一种避错技术，即避免出错。要求组成系统的各个部件、器件具有高可用性，不允许出错，或者出错率降至最低。硬件的可用性与完美性指元器件的完美性、部件的完美性、整机与系统的完美性软件的可用性与完美性是指软件的正确性、完美性、兼容性。容错性与容错技术容错技术：在一定程度上容忍故障的技术容错系统：采用容错技术的系统当系统因某种原因出错或者失效，系统能够继续工作，程序能够继续运行，不会因计算机故障而中止或被修改，执行结果也不包含系统中故障引起的差错。容错技术也称为故障掩盖技术(fault masking)。容错性与容错技术冗余技术是容错技术的重要结构，它以增加资源的

45、办法换取可用性。由于资源的不同，冗余技术分为硬件冗余、软件冗余、时间冗余和信息冗余。资源与成本按线性增加，而故障概率则可按对数规律下降。冗余要消耗资源，应当在可用性与资源消耗之间进行权衡和折衷。双CPU容错系统当一个 CPU板出现故障时，另一个 CPU保持继续运行。这个过程对用户是透明的，系统没有受到丝毫影响，更不会引起交易的丢失，充分保证数据的一致性和完整性。系统的容错结构能够提供系统连续运行的能力，任何单点故障不会引起系统停机，系统提供在线的维护诊断工具可在应用继续运转的情况下修复单点故障。冗余类型1.硬件冗余：增加线路、设备、部件，形成备份。2.软件冗余：增加程序，一个程序分别用几种途径

46、编写，按一定方式执行，分段或多种表决。3.时间冗余：指令重复执行，程序回卷技术。4.信息冗余：增加信息数据位数，检错、纠错。容错系统工作方式自动侦测(AUTO-DETECT)自动侦测(Auto-Detect)通过专用的冗余侦测线路和软件判断系统运行情况，发现可能的错误和故障，进行严谨的判断与分析。确认主机出错后，启动后备系统。侦测程序需要检查主机硬件（处理器与外设部件）、主机网络、操作系统、数据库、重要应用程序、外部存储子系统（如磁盘阵列）等。为了保证侦测的正确性，防止错误判断，系统可以设置安全侦测时间、侦测时间间隔、侦测次数等安全系数，通过冗余通信连线，收集并记录这些数据，作出分析处理。数据

47、可信是切换的基础。自动切换(AUTO-SWITCH)当确认某一主机出错时，正常主机除了保证自身原来的任务继续运行外，将根据各种不同的容错后备模式，接管预先设定的后备作业程序，进行后续程序及服务。系统的接管工作包括文件系统、数据库、系统环境（操作系统平台）、网络地址和应用程序等。如果不能确定系统出错，容错监控中心通过与管理者交互进行有效的处理。决定切换基础、条件、时延、断点自动恢复(AUTO-RECOVERY)故障主机被替换后，离线进行故障修复。修复后通过冗余通信线与正常主机连线，继而将原来的工作程序和磁盘上的数据自动切换回修复完成的主机上。这个自动完成的恢复过程用户可以预先设置，也可以设置为半

48、自动或不恢复。常用方法双机双工热备份(MUTUALBACKUP)两机同时运行，分不同作业，各自资源负载，故障、接管、修复、交还。双主机通过一条TCP/IP网络线以及一条RS-232电缆线相联双主机各自通过一条SCSI电缆线与RAID磁盘阵列相联双主机各自运行不同的作业，彼此独立，并相互备援主机A故障后，主机B自动接管主机A运行。主机A的作业将在主机B上自动运行。主机A修复后，主机B将把A的作业自动交还主机A。主机B故障时，主机A接管主机B的作业和数据。主机B修复时,主机A再将原来接管的作业和数据交还主机B。主从热备份(MASTER/SLAVE)主从式（M/S），M运行，S后备，M故障，S接管并

49、升级为M,原M修复后作为S。双主机通过一条TCP/IP网络线以及一条RS-232电缆线相联。双主机各自通过一条SCSI电缆线与RAID相联。主机A为Master，主机B为Slave。主机A处理作业和数据，主机B作为热备份机。主机A故障后，主机B自动接管主机A的作业和数据。主机B同时接管A的主机名(Host)及网络地址(IP)。主机A的作业将在主机B上自动运行。主机A的客户(client)可继续运行，无需重新登录。主机B现为Master,主机A修复后作为Slave，作为热备份机。热备份(HOT-STANDBY)M运行，S后备M故障，S接管作M原M修复，S归还M。RULES OF HIGHAVAI

50、LABILITYPrepare for failureAim to ensure that no important data is lostKeep it simple,stupid(KISS)Complexity is the enemy of reliabilityAutomate itTest your setup frequently!高可用常用方法主机硬件高可用 硬件冗余（冷备/热备）主机冗余、电源冗余、网络环境冗余.数据高可用 基于共享数据存储的数据高可用 SAN、NAS、iScsi、SAS 基于数据库软件的数据复制冗余 MySQL Replication、Oracle Data