zookeeper与dubbo核心面试题
简单介绍下zk选举机制
-
发生时机: 整个集群群龙无首的时候
- 服务启动
- leader宕机之后
-
选举机制
- 集群中,半数zkServer同意,则产生新的leader
- 搭建集群时,一般是奇数个,半数以上同意产生leader
三台服务器,最多允许一台宕机
四台服务器,也是最多允许一台宕机
-
选举算法
- 对比(myid,zxid),先对比zxid,zxid大(数据越新)胜出,成为leader
- 如果zxid一致,则myid大者成为leader
zk集群是怎么处理读写请求的
- 从集群的角色出发:leader follower observer
leader 唯一可以处理写请求的角色 follower 只能处理读请求 observer
无选举投票权的follower,主要协助follower处理更多的读请求
- 请求过来时,如何处理
是读请求,到follower,则直接返回给客户端;如果是写请求,则转发给leader处理;
分布式锁实现
-
为什么要分布式锁
- 分布式环境中,如果各个服务节点去竞争资源,没办法使用单机多线程中JDK自带的锁,此时需要分布式锁来协调
-
企业有哪些常见的手段实现分布式锁
zookeeper 、redis、memcache
-
分布式锁的原理
zookeeper : 创建相应的节点,创建成功,则表示获取到相应的锁;释放锁时,则删除节点;创建失败,表示获取锁失败
redis、memcache : 对应的去设置一个值作为锁的标志,每次获取锁的时候,判断对应的值是否存在;
存在,则无法获取;不存在,则设置相应的锁,表示获取到锁。(redis使用setnx,memcache使用add)
4 dubbo的架构
- 基于生产者和消费者机制
-
container: 服务容器负责启动,加载,运行服务提供者
-
服务提供者再启动时,向注册中心注册自己提供的服务
-
服务消费者再启动时,向注册中心订阅自己所需的服务
-
Registry:注册中心返回服务提供者地址列表给消费者,如果有变更注册中心将基于长连接推送变更数据给消费者。
-
服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
-
Monitor: 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。
如果集群崩溃,会短暂不可用,重新选举leader(基于zookeeper的选举机制)
如果注册中心短暂的down掉,consumer会基于本地缓存的注册中心信息发起远程的请求