dubbo+zookeeper

Dubbo

1.dubbo：是一款高性能的RPC（远程过程调用）框架。

它提供了三大核心能力：

• 面向接口的远程方法调用
• 智能容错和负载均衡
• 服务自动注册和发现zookeeper。

1.1 RPC技术基本原理

stub是为了方便client，service交互而生成出来的代码。

影响RPC速度的两个核心点：

• 序列化和反序列化(底层Io流 在传输)
• 底层封装socket传递消息通信,影响dubbo的通信时间

2.zookeeper宕机之后，dubbo还能使用吗？

• 可以，如果zookeeper集群中的某一台机器坏了，那么dubbo会自动访问zookeeper集群中的其他主机，zookeeper集群全部坏了，dubbo在第一次加载完的数据后，保存到数据本地(消费者端备份地址,ip,端口,包类名)一份，可以直接访问本地数据。
• dubbo可以进行直连 ——>绕开zookeeper (消费者端保存信息,)

3.集群下的dubbo负载均衡策略：

在集群情况下，dubbo提供了多种负载均衡策略，默认值是random随机调用。

• 方案一、random loadbalance：默认情况下，dubbo是random loadbalance随机调用实现负载均衡**(基于权重)**，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。

• 方案二、roundrobin loadbalance：是基于轮询和权重将流量打入到各个机器上去。可以调整权重，来控制各个机器的流量大小，合理分配请求。

• 方案三、leastactive loadbalance：这个是自动感知，如果这个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求。
  
• 方案四、consistanthash loadbalance：一致性hash算法，相同参数的请求一定分发到一个provider上去，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那么就走了一致性hash策略。

3.1 dubbo和zookeeper机制

zookeeper专门处理分布式，统一管理注册服务

底层: 文件系统+通知

通知: 提供者模块发生变化即时消费者

容错机制： 随机调用一个服务地址，如果失败重试另一地址

流程： 生产者生产出来内容后，往zookeeper中注册。消费者去找zookeeper订阅，zookeeper具有通知的特征，生产者发生变化的时候，zookeeper会把变化推送给消费者，同时，dubbo自身也具备容错机制，调用服务器的时候，如果出错，会重试另一地址。长连接就是说一直处于连接状态。短连接是定时过一会连接一次。

4.集群容错：

当一个服务调用另一个服务，如果失败时的处理方案； 以下5种：

• failover cluster模式：失败自动切换，自动重试其他机器，默认值。(重试多少次 )
• failfast cluster模式：一次调用失败就立即失败。
• failsafe cluster模式：出现异常，直接忽略,返回一个正常的空结果。(比价重要的数据)
• failbackc cluster模式：失败了后台自动记录请求，然后隔一段时间再次重发，直到发送请求成功.比较适合于写消息队列这种。
• forking cluster模式：(尽可能的保证成功)并行调用多个provider，只要一个成功就立即返回，forks设置最大并行数，消耗资源。

4.1 zookeeper宕 机与dubbo相连:

高可用的定义:通过设计,减少系统不能提供的服务时间

5.dubbo的服务降级：

**介绍:**当服务压力剧增时，根据实际业务情况和流量，对一些服务和页面有策略的不处理或做一种简单的方式处理，从而释放服务器资源以保证核心逻辑正确高效执行。

​ 两种手段： 1. 调用直接返回值为null，牺牲该模块,直接不发起远程调用。

​ 2.调用失败返回为null，不抛出异常，用来容忍服务不 稳定对调用方的影响。

6.dubbo原理：

dubbo的通信是实现了RPC技术，致力于封装通信的细节，通信底层是Netty。

netty：是一个异步事件驱动的网络应用框架，用于快速开发可维护的高性能协议服务器和客户端，它 极大的简化了TCP和UDP套接字服务器等网络编程，利用NIO（非阻塞io）实现。 底层是sockets

NIO原理

NIO主要有三大核心部分：

Channel(通道)，Buffer(缓冲区),Selector(多路复用选择器)
传统IO基于字节流和字符流进行操作，而NIO基于Channel和Buffer(缓冲区)进行操作，数据总是从通道读取到缓冲区中，或者从缓冲区写入到通道中。Selector(选择区)用于监听多个通 道的事件（比如：连接打开，数据到达）。因此，单个线程只要控制selectot就可用实现可以监听多个数据通道,从而线程非阻塞.一个多路复用器(Selector)可以负责成千上万个Channel,没有上限

