可用性

分布式事务 分布式理论 单个数据库的性能产生瓶颈的时候，我们可能对数据库进行分区，这里所说的分区是指物理分区，分区之后可能不同的库就处于不同的服务器上了，这个时候单个数据库的ACID已经不能适应这种情况了，而在这种ACID的集群环境下，再想保证集群的ACID会导致我们的系统变得很差，这个时候我们需要引入CAP原则。 一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效) 可用性(Availability) ： 每个操作都必须以可预期的响应结束 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成 具体地讲在分布式系统中，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。 [了解] 数据库支持2PC，又叫XA Transactions,MySQL5.5、SQL Server2005、Oracle7开始支持。 其中，XA是一个两阶段提交协议，该协议分为以下两个阶段： ·第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。 ·第二阶段：事务协调器要求每个数据库提交数据。 如果任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在次数据库中的那部分信息

在Hadoop2.0.0之前，NameNode(NN)在HDFS集群中存在 单点故障（single point of failure） ，每一个集群中存在一个NameNode，如果NN所在的机器出现了故障，那么将导致整个集群无法利用，直到NN重启或者在另一台主机上启动NN守护线程。 　　主要在两方面影响了HDFS的可用性： 　　（1）在不可预测的情况下，如果NN所在的机器崩溃了，整个集群将无法利用，直到NN被重新启动； 　　（2）在可预知的情况下，比如NN所在的机器硬件或者软件需要升级，将导致集群宕机。 　　HDFS的高可用性将通过在同一个集群中运行两个NN（active NN & standby NN）来解决上面两个问题，这种方案允许在机器破溃或者机器维护快速地启用一个新的NN来恢复故障。 　　在典型的HA集群中，通常有两台不同的机器充当NN。在任何时间，只有一台机器处于Active状态；另一台机器是处于Standby状态。Active NN负责集群中所有客户端的操作；而Standby NN主要用于备用，它主要维持足够的状态，如果必要，可以提供快速的故障恢复。 　　为了让Standby NN的状态和Active NN保持同步，即元数据保持一致，它们都将会和JournalNodes守护进程通信。当Active NN执行任何有关命名空间的修改

consul、eureka、nacos对比 配置中心 eureka 不支持 consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新 nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新 注册中心 eureka 依赖：依赖ZooKeeper 应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现， ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。 版本迭代：目前已经不进行升级 集成支持：只支持SpringCloud集成 访问协议：HTTP 雪崩保护：支持雪崩保护 界面：英文界面，不符合国人习惯 上手：容易 consul 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。 版本迭代：目前仍然进行版本迭代 集成支持：支持SpringCloud K8S集成 访问协议：HTTP/DNS 雪崩保护：不支持雪崩保护 界面：英文界面，不符合国人习惯 上手：复杂一点 nacos 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍） 版本迭代

基于Web的 系统测试 与传统的 软件测试 既有相同之处，也有不同的地方，对 软件测试 提出了新的挑战。基于Web的 系统测试 不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和 可用性 测试。本文从功能、性能、 可用性 、客户端兼容性、安全性等方面讨论了基于Web的 系统测试 方法。 随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和 数据库系统 正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的 分布式 应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。 Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。 在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中

架构的复杂度来源-高可用 高可用是指系统不会轻易的挂掉，这里的“高”是指不可能达到100%的可用性，或者说100%的可用性成本非常高，所以一般用4个九5个九表达高可用，其实就是指99.99%的可用性，99.999的可用性。 相对于高性能，高可用要复杂得多。因为高性能只需要考虑性能。而高可用必须得考虑可用性，一致性和分区容忍性 CAP和Base CAP原则，CAP分别指C（一致性），A（可用性），P（分区容忍性）。这三个要素最多只能实现两点，不可能三者兼顾。平衡这三者得关系，就是其复杂度来源。 可用性：非故障的节点在合理的时间内返回合理的请求（非错误或超时） 一致性：从客户端的角度，读操作都能够返回最新的写操作。 分区容忍性：但网络出现分区时，系统能够继续履行职责。 所谓分区是指，当服务器集群因为网络的原因，导致分成了多个隔离的区域，如一主三备的服务器集群，分成了独立的两个服务集群，这个时候会出现两个主机（其中两个备机的区其中一个升级为主机），这个时候对于客户端来是迷惑的，最终可能导致两个主机的状态不一致。这种状态备称为脑裂。 脑裂原指人的一种脑损伤疾病： 如果人的左右脑因为损伤导致不能互相通信，那么一个人的脑袋可能会对身体发出两个截然相反的命令。比如左腿向前走，右腿向后走。 Base可以说是对CAP的一种妥协，CAP是理想状态下的设定，CAP要求强一致性，强可用性

https://www.cnblogs.com/bangerlee/p/5328888.html CAP是分布式系统、特别是分布式存储领域中被讨论最多的理论，“什么是CAP定理？”在Quora 分布式系统分类下排名 FAQ 的 No.1。CAP在程序员中也有较广的普及，它不仅仅是“C、A、P不能同时满足，最多只能3选2”，以下尝试综合各方观点，从发展历史、工程实践等角度讲述CAP理论。希望大家透过本文对CAP理论有更多地了解和认识。 CAP定理 CAP由Eric Brewer在2000年PODC会议上提出[1][2]，是Eric Brewer在Inktomi[3]期间研发搜索引擎、分布式web缓存时得出的关于数据一致性(consistency)、服务可用性(availability)、分区容错性(partition-tolerance)的猜想： It is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance. 该猜想在提出两年后被证明成立[4]，成为我们熟知的CAP定理： 数据一致性(consistency)：如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败

