Zookeeper之基于Observer部署架构
2017-06-05 08:11
232 查看
Observers:在不伤害写性能的情况下扩展Zookeeper
虽然通过Client直接连接到Zookeeper集群的性能已经很好了,可是这样的架构假设要承受超大规模的Client,就必须添加Zookeeper集群的Server数量,随着Server的添加,Zookeeper集群的写性能必定下降。我们知道Zookeeper的Znode变更是要过半数投票通过,随着机器的添加,因为网络消耗等原因必定导致投票成本添加,从而导致写性能的下降。
Observer是一种新型的Zookeeper节点。能够帮助解决上述问题,提供Zookeeper的可扩展性。Observer不參与投票,仅仅是简单的接收投票结果。因此我们添加再多的Observer,也不会影响集群的写性能。除了这个区别,其它的和Follower基本上全然一样。
比如:Client都能够连接到他们,而且都能够发送读写请求给他们,收到写请求都会上报到Leader。
Observer有另外一个优势,由于它不參与投票,所以他们不属于Zookeeper集群的关键部位,即使他们Failed,或者从集群中断开,也不会影响集群的可用性。
依据Observer的特点。我们能够使用Observer做跨数据中心部署。假设把Leader和Follower分散到多个数据中心的话,由于数据中心之间的网络的延迟。势必会导致集群性能的大幅度下降。使用Observer的话,将Observer跨机房部署。而Leader和Follower部署在单独的数据中心,这样更新操作会在同一个数据中心来处理,并将数据发送的其它数据中心(包括Observer的),然后Client就能够在其它数据中心查询数据了。可是使用了Observer并不是就能全然消除数据中心之间的延迟,由于Observer还得接收Leader的同步结果合Observer有更新请求也必须转发到Leader,所以在网络延迟非常大的情况下还是会有影响的,它的优势就为了本地读请求的高速响应。
使用Observer
假设要使用Observer模式,能够在相应节点的配置文件加入例如以下配置:
上面不过告诉Zookeeper该节点是Observer,其次。必须在配置文件指定哪些节点被指定为Observer,比如:
眼下我的工作中就用到了Observer,大致的架构例如以下图:
虽然通过Client直接连接到Zookeeper集群的性能已经很好了,可是这样的架构假设要承受超大规模的Client,就必须添加Zookeeper集群的Server数量,随着Server的添加,Zookeeper集群的写性能必定下降。我们知道Zookeeper的Znode变更是要过半数投票通过,随着机器的添加,因为网络消耗等原因必定导致投票成本添加,从而导致写性能的下降。
Observer是一种新型的Zookeeper节点。能够帮助解决上述问题,提供Zookeeper的可扩展性。Observer不參与投票,仅仅是简单的接收投票结果。因此我们添加再多的Observer,也不会影响集群的写性能。除了这个区别,其它的和Follower基本上全然一样。
比如:Client都能够连接到他们,而且都能够发送读写请求给他们,收到写请求都会上报到Leader。
Observer有另外一个优势,由于它不參与投票,所以他们不属于Zookeeper集群的关键部位,即使他们Failed,或者从集群中断开,也不会影响集群的可用性。
依据Observer的特点。我们能够使用Observer做跨数据中心部署。假设把Leader和Follower分散到多个数据中心的话,由于数据中心之间的网络的延迟。势必会导致集群性能的大幅度下降。使用Observer的话,将Observer跨机房部署。而Leader和Follower部署在单独的数据中心,这样更新操作会在同一个数据中心来处理,并将数据发送的其它数据中心(包括Observer的),然后Client就能够在其它数据中心查询数据了。可是使用了Observer并不是就能全然消除数据中心之间的延迟,由于Observer还得接收Leader的同步结果合Observer有更新请求也必须转发到Leader,所以在网络延迟非常大的情况下还是会有影响的,它的优势就为了本地读请求的高速响应。
使用Observer
假设要使用Observer模式,能够在相应节点的配置文件加入例如以下配置:
peerType=observer
上面不过告诉Zookeeper该节点是Observer,其次。必须在配置文件指定哪些节点被指定为Observer,比如:
server.1:localhost:2181:3181:observer
眼下我的工作中就用到了Observer,大致的架构例如以下图:
相关文章推荐
- Zookeeper之基于Observer部署架构
- [置顶] 基于docker部署的微服务架构: docker环境下的zookeeper和kafka部署
- 基于 SIP webRTC 架构的系统部署模型分析
- Spark集群基于Zookeeper的HA搭建部署笔记(转)
- ZooKeeper增加Observer部署模式提高性能(转)
- 基于dubbo从传统MVC架构转向SOA架构分布式设计4--(服务部署集群搭建及负载均衡)
- 基于dubbo从传统MVC架构转向SOA架构分布式设计3--(zookeeper集群)
- 基于LAMP架构部署web应用系统
- Docker 实践 06 搭建基于Nginx+Tomcat的分布式部署架构
- Kubernetes——基于容器技术的分布式架构领先方案,它的目标是管理跨多个主机的容器,提供基本的部署,维护以及运用伸缩
- 部署hadoop2.7.2 集群 基于zookeeper配置HDFS HA+Federation
- ZooKeeper 增加Observer部署模式提高性能
- Spark集群基于Zookeeper的HA搭建部署笔记
- Spark集群基于Zookeeper的HA搭建部署
- Mini Centos环境部署YDB,基于haoop,zookeeper和kafka
- 基于Zookeeper的TbSchedule任务调度服务部署以及应用
- 基于 SIP webRTC 架构的系统部署模型分析
- 基于 SIP webRTC 架构的系统部署模型分析
- 基于Dubbo的分布式系统架构-Zookeeper注册中心的安装
- 基于Dubbo的分布式系统架构(五):在Linux操作系统上手工部署Dubbo服务