Dubbo+zookeper知识点

zmw1502

已于 2022-08-14 09:04:11 修改

阅读量180

点赞数

文章标签： dubbo java 微服务

于 2022-08-13 20:36:35 首次发布

本文链接：https://blog.csdn.net/zmw1502/article/details/126324052

版权

Dubbo+zookeper知识点
1、集群和分布式
集群：很多“人”一起，干一样的事。
分布式：很多“人”一起，干不一样的事。这些不一样的事，合起来是一件大事。
2、架构演进

3、架构演进–单体架构
优点：
简单：开发部署都很方便，小型项目首选
缺点：
项目启动慢
可靠性差
可伸缩性差
扩展性和可维护性差
性能低
4、架构演进–垂直架构
垂直架构是指将单体架构中的多个模块拆分为多个独立的项目。形成多个独立的单体架构。
单体架构存在的问题：
项目启动慢
可靠性差
可伸缩性差
扩展性和可维护性差
性能低

垂直架构存在的问题：
重复功能太多
5、架构演进–分布式架构
分布式架构是指在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务，供其他调用者消费，以实现服务的共享和重用。
RPC： Remote Procedure Call 远程过程调用。有非常多的协议和技术来都实现了RPC的过程。比如：HTTP REST风格，Java RMI规范、WebService SOAP协议、Hession等等。
垂直架构存在的问题：
重复功能太多

