面试官:咳咳咳,看你简历写了精通ZooKeeper,那我就随便考考你吧
面试官:不用慌尽管说,错了也没关系?。。。
每日分享大厂面试演练,感兴趣就关注我吧??
嗯嗯,主要有这几种。
面试官思考中…
嗯嗯好的,那我讲下分布式锁。
是这样的,ZooKeep的获取锁时会在/exclusive_lock节点下创建子节点,如果创建成功则获得锁。如果失败,则客户端会在该节点注册一个子节点变更的Watcher监听。
同样,释放锁则删除该子节点,此时Watcher监听就会通知客户端可以重新获取了。
面试官思考中…
好的面试官。共享锁也是类似的场景。
每次读、写请求同样是创建子节点,是一个类似于“/shared_lock/Hostname-请求类型-序号”的临时顺序节点。
接着会获取子节点列表,同时注册Watcher监听。
而共享锁的释放锁和排他锁都是一样的。
噢噢知道的面试官,这个问题主要是出现在集群规模比较大的场景下。
其实共享锁的特别之处,在于每次读、写请求都要注册Watcher监听来获取子节点列表,特别是数量更多的读请求。
子节点列表每次变动都要通知所有的服务器客户端,造成了短时间大量的事件通知,给ZooKeeper带来很大性能消耗。
面试官思考中…
我认为要两方面来看吧。
首先我上面说的共享锁实现方式如果在集群不大的情况下是可行的,而且他实现简单实用。而如果在集群规模大的场景下,可以这样改进。
读、写请求首先获取子节点列表,但都不注册Watcher监听。
这样就可以避免羊群效应,主要是从监听子节点列表,改进为只监听某个子节点。
面试官心想,还不错嘛..
嗯嗯好的,我了解到的主要有3方面。
Broker启动后都会到ZooKeeper上创建属于自己的临时节点,其节点路径为/broker/ids/0…N,注册Topic节点也是一样。
Kafka消息生产者会通过监听Broker节点列表,负载均衡地分发到某一个Broker。
消费者消费消息后,都会在消息分区写入临时节点,代表该消息已消费。
面试官思考中…
哦哦说欠了,消费者负载均衡有两方面。
面试官抓抓脑袋,继续看你的简历......得想想考点你不懂的?
好了,今天的分享就先到这,我们下期继续。
创作不易,不妨点赞、收藏、关注支持一下,各位的支持就是我创作的最大动力??
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。