微服务：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处理更多的读请求

• 请求过来时，如何处理

是读请求，到follower，则直接返回给客户端；如果是写请求，则转发给leader处理；

分布式锁实现

• 为什么要分布式锁

  • 分布式环境中，如果各个服务节点去竞争资源，没办法使用单机多线程中JDK自带的锁，此时需要分布式锁来协调

• 企业有哪些常见的手段实现分布式锁

  zookeeper 、redis、memcache

• 分布式锁的原理

  zookeeper : 创建相应的节点，创建成功，则表示获取到相应的锁；释放锁时，则删除节点；创建失败，表示获取锁失败

  redis、memcache ： 对应的去设置一个值作为锁的标志，每次获取锁的时候，判断对应的值是否存在；
  存在，则无法获取；不存在，则设置相应的锁，表示获取到锁。(redis使用setnx，memcache使用add)

4 dubbo的架构

• 基于生产者和消费者机制

• container: 服务容器负责启动，加载，运行服务提供者

• 服务提供者再启动时，向注册中心注册自己提供的服务

• 服务消费者再启动时，向注册中心订阅自己所需的服务

• Registry:注册中心返回服务提供者地址列表给消费者，如果有变更注册中心将基于长连接推送变更数据给消费者。

• 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

• Monitor: 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

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