【分布式协调服务】-- zookeeper 出现背景

本文介绍了在集群服务中遇到的协议地址维护、负载均衡和服务动态上下线感知等问题,并提出通过引入分布式协调服务Zookeeper来解决这些问题。Zookeeper最初为解决共享资源竞争而设计,后演变为高可用的集群,采用ZAB协议处理领导者选举和故障恢复。它在分布式系统中提供顺序访问和数据一致性,简化了分布式事务处理。文章还提及了数据同步中的CAP理论,以及为何事务请求集中在领导者节点上。
摘要由CSDN通过智能技术生成

集群服务的问题:

  1. 协议地址的维护
    一个服务分别部署在多个服务器上,每个服务器的地址都是一个协议地址
  2. 负载均衡机制
    转发请求,均衡各个服务节点的负载
  3. 服务动态上下线感知
    (上线:某个服务发布上线调用者可以知晓; 下线:如若集群中某个节点服务出问题宕机可以迅速定位)

如何解决集群服务问题

思路: (我们需要一个什么样的东西来解决上述问题)

  1. 需要有一个中间件
  2. 发布服务的时候可以注册到中间件上去,在中间件上维护一个类似电话簿的功能(存着所有目标服务器的地址),断开时也可以立即知晓。
  3. 客户端只需要拿到中间件地址即可知道目标服务器的所有信息
  4. 中间件可以感知各个服务的上下线状况,
  5. 这样开发者更专注与其应用本身的逻辑而不是关注分布式系统处理。

引入了zookeeper(分布式协调服务)

zookeeper是用来协调各个服务访问的顺序性,也用来管理中间件。

  1. zookeeper起源于雅虎,最初设计目标是解决共享资源竞争的问题,解决了多节点访问共享资源时候各个节点的接入顺序,(各个节点都是独立的进程)
  2. 后来,为了防止单点故障,zookeeper作为了一个中间件也需要做集群,来保证本身的高可用。
  3. 由此引入了zookeeper集群中各个中间件之间的数据同步问题,集群中的每个节点都可以接收到请求,而且每个节点的数据都必须要保持一致,这样就引入了一个leader节点来负责协调和做数据同步操作。因为集群中
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值