分布式系统CAP理论以及注册中心选择

CAP定理:
指的是在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可同时获得。

一致性(C-数据同步耗时):所有节点在同一时间具有相同的数据,节点越多,数据同步越耗时。
可用性(A-保证正常响应时间):服务一直可用,保证每个请求不管成功或者失败都有响应,而且是正常响应时间
分区容错性(P-机器数量多):分区容忍性,就是高可用性,一个节点崩了,并不影响其它的节点(100个节点,挂了几个,不影响服务,机器越多越好)

值得注意的是,CAP原理指的是在分区容错发生时,只能在保证一致性或可用性中二选其一。因为分区容错不可避免,在系统设计时必须放弃一致性或可用性,没有分区发生时可以同时保证一致性和可用性。

CA 满足的情况下,P不能满足的原因:
数据同步(C)需要时间,也要正常的时间内响应(A),那么机器数量就要少,所以P就不满足,存在单点问题。

CP 满足的情况下,A不能满足的原因:
数据同步(C)需要时间, 机器数量也多(P),但是同步数据需要时间,所以不能再正常时间内响应,所以A就不满足。

AP 满足的情况下,C不能满足的原因:
机器数量也多(P),正常的时间内响应(A),那么数据就不能及时同步到其他节点,所以C不满足。

好了,明白这些理论,就可以在相应的场景选择服务注册与发现了。

注册中心选择:
Zookeeper:CP原则,保证了一致性,集群搭建的时候,某个节点失效,则会进行选举leader,或者半数以上节点不可用,则无法提供服务,因此可用性没法满足
Eureka:AP原则,无主从节点,一个节点挂了,自动切换其他节点可以使用,去中心化
Consul:保证CA,提供较高的可用性,并能 k-v store 服务保证一致性 CA 类型的场景

结论:分布式系统中 P 肯定要满足,所以只能在CA中二选一。

没有最好的选择,最好的选择是根据业务场景来进行架构设计,
如果要求一致性,则选择zookeeper,如金融行业
如果要求可用性,则Eureka,如电商系统

原文地址:https://www.cnblogs.com/linjiqin/p/10078127.html

时间: 2024-07-30 14:47:58

分布式系统CAP理论以及注册中心选择的相关文章

分布式系统CAP理论

引言 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]期间研发搜索引擎.分布

Spring Cloud 核心组件——注册中心

1. 什么是微服务的注册中心 注册中心:服务管理,核心是有个服务注册表,心跳机制动态维护. 为什么要用? 微服务应用和机器越来越多,调用方需要知道接口的网络地址,如果靠配置文件的方式去控制网络地址,对于动态新增机器,维护带来很大问题. 主流的注册中心:Zookeeper.Eureka.Consul.ETCD 等. 服务提供者 Provider:启动的时候向注册中心上报自己的网络信息. 服务消费者 Consumer:启动的时候向注册中心上报自己的网络信息,拉取 Provider 的相关网络信息.

spring cloud(二)服务(注册)中心Eureka

Eureka是Netflix开源的一款提供服务注册和发现的产品,它提供了完整的Service Registry和Service Discovery实现.也是springcloud体系中最重要最核心的组件之一. 背景介绍 服务中心 服务中心又称注册中心,管理各种服务功能包括服务的注册.发现.熔断.负载.降级等,比如dubbo admin后台的各种功能. 有了服务中心调用关系会有什么变化,画几个简图来帮忙理解 项目A调用项目B 正常调用项目A请求项目B 有了服务中心之后,任何一个服务都不能直接去掉用

springcloud(二):注册中心Eureka

http://www.ityouknow.com/spring-cloud.html Eureka是Netflix开源的一款提供服务注册和发现的产品,它提供了完整的Service Registry和Service Discovery实现.也是springcloud体系中最重要最核心的组件之一. 背景介绍 服务中心 服务中心又称注册中心,管理各种服务功能包括服务的注册.发现.熔断.负载.降级等,比如dubbo admin后台的各种功能. 有了服务中心调用关系会有什么变化,画几个简图来帮忙理解 项目

spring cloud 搭建注册中心Eureka(集群模式)

集群 注册中心这么关键的服务,如果是单点话,遇到故障就是毁灭性的.在一个分布式系统中,服务注册中心是最重要的基础部分,理应随时处于可以提供服务的状态.为了维持其可用性,使用集群是很好的解决方案.Eureka通过互相注册的方式来实现高可用的部署,所以我们只需要将Eureke Server配置其他可用的serviceUrl就能实现高可用部署. 新建3个配置文件 application-peer1.yml spring: application: name: Service #应用名称,也是服务注册的

这个注册的 IP 网络都不通了,Eureka 注册中心竟然无法踢掉它!

本文导读: 微服务技术架构选型介绍 k8s 容器化部署架构方案 Eureka 注册中心问题场景 问题解决手段及原理剖析 阅读本文建议先了解: 注册中心基本原理 K8s(Kuberneters)基本概念 我们的微服务目前都是在服务器上部署的,也是基于 Docker 来部署的. 运维部门基于 K8s 自研了一套容器云管理平台,平台名称叫做 Ares,我们也开始准备将微服务迁移到这平台上,降低虚拟机或实体机服务器运维成本,提高服务器资源利用效率. Ares:阿瑞斯(战神) 希腊神话中为战争而生的神,奥

微服务时代之网关及注册中心高可用架构设计

1. 微服务关系架构图 简要说明: (1)所有应用或者服务要想对外提供服务(包括网关),必须首先到注册中心进行注册. (2)所有访问通过服务网关进行访问,然后由服务网关路由到对应服务中心进行交互访问. 2. 网关及注册中心高可用架构图 2.1 springcloud eureka高可用方案 由上图可以看出,注册中心与路由很容易成为单点故障,软件老王以前使用springcloud eureka高可用架构方案: (1)euraka部署成集群模式,相互注册,通过心跳策略同步注册信息: (2)客户端注册

CAP理论以及服务注册与发现

CAP理论是分布式架构中重要理论 一致性(Consistency) (所有节点在同一时间具有相同的数据)可用性(Availability) (保证每个请求不管成功或者失败都有响应)分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作) 关于P的理解,我觉得是在整个系统中某个部分,挂掉了,或者宕机了,并不影响整个系统的运作或者说使用,而可用性是,某个系统的某个节点挂了,但是并不影响系统的接受或者发出请求,CAP 不可能都取,只能取其中2个 原因是如

Eureka 2.X 停止开发,但注册中心还有更多选择:Consul 使用详解

在上个月我们知道 Eureka 2.X 遇到困难停止开发了,但其实对国内的用户影响甚小,一方面国内大都使用的是 Eureka 1.X 系列,另一方面 Spring Cloud 支持很多服务发现的软件,Eureka 只是其中之一,下面是 Spring Cloud 支持的服务发现软件以及特性对比: Feature euerka Consul zookeeper etcd 服务健康检查 可配支持 服务状态,内存,硬盘等 (弱)长连接,keepalive 连接心跳 多数据中心 - 支持 - - kv 存