可用性

异地多活在近年越来越多大型互联网公司采用的方案，几乎也是大型应用发展到一定阶段的必然选择，综合比较一下各个互联网公司的方案，会发现有很多共性的东西，也有很多差异化的东西，这是最有意思的地方 什么是异地多活 异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活，是指这些机房在日常的业务中也需要走流量，做业务支撑。冷备份的主要问题是成本高，不跑业务，当主机房出问题的时候，也不一定能成功把业务接管过来。 CAP原则 分布式架构设计无论怎样都绕不开CAP原则，C一致性 A可用性 P分区容错性，分区容错性是必不可少的，没有分区容错性就相当于退化成了单机系统，所以实际上架构设计是在一致性和可用性一个天平上的两端做衡量。为什么强一致性和高可用性是不能同时满足？假如需要满足强一致性，就需要写入一条数据的时候，扩散到分布式系统里面的每一台机器，每一台机器都回复ACK确认后再给客户端确认，这就是强一致性。如果集群任何一台机器故障了，都回滚数据，对客户端返回失败，因此影响了可用性。如果只满足高可用性，任何一台机器写入成功都返回成功，那么有可能中途因为网络抖动或者其他原因造成了数据不同步，部分客户端独到的仍然是旧数据，因此，无法满足强一致性。 异地多活的挑战 延迟

单机MySQL的美好时代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 在那个时候，更多的都是静态网页，动态交互类型的网站不多 初期架构 | center DAL，（Data Access Layer）。其功能主要是负责数据库的访问。简单地说就是实现对数据表的Select（查询）、Insert（插入）、Update（更新）、Delete（删除）等操作。 上述架构下，我们来看看数据存储的瓶颈是什么？ 1、数据量的总大小 一个机器放不下时。（表要占空间，表的索引要占空间） 2、数据的索引（B+ Tree树）一个机器的内存放不下时库 3、访问量(读写混合)一个实例不能承受，（读写一个库） 真正意义上的库应该是主从复制，读写分离，而mysql等数据库只能自己从自己的库中读与写，也就是自己和自己玩。 如果满足了上述1 or 3个，则需要进化.. Memcached(缓存,java上还有一个ehcache)+MySQL+垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力， 优化数据库的结构和索引 。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享

什么是CAP理论？ 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后麻省理工学院的Seth Gilbert和NancyLynch从理论上证明了CAP，之后CAP理论正式成为分布式计算领域的公认定理。 CAP理论是由下面三个概念组成的，且在分布式系统中三者不能兼得，只能同时满足两种条件。 一致性（C） All nodes see the same data at the same time 所有数据库集群节点在同一时间点看到的数据完全一致，即所有节点能实时保持数据同步。 可用性（A） Reads and writes always succeed 读写操作永远是成功的。即服务一直是可用的，即使集群一部分节点故障，集群整体还能正常响应客户端的读写请求。 分区容错性（P） The system continues to operate despite arbitrary message loss or failure of part of the system 尽管系统中有任意的信息丢失或故障，系统仍在继续运行。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 CAP权衡使用 1、保留CA，放弃P 如果想避免分区容错性问题的发生

现在很火的微服务系统所设计的系统是分布式系统。分布式系统有一个著名的CAP理论，即一个分布式系统要同时满足一致性（Consistency）、可用性（Availablility）和分区容错（Partition Tolerance）三个特性是一件不可能的事情。 CAP理论的简介 CAP理论是由Eric Brewer在2000年的PODC会议上提出的，该理论在两年后被证明成立。 CAP理论告诉架构师不要妄想设计出同时满足三者的系统，应该有所取舍，设计出适合业务的系统。 一致性（Consistency）： 一致性指的是数据的强一致性。每次的读操作都是读取的最新数据。即如果写入某个数据成功的话，之后的读取都应该读的是新写入的数据；如果写入失败的话，之后读取的都不应该是写入失败的数据。 可用性（Availability）： 可用性指的是服务的可用性。即每个请求都能在合理的时间内获得符合预期的响应结果。 分区容错性（Partition Tolerance）： 分区容错性指的是当节点之间的网络出现问题之后，系统仍然能够正常提供服务。 在分布式的系统中，P是基本要求，而单体应用则是CA系统。微服务系统通常是一个AP系统，即同时满足可用性和分区容错性。这样就有了一个在分布式系统中保证数据强一致性的难题，这个难题的一个解决方案就是分布式事务。 分布式事务的解决方案 在微服务系统中

