Zookeeper概述
Zookeeper是一个开源的分布式（多台服务器干一件事）的，为分布式应用提供协调服务的Apache项目。
在大数据技术生态圈中，zookeeper（动物管理员），Hadoop（大象），Hive（蜜蜂），Pig（猪）等技术。
工作机制
- Zookeeper从设计模式角度来理解：是一个基于观察者模式（一个人干活，有人盯着他）设计的分布式服务管理框架
- 它负责 存储 和 管理 大家都关心的数据
- 然后接受观察者的注册，一旦这些数据的发生变化
- Zookeeper就将负责通知已经注册的那些观察者做出相应的反应
- 从而实现集群中类似Master/Slave管理模式
- Zookeeper = 文件系统 + 通知机制
1. 商家营业并入驻
2. 获取到当前营业的饭店列表
3. 服务器节点下线
4. 服务器节点上下线事件通知
5. 重新再去获取服务器列表，并注册监听
特点
分布式和集群的区别？
无论分布式和集群，都是很多人在做事情。具体区别如下：
例如：我有一个饭店，越来越火爆，我得多招聘一些工作人员
分布式：招聘1个厨师，1个服务员，1个前台，三个人负责的工作不一样，但是最终目的都是为饭店工作
集群：招聘3个服务员，3个人的工作一样
1. 是一个leader和多个follower来组成的集群（狮群中，一头雄狮，N头母狮）
2. 集群中只要有半数以上的节点存活，Zookeeper就能正常工作（5台服务器挂2台，没问题；4台服务器挂2台，就停止）
3. 全局数据一致性，每台服务器都保存一份相同的数据副本，无论client连接哪台server，数据都是一致的
4. 数据更新原子性，一次数据要么成功，要么失败（不成功便成仁）
5. 实时性，在一定时间范围内，client能读取到最新数据
6. 更新的请求按照顺序执行，会按照发送过来的顺序，逐一执行（发来123，执行123，而不是321或者别的）
数据结构
- ZooKeeper数据模型的结构与linux文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode（ZookeeperNode）。
- 每一个ZNode默认能够存储1MB的数据（元数据），每个ZNode的路径都是唯一的
- 元数据（Metadata），又称中介数据、中继数据，为描述数据的数据（data aboutdata），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能
应用场景
- 提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等
统一命名服务
- 在分布式环境下，通常需要对应用或服务进行统一的命名，便于识别
- 例如：服务器的IP地址不容易记，但域名相比之下却是很容易记住
统一配置管理
将配置管理交给Zookeeper
1、将配置信息写入到Zookeeper的某个节点上
2、每个客户端都监听这个节点
3、一旦节点中的数据文件被修改，Zookeeper这个话匣子就会通知每台客户端服务器
服务器节点动态上下线
客户端能实时获取服务器上下线的变化
在美团APP上实时可以看到商家是否正在营业或打样
软负载均衡
Zookeeper本地模式安装
拷贝apache-zookeeper-3.6.0-bin.tar.gz到opt目录，解压安装包
[root@localhost opt]# tar -zxvf apache-zookeeper-3.6.0-bin.tar.gz
重命名
[root@localhost opt]# mv apache-zookeeper-3.6.0-bin zookeeper
配置修改
1. 在/opt/zookeeper/这个目录上创建zkData和zkLog目录
[root@localhost zookeeper]# mkdir zkData [root@localhost zookeeper]# mkdir zkLog
2. 进入/opt/zookeeper/conf这个路径，复制一份 zoo_sample.cfg 文件并命名为 zoo.cfg
[root@localhost conf]# cp zoo_sample.cfg zoo.cfg
3. 编辑zoo.cfg文件，修改dataDir路径：
dataDir=/opt/zookeeper/zkData
dataLogDir=/opt/zookeeper/zkLog
操作Zookeeper
1. 启动Zookeeper
[root@localhost bin]# ./zkServer.sh start
2. 查看进程是否启动
[root@localhost bin]# jps
QuorumPeerMain：是zookeeper集群的启动入口类，是用来加载配置启动QuorumPeer线程的
3. 查看状态：
[root@localhost bin]# ./zkServer.sh status
4. 启动客户端
[root@localhost bin]# ./zkCli.sh
5. 退出客户端
[zk: localhost:2181(CONNECTED) 0] quit
配置参数解读
Zookeeper中的配置文件zoo.cfg中参数含义解读如下：
- tickTime =2000：通信心跳数，Zookeeper服务器与客户端心跳时间，单位毫秒
- Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。
- initLimit =10：LF初始通信时限
- 集群中的Follower跟随者服务器与Leader领导者服务器之间，启动时能容忍的最多心跳数
- 10*2000（10个心跳时间）如果领导和跟随者没有发出心跳通信，就视为失效的连接，领导和跟随者彻底断开
- syncLimit =5：LF同步通信时限
- 集群启动后，Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime->10秒，Leader就认为Follwer已经死掉，会将Follwer从服务器列表中删除
- dataDir：数据文件目录+数据持久化路径
- 主要用于保存Zookeeper中的数据。
- dataLogDir
- 日志文件目录
- clientPort =2181：客户端连接端口
- 监听客户端连接的端口。
Zookeeper内部原理
选举机制（面试重点）
半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器
虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的
1. Server1先投票，投给自己，自己为1票，没有超过半数，根本无法成为leader，顺水推舟将票数投给了id比自己大的Server2
2. Server2也把自己的票数投给了自己，再加上Server1给的票数，总票数为2票，没有超过半数，也无法成为leader，也学习Server1，顺水推舟，将自己所有的票数给了id比自己大的Server3
3. Server3得到了Server1和Server2的两票，再加上自己投给自己的一票。3票超过半数，顺利成为leader
4. Server4和Server5都投给自己，但是无法改变Server3的票数，只好听天由命，承认Server3是leader
节点类型
- 持久型（persistent）：
- 持久化目录节点（persistent）客户端与zookeeper断开连接后，该节点依旧存在
- 持久化顺序编号目录节点（persistent_sequential）客户端与zookeeper断开连接后，该节点依旧存在，创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护，例如：Znode001，Znode002...
- 短暂型（ephemeral）：
- 临时目录节点（ephemeral）客户端和服务器端断开连接后，创建的节点自动删除
- 临时顺序编号目录节点（ephemeral_sequential）客户端与zookeeper断开连接后，该节点被删除，创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护，例如：Znode001，Znode002...
注意：序号是相当于i++，和数据库中的自增长类似
监听器原理（面试重点）
1. 在main方法中创建Zookeeper客户端的同时就会创建两个线程，一个负责网络连接通信，一个负责监听
2. 监听事件就会通过网络通信发送给zookeeper
3. zookeeper获得注册的监听事件后，立刻将监听事件添加到监听列表里
4. zookeeper监听到 数据变化 或 路径变化，就会将这个消息发送给监听线程
常见的监听:
1. 监听节点数据的变化：get path [watch]
2. 监听子节点增减的变化：ls path [watch]
5. 监听线程就会在内部调用process方法（需要我们实现process方法内容）
写数据流程
1. Client 想向 ZooKeeper 的 Server1 上写数据，必须的先发送一个写的请求
2. 如果Server1不是Leader，那么Server1 会把接收到的请求进一步转发给Leader。
3. 这个Leader 会将写请求广播给各个Server，各个Server写成功后就会通知Leader。
4. 当Leader收到半数以上的 Server 数据写成功了，那么就说明数据写成功了。
5. 随后，Leader会告诉Server1数据写成功了。
6. Server1会反馈通知 Client 数据写成功了，整个流程结束
Zookeeper实战
分布式安装部署
集群思路：先搞定一台服务器，再克隆出两台，形成集群！
1. 在/opt/zookeeper/zkData创建myid文件（在文件中添加与server对应的编号）
2. 配置zoo.cfg文件
#######################cluster########################## server.1=192.168.204.141:2888:3888 server.2=192.168.204.142:2888:3888 server.3=192.168.204.143:2888:3888
配置参数解读 server.A=B:C:D
A：一个数字，表示第几号服务器
集群模式下配置的/opt/zookeeper/zkData/myid文件里面的数据就是A的值
B：服务器的ip地址
C：与集群中Leader服务器交换信息的端口
D：选举时专用端口，万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。
3. 配置其余两台服务器
1). 在虚拟机数据目录vms下，创建zk02
2). 将本台服务器数据目录下的.vmx文件和所有的.vmdk文件分别拷贝zk02下
3). 虚拟机->文件->打开 （选择zk02下的.vmx文件）
4). 开启此虚拟机，弹出对话框，选择“我已复制该虚拟机”
5). 进入系统后，修改linux中的ip，修改/opt/zookeeper/zkData/myid中的数值为2
第三台服务器zk03，重复上面的步骤
集群操作
每台服务器的防火墙必须关闭
systemctl stop firewalld.service
客户端命令行操作
启动客户端
[root@localhost bin]# ./zkCli.sh
显示所有操作命令
help
查看当前znode中所包含的内容
ls /
查看当前节点详细数据
ls -s /
cZxid：创建节点的事务
每次修改ZooKeeper状态都会收到一个zxid形式的时间戳，也就是ZooKeeper事务ID。
- 事务ID是ZooKeeper中所有修改总的次序。
- 每个修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前发生。
- ctime：被创建的毫秒数(从1970年开始)
mZxid：最后更新的事务zxid
mtime：最后修改的毫秒数(从1970年开始)
pZxid：最后更新的子节点zxid
cversion：创建版本号，子节点修改次数
dataVersion：数据变化版本号
aclVersion：权限版本号
ephemeralOwner：如果是临时节点，这个是znode拥有者的session id。如果不是临时节点则是0。
dataLength：数据长度
numChildren：子节点数
分别创建2个普通节点
create /china
create /usa
在根目录下，创建俄罗斯节点，并保存“普京”数据到节点上
create /ru "pujing"
多级创建节
- 在日本下，创建东京 “热”
- japan必须提前创建好，否则报错 “节点不存在”
create /japan/Tokyo "hot"
获得节点的值
get /japan/Tokyo
创建短暂节点：创建成功之后，quit退出客户端，重新连接，短暂的节点消失
create -e /uk
创建带序号的节点
create -s /ru/city
修改节点数据值
set /japan/Tokyo "too hot"
监听 节点的值变化 或 子节点变化（路径变化）
addWatch /usa
删除节点
delete /usa/NewYork
递归删除节点 （非空节点，节点下有子节点）
deleteall /ru
API应用
添加pom文件，配置依赖
<dependencies> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.8.2</version> </dependency> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.6.0</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> </dependency> </dependencies>
在resources下创建log4j.properties
log4j.rootLogger=INFO, stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n log4j.appender.logfile=org.apache.log4j.FileAppender log4j.appender.logfile.File=target/zk.log log4j.appender.logfile.layout=org.apache.log4j.PatternLayout log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n
创建ZooKeeper客户端
// zookeeper集群的ip和端口 private String connectString = "192.168.199.128:2181,192.168.199.129:2181,192.168.199.130:2181"; /* session超时的时间: 时间不宜设置太小。因为zookeeper和加载集群环境会因为性能等原因而延迟略高， 如果时间太少，还没有创建好客户端，就开始操作节点。会报错的。 （心急吃不了热豆腐） */ private int sessionTimeout = 60 * 1000; //zookeeper客户端对象 private ZooKeeper zkClient; @Before public void init() throws Exception { zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() { public void process(WatchedEvent watchedEvent) { System.out.println("得到监听反馈，再进行的业务处理代码！"); System.out.println(watchedEvent.getType()); } }); }
创建节点
创建节点时需要对节点指定权限
一个ACL对象就是一个Id和permission对
表示哪个/哪些范围的Id（Who）在通过了怎样的鉴权（How）之后，就允许进行那些操作（What）：Who How What；
permission（What）就是一个int表示的位码，每一位代表一个对应操作的允许状态。
类似linux的文件权限，不同的是共有5种操作：CREATE、READ、WRITE、DELETE、ADMIN(对应更改ACL的权限)
OPEN_ACL_UNSAFE：创建开放节点，允许任意操作 （用的最少，其余的权限用的很少）
READ_ACL_UNSAFE：创建只读节点
CREATOR_ALL_ACL：创建者才有全部权限
public void createNode() throws Exception { String str = zkClient.create("/lagou", "laosun".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); System.out.println("已创建节点: " + str); }
查询节点的值
public void getNodeData() throws Exception { byte[] bytes = zkClient.getData("/lagou", false, new Stat()); String str = new String(bytes); System.out.println("/lagou节点的数据：" + str); }
修改节点的值
public void update()throws Exception{ Stat stat = zKcli.setData("/lagou", "laosunA".getBytes(), 0); //先查看节点详 情，获得dataVersion = 0 System.out.println(stat); }
删除节点
public void delete() throws Exception { zKcli.delete("/lagou", 1); // 先查看节点详情，获得dataVersion = 1 System.out.println("删除成功！"); }
获取子节点
public void getChildren() throws Exception { List<String> children = zKcli.getChildren("/",false); // false:不监听 for (String child : children) { System.out.println(child); } }
监听子节点的变化
public void getChildren() throws Exception { List<String> children = zKcli.getChildren("/", true); // true：注册监听 for (String child : children) { System.out.println(child); } // 让线程不停止，等待监听的响应 System.in.read(); }
程序在运行的过程中，我们在linux下创建一个节点
IDEA的控制台就会做出响应：NodeChildrenChanged--/
判断Znode是否存在
public void exist() throws Exception { Stat stat = zKcli.exists("/lagou", false); System.out.println(stat == null ? "不存在" : "存在"); }
案例-分布式锁-商品秒杀
锁：我们在多线程中接触过，作用就是让当前的资源不会被其他线程访问！
我的日记本，不可以被别人看到。所以要锁在保险柜中
当我打开锁，将日记本拿走了，别人才能使用这个保险柜
在zookeeper中使用传统的锁引发的 “羊群效应” ：1000个人创建节点，只有一个人能成功，999人需要等待！
羊群是一种很散乱的组织，平时在一起也是盲目地左冲右撞，但一旦有一只头羊动起来，其他的羊也会不假思索地一哄而上，全然不顾旁边可能有的狼和不远处更好的草。羊群效应就是比喻人都有一种从众心理，从众心理很容易导致盲从，而盲从往往会陷入骗局或遭到失败。
传统锁模式：
避免“羊群效应”，zookeeper采用分布式锁
1. 所有请求进来，在/lock下创建 临时顺序节点 ，放心，zookeeper会帮你编号排序
2. 判断自己是不是/lock下最小的节点
1. 是，获得锁（创建节点）
2. 否，对前面小我一级的节点进行监听
3. 获得锁请求，处理完业务逻辑，释放锁（删除节点），后一个节点得到通知（比你年轻的死了，你成为最嫩的了）
4. 重复步骤2
在控制层中加入分布式锁的逻辑代码
{ // 重试策略 （1000毫秒试1次，最多试3次） RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3); //1.创建curator工具对象 CuratorFramework client = CuratorFrameworkFactory.newClient(connectString, retryPolicy); client.start(); //2.根据工具对象创建“内部互斥锁” InterProcessMutex lock = new InterProcessMutex(client, "/product_"+id); try { //3.加锁 lock.acquire(); productService.reduceStock(id); }catch(Exception e){ if(e instanceof RuntimeException){ throw e; } }finally{ //4.释放锁 lock.release(); } return "ok"; }
dubbo
什么是分布式系统？
《分布式系统原理与范型》定义：
“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”
分布式系统（distributed system）是建立在网络之上的软件系统。
简单来说：多个（不同职责）人共同来完成一件事！
任何一台服务器都无法满足淘宝的双十一的数据吞吐量，一定是很多台服务器公共来完成的。
歇后语：“三个臭皮匠赛过诸葛亮”，就是分布式系统的真实写照
单一应用架构
优点
- 小项目开发快 成本低
- 架构简单
- 易于测试
- 易于部署
缺点
- 大项目模块耦合严重 不易开发 维护 沟通成本高
- 新增业务困难
- 核心业务与边缘业务混合在一块，出现问题互相影响
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成几个互不相干的几个应用,以提高效率；
大模块按照mvc分层模式，进行拆分成多个互不相关的小模块，并且每个小模块都有独立的服务器此时，用于加速前端页面开发的web框架（MVC）是关键；因为每个小应用都有独立的页面
MVC：模型视图控制器 （Model View Controller）
缺点：
模块之间不可能完全没有交集，公用模块无法重复利用，开发性的浪费
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的业务，逐渐形成稳健的服务中心，使前端应用能更快速的响应多变的市场需求；
此时，用户提高业务复用及整合的分布式服务框架（RPC）远程调用是关键；
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐呈现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率；
此时，用于提高机器利用率的资源调度和治理中心（SOA）是关键；
SOA：面向服务架构（Service-Oriented Architecture），简单理解就是“服务治理”，例如：公交车站的“调度员”
Dubbo简介
Dubbo是分布式服务框架，是阿里巴巴的开源项目，现交给apache进行维护
Dubbo致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案
简单来说，dubbo是个服务框架，如果没有分布式的需求，是不需要用的
RPC
RPC【Remote Procedure Call】是指远程过程调用，是一种进程间通信方式
RPC基本的通信原理
1. 在客户端将对象进行序列化
2. 底层通信框架使用netty（基于tcp协议的socket），将序列化的对象发给服务方提供方
3. 服务提供方通过socket得到数据文件之后，进行反序列化，获得要操作的对象
4. 对象数据操作完毕，将新的对象序列化，再通过服务提供方的socket返回给客户端
5. 客户端获得序列化数据，再反序列化，得到最新的数据对象，至此，完成一次请求
RPC两个核心模块：通讯（socket），序列化。
节点角色
调用关系
1.服务容器负责启动，加载，运行服务提供者；
2.服务提供者在启动时，向注册中心注册自己提供的服务；
3.服务消费者在启动时，向注册中心订阅自己所需的服务；
4.在注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者；
5.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用；
6.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心；
注册中心
官方推荐使用zookeeper注册中心；
注册中心负责服务地址的注册与查找，相当于目录服务；
服务提供者和消费者只在启动时与注册中心交互，注册中不转发请求，压力较小；
Zookeeper是apache hadoop的子项目，是一个树形的目录服务，支持变更推送，适合作为dubbo的服务注册中心，工业强度较高，可用于生产环境；
dubbo即是求职的人，也是招聘单位，而zookeeper就是人才市场/招聘网站
服务消费方
@Reference // 远程去服务方将service的实现类注入进来
服务方和消费方关于spring.xml文件的配置
<!--1.服务提供方在zookeeper中的“别名”--> <dubbo:application name="dubbo-server"/> <!--Dubbo的应用名称，通常使用项目名 --> <dubbo:application name="dubbo-consumer" /> <!--2.注册中心的地址--> <dubbo:registry address="zookeeper://192.168.204.141:2181"/> <!--3.扫描类（将什么包下的类作为服务提供类）--> <dubbo:annotation package="service.impl"/>
监控中心
1. 解压 dubbo-admin-master.zip
2. 修改配置文件
3. 返回到项目根目录，使用maven打包： mvn clean package
4. 在dos下运行target目录中的jar文件：java -jar dubbo-admin-0.0.1-SNAPSHOT.jar
监控统计中心
Monitor：统计中心 ，记录服务被调用多少次等
1. 解压dubbo-monitor-simple-2.5.3.zip
2. 修改dubbo-monitor-simple-2.5.3confdubbo.properties
3. 双击运行dubbo-monitor-simple-2.5.3instart.bat
4. 分别修改dubbo-server和dubbo-consumer的spring.xml，加入下面标签
<!-- 让监控 去注册中心 自动找服务 --> <dubbo:monitor protocol="registry"/>
启动时检查
启动时会在注册中心检查依赖的服务是否可用，不可用时会抛出异常
在消费方编写初始化容器的main方法启动（tomcat启动方式，必须访问一次action才能初始化spring）
public class Test { public static void main(String[] args) throws IOException { ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:spring/spring.xml"); System.in.read(); } }
<!--默认是true:抛异常；false:不抛异常--> <dubbo:consumer check="false" />
系统级别日志，需要配合log4j才输出，在resources下添加log4j.properties，内容如下：
log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.Target=System.out log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %m%n log4j.appender.file=org.apache.log4j.FileAppender log4j.appender.file.File=dubbo.log log4j.appender.file.layout=org.apache.log4j.PatternLayout log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %l %m%n log4j.rootLogger=error, stdout,file
超时时间
由于网络或服务端不可靠，会导致调用过程中出现不确定的阻塞状态（超时）
为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间
在服务提供者添加如下配置：
<!--设置超时时间为2秒，默认为1秒--> <dubbo:provider timeout="2000"/>
配置原则：
dubbo推荐在Provider上尽量多配置Consumer端属性：
1. 作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等
2. 在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作消费者的缺省值。
重试次数
当出现失败，自动切换并重试其它服务器，dubbo重试的缺省值是2次，我们可以自行设置
在provider提供方配置：
<!-- 消费方连接第1次不算，再来重试3次，总共重试4次 --> <dubbo:provider timeout="2000" retries="3"/>
并不是所有的方法都适合设置重试次数
- 幂等方法：适合（当参数一样，无论执行多少次，结果是一样的，例如：查询，修改）
- 非幂等方法：不适合（当参数一样，执行结果不一样，例如：删除，添加）
单独设置某个方法（消费方配置方法重试次数）
<dubbo:reference interface="service.HelloService" id="helloService"> <dubbo:method name="sayHello" retries="3"/> <dubbo:method name="sayNo" retries="0"/> <!-- 不重试 --> </dubbo:reference>
多版本
一个接口，多个（版本的）实现类，可以使用定义版本的方式引入
为HelloService接口定义两个实现类，提供者修改配置：
<dubbo:service interface="service.HelloService" class="service.impl.HelloServiceImpl01" version="1.0.0"/> <dubbo:service interface="service.HelloService" class="service.impl.HelloServiceImpl02" version="2.0.0"/>
消费者就可以根据version的版本，选择具体的服务版本
<dubbo:reference interface="service.HelloService" id="helloService" version="2.0.0"> <dubbo:method name="sayHello" retries="3"/> <dubbo:method name="sayNo" retries="0"/> </dubbo:reference>
当消费者的版本修改为 version="*"，那么就会随机调用服务提供者的版本
本地存根
先在消费者处理一些业务逻辑，再调用提供者的过程，就是“本地存根”
代码实现肯定在 消费者，创建一个HelloServiceStub类并且实现HelloService接口
注意：必须使用构造方法的方式注入
public class HelloServiceStub implements HelloService { private HelloService helloService; // 注入HelloService public HelloServiceStub(HelloService helloService) { this.helloService = helloService; } public String sayHello(String name) { System.out.println("本地存根数据验证。。。"); if(!StringUtils.isEmpty(name)){ return helloService.sayHello(name); } return "i am sorry!"; } public String sayNo() { return helloService.sayNo(); } }
修改消费者配置：
<dubbo:reference interface="service.HelloService" id="helloService" version="1.0.0" stub="service.impl.HelloServiceStub"> <dubbo:method name="sayHello" retries="3"/> <dubbo:method name="sayNo" retries="0"/> </dubbo:reference>
负载均衡策略
负载均衡（Load Balance）, 其实就是将请求分摊到多个操作单元上进行执行，从而共同完成工作任务。
简单的说，好多台服务器，不能总是让一台服务器干活，应该“雨露均沾”
dubbo一共提供4种策略，缺省为 random 随机分配调用
修改提供者配置并启动3个提供者，让消费者对其进行访问
tomcat端口8001，8002，8003
provider端口20881，20882，20883
<dubbo:provider timeout="2000" retries="3" port="20881"/>
HelloServiceImpl01类，服务器1，服务器2，服务器3
public String sayNo() { System.out.println("----服务器1---1.0被调用一次-------"); return "no!"; }
消费者配置负载均衡策略：
<dubbo:reference loadbalance="roundrobin" interface="service.HelloService" id="helloService" version="2.0.0" stub="stub.HelloServiceStub"> <dubbo:method name="sayHello" retries="3"/> <dubbo:method name="sayNo" retries="0"/> </dubbo:reference>
最好使用管理端修改权重
高可用
zookeeper宕机
zookeeper注册中心宕机，还可以消费dubbo暴露的服务
- 监控中心宕掉不影响使用，只是丢失部分采样数据
- 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
- 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
- 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
- 服务提供者无状态，任意一台宕掉后，不影响使用
- 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
测试：
- 正常发出请求
- 关闭zookeeper：./zkServer.sh stop
- 消费者仍然可以正常消费
服务降级
壁虎遇到危险会自动脱落尾巴，目的是损失不重要的东西，保住重要的
服务降级，就是根据实际的情况和流量，对一些服务有策略的停止或换种简单的方式处理，从而释放服务器的资源来保证核心业务的正常运行
为什么要服务降级
而为什么要使用服务降级，这是防止分布式服务发生雪崩效应
什么是雪崩？就是蝴蝶效应，当一个请求发生超时，一直等待着服务响应，那么在高并发情况下，很多请求都是因为这样一直等着响应，直到服务资源耗尽产生宕机，而宕机之后会导致分布式其他服务调用该宕机的服务也会出现资源耗尽宕机，这样下去将导致整个分布式服务都瘫痪，这就是雪崩。
服务降级实现方式
在 管理控制台配置服务降级：屏蔽和容错
屏蔽：mock=force:return+null 表示消费方对该服务的方法调用都 直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
容错：mock=fail:return+null 表示消费方对该服务的方法调用在 失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
