xiaozhigang

各级缓存

spring中有三级缓存：一级二级三级。三个都是存储bean相关的内容，但是具体存储的内容有所差异。

一级缓存：就绪状态的bean，保存在该缓存中的Bean所实现Aware子接口的方法已经回调完毕，自定义初始化方法已经执行完毕，也经过BeanPostProcessor实现类的postProcessorBeforeInitialization、postProcessorAfterInitialization方法处理。

二级缓存：早期曝光的bean，一般只有处于循环引用状态的bean才会被保存在该缓存中，所实现的Aware子接口方法还未回调，自定义初始化方法还未执行。

三级缓存：存放获取bean的工厂类-ObjectFactory实例，在IoC容器中，所有刚被创建出来的bean，默认都会保存到该缓存中。

解决循环依赖问题

什么是循环依赖：

1
2
3
4
5
6
7
8
9
10
11

@Service
public class CircularServiceA {
    @Autowired
    private CircularServiceB circularServiceB;

}
@Service
public class CircularServiceB {
    @Autowired
    private CircularServiceA circularServiceA;
}

简介

现在大模型大行其道，我们普通人没有那么多资源，有没有办法搭建一个大模型玩一下呢，答案肯定是有的，我们可以搭建一个知识库，用一下大模型。

总所周知，大模型的训练是需要大量资源的，我们没有这么多资源，那我们就得想办法绕过训练或者减少训练。这时候知识库就是一个比较好的选择，它不需要对大模型进行大量的训练，大模型只是帮我们生成一个类人话的答案。

架构

目前比较用的比较多的就是LangChain框架，这是一种基于Langchain 与 ChatGLM 等大语言模型的本地知识库问答应用实现。

可以从上面的原理图看出知识库的整个实现原理。

1、先加载文件，文件可以是结构化的也可以是非结构化的

2、读取文本，这就很好理解了，将加载进来的文件读取

3、分割文本，将读取的文本分割成一段一段的，便于提取其中的关键字和让内容更内敛

简介

配置中心可以兼顾配置实时性、配置的流程管理、以及分布式场景的应用。

配置实时性：传统的静态配置方式想要修改某个配置，则需要修改后重启，如果想要实现动态修改，可以使用数据库，采用轮询的方式，访问数据库获得配置数据。轮询频率低的话对配置数据变更的感知就慢，频率高的话，就会消耗过多的性能。

配置管理流程：权限管理、灰度管理、版本管理、格式检验和安全配置

分布式场景：随着采用分布式开发模式，项目之间的相互引用不断增多，相互之间的调用复杂度也指数上升，需要配置中心治理。

功能

灰度发布：当配置修改影响较大时，需要先在部分实例中生效，验证配置变更符合预期之后再推送到所有实例。

权限管理：对配置变更的权限管控，以及对审计权限的管控

版本管理&回滚：当配置变更不符合预期时，需要根据配置发布版本回滚

配置格式校验：配置数据一般会以一种配置格式存储，配置中心会对配置数据的格式进行校验，防止格式错误导致的各种问题

简述

之前面试问到了工作中用到的注册中心和市面上的有啥异同。

公司用的注册中心：Zookeeper

市面上除此之外还有其他注册中心：Eureka、Consul、Nacos

Zookeeper

遵循CP原则（一致性，分区容错性），牺牲了高可用。所以任何时候请求都能得到一致的数据结果，但是不能保证每次服务请求都是可达的。比如请求的时候leader节点宕机，或者集群中半数以上节点不可用，那么将无法处理请求。

Eureka

遵循AP原则（可用性，分区容错性），牺牲了数据一致性。也就是能保证每次服务请求都是可达的，但是不能保证每次的请求结果都是一致的。Eureka集群没有主从之分，采用的是Peer to Peer对等通信，这是一种去中心化的架构，每个节点都需要添加一个或多个有效的serviceUrl指向其他节点，每个节点都是其他节点的副本。集群中只要还有一个节点存活，那么服务就是可用的，但是不饿能保证查到的数据是最新的或者一致的。

除此之外还有一种保护机制，如果在15分钟内超过85%的节点都没有正常心跳，Eureka则认为客户端与注册中心之间出现了网络故障，此时会出现以下几种情况：

简述

今天面试了两个，一个下午，一个晚上，下午面试没有聊的很深，貌似很着急招人的样子，晚上聊了很久，更类似于聊天探讨形式。

面试问题

有些问题记不上来了，将记忆清楚和答的不好的记录复盘。

问题1

问：

我们使用的注册中心、配置中心和市面使用的spring或者nacos的异同。

复盘：

公司使用的是zookeeper，市面常见的主要有4种Eureka、Zookeeper、Consul、Nacos。