张大胖和CAP定理 原创： 刘欣 码农翻身 2017-03-13 计算机界有很多高大上又难于理解的术语，CAP就是其中之一， 什么一致性（Consistency）， 可用性（Availability）， 分区容错性（Partition tolerance） 就很难理解了， 再加上 CAP定理 更是让人云里雾里， 今天咱们试图通俗的演绎一下。 张大胖在公司奋发图强，经过多年的努力，终于做到了架构师的位置。 架构师的椅子还没坐热，很快就来了一个项目要做架构设计。 老板把大胖叫来，谆谆教导说： 大胖啊， 数据是我们的宝贵资产，你设计的系统可千万要保证数据不能丢失啊！ 大胖说老板放心， 这方面我有经验， 一般来讲我们要做数据的冗余处理， 简单的来讲就是给数据做多个副本来保存。 我会设计一个分布式系统， 把数据备份到多个机器节点去。 几天后， 大胖给发了一张图， 展示了这个分布式系统是怎么工作的： 数据副本在不同的机器上做冗余， 中间有数据的复制， 保证数据的同步。 虽然只是两台机器， 但是也构成了一个简单的分布式环境。 老板虽然不懂技术， 但是看到数据在不同的机器之间有备份，也就放心了。 经过几个月的开发和测试，系统顺利上线， 但是大家很快就发现： 分布式系统不像单机系统那么简单， 由于网络的原因， 或者某个机器的原因很容易导致通讯失败，或者节点不可用。 有一天， 用户先访问了左边的机器A

1.1. 分布式系统基础知识 一个 tomcat 打天下的时代，不能说完全淘汰了，在一个管理系统，小型项目中还经常使用，这并不过分，出于成本的考虑，这反而值得提倡。 1.1.1. 分布式系统是什么 分布式系统：一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统 这是分布式系统，在不同的硬件，不同的软件，不同的网络，不同的计算机上，仅仅通过消息来进行通讯与协调 这是他的特点，更细致的看这些特点又可以有：分布性、对等性、并发性、缺乏全局时钟、 故障随时会发生。 1.1.1.1. 分布性 既然是分布式系统，最显著的特点肯定就是分布性，从简单来看，如果我们做的是个电商项目，整个项目会分成不同的功能，专业点就不同的微服务，比如用户微服务，产品微服务，订单微服务，这些服务部署在不同的 tomcat 中，不同的服务器中，甚至不同的集群中，整个架构都是分布在不同的地方的，在空间上是随意的，而且随时会增加，删除服务器节点，这是第一个特性 1.1.1.2. 对等性 对等性是分布式设计的一个目标，还是以电商网站为例，来说明下什么是对等性，要完成一个分布式的系统架构，肯定不是简单的把一个大的单一系统拆分成一个个微服务，然后部署在不同的服务器集群就够了，其中拆分完成的每一个微服务都有可能发现问题，而导致整个电商网站出现功能的丢失。 比如订单服务，为了防止订单服务出现问题

