微服务：8：zookeeper与dubbo核心面试题

简单介绍下zk选举机制

发生时机： 整个集群群龙无首的时候 服务启动 leader宕机之后 选举机制 集群中，半数zkServer同意，则产生新的leader 搭建集群时，一般是奇数个，半数以上同意产生leader 三台服务器，最多允许一台宕机 四台服务器，也是最多允许一台宕机 选举算法 对比(myid,zxid),先对比zxid，zxid大(数据越新)胜出，成为leader 如果zxid一致，则myid大者成为leader

zk集群是怎么处理读写请求的

从集群的角色出发：leader follower observer

leader 唯一可以处理写请求的角色 follower 只能处理读请求 observer 无选举投票权的follower，主要协助follower处理更多的读请求

请求过来时，如何处理

分布式锁实现

为什么要分布式锁 分布式环境中，如果各个服务节点去竞争资源，没办法使用单机多线程中JDK自带的锁，此时需要分布式锁来协调 企业有哪些常见的手段实现分布式锁 zookeeper 、redis、memcache 分布式锁的原理 zookeeper : 创建相应的节点，创建成功，则表示获取到相应的锁；释放锁时，则删除节点；创建失败，表示获取锁失败 redis、memcache ： 对应的去设置一个值作为锁的标志，每次获取锁的时候，判断对应的值是否存在； 存在，则无法获取；不存在，则设置相应的锁，表示获取到锁。(redis使用setnx，memcache使用add)

4 dubbo的架构

基于生产者和消费者机制

container: 服务容器负责启动，加载，运行服务提供者 服务提供者再启动时，向注册中心注册自己提供的服务 服务消费者再启动时，向注册中心订阅自己所需的服务 Registry:注册中心返回服务提供者地址列表给消费者，如果有变更注册中心将基于长连接推送变更数据给消费者。 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 Monitor: 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

如果集群崩溃，会短暂不可用，重新选举leader(基于zookeeper的选举机制) 如果注册中心短暂的down掉，consumer会基于本地缓存的注册中心信息发起远程的请求