分布式架构存在的问题：
服务提供方一旦产生变更，所有消费方都需要变更。
6、架构演进–SOA架构
SOA：（Service-Oriented Architecture，面向服务的架构）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。
ESB：(Enterparise Servce Bus) 企业服务总线，服务中介。主要是提供了一个服务于服务之间的交互。ESB 包含的功能如：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。
分布式架构存在的问题：
服务提供方一旦产生变更，所有消费方都需要变更
7、架构演进–微服务架构
微服务架构是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
特点：
服务实现组件化：开发者可以自由选择开发技术。也不需要协调其他团队
服务之间交互一般使用REST API
去中心化：每个微服务有自己私有的数据库持久化业务数据
自动化部署：把应用拆分成为一个一个独立的单个服务，方便自动化部署、测试、运维
8、Dubbo概念
Dubbo是阿里巴巴公司开源的一个高性能、轻量级的 Java RPC 框架。
致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。
官网：http://dubbo.apache.org
9、节点角色说明：
Provider：暴露服务的服务提供方
Container：服务运行容器
Consumer：调用远程服务的服务消费方
Registry：服务注册与发现的注册中心
Monitor：统计服务的调用次数和调用时间的监控中心
Dubbo官方推荐使用Zookeeper作为注册中心
10、Dubbo快速入门
实现步骤：
创建服务提供者Provider模块
创建服务消费者Consumer模块
在服务提供者模块编写 UserServiceImpl 提供服务
在服务消费者中的 UserController 远程调用UserServiceImpl 提供的服务
分别启动两个服务，测试
11、序列化
dubbo 内部已经将序列化和反序列化的过程内部封装了
我们只需要在定义pojo类时实现Serializable接口即可
一般会定义一个公共的pojo模块，让生产者和消费者都依赖该模块。
12、地址缓存
注册中心挂了，服务是否可以正常访问？
可以，因为dubbo服务消费者在第一次调用时，会将服务提供方地址缓存到本地，以后在调用则不会访问注册中心。
当服务提供者地址发生变化时，注册中心会通知服务消费者。
13、超时与重试
服务消费者在调用服务提供者的时候发生了阻塞、等待的情形，这个时候，服务消费者会一直等待下去。
在某个峰值时刻，大量的请求都在同时请求服务消费者，会造成线程的大量堆积，势必会造成雪崩。
dubbo 利用超时机制来解决这个问题，设置一个超时时间，在这个时间段内，无法完成服务访问，则自动断开连接。
使用timeout属性配置超时时间，默认值1000，单位毫秒。
设置了超时时间，在这个时间段内，无法完成服务访问，则自动断开连接。
如果出现网络抖动，则这一次请求就会失败。
Dubbo 提供重试机制来避免类似问题的发生。
通过 retries 属性来设置重试次数。默认为 2 次。
14、多版本
灰度发布：当出现新功能时，会让一部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能。
dubbo 中使用version 属性来设置和调用同一个接口的不同版本
15、负载均衡
负载均衡策略（4种）：
Random ：按权重随机，默认值。按权重设置随机概率。
RoundRobin ：按权重轮询
负载均衡策略（4种）：
LeastActive：最少活跃调用数，相同活跃数的随机。
ConsistentHash：一致性 Hash，相同参数的请求总是发到同一提供者。
16、集群容错
集群容错模式：
Failover Cluster：失败重试。默认值。当出现失败，重试其它服务器，默认重试2次，使用 retries 配置。一般用于读操作
Failfast Cluster ：快速失败，只发起一次调用，失败立即报错。通常用于写操作。
Failsafe Cluster ：失败安全，出现异常时，直接忽略。返回一个空结果。
Failback Cluster ：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster ：并行调用多个服务器，只要一个成功即返回。
Broadcast Cluster ：广播调用所有提供者，逐个调用，任意一台报错则报错。
17、大型互联网项目架构目标
衡量网站的性能指标：
响应时间：指执行一个请求从开始到最后收到响应数据所花费的总体时间。
并发数：指系统同时能处理的请求数量。
并发连接数：指的是客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器连接的总TCP数量
请求数：也称为QPS(Query Per Second) 指每秒多少请求.
并发用户数：单位时间内有多少用户
吞吐量：指单位时间内系统能处理的请求数量。
QPS：Query Per Second 每秒查询数。
TPS：Transactions Per Second 每秒事务数。
一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
一个页面的一次访问，只会形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，就会有多个QPS
高性能：提供快速的访问体验。
高可用：网站服务一直可以正常访问。
可伸缩：通过硬件增加/减少，提高/降低处理能力。
高可扩展：系统间耦合低，方便的通过新增/移除方式，增加/减少新的功能/模块。
安全性：提供网站安全访问和数据加密，安全存储等策略。
敏捷性：随需应变，快速响应。
18、Zookeeper 概念
Zookeeper 是 Apache Hadoop 项目下的一个子项目，是一个树形目录服务。
Zookeeper 翻译过来就是动物园管理员，他是用来管 Hadoop（大象）、Hive(蜜蜂)、Pig(小猪)的管理员。简称zk
Zookeeper 是一个分布式的、开源的分布式应用程序的协调服务。
Zookeeper 提供的主要功能包括：
配置管理
分布式锁
集群管理

19、Zookeeper 数据模型
ZooKeeper 是一个树形目录服务,其数据模型和Unix的文件系统目录树很类似，拥有一个层次化结构。
这里面的每一个节点都被称为： ZNode，每个节点上都会保存自己的数据和节点信息。
节点可以拥有子节点，同时也允许少量（1MB）数据存储在该节点之下。
节点可以分为四大类：
PERSISTENT 持久化节点
EPHEMERAL 临时节点：-e
PERSISTENT_SEQUENTIAL 持久化顺序节点：-s
EPHEMERAL_SEQUENTIAL 临时顺序节点：-es
20、Zookeeper 服务端常用命令
启动 ZooKeeper 服务: ./zkServer.sh start
查看 ZooKeeper 服务状态: ./zkServer.sh status
停止 ZooKeeper 服务: ./zkServer.sh stop
重启 ZooKeeper 服务: ./zkServer.sh restart
21、Zookeeper 客户端常用命令
连接ZooKeeper服务端：
./zkCli.sh –server ip:port
断开连接：
quit

查看命令帮助
Help
设置节点值：
set /节点path value
删除单个节点
delete /节点path
创建节点：
create /节点path value

