可用性

1. CAP理论 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。 CAP理论为：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 1.1 一致性（Consistency） 一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。 1.2 可用性（Availability） 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。 1.3 分区容错性（Partition tolerance） 分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 2. CAP权衡

关于分布式事务，工程领域主要讨论的是强一致性和最终一致性的解决方案。典型方案包括： 两阶段提交（2PC, Two-phase Commit）方案 eBay 事件队列方案 TCC 补偿模式 缓存数据最终一致性 一、一致性理论 分布式事务的目的是保障分库数据一致性，而跨库事务会遇到各种不可控制的问题，如个别节点永久性宕机，像单机事务一样的ACID是无法奢望的。另外，业界著名的CAP理论也告诉我们，对分布式系统，需要将数据一致性和系统可用性、分区容忍性放在天平上一起考虑。 两阶段提交协议（简称2PC）是实现分布式事务较为经典的方案，但2PC 的可扩展性很差，在分布式架构下应用代价较大，eBay 架构师Dan Pritchett 提出了BASE 理论，用于解决大规模分布式系统下的数据一致性问题。BASE 理论告诉我们：可以通过放弃系统在每个时刻的强一致性来换取系统的可扩展性。 1、CAP理论 在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）3 个要素最多只能同时满足两个，不可兼得。其中，分区容忍性又是不可或缺的。 <img src="https://pic4.zhimg.com/v2-8bb62ba9e7ce9f35199da032e17f9bb7_b.png" data-rawwidth=

分布式系统理论基础 - CAP 12513 0 收藏 编辑 引言 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)：如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败

CAP理论 小结： Consistency 一致性 就是数据的一致性。一致性根据时间长短来达到一致性，又分为 强，弱，最终一致性 Availability 可用性 可用性是针对用户角度，发送一个请求，一定回复。保证这一点就是可用性 分区容错性 就是分布式节点中 某一个节点挂了，系统还能满足一致性和可用性 CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。 CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。 AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。 因为 AP更为重要 所以一般都是C，使用最终以执行 版权 我仅对文章的排版和部分文字进行了润色 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy

C onsistency 一致性 A vailability 可用性(指的是快速获取数据) P artition 分区容忍性(分布式) 10年前，Eric Brewer教授指出了著名的CAP理论，后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们，一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。 而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。如果你 关注的是一致性，那么您就需要处理因为系统不可用而导致的操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同，相应的采用的策略也是不一样的，只有真正的理解了系统的需求，才有可能利用好CAP理论。 作为架构师，一般有两个方向来利用CAP理论 key-value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。 领域模型 + 分布式缓存 + 存储 （Qi4j和NoSql运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。 我准备提供第三种方案：实现可以配置CAP的数据库，动态调配CAP。 CA

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

一、Eureka原理 1、架构图 首先来看eureka的官方结构图 　　其中，在Eureka集群配置中，处于不同节点的Eureka通过Replicate进行数据同步；Application Server为服务提供者，Client为服务消费者。 2、基本原理 在Eureka响应的过程中，有三个角色，分别是Eureka、服务提供者、服务消费者； 在服务启动后，服务提供者向Eureka注册自己的信息，如调用地址、提供服务信息等 Eureka为服务注册中心，向外暴露自己的地址，负责管理、记录服务提供者的信息，同时将符合要求的服务提供者地址列表返回服务消费者 服务消费者向Eureka订阅服务，表达自己的需求，然后得到服务提供者消息，远程调用即可 Eureka包含两个组件：Eureka Server和Eureka Client，作用如下: Eureka Client是一个Java客户端，主要用来简化和Eureka Server的交互 Eureka Server提供服务发现的能力，各个微服务启动时，通过Eureka Client向Eureka Server注册自己的信息，Server储存该服务的信息 微服务启动后，周期性(默认为30s)地向Server发送心跳信息，以续约自己的信息，超时(默认为90s)未接受到心跳信息，Server将注销该服务节点 在Eureka

做爬虫时，遇到访问太频繁IP被封是难以避免的，而本地单个IP是不足以进行大规模爬取，并且自己并不想购买付费代理，在这里构建一个IP代理池是非常有必要的。 代理池主要由5部分组成：ProxyGeter(代理获取模块)、RedisClient(代理管理模块，负责存储、删除、取出等基本操作)、Texter(代理可用性测试模块)和Web_Api(用户获取模块)。 ProxyGeter 从几个代理网站爬取最新的代理，并把代理存储到redis数据库中 RedisClient 主要实现ip的删、减、增等基本操作， 采用reids的几方面原因如下： redis的hash数据结构可以为IP的有效性（根据可用性分为0-100）进行评分； redis提供的key-value更方便地储存IP; 对于IP的存储、提取、删除、查询数量等功能会更加地快捷； Texter 模块的主要目的是检测ip的可用性。提前设置好需要检测的网站站点，然后随机取出数据库中的代理，用获取到的ip来访问目标站点： 若访问无效，首先降低ip的分数等级（减10），其次做判断：若该ip的分数等级低于10分直接从reids数据库中删除； 若访问有效，首先增加ip的分数等级（加10），其次更新reids中该ip的分数等级； Web_Api 为了让用户获取可用性ip更加方便一点，这里利用flask框架做了一个API

根据百度百科的定义，CAP定理又称CAP 原则 ，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。 一、CAP的定义 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了

MQ的优点和缺点? 优点:解耦 异步,削峰 解耦: 所以需要用来解耦: 异步: 解决方法: 削峰: 解决方法是: 缺点:降低高可用性.增加系统的复杂程度.一致性问题 降低高可用的原因: 系统引入的外部依赖越多,越容易挂掉,本来你就是A系统调用BCD三个系统的接口就好了,现在又加入一个mq,万一mq挂掉了,整个系统也就崩溃了. 增加系统的复杂程度: 硬生生的增加一个MQ进来怎么保证不被重复消费?怎么保证不会出现消息丢失的情况?怎么保证消息传递的顺序性? 一致性问题: 系统A处理完以后直接返回成功了,人家都认为你这个请求成功了,但问题是,要是BCD三个系统成功了,结果C系统写库失败了,咋整?数据就不一致了. 如果发生丢消息的时候怎么解决? 同时还可以采用mq手动签到的方式,client真的接收到了消息,才签到,否则就不能签到,直接接收再签到. 怎么保证MQ不会重复发送消息? 采用的是一张表来记录消息处理的状态,在处理MQ发送的消息的时候,我先查看一下这张表,是不是处理过相同的消息.如果发送过,就不在发送. MQ重复消费的问题 1.首先产生mq重复消费的问题的原因 2.如何解决mq的重复消费问题 mq消息的顺序是怎么进行保证的? 消息被发送的时候保持顺序 消息被存储的时候保持和发送的顺序的一致 消息被消费的时候保持和存储的消息顺序一致. 1. 引入消息队列之后如何保证其高可用性? （1