java 知识点突击-(171-180)

Posted 2022-02-04 栗子~~

文章目录

• 前言
• • java 知识点扫盲目录
  • java 知识点突击-(171-180)
  • • 171 简述ZAB协议
    • 172 ZAB协议原理?
    • • 172::01 消息广播:
      • 172::02 崩溃恢复:
    • 173 zk的数据模型和节点类型?
    • 174 zk的功能特性是什么?
    • 175 zk一般用来干什么?
    • 176 讲述下zk watch 机制
    • 177 zk和eureka的区别
    • 178 springCloud和Dubbo的区别?
    • 179 简述一下hystrix?
    • 180 springCloud 核心组件与作用?
• 创作不易、点关注、不迷路
• 点击主页、更精彩 !!!

前言

  如果您觉得有用的话，记得给博主点个赞，评论，收藏一键三连啊，写作不易啊^ _ ^。
  而且听说点赞的人每天的运气都不会太差，实在白嫖的话，那欢迎常来啊!!!

---

java 知识点扫盲目录

https://blog.csdn.net/weixin_38316697/article/details/121991582

java 知识点突击-(171-180)

171 简述ZAB协议

zk的基础。
即分布式协调协议，为zookeeper专用，支持崩溃恢复的原子广播协议，用来实现分布式数据的一致性。

主节点来写，从节点来读，即如果从节点来一个写操作时，会通过路由给主节点来进行写操作，而主节点和从节点的数据是通过zab协议来保证一致。

---

172 ZAB协议原理?

172::01 消息广播:

1、所有写操作由主节点来处理，主节点处理时将客户端发来的写操作事务，
封装一个事务广播给其他从节点(广播事务操作)；
2、当从节点收到请求时，反馈给主节点；
3、当主节点接受到的反馈过半时，即反馈的节点数>=从节点/2 + 1，主节点广播事务提交操作；

172::02 崩溃恢复:

1)崩溃场景:

• 初始化集群、刚启动
• 主节点崩溃
• 从节点大半断联

2)恢复:
开启新的一轮主节点选举，当与过半从节点达成一致时，退出崩溃恢复模式、进行消息广播模型。

注:当崩溃恢复阶段、无法进行写操作，所以我们说zk它放弃高可用、保证强一致性。

---

173 zk的数据模型和节点类型?

数据模型:树形结构
ZooKeeper将所有数据存储在内存中，最终构成的数据结构可以看成一棵树(ZNode Tree),由斜杠进行分割，分割之后每个节点即为路径，每个路径对应的即为一个ZNode，例:ZNode1/Znode1，每个节点都会保存自己的数据内容及一系列属性信息，并每个节点的存放数据上限为 1M。

Znode特点:
1)Znode兼文件和目录两种特性；
2)Znode具有原子性，读操作时将获取与节点相关的所有操作，写操作时替换掉节点的所有数据；
3)Znode存储数据有限制，1M；
4)Znode通过路径引用，路径必须是绝对的，因为他们必须由斜杠字符来开头；

节点类型:
【持久化节点】:即一旦这种ZNode被创建，除非主动移除，否则它将一直保存在ZooKeeper上；
【顺序自动编号持久化节点】:在【持久化节点】这种节点会根据当前已存 在的节点数自动加 1；
【临时节点】:即生命周期和客户端的会话绑定在一起，客户端会话超时这类节点就会自动删除；
【临时自动编号节点】:在【临时节点】的基础上，根据当前已近存在的节点数自动加 1，然后返回给客户端已经成功创建的目录节点名；

---

174 zk的功能特性是什么?

【顺序一致性】: 从同一个客户端发起的事务请求，最终将会严格地按照顺序被应用到ZooKeeper上。
【原子性】:所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功某一个事务请求，要么就失败。
【单一系统映像】:无论客户端链接到那个ZooKeeper上，其看到的服务端数据模型都是一样的。
【可靠性】:一旦一次更改请求被应用，就会持久化，直到被下次更改所覆盖。

---

175 zk一般用来干什么?