czxid：节点被创建的事务ID
ctime: 创建时间
mzxid: 最后一次被更新的事务ID
mtime: 修改时间
pzxid：子节点列表最后一次被更新的事务ID
cversion：子节点的版本号
dataversion：数据版本号
aclversion：权限版本号
ephemeralOwner：用于临时节点，代表临时节点的事务ID，如果为持久节点则为0
dataLength：节点存储的数据的长度
numChildren：当前节点的子节点个数
22、Curator 介绍
Curator 是 Apache ZooKeeper 的Java客户端库。
常见的ZooKeeper Java API ：
原生Java API
ZkClient
Curator
Curator 项目的目标是简化 ZooKeeper 客户端的使用。
Curator 最初是 Netfix 研发的,后来捐献了 Apache 基金会,目前是 Apache 的顶级项目。
官网：http://curator.apache.org/
23、Curator API 常用操作 - Watch事件监听
ZooKeeper 允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是 ZooKeeper 实现分布式协调服务的重要特性。
ZooKeeper 中引入了Watcher机制来实现了发布/订阅功能能，能够让多个订阅者同时监听某一个对象，当一个对象自身状态变化时，会通知所有订阅者。
ZooKeeper 原生支持通过注册Watcher来进行事件监听，但是其使用并不是特别方便
需要开发人员自己反复注册Watcher，比较繁琐。
Curator引入了 Cache 来实现对 ZooKeeper 服务端事件的监听。
ZooKeeper提供了三种Watcher：
NodeCache : 只是监听某一个特定的节点
PathChildrenCache : 监控一个ZNode的子节点.
TreeCache : 可以监控整个树上的所有节点，类似于PathChildrenCache和NodeCache的组合
24、锁分布式
在我们进行单机应用开发，涉及并发同步的时候，我们往往采用synchronized或者Lock的方式来解决多线程间的代码同步问题，这时多线程的运行都是在同一个JVM之下，没有任何问题。
但当我们的应用是分布式集群工作的情况下，属于多JVM下的工作环境，跨JVM之间已经无法通过多线程的锁解决同步问题。
那么就需要一种更加高级的锁机制，来处理种跨机器的进程之间的数据同步问题——这就是分布式锁。
25、ZooKeeper分布式锁原理
核心思想：当客户端要获取锁，则创建节点，使用完锁，则删除该节点。
客户端获取锁时，在lock节点下创建临时顺序节点。
然后获取lock下面的所有子节点，客户端获取到所有的子节点之后，如果发现自己创建的子节点序号最小，那么就认为该客户端获取到了锁。使用完锁后，将该节点删除。
如果发现自己创建的节点并非lock所有子节点中最小的，说明自己还没有获取到锁，此时客户端需要找到比自己小的那个节点，同时对其注册事件监听器，监听删除事件。
如果发现比自己小的那个节点被删除，则客户端的
Watcher会收到相应通知，此时再次判断自己创建的节点
是否是lock子节点中序号最小的，如果是则获取到了锁，
如果不是则重复以上步骤继续获取到比自己小的一个节点
并注册监听。
26、Curator实现分布式锁API
在Curator中有五种锁方案：
InterProcessSemaphoreMutex：分布式排它锁（非可重入锁）
InterProcessMutex：分布式可重入排它锁
InterProcessReadWriteLock：分布式读写锁
InterProcessMultiLock：将多个锁作为单个实体管理的容器
InterProcessSemaphoreV2：共享信号量
27、Zookeeper 集群介绍
Leader选举：
Serverid：服务器ID
比如有三台服务器，编号分别是1,2,3。
编号越大在选择算法中的权重越大。
Zxid：数据ID
服务器中存放的最大数据ID.值越大说明数据越新，在选举算法中数据越新权重越大。
在Leader选举的过程中，如果某台ZooKeeper
获得了超过半数的选票，
则此ZooKeeper就可以成为Leader了。
27、Zookeeper 集群角色
在ZooKeeper集群服中务中有三个角色：
Leader 领导者：