架构-CP & AP

分布式系统的三个核心要素

  • 一致性(Consistency),同一时刻同一请求的不同实例返回的结果相同,这要求数据具有强一致性
  • 可用性(Availability),所有读写请求在一定时间内得到正确的响应
  • 分区容错性(Partition tolerance),在网络异常情况下,系统仍能正常运作

分布式系统设计要考虑的是在满足P的前提下选择C还是A

  • 如果要保证一致性(C)即:所有节点可查询到的数据随时随刻都是一致的(同步中的数据不可查询),就要求一个节点写入数据后必须再将数据写入到另一个节点后才能返回成功,这样当我们读取之前写入的数据时才能确保一致,但网络异常在所难免,节点间通讯异常,导致数据无法同步,此时返回了错误,进而牺牲了可用性(A)
  • 要保证可用性(A),即只要不是服务宕机所有请求都可得到正确的响应,那么在网络异常节点不能通讯的情况下要让数据没有同步到另一节点的请求也返回成功,这就必须牺牲一致性(C),导致在一段时间内两个服务节点所查询到的数据可能不同

结论

  • 选择CP,即满足一致性而牺牲可用性。意味着在网络异常出现多个节点孤岛时为了保证各个节点的数据一致系统会停止服务
  • 选择AP,即满足可用性牺牲一致性。网络异常时系统仍可工作,但会出现各节点数据不致的情况

举例

注册中心常用的Eureka和Zookeepr实现
	1、Eureka是AP的,Zookeeper是CP的
	   Spring Cloud推荐Eureka
	   因为注册中心的场景允许出现短暂的数据不一致情况,可用性要高于强一致性
	2、数据库HBase与Cassandra
	   两者同为NoSQL数据,部分需求两者都可满足,
	   但我们要考虑允不允许出现数据不一致
	   HBase是强一致性的,Cassandra则是弱一致性的,但换来了更好的可用性
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值