#

1.zookeeper的概述

虚线都是异步访问，实线都是同步访问
蓝色虚线:在启动时完成的功能
红色虚线(实线)都是程序运行过程中执行的功能

调用关系说明:

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

Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。

Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式。

Zookeeper

1 Zookeeper=文件系统+通知机制

2.zookeeper能做什么？

• 统一命名服务（dubbo）
• 配置维护(如果数据发生改变,dubbo会自动通知其他的服务)
• 集群管理
• 分布式消息同步和协调机制(类似配置维护)
• 负载均衡
• 对dubbo的支持

备注：zookeeper提供了一套很好的分布式集群管理的机制，就是它基于层次型的目录树的数据结构，并对树种的节点进行有效的管理，从而设计出多种多样的分布式的分布式管理模式，作为分布式调度和沟通的桥梁。

3.配置参数解读

​ 解读zoo.cfg 文件中参数含义

• tickTime：通信心跳数，Zookeeper服务器心跳时间，单位毫秒

Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。

它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime)

• initLimit：LF初始通信时限

集群中的follower跟随者服务器(F)与leader领导者服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。

投票选举新leader的初始化时间

Follower在启动过程中，会从Leader同步所有最新数据到Follower，然后确定自己能够对外服务的起始状态。

Leader允许Follower 在initLimit时间内完成这个工作。

• syncLimit：LF同步通信时限

集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit ***** tickTime，

Leader认为Follwer死掉，从服务器列表中删除Follwer。

在运行过程中，Leader负责与ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。

如果L发出心跳包在syncLimit之后，还没有从F那收到响应，那么就认为这个F已经不在线了。

• dataDir：数据文件目录+数据持久化路径保存内存数据库快照信息的位置，如果没有其他说明，更新的事务日志也保存到数据库。
• clientPort：客户端连接端口

4.数据结构

4.1 文件系统

• zookeeper维护了一个类型文件系统的数据结构
• 类似windows的注册表,有名称,有树的节点, key–value的形式
• 可以看成一个数的结构的数据库,分布在不同的机器上叫做名称管理

4.1.1 初始节点Znode:

• ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点(都是键值对形式 key value )称做一个ZNode。
• 很显然zookeeper集群自身维护了一套数据结构。这个存储结构是一个树形结构，其上的每一个节点，我们称之为”znode”，每一个znode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。

4.1.2 深入节点Znode:

zookeeper的stat结构体：

znode维护一个stat结构体，这个stat包含数据变化的版本号，访问控制列表变化，还有时间戳。版本号和时间戳一起，可让zookeeper验证缓存和协调更新，每个znode数据发生了变化，版本号就增加。

例如：无论何时客户端检索数据，它也一起检索数据的版本号，并且客户端执行更新或删除时，客户端必须提供它正在改变的znode版本号，如果它提供的版本号和真实版本号不一致，更新。

• czxid：引起这个znode创建的zxid，创建节点的事务zxid，为了保证顺序性
• zkid：必须单调递增，因此zookeeper使用一个64位的数来表示，高32位是leader的epoch，从1开始，每次选出新的leader，epoch加1，低32位为该epoch内的序号，每次epoch变化，都将低32位的序号重置，这样保证zkid的全局递增性
• ctime：znode被创建的毫秒数（1970年开始）
• mzxid：znode最后更新的zxid
• mtime：znode最后被修改的时间
• pzxid：znode最后更新的子节点zxid

4.1.3 znode存在的类型

• 创建节点方式 -e临时数据 -s防止节点存在,

• PERSISTENT 持久化目录节点

• PERSISTENT_SEQUENTIAL 持久化顺序编号目录节点
• EPHEMERAL 临时目录节点
• EPHEMERAL SEQUENTIAL 临时顺序编号目录节点

小结：zookeeper的一个节点对应一个应用，节点存储的数据就是应用需要的配置信息

4.2.watch 通知机制

数据观察和节点观察

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、删除、子节点增加、zookeeper会通知客户端）

zookeeper支持watch的概念，客户端可以在每个znode节点上设置一个监听watch，如果被观察服务端的znode节点有变更，那么watch就被触发process，然后去重新取出数据,这个watch所属的客户端将收到一个通知包被告知那个节点发生了变化，把相应的时间通知给设置watcher的client端

在getData() getChildren()和exist()都有设置watch的选项。