具体的对比差异没有答好，简述了注册中心AP，CP的差异。

简述

这次面试场面有点大，6个面试官，但只有3个面试官提问了。前两个面试官回答的还行，后一个面试官直接问懵了。

自我介绍

19年毕业，4年多工作经验，华为这边工作。

目前团队业务是以洞察、评估、规划和收益四个部分向运营商提供数字化机会点发现。

项目是以全球数据沙盘项目为基础，业务向外扩展OTN to 楼宇，OTN综合承载等项目。

自己近项目组以来，从构建测试网络开始了解全球数据沙盘项目，到路网算法开始参与项目，然后开始OTN to 楼宇参与业务拓展，到最后的模型收编和原子能力编排重构项目。

回溯

可以说一下自己参与开源项目dubbo，个人学习构建商城项目的框架代码，以及个人博客文章的分享。

也可以说一下自己在团队内的定位。

现在chatgpt这么火，我们也可以通过人工智能为我们的工作提供便利。

可行性

1、代码开源，不需要冲头开发，基本拿来可用。

2、单业务领域小数据量训练的可行性，单个公司一般聚焦于一个领域业务，多领域公司可以下分到各部门。单业务领域的训练数据就会小很多，基本可以内部清洗提供。

安全性

1、内部服务器部署，机器人服务部署于内部服务器，保证数据安全性。

交互性

1、通过开放接口和外部交互，如钉钉，微信。降低交互成本，提升交互沟通效率。

优越性

下面谈一谈我对chatGPT的简单认知，这也是看了许多资料总结出来的，没有去实际去研究chatGPT的代码，我姑且言之，有兴趣的同学姑且听之。

去年chatGPT大火，才让我们对人工智能有了更深一步的了解。之前认为的智能聊天就是像那些客服机器人一样，反反复复就那么几句话，跟智障一样，现在看到chatGPT这么厉害，宛若神明。

归根到底的数学概率

​ 其实大家可以简单理解，chatGPT的语言生成是一个数学概率模型，他的一个词语到生成下一个词语是采用概率最大的词语生成，就比如说，你输入一堆数据提供chatGPT训练，其中词语A后面接词语B的次数最多也就是概率最大，那么下次chatGPT给你生成回复的时候词语A后面接词语B的概率也最大。当然这也是简单说，实际肯定没这么简单。如下图，伟大的国家 这个概率是99%，拎一个选项是1%。那自然会生成 中国是个伟大的国家 。

语言模型的两个方向

​ 其实在语言模型这块一直有两个方向，一个是语义理解，一个是语句生成。语义理解是谷歌主要研究的方向，这个类似于完形填空。而语句生成是0penAI的主要方向，也就是我们现在看到的chatGPT，这个类似于写作文。这两种的应用环境和使用的算法也是不一样的，简单的说一下，语义理解，是根据前后文，两个维度计算出中间的缺失，谷歌已经做到了很高的准确率，这就对我们英语考试中的完形填空很友好了。而语句生成就跟我们写作文一样，从头写到尾，只有一个维度支撑。这就是谷歌Bert和openAI的ChatGPT的差别，双向和自回归。

数学+技术

​ Bert和ChatGPT都是基于Transformer实现的，啥是Transformer呢，简单理解就是我们上面说的根据概率最大生成文字。只不过这生成的实现很复杂，大概说-下，我们输入的句子会被拆分成一个一个的单词(token),根据这些单词计算向量权重，最后根据这些解析拆分后的向量权重计算概率生成输出。这些向量是怎么计算的呢，我们看个例子，国王-男人+女人=女王，这种向量的计算是不是很有意思。

简述

在kafka的使用过程中，消息传递有下图三个步骤，消息的丢失也就在这三个步骤中：发送过程中丢失、同步过程中丢失、拉取过程中丢失。

发送过程中丢失

发送方式

生产者的发送方式有三种：

1、简单发送，不关心发送结果，所以发送失败消息丢失也不知道。

1
2
3
4
5
6
7
8

ProducerRecord<String,String> record = new ProducerRecord<>("topicName","key","value");
try{
   //这里只是把消息放进了一个缓冲区中，然后使用单独的线程将消息发送到服务端
   producer.send(record);
}
catch(Exception){
   e.printStackTrace();
}

2、同步发送，等待发送返回

1
2
3
4
5
6
7
8
9

ProducerRecord<String,String> record = new ProducerRecord<>("topicName","key","value");
try{
   //send方法返回的是Future<RecordMetaData> 对象，然后我们可以调用get()方法等待响应
   Future<RecordMetaData> future = producer.send(record); 
   future.get();
}
catch(Exception){
   e.printStackTrace();
}