分布式领域CAP理论

Posted 2021-05-01 爆走小剧情

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼；

分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳

● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

● 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

对于web网站来说，关系数据库的很多主要特性却往往无用武之地

1. 数据库事务一致性需求 
   　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。

2. 数据库的写实时性和读实时性需求
   　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

3. 对复杂的SQL查询，特别是多表关联查询的需求 
   　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

4. 说到这里，技术的同学，是不是get到了新的技能呢，非技术的同学，还在一脸懵逼的吧，下面，给大家举个例子，让大家更好的理解这个精髓；

互联网世界里，有两个罗胖子，一个是前段时间，在鸟巢开发布会的罗永浩，重新定义了下一个十年的PC，重新定义了“‘重新定义”……感兴趣的同学可以自己去查看哦，下面说的是，《罗永浩不可能三角（Lou is impossible triangle）》

罗永浩“不可能三角”

所以江湖上有了罗永浩不可能三角：“要脸”、“诚实”、“保销量”，在老罗那里，三者不可能同时存在。意即：如果罗老师“要脸”并且“诚实”，那他就不可能“保销量”；如果罗老师“要脸”“保销量”，那他就不可能“诚实”；而如果他“诚实”并且“保销量”，那他就不可能“要脸”。

看到这里，是不是跟cap理论很像，三者是不可兼得；大家对这个理论有了概念之后，下面，我们来说下，在分布式的系统中的服务发现几个框架的一点对比

Eureka保证AP

    

Eureka各个节点之间，采取的是伙伴机制做集群操作的，都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

a. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务

b. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)

c. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

Zookeeper保证CP

zk各个节点之间，采用的是选举模式（所以都会建议，zk集群的时候，采用单数的服务，如3，5，7这样，保证在选举过程中，可以保证会有主线程产生），做集群操作的，当主的线程宕机了，或者网络原因，产生故障的时候，内部就会使用选举模式，来选出新的领导出来，整个选举过程，时间较长，在选举过程中，zk是不可用的；这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

consul 保证的CA

Consul提供强大的一致性保证，因为服务器使用Raft协议复制状态 。Consul支持丰富的健康检查，包括TCP，HTTP，Nagios / Sensu兼容脚本或基于Eureka的TTL。客户端节点参与基于XX的健康检查，该检查分发健康检查工作，而不像集中式心跳检测那样成为可扩展性挑战。发现请求被路由到选举出来的领事领导，这使他们默认情况下强烈一致。允许陈旧读取的客户端使任何服务器都可以处理他们的请求，从而实现像Eureka这样的线性可伸缩性。

另外consul ，其实我也不熟悉，zk和eureka用的比较多点，比如说基于zk的调度工具，当当开源的《elastic-job》，以及阿里开源的dubbo等，英语好的同学，可以自己翻译；今天就先分享到这里