“数据不能丢，服务不能停”，可以说这句话道出了用户对数据库的核心能力的要求。然而，传统的商业数据库必须依赖高可靠的硬件才能实现数据可靠性和服务可用性。OceanBase作为一款成熟的企业级分布式数据库，基于普通PC服务器，就能够做到传统高端硬件环境下的数据可靠性和服务可用性，而且还能做得更好！跟我们一起看看OceanBase的技术秘诀吧！ Part1 前言 说到数据可靠性和服务可用性，在数据库领域真是老生常谈的话题，可以说从数据库诞生之日起就如影随形。如果要用一句话来概括数据库对数据可靠性和服务可用性的要求，可以借用OceanBase数据库创始人阳振坤老师的一句话：“数据不能丢，服务不能停”。可以说，这句话也道出了用户对数据库的一个核心能力要求：除了功能完善、使用方便之外，还要绝对安全、足够健壮。可以说，为了满足这两个看似简单的要求，在数据库领域诞生了大量的技术和论文，也让无数人绞尽了脑汁。 在传统的商业数据库产品（如Oracle、DB2）中，虽然也有一些行之有效的软件技术（如Redo Log、主从热备技术等）用来提高数据可靠性和服务可用性，但整体来说对硬件的稳定性有很强的依赖。而传统的企业级服务器（如IBM 的Mainframe、AS400、Power等）和EMC、IBM等厂商的高端存储产品，能够很好的保证硬件的稳定性，因此也就成为了Oracle为代表的传统数据库产品的理想平台

分布式CAP理论 来自wiki: 在 理论计算机科学 中， CAP定理 （CAP theorem），又被称作 布鲁尔定理 （Brewer's theorem），它指出对于一个 分布式计算系统 来说，不可能同时满足以下三点：[ 1] [ 2] 一致性（ C onsistency） （等同于所有节点访问同一份最新的数据副本） 可用性 （ A vailability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据） 分区容错性 （ P artition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择[ 3] 。） 根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项[ 4] 。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。 来自 : 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后

下面继续本书第二部分的读书笔记部分 第二部分 软件测试基础 　　包括第4章 测试用例设计；第5章 单元（模块）测试；第6章 更高级别的测试 第6章 更高级别的测试（包括第7章 可用性测试） 　　1、为什么要进行更高级别的测试？ 　　回答更高级别测试是什么之前，需要知道软件产品开发周期模型，可以归纳为7个步骤： 　　 　　1.需求：由最终用户转换的一系列书面的需求 　　2.目标：通过同用户评估可行性和成本，将用户需求转换为具体的目标 　　3.产品规格说明：将目标转换为一个可以与最终用户交互的产品规格说明 　　4.系统设计：将规格说明进行系统设计，并将系统分割为单独的程序、部件或子系统。 　　5.程序结构设计：定义模块功能，模块层次结构及模块间接口，对程序结构进行设计 　　6.模块接口规格说明：设计规格说明，定义每个模块的接口和功能 　　7.代码：将模块接口规格说明转换为模块的源码 　　以上7个步骤之间，都包括信息的沟通、理解和转换，如果两个步骤之间的信息沟通和转换发生错误和偏差，程序中都会出现软件错误。而为了减少这种信息沟通和转换时发生的错误，需要在开发周期的不同阶段采用不同的测试方法（更高级别的测试），避免沟通和信息转换的不一致现象的发生。 　　在这些开发阶段采用的不同的测试方法，包括：模块测试、集成测试、功能测试、系统测试、验收测试、安装测试和可用性测试等。 　　 　　2

1…消息中间件？消息中间件特点、应用场景？ 异步处理，用户注 解耦，用户下单. 流量削峰，秒杀活动 日志处理 （kafka） 消息通讯，点对点，聊天室 缺点： 系统可用性降低（MQ挂了、MQ高可用性） 系统复杂度提高（重复消费、消息丢失） 数据一致性（B、C成功，D失败） 2.MQ挂了、MQ高可用性怎么解决？ RabbitMq的高可用性，基于主从分离 RabbitMq有三种模式： 单机模式 普通集群模式（无高可用性） 互相拉取，做本地持久化，可以提高吞吐量 镜像集群模式（高可用性） 每个MQ都有完整的镜像，太消耗资源 3.重复消费问题？如何保证消息消费的幂等性？ 比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update 一下好吧。 比如你是写 Redis，那没问题了，反正每次都是 set，天然幂等性。 比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。 比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据