主从复制与sentinel CAP原理 CAP原理是设计和部署分布式应用时存在三个核心系统需求：consistent（一致性）、availability（可用性）、partition tolerance（分区容忍性）。一致性不满足就是多个分布式节点的数据不一致，一个节点的修改操作无法同步到另一个节点。当网络分区（网络断开，分布式节点之间失去联系）发生时，一致性很难满足。除非牺牲可用性，就是暂停节点的服务，当网络恢复时重启。所以，网络分区发生时（集群中出现不能相互通信的两部分，即不满足分区容忍性），一致性和可用性难以同时满足。 大多数网站的架构都是AP，放弃对一致性的严格要求。 增量同步和快照同步 redis的主从数据是异步同步的，所以并不满足一致性的要求，在主从网络断开的条件下，主节点依然可以正常对外提供修改服务，满足可用性。 主动同步（严格意义上讲分为主从同步和从从同步）主要分为增量同步和快照同步两种。 增量同步会将那些修改性指令存在本地的内存缓冲区中，然后异步的将其同步到从节点，从节点一边执行同步指令一边向主节点反馈偏移量。因为内存缓冲区是有限的，所以主库不可能装入太多指令，实际上这个缓冲区是一个环形数组，如果满了就会覆盖开始的内容。如果网络长时间断开就有可能缓冲区的指令被覆盖掉，此时就需要使用快照同步。 快照同步将主库中的内存数据全部装入磁盘中，然后将其传送到从节点

1.ACID特性 数据库管理系统中事务(transaction)的四个特性： 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability） 1、原子性 原子性是指事务是一个不可再分割的工作单元，事务中的操作要么全部成功，要么全部失败。 2、一致性 一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。 3、隔离性 多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。 4、持久性 持久性，意味着在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。 2.CAP理论 CAP理论，指的是在一个分布式系统中，不可能同时满足Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能满足其中的两项。 1、一致性： 指数据在多个副本之间是否能够保持一致的特性。当执行数据更新操作后，仍然可以保证系统数据处于一致的状态。 2、可用性： 系统提供的服务必须一直处于可用的状态。对于用户的每一个操作请求总是能够在“有限的时间内”返回结果。这个有限时间是系统设计之初就指定好的系统运行指标

（一）SQL Server-AlwaysOn 技术：SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案” 1、数据库级可用性-只读副本：SQL Server 2012-4个，SQL Server 2014-8个 a、每个节点都安装了本地的 SQL Server，可以不使用共享存储，但是数据库在每个节点上的磁盘文件夹必须是一致的。 b、主节点可读可写，其它辅助节点只可读。 c、全部节点都加入一个 Windows Fail-over Cluster 中。 可以为AlwaysOn可用性组配置一个侦听器（虚拟计算机）。客户端如果访问这个侦听器则可以实现read/write；客户端如果访问指定的辅助节点，可能实现read/write（如果该节点是主节点），或者只能read-only。 负载分离： a、可以将一部分的read only请求发送到辅助副本： 1）第一种：修改应用程序，在客户端实现。例如，指定将read/write都指向AlwaysOn可用性组的侦听器（不赞成指向某个节点，因为无法确保某个节点可以write），将部分read only请求指向辅助副本。 2）第二种：为AlwaysOn可用性组配置只读路由： 脚本如下： ALTER AVAILABILITY GROUP [AG1] MODIFY REPLICA ON N'COMPUTER01' WITH

无论是云计算、大数据还是互联网公司的各种应用，其后台基础设施的主要目标都是构建低成本、高性能、可扩展、易用的分布式存储系统。 大规模分布式存储系统的定义如下：分布式存储系统是大量普通PC服务器通过Internet互联，对外作为一个整体提供存储服务。 几个特点： （1）可扩展：分布式存储系统可以扩展到几百台甚至上千台的集群规模，而且，随着集群规模的增长，系统整体性能表现为线性增长 （2）低成本：自动容错、自动负载均衡机制使其可以构建在普通PC机之上。另外，线性扩展能力也使得增加、减少机器非常方便，可以实现自动运维。 （3）高性能：针对整个集群还是单台服务器，都要求分布式存储系统具备高性能。 （4）易用：分布式存储喜提需要能够提供易用的对外接口，另外，也要求具备完善的监控、运维工具。 分布式存储数据需求比较复杂，大体可以分为三类： （1）非结构化数据 （2）结构化数据 （3）半结构化数据 不同的分布式存储系统适合处理不同类型的数据，将分布式存储系统分为四类： （1）分布式文件系统：互联网应用需要存储大量的图片，视频等非结构化数据对象，这类数据以对象的形式组织，对象之间没有关联，这样的数据一般称为Blob数据（Binary Large Object二进制大对象） 分布式文件系统存储三种类型的数据：Blob对象，定长块，大文件 （2）分布式键值系统：存储关系检点的半结构化数据