【命名服务】:通过给ZNode进行统一命名，各个子系统便可以通过名字获取到该节点上相应的资源
【配置管理】:将每个子系统都需要配置的文件统一放在一个ZooKeeper的ZNode节点中
【分布式锁】:控制多线程对共享资源的并发访问
【集群状态】:通过动态节点的增加、删除、从而保证集群下的相关节点数据主、副本的一致性。

---

176 讲述下zk watch 机制

监听器，即客户端，可以通过在Znode上面设置watch，实现实时监听Znode的变化:
父节点的创建、修改、删除 都会触发watch事件；
子节点的创建、删除会触发watch事件；
特点:
轻量、只通知发生了事件、不会告知事件内容，减轻服务端和带宽压力。

简单来说、client 端对某个 ZNode建立一个 watcher 事件，只有当该 ZNode发生变化时，zookeeper主动通知 watch 这个 ZNode的 client端，从而让客户端做出相对应的措施 。

注:3.6.0版本前是一次性的，之后可以触发多次。

watch机制包括三个角色:客户端线程、客户端watchManager以及zk服务端。

1、客户端向zk服务端注册一个watch监听；
2、把这个监听信息存放在客户端的watchManager中；
3、当zk服务端的Znode节点触发watch事件时，通知客户端，客户端会调用相应watcher对象中的回调方法，watch回调是串行同步的；

为什么是串行同步的:
队列机制，把watch对象放入队列中，取完后删除掉。

---

177 zk和eureka的区别

C:一致性
所有节点上的数据要一致，比如:有三个节点，A节点上的数据有更新，那么B、C节点上的数据同一时间同步更新，达到所有节点上数据完全一致的目的(强一致性)。
A:可用性
服务一直可用，不能说某个节点宕机掉，导致整个服务不可用，即用户操作失败。
P:分区容错性
当某个节点网络分区故障时，仍然能对外提供一致性和可用性服务。
注:
当触发分区容错时:
即网络中断，对外提供访问时( 数据不一致，一致性是不能保证)，在恢复的这段时间内( 可用性就保证不了)。
即CP和AP:分区容错必须保证，当发生网络分区，那么强一致性和可用性只能二选一。

zk是CP设计(强一致性):
zk是主从设计，同时zk的ZAP协议保证强一制性，其中的崩溃恢复期，zk的写操作是不可用的。
eureka是AP设计(高可用):
eureka各个节点都是平等的，几个节点挂掉，不会影响正常节点的访问，如果节点通信之间断掉，查到的信息可能不是最新的( 放弃强一致性)，同时eureka发现85%的节点都没有心跳时，eureka会认为自己的网络出现问题，就不会删除失去心跳的服务，同时eureka客户端也会缓存服务信息，eureka对服务注册发现来说是很好的选择。

---

178 springCloud和Dubbo的区别?

底层协议:
springCloud基于http协议；
Dubbo基于Tcp协议；

注册中心:
springCloud基于eureka为注册中心；
dubbo基于zk为注册中心；

模型定义:
springCloud以服务为颗粒度
dubbo以接口为颗粒度

springCloud是一个生态，Dubbo是SpringCloud中的服务治理这个场景下的方案。

---

179 简述一下hystrix?

分布式容错框架:

• 阻止故障的连锁反应，实现熔断

• 快速失败、实现优雅降级

• 提供实时的监控和报警

特性:
1)资源隔离:

• 线程隔离
  Hystrix会给每一个Command分配一个线程池，这样进行单个服务调用的时候，就可以在独立的线程池中进行， 而不会对其他线程造成影响。
• 信号量隔离:
  客户端向依赖服务发起请求时，首先获取一个信号量才能真正发起调用，由于信号量的数量有限，当并发量超过信号量个数时，后续都会拒绝，进入fallback流程，目的是控制并发请求量，防止请求线程大面积阻塞，从而达到限流和防止雪崩的目的。

2)熔断和降级:
熔断:防止异常不扩散，保证系统可用性；
降级:编写调用失败的补写逻辑。

---

180 springCloud 核心组件与作用?

eureka: 服务治理(服务的注册和发现)；
Ribbo:负载均衡
feign:封装调用细节的，基于动态代理机制，达到调用远程和调用本地一样。
hystrix:熔断机制(断路器)
zuul:网关

---

创作不易、点关注、不迷路

点击主页、更精彩 !!!