简述

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

公司用的注册中心：Zookeeper

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

Zookeeper

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

Eureka

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

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

1
2
3
4
5

1、Eureka不再从注册表中移除因长时间没有收到心跳而过期的服务

2、Eureka仍然能够接受新服务注册和查询请求，但不会同步到其他节点上，只保证当前节点可用

3、当网络稳定时，当前实例新注册的信息会被同步到其他节点

Consul

遵循CP原则，Hashicorp公司开发，用于实现分布式系统的服务发现与配置。使用的时Raft算法，比zookeeper使用的Paxos算法更简单，虽然保证了强一致性，但是可用性方面性能有所下降，比如在服务注册方面，Raft协议要求半数以上的节点都写入才算注册成功，leader节点宕机之后，在重新选取出leader节点之前都会导致不可用。

Nacos

遵循AP原则，也可支持CP原则，阿里开源，nacos = 注册中心 + 配置中心，总之很强大，推荐。

总结

简述

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

面试问题

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

问题1

问：

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

复盘：

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

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

在配置中心上，目前常用的有springcloud config、nacos、apollo

具体的差异也没答上。

后续整理归纳一篇文章。

问题2

问：自定义经典线程池拒绝策略

复盘：

相当于知识盲区了，没有答上，只知道有4种拒绝策略：

1
2
3
4
5
6
7

1、AbortPolicy：默认拒绝策略，抛出RejectExecutionException异常

2、CallerRunsPolicy：不抛异常，而是让提交任务的线程自己去执行这个任务

3、DiscardOldestPolicy：策略会丢失队列中最老的以恶搞任务，然后重新尝试新提交被拒绝的任务

4、DiscardPolicy：抛弃被拒绝的任务，不会做任何处理也不会抛出异常。

自定义的拒绝策略没有了解过，可以写篇文章总结了解一下。

问题3

问：优化SQL方案

复盘：知道一些优化方案，但是没有条理性

需要整理一下，最好整理成一个全面的方法论

问题4

问：redis和数据库同步一致性方案

复盘：知道新跟新数据库，再更新缓存

但是全面的方法论没有将出来。

问题5

问：jdk 虚拟线程，新版jdk特性

复盘：jdk8之后都没有了解，这块短板等补齐，目前面试很少问到这个，但是得了解补齐.

问：新版jdk的垃圾回收器

复盘：同上

问题6

问：jdk调优工具

复盘：知识盲点。得补齐，可能后续面试工作中用不到，但是得了解一下。

问题7

问：如何打破双亲加载机制

复盘：知道双亲加载机制，但是如何打破倒是没有深入了解，自己也写篇文章总结一下。

总结

总体来说，每个问题都有自己知道的点，但是好多没有全面的回答。回答的都是一个个的点，没有梳理成一个面，体现自己的逻辑性，条理性和全面性

简述

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

自我介绍

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

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

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

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

回溯

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

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

可以画个思维导图，下次按思维导图介绍。

第一个面试官

MySQL索引

问：简述一下mysql的索引

答：索引类似于书的目录，加快查找数据，它的存在空间换时间。空间就不用说了，索引的存在必然消耗空间，时间的话就是提高了查找效率，减少了消耗的时间。索引分为聚簇索引和非聚簇索引，以InnoDB而言，索引以B+数的形式存储，只不过聚簇和非聚簇在存储细节上有所不同。聚簇也就是主键索引，在叶子节点上是以主键和数据一起存放的，而非聚簇索引的叶子节点存储的是普通索引和主键。在查找数据的时候，如果是主键查询责直接通过B+数找到数据，非聚簇索引的话，要通过B+树先找到主键，在通过主键查到数据，这个过程叫做回表。为了提高查找的效率，所以我们一般在查询的时候尽量使用索引，且减少回表。

回溯

点应该都答到了，感觉面试官还比较满意回答，具体的细节和描述的方法可以更提高一点，显得更有条理性。

总述：索引类似于书的目录，空间换时间，占用了磁盘空间，减少了查找时间。

分述：分聚簇索引和非聚簇索引，二者在存储上的差异（B+树叶节点的不同），在查询上的差异（回表）。以及我们在实际使用的时候需要注意的点（减少回表，最左覆盖，索引下推，等）。

追问：既然说到B+树，说一下10个节点的红黑树需要查询一个节点的时间消耗

答：时间复杂度O(ln)，红黑树的第一层是一个节点，第二层是2个节点，第三层是4个，第5层是8个。查询的话上来先比较根节点，如果比根节点大往右，否则往左…（简述了一下查询流程）…查询像二分查找，先找中间值，比大小等

回溯

应该是面试官想听到的，现场感觉面试官比较满意，但是自己不是很清楚红黑树，不清楚红黑树的非叶子节点是否保存了数据，还是和B+树一样只做比较。

增加实际业务中的的案例，走联合索引的案例，调换where中的条件顺序。

SpringMVC流程

问：说一下MVC的查询流程

答：客户端 请求到 DispatcherServlet， DispatcherServlet到HandlerMapping，然后返回结果给DispatcherServlet，DispatcherServlet在将handler转发到适配器，适配器会有一些过滤拦截啥的，通过后到处理器，也就是controller->service->map，然后结果在原路返回到DispatcherServlet，DispatcherServlet在拿到结果后回去调用视图解析器啥的，去将返回的结果解析渲染。

回溯

回答面试官比较满意，听其语义主要想听到DispatcherServlet，但是此流程中记得是在适配器中会有拦截过滤，不是特别确定，已经返回结果后的视图解析渲染，两个组件名称记得不是特别清楚。

服务间通信

问：你们有多模块多服务吗，服务间的调用是用的什么。

答：有，上面自我介绍中也说到了，我们所有业务基本可以分为：洞察，评估，规划，收益，四个模块。模块间的调用用的是http请求。

追问：请求的结果是要转换的，你们是怎么转换的。

答：我们的请求不涉及到请求结果的转换，不是那种强依赖。我们模块间的数据交互都是放在数据库的，比如洞察处理完的数据会放在数据库，然后调用评估的模块开始处理，评估模块处理的时候会调用数据库的数据处理，处理的结果会放回数据库，而不是返回给评估模块，这样更解耦。

回溯

其实对这请求调用的方式记得不是特别清楚了，需要复习回顾一下。

https://blog.csdn.net/Andy19891117/article/details/134981402

RPC调用和http调用，RPC基于传输层TCP协议，Http基于应用层http协议，所以RPC调用的传输效率更高。Http规定了返回的格式而RPC没有。

第二个面试官

jar包加载

问：简历中说的到的原子能力编排是怎么理解的，包是spring jar还是啥，编排是怎么理解。

答：jar包是fast jar，不是那种有启动类的可执行jar包，编排的话，是我们把能力抽取成一个个的jar包，再以可视化配置的方式，类似于链式调用。

追问：编排的结果，jar包的顺序执行，这个是以什么数据结构存储的。

答：存在数据库中，是以字符串的形式存储的，在读取到数据库中字符串，在以特定的字符将字符串分割开，然后遍历执行。

追问：前端是怎么配置调用后端的jar的

答：我们是按迭代内的业务需求配置上线的，前台只是提供一个可视化的界面供开发配置，其实我们更习惯直接在配置文件xml中配置，配置完的xml文件会提交到代码仓，在我们的部署阶段，会将这配置文件解析成字符串保存在数据库中，供读取。

追问：这个项目里的调度和引擎服务怎么理解。

答：这个网关，调度，引擎内容都比较简单，网关的话直接对外，调度只负责调用原子能力jar，引擎是加载运行jar。这么分是为了职责更单一内敛。

追问：jar包是怎么加载的。

答：读取到lib目录下的依赖，先将依赖通过双亲依赖加载给加载进来，然后在通过同一规范的jar包入口，开始调用jar内的方法。

追问：双亲加载有三个加载器，加载器是啥。

答：记得不是特别清了，只记得一个是系统加载，两个是加载外部文件依赖加载。

回溯

面试感觉一般，虽然大部分都答到了，但是还有结果点不熟。

1、jar包的分类不熟

fat jar

2、jar包的加载，了解大概流程，不了解其具体细节。

3、三个父加载器忘了，没想起来名字。

4、怎么卸载jar包

启动类加载器（Bootstrap Class Loader）：也称为根类加载器，它负责加载Java虚拟机的核心类库，如java.lang.Object等。启动类加载器是虚拟机实现的一部分，它通常是由本地代码实现的，不是Java类。

扩展类加载器（Extension Class Loader）：它是用来加载Java扩展类库的类加载器。扩展类库包括javax和java.util等包，它们位于jre/lib/ext目录下。

应用程序类加载器（Application Class Loader）：也称为系统类加载器，它负责加载应用程序的类。它会搜索应用程序的类路径（包括用户定义的类路径和系统类路径），并加载类文件。

注解加载

问：注解是怎么加载的

答：看过源码，记得不是特别清了，spring启动类上会有enable开启注解加载，后面通过一层层的调用，大概3~4层，读取到lib目录下的文件，然后再通过条件判断是否加载。

回溯

回答一般，之前确实看过，现在确实忘了

自动配置原理：SpringBoot 项目的核心注解 @SpringBootApplication，这个注解位于启动类上方。@SpringBootApplication 看作是 @Configuration、@EnableAutoConfiguration、@ComponentScan 注解的集合。自动装配核心功能的实现是通过@EnableAutoConfiguration内部的AutoConfigurationImportSelector类。AutoConfigurationImportSelector 类实现了 ImportSelector 接口，也就实现了这个接口中的 selectImports 方法，该方法主要用于获取所有符合条件的类的全限定类名，需要为这些类创建对象并加载到 IoC 容器中。@ConditionOnXXX 中的所有条件都满足，该类才会生效

​ @EnableAutoConfiguration：启用 SpringBoot 的自动配置机制。

​ @Configuration：允许在上下文中注册额外的 bean 或导入其他配置类，作用与 applicationContext.xml 的功能相同。

​ @ComponentScan： 扫描包下的类中添加了@Component (@Service，@Controller，@Repostory，@RestController)注解的类 ，并添加的到spring的容器中，可以自定义不扫描某些 bean。

getAutoConfigurationEntry：

第 1 步：判断自动装配开关是否打开。默认 spring.boot.enableautoconfiguration = true，可在 application.properties 或 application.yml 中设置

第 2 步：用于获取 EnableAutoConfiguration 注解中的 exclude 和 excludeName。

第 3 步：从 META-INF/spring.factories 读取需要自动装配的所有配置类。

第 4 步：这一步有经历了一遍筛选过滤，@ConditionOnXXX 中的所有条件都满足，该类才会生效

https://blog.csdn.net/m0_59749089/article/details/131280769

第三个面试官

bean加载

问：如果我想再bean初始化时候改变其变量值，或者说再方法前打印一个日志。

答：使用代理，再调用方法前后打印日志。

追问：不是代理，是在初始化的时候。

答：在xml文件中，配置修改，在bean初始化的时候给其赋值。

回溯

貌似这也不是面试官想要的，确实不知道是啥，得查资料研究看看。

bean的加载过程：

加载bean信息–>实例化bean–>属性填充–>初始化阶段–>后置处理

https://blog.csdn.net/m0_46897923/article/details/129850717

容器化

问：你们容器化用的怎么样。

答：我们部门目前才开始推，我们还没有开始使用容器化，但是自己也搭环境简单使用过容器化，比如部署一个redis、mysql等。

回溯

熟悉了解一下容器化，这方面得了解确实不够，只是简单得使用了一下。

多线程

问：核心线程数10，最大线程数20，现有1w个并发，为什么线程数一直是10，不是队列里有1w。

答：不知，尝试分析，是不是资源不够，没办法新增。

回溯

确实不知，等了解。

问：synchronized的用法

答：修饰代码块或者方法，注意synchronized()中括号内的内容，可以是变量，对象和class类，对应锁的颗粒不一样。

追问：对象和class类有什么不一样。

答：对象是可以重复new的，但是class类只有一个，跟静态变量一样，用的时候要注意，别用错导致没锁好。

追问：线程的睡眠和唤醒是怎么样的。

答：A、B两个线程，A运行到某个地方，停住了睡眠了，B开始运行，运行到某个地方，通过A的方法唤醒A。

回溯

1、感觉追问的对象和类有什么不一样，没回答到他想要的，复习一下。

2、睡眠唤醒的模型有点忘了，再代码实操一下。

kafka

问：kafka里的消费者组是什么。

答：消费者的集合，一堆消费者组成的一个集合。

问：topic里的分区能被消费者组内的多个消费者消费吗

答：不能，一个分区只能被消费者组内一个消费者消费。

问：怎么保证生产者生产的消息，顺序消费。

答：都放在一个分区内，kafka不保证topic内的消息是顺序的，但是保证分区内的数据是顺序消费的。

问：消息是怎么划分分区的。

答：根据key的计算，具体的计算方法不知道。

问：如果key为null会怎么样。

答：不知

回溯

1、消费者组的概念

2、分区和消费者组、消费者的消费关系模型

3、分区的指定逻辑。

4、key为null会怎样。

随机选取一个分区缓存发送，过了分区的缓存时间后在随机选取一个分区缓存发送。

https://blog.csdn.net/yizhiniu_xuyw/article/details/109206709

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

可行性

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

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

安全性

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

交互性

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

优越性

1、人工智能的参与，提升员工工作效率，通过员工和人工智能沟通可以提升员工的工作效率，比如程序员可以问个代码怎么写啊类似的，不做缀叙。

2、部署在内部服务器的化，还可以通过其和内部任务交互，比如日常的一些小任务，可以程序化之后，部署服务器，暴露接口和人工智能交互，我们通过聊天软件通知智能机器人，让他去触发这些任务。

3、降低工作量的重复，不知道大家有没有遇到过这样的情况，有时候，想请同事帮忙处理一下什么问题或这任务，同事由于有之前处理的经验或者记录，一两分钟可能就处理好了，而自己从头开始处理的话可能需要一两个小时。如果我们把这种任务程序化之后，交由机器人触发，我们需要的时候只需要以聊天的形式，通知机器人触发任务，那得多爽，这样就可以提高工作效率。

4、提升人工智能的准确性，从而提高员工的效率，员工在和人工智能交互的过程也是一种训练，而且还是一种监督训练，可以提供人工智能的回答准确性，从而可以提高下次和人交互的准确性。

机会点

当此人工智能在单个领域训练的准确性很高的，可以考虑将此接口暴露出去，商业化，从而盈利。

​ 在java中，我们主要用到的锁有两个：synchronized、ReentrantLock。一个是内置锁（语言级），一个是显示锁，一般如果我们不思考只图方便的化，会直接使用synchronized锁。其实ReentrantLock更灵活多变，适用跟多的场景。我们可以通过下面的表对比一下两者。

​ 其实在上述这些维度方面都没啥好说的，这些一般都知道。都知道synchronized是关键字而ReentrantLock是一个类，然后两者都能加锁，这锁怎么去加，有什么效果，都是知道的。

​ 那synchronized和ReentrantLock又分别是怎么加锁的呢？

#### synchronized

加锁原理（底层）

• Java 对象头中包含了 Mark Word，在没有加锁时存储哈希值、GC信息等。
• 当线程进入 synchronized 块时，会尝试修改对象头的 Mark Word，以标识当前线程持有锁。
• JVM 使用了多种锁优化策略（偏向锁、轻量级锁、重量级锁）：
  • 偏向锁：如果只有一个线程访问，尽量不加锁，提高性能。
  • 轻量级锁：使用 CAS 尝试获取锁，适用于低竞争。
  • 重量级锁（互斥锁）：竞争激烈时，会挂起线程，使用 Monitor 来实现，依赖操作系统的互斥机制。

加锁过程简要流程图（逻辑）

1
2
3
4
5
6
7

线程进入synchronized：
    |
    |-- 检查对象头Mark Word（是否偏向、锁状态）
        |
        |-- 如果空闲，则尝试通过CAS加锁（轻量级）
        |
        |-- 如果失败，有竞争，则升级为重量级锁（挂起线程）

字节码层面

编译后使用 javap -v Test.class 查看，会看到如下结构：

1
2
3
4
5
6
7
8
9

java


CopyEdit
public void syncBlock() {
    synchronized (this) {
        System.out.println("Hello");
    }
}

反编译字节码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

asm


CopyEdit
0: aload_0
1: dup
2: monitorenter       // 进入同步块
3: getstatic java/lang/System.out : Ljava/io/PrintStream;
6: ldc "Hello"
8: invokevirtual java/io/PrintStream.println(Ljava/lang/String;)V
11: monitorexit       // 退出同步块
12: goto 20
15: astore_1
16: monitorexit       // 异常时也要退出同步块
17: aload_1
18: athrow

monitorenter 和 monitorexit 是 JVM 指令，由 JVM 解释器直接处理，底层是调用 native 方法去操作对象的 Monitor。

JVM实现细节

HotSpot 中，对象的 Monitor 实际上是 ObjectMonitor：

1
2
3
4
5
6
7

class ObjectMonitor {
  ...
  ObjectWaiter * _EntryList;   // 等待锁的线程队列
  Thread * _Owner;             // 当前持有锁的线程
  int _recursions;             // 重入次数
  ...
};

Monitor 与每个对象的 对象头（Mark Word） 关联，当竞争严重时锁会升级：

• 偏向锁：只记录线程 ID，适合无竞争场景
• 轻量级锁：线程通过 CAS 抢占锁
• 重量级锁：膨胀为 ObjectMonitor，线程挂起和唤醒都依赖 OS 的 park/unpark

ReentrantLock

加锁原理（底层）

• ReentrantLock 是基于 AQS（AbstractQueuedSynchronizer） 实现的。
• 调用 lock() 会尝试通过 CAS 修改一个 state 状态变量，来标识是否持有锁。
• 若获取失败，线程会被放入 AQS 的 双向等待队列中，等待唤醒。

加锁过程简要流程图（逻辑）

1
2
3
4
5
6
7

线程调用lock()：
    |
    |-- 尝试通过CAS将state从0改为1（加锁）
        |
        |-- 如果成功，获得锁
        |
        |-- 如果失败，进入AQS等待队列

AQS的队列结构

1
2
3

head -> [Node1] -> [Node2] -> ...
         ^          ^
      线程1     线程2（阻塞）

每个 Node 包含：

• 等待线程 Thread thread
• 等待状态 waitStatus
• 前驱/后继节点 prev / next

底层通过 LockSupport.park() 和 unpark() 来实现线程的阻塞与唤醒。

如何唤醒

​ 两者都是有阻塞队列，队列都是有序的，为什么会出现非公平唤醒呢？

​ **因为”排队” ≠ “唤醒一定按顺序”**。

Java 的锁（尤其是默认的 synchronized 和非公平 ReentrantLock）使用的阻塞队列只是阻塞等待顺序的组织方式，但唤醒后是否真正获得锁，还要竞争（CAS），所以就可能出现：

先排队的线程被唤醒了，但还没抢到锁；此时一个新线程进来，直接CAS成功拿到了锁。

1. synchronized 的非公平行为

synchronized 底层用的是 ObjectMonitor，当有多个线程竞争时，JVM 不保证 先唤醒的一定先拿到锁。

1
2
3
4
5

CopyEdit
// ObjectMonitor.cpp
void ObjectMonitor::exit(...) {
    // 调用 _EntryList 中的某个线程 unpark（但可能不是严格FIFO）
}

唤醒后还要重新尝试获取锁（CAS），不是直接转移锁的拥有权，所以：

• 后来的线程进来，如果没有阻塞，仍然可能直接成功拿到锁。

• 被唤醒的线程，反而还得和新线程竞争，可能继续失败。

2. ReentrantLock 的非公平行为

默认构造的 ReentrantLock() 是非公平锁，非公平策略体现在 lock() 方法中：

1
2
3
4
5
6
7
8

CopyEdit
final void lock() {
    if (compareAndSetState(0, 1)) {     // 直接抢锁，不管队列中有没有人
        setExclusiveOwnerThread(Thread.currentThread());
    } else {
        acquire(1);                     // 抢不到才排队
    }
}

也就是说：

• 没有优先检查 AQS 队列中是否有等待的线程
• 只要锁是空闲的，谁来谁抢，先到的不一定先拿到

即使队列中有等待线程，新线程仍然可以“插队”成功。

​ 在大模型大行其道的今天，学习使用大模型已经是我们程序猿不可或缺的一部分。网传的大模型神乎其神，貌似无所不能，那么大模型的底层到底是什么，是怎么一步一步的发展到今天的大模型的呢。其实大模型的底层本质就是深度学习，只不是跟我们了解的深度学习不一样的是大模型的参数比较多，甚至可以说多的可怕。了解完深度学习之后你就知道为什么参数可以作为大模型的一个指标了。

​ 其实深度学习大致可以划分成三步：构建函数模型、计算缺失值、优化。

案例背景

​ 已知店铺A，11月份每一天的每一天的营业额，我们怎么计算预测12月前3天的营业额。

简单模型预测

​ 按照我们上述说的三个步骤，将整个过程划分成三步，构建函数模型，计算缺失值，计算参数。

构建函数模型

​ 这里我们先构建一个简单的预测模型，其实预测模型就是一个关系函数，就是被预测的结果和前面输入之间的关系函数，在这里就是12月前3天的营业额和11月营业额之间的关系。关系函数我们表示为 y=f(x)，在这里我们先构建一个最简单的预测模型，假设后一天的营业额和前一天的营业额之间的关系函数是 y=ax+b，y是后一天我们预测的营业额，x是当日的营业额。

计算缺失值

​ 现在我们知道了营业额之间的预测函数和11月整个月的营业额，这样我们就可以计算出整个11月真是营业额和我们预测函数计算出来的预测营业额之间的差值L。
$$
L=\frac{1}{N} \Sigma(|y- \hat{y}|)
$$
​ 上面的公式，就是11月的预测值和实际值的差值求平均值。如果我们随机选取一个较小的a、b的初始值，就能计算出缺失值L的值，当我们不停的变幻a、b值之后，就会得到不同的L值。不同的a、b值和L可以构建出下图这样一个统计图，其中蓝色区域是L的较小值，红色是交大值。

计算参数

​ 根据公式，我们是能算出缺失值L的，但是由于我们的预测模型是 y=ax+b，那么我们的缺失值的结果这也一定包含着这两个参数，换而言之就是这两个参数影响着我们的计算结果缺失值L。实际情况中，我们总是希望误差越小越好，也就是缺失值L越小越好。

​ 在数学中，我们求最小值，一般都和斜率相关，找到L的斜率等于0的值，我们应该就能找到一个合适a、b值。我们将L对a、b求偏导，就能找到L相对小的点。这样也就得出了合适的a、b值，从而得到了一个合适的预测函数y=ax+b。

优化

​ 上面我们只是选了一个最简单的折线模型去计算预测值，折线模型只是最简单的模型，在本质上就有所不足，不能很好的预测多参数曲线值。如下图，如果我们用折线模型去模拟计算那条红色的折线，就不是很好计算模拟。如果我们多加几个参数，就比较好计算模拟了。

​ 可以使用sigmoid(x)的函数(下图蓝色折线1)，多几个参数模拟出红色折线。蓝色折线0、1、2、3相加就等于红色折线，折线0是一个常数a，折线2是 csigmoid(x+b)，折线3是dsigmoid(x+e)。从而得出：*

y=sigmoid(x) + a + csigmoid(x+b) + d*sigmoid(x+e)

$$
y=b+\sum_iC_i*sigmoid(b_i+w_ix)
$$
同时我们可以看到，销售额呈周期性变化。我们可以通过一个周期内销售额去计算预测值，公式如下。
$$
y=b+\sum_ic_isigmoid(b_i+\sum_jw_{ij}x_j)
$$

​ 我们根据上面的公式可以计算出预测值，上述的公式5得出，如果我们计算出在得知前三个销售额的情况下，预测出的销售额。

​ 上面的演示结果可以得出
$$
y = b + \sum_i c_i sigmoid(r_i)
$$
​ 如果我们将 sigmoid(r) 看出一个整体的话，可以简化成
$$
y = b + c^Ta
$$
​ 整个公式：
$$
y=b+c^Ta = b+c^T * \sigma(b+wx)
$$
​ 注意上面的两个b不是同一个值。

​ 整个计算逻辑，如图展示：

​ 上面的计算模型只是模拟计算了一层，我们可以模拟计算多层，深度学习的本质就是让我们模拟计算跟多的层次以达到更好的效果，如果我们模拟计算两层的话，可以将我们第一层计算出来的a，再来一次计算。

总结

总结

​ 整个深度学习的过程就是推导出一个合适的计算模型。推导模型的过程可以分为三步：构建函数模型，计算缺失值，计算参数。在后面的优化过程中，我们总共优化了三个点：

1、模型替换，更换成了一个更有弹性的模型

2、增加模型输入，以上述销售额为例，从前一天的销售额预测后一天的销售额变成前几天的销售额预测后一天

3、增加训练层数，将一层计算变成多层计算

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

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

归根到底的数学概率

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

语言模型的两个方向

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

数学+技术

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

监督学习

​ 当然上面的过程也只是其中的训练的一环，还有重要的监督学习。ChatGPT根据概率输出的东西很难保证准确性，毕竟是没有思想的机器，所以这时候就需要我们监督学习，给他的输出打分，正确的分数就高，错误的分数就低，这要提高了正确回答的权重，也就影响了概率和输出。

总结

​ 网上好多资料说了一大堆高大尚的名词:深度学习、循环神经网络、自然语言处理技术、注意力机制、损失函数。这些都是具体实现，不做ai 的也没必要深入了解，知道chatGPT的大概原理也就够了。目前好多人说chatGPT的出现会对现在的社会造成巨大的冲击，绝大多数人都会失业。我想说这并不一定，上面也说了人工智能是根据概率推算结果的，这个概率是根据已有事件计算的，类似于绝大多数人说啥，他也会说啥。这也就是说，他是没有创造力的，他只能帮我们整理已有事件，不会突破已有的事件。比如说当绝大多数人都认为地球是-个平面的时候，chatGPT也会认为地球是一个平面，不会有思考发现地球是个球体。人工智能只是解放了我们生产力，让我们有更多的时间去完成一些创造性的事情。但是如果我们一直在做这种重复性的事情，没有思考创新，chatGPT的出现对我们来说绝对会是个巨大的灾难，至少摸鱼的机会会大大减少。

简述

在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();
}

3、异步发送，执行回调方法

1
2
3
4
5
6
7
8

private class DemoProducerCallback implements Callback{
   @override
   public void onCompletion(RecordMetadata recordMetadata,Exception e){
       //发生错误的回调方法,可以写入日志，或写入DB通过其它线程重重试，保证最终的数据送达
   }
}
ProducerRecord<String,String> record = new ProducerRecord<>("topicName","key","value");
producer.send(record，new DemoProducerCallback()))

在这三种发送方法中，第一种方法，无返回，不感知，所以也无法保证消息不丢失。所以要保证消息不丢失，只能选择第二种或者第三种，一般情况下更推荐第三种。

acks参数设置

在生产者中有acks参数，该参数指定了kafka的多少个副本同步后才算消息发送成功。该参数取值范围：

1、acks=0，表示生产者在消息后不管有没有在leader磁盘上落盘，就认为消息发送成功。

2、acks=1，表示生产者在消息后，在leader磁盘上落盘，就认为消息发送成功，不管其他follower有没有同步。

3、acks=all，表示生产者在消息后，在leader磁盘上落盘，其他follower都同步落盘， 认为消息发送成功。

小结

通过设置发送方式和acks参数，可以保证在发送方式中不丢失，甚至acks参数都可以保证后面的同步过程中消息不丢失。

发送方式一般设置为异步发送，acks参数默认设置为1。

同步过程中丢失

在同步过程中，除了上面说的答acks参数，还有其他副本机制保证消息不丢失。避免leader节点的崩溃导致消息的丢失。

broker中的配置项,unclean.leader.election.enable = false，表示不允许非ISR中的副本被选举为首领，以免数据丢失。

ISR：是指与leader保持一定程度（这种范围是可通过参数进行配置的）同步的副本和 leader 共同被称为ISR

OSR：与leader同步时，滞后很多的副本（不包括leader）被称为OSR

AR，分区中所有的副本统称为AR。AR = ISR + OSR

拉取过程中丢失

设置 enable.auto.commit = false，在consumer端消费消息操作完成以后再手动提交 offset，类似于下文中的代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public void consumerMsg(){
    while(true){
        //这里的poll(100)指的是kafka server端没有消息时，连接等待的时间，超过该时间立即返回空给consumer
        ConsumerRecords<String,String> records = consomer.poll(100);
        for(ConsumerRecord<String,String> record : records){
            // 这里是消费消息的逻辑（简单逻辑输入到控制台）
            System.out.printIn(record.value));
            //提交偏移量
            try{
                consumer.commitSync();  //同步提交 如果异步的话，可以使用 consumer.commitAsync();
            }
            catch(CommitFailedException ex){
                log.error("commit fail");
            }
        }
    }
}

需求描述

计划将原有的代码抽取成可复用的原子能力jar包，一个业务可能需要调用多个原子能力jar包，jar包调用链配置在配置文件中。

实现外部调用接口，通过原子能力调用链实现原子能力包调用。

主要目的：1、实现能力抽取复用，2、实现原子能力编排。

1、没有架构的架构

外部业务通过接口调用service服务，service服务内部通过配置文件调用封装好的jar包。kafka作为消息中间件，为service和运行的jar收集日志。

redis作为缓存中间件，为service和运行的jar提供缓存服务，而MySQL为为service和运行的jar提供持久化数据存储。

2、抽取engine服务

所有的逻辑都杂糅在service服务内，很明显不合适，如果需要扩展多节点的化，那整个service服务都要部署扩展。

其实扩展多节点，主要是为了可复用的jar包能在多节点运行，提高运行效率。

那么我们抽取出一个engine服务，只做加载运行jar包，这样扩展多节点的话，只要扩展engine服务就行。

在抽取完之后，engine和service就不是一个服务了，service调用engine可以通过http请求，但是engine还得向service返回心跳。最好的就是通过kafka来实现这个心跳检测。

3、拆分service

为了提高可拓展性，我们抽出了engine服务，现在的service其实还负责两件事，第一个就是对外的接口暴露，第二个就是内部原子能力的调度。

现在为了使职责更内敛，我们将service再次拆分，拆分成：getaway和schedule

4、新增注册中心

现在又多了getaway和schedule服务，那么服务间的检测就不能只用kafka做的心跳检测了，得增加一个注册中心，这样都方便调度，尤其使engine有多节点部署的需求。engine和schedule都注册在nacos中，getaway和是schedule的调度都是先从nacos中获取相应的服务地址和端口，然后再开始调取相应接口。

5、调用链的转移

原本的调用链是在配置文件中的，经过service的拆分，现在应该在schedule的配置文件中。

虽然调用链是在开发中就已经配置好的，但是我们将调用链移动到MySQL中，这样可以更好的扩展。可以通过其他途径改动MySQL中的调用链，实现实时变更。

由于调用链这种配置不会随便改动，可以通过预加载，将其加载到redis中，这样可以减小MySQL的压力。

简介

ELK是elasticsearch、logstash、kibana软件的集合，对外是作为一个日志管理系统的开源方案，它可以从任何来源、任何格式进行日志搜索、分析与可视化展示。
基本组成软件：

• elasticsearch：一个开源分布式搜索引擎，提供收集、分析、存储数据三大功能。

• kibana：一个基于web的图形界面，用于搜索、分析和可视化存储在elasticsearch中的日志数据。

• logstash：一个服务端的数据处理管道，可以从多个源中提取数据，对其进行转换，然后将其存储到Elasticsearch中。简单来说就是日志的收集、分析、过滤工具。

搭建步骤

使用版本是7.9.3，部署前我们可以先提前从官网上下载下面4个安装包：
elasticsearch-7.9.3-linux-x86_64.tar.gz
kibana-7.9.3-linux-x86_64.tar.gz
logstash-7.9.3.tar.gz

这4个组件可以部署在不同的机器上，只要机器之间是端口开放即可
本文档中elasticsearch、logstash、kibana部署在一台机器，filebeat部署在有业务服务的机器上。

1. 创建用户和解压文件
   groupadd elk
   useradd elk -g elk
   解压文件：
   tar -zxvf elasticsearch-7.9.3-linux-x86_64.tar.gz -C /home/elk
   tar -zxvf kibana-7.9.3-linux-x86_64.tar.gz -C /home/elk
   tar -zxvf logstash-7.9.3.tar.gz -C /home/elk
   
   
   cd /home/elk
   mv kibana-7.9.3-linux-x86_64 kibana-7.9.3
   
   chown -R elk:elk /home/elk/elasticsearch-7.9.3
   chown -R elk:elk /home/elk/kibana-7.9.3
   chown -R elk:elk /home/elk/logstash-7.9.3

2. 部署elasticsearch

   1. 切换到elk用户
      su - elasticsearch
      cd /home/elk/

   2. 修改elasticsearch.yml
      cd /home/elk/elasticsearch-7.9.3/config
      vi elasticsearch.yml
      在文件末尾增加以下内容
      # 集群初始主节点
      cluster.name: “es-cluster”
      network.host: 0.0.0.0
      node.name: “node-1”
      
      
      # discovery type
      discovery.type: single-node
      #discovery.seed_hosts: [“127.0.0.1”, “[::1]”]
      
      # 设置允许所有ip可以连接该elasticsearch
      network.host: 0.0.0.0
      
      # 开启监听的端口为9200
      http.port: 9200
      
      # 增加新的参数，为了让elasticsearch-head插件可以访问es
      http.cors.enabled: true
      http.cors.allow-origin: “*”
      
      # 启用密码
      xpack.security.enabled: true
      
      # 使用默认密码
      xpack.security.authc.accept_default_password: true
      xpack.security.transport.ssl.enabled: true
      如果需要外置存储和日志，需要修改path.data和path.logs
      path.data: /nfsc/cnas_csp_pase_hrx_id010797_vol1003_dev/elasticsearch
      path.logs: /nfsc/cnas_csp_pase_hrx_id010797_vol1003_dev/elasticsearch_logs

   3. 修改Elasticsearch占用内存
      cd /home/elk/elasticsearch-7.9.3/config
      vi jvm.options
      修改JVM参数 ：
      -Xms16g
      -Xmx16g

   4. 启动es的时候有可能会报类似的下面的错误【max virtual memory areas vm.max_map_count [65530] is too low】，所以我们可以通过下面的方法去处理：
      vi /etc/sysctl.conf
      文件末尾添加一行
      vm.max_map_count=655360
      保存之后执行下面的命令加载参数
      sysctl -p

   5. 启动Elasticsearch
      切换用户，进入bin目录启动：
      cd /home/elk/elasticsearch-7.9.3/bin
      ./elasticsearch -d

   6. 为内置账号添加密码

      interactive：给用户一一设置密码

      # auto：自动生成密码
      cd /home/elk/elasticsearch-7.9.3/bin/
      ./elasticsearch-setup-passwords interactive
      

   7. 验证是否启动成功

      curl -XGET -u elastic ‘localhost:9200’

      {
        "name" : "node-1",
        "cluster_name" : "es-cluster",
        "cluster_uuid" : "8eGk8_ohRbWl8ZcNSPsFDQ",
        "version" : {
          "number" : "7.9.3",
          "build_flavor" : "default",
          "build_type" : "tar",
          "build_hash" : "c4138e51121ef06a6404866cddc601906fe5c868",
          "build_date" : "2020-10-16T10:36:16.141335Z",
          "build_snapshot" : false,
          "lucene_version" : "8.6.2",
          "minimum_wire_compatibility_version" : "6.8.0",
          "minimum_index_compatibility_version" : "6.0.0-beta1"
        },
        "tagline" : "You Know, for Search"
      }
      

3. 部署kibana

   1. 修改配置文件，文件位置在/home/elk/kibana-7.9.3/config目录下
      su - elasticsearch
      cd /home/elk/kibana-7.9.3/config
      vi kibana.yml
      添加es的配置，由于是都在同一台机器所以用localhost，如果是不同机器，就换成对应的ip即可
      # kibana端口
      server.port: 5601
      
      
      # 允许所有ip访问
      server.host: “0.0.0.0”
      
      # elasticsearch所在的ip及监听的地址
      elasticsearch.hosts: [“http://localhost:9200"]
      elasticsearch.username: “kibana_system”
      elasticsearch.password: “kibana_system”
      
      # kibana默认创建的索引
      kibana.index: “.kibana”
      
      # 字符编码
      i18n.locale: “zh-CN”
      
      # elasticsearch加密所需配置
      xpack.reporting.encryptionKey: “a_random_string”
      xpack.security.encryptionKey: “something_at_least_32_characters”

   2. 启动kibana
      cd /home/elk/kibana-7.9.3/bin
      ./kibana &

   3. 访问kibana
      http://IP:5601/

4. 部署Logstash

   1. 修改Logstash的YML配置文件
      cd /home/elk/logstash-7.9.3/config/
      vim logstash.yml
      修改以下内容
      # 配置自动刷新
      config.reload.automatic: true
      config.reload.interval: 20s
      
      
      # 配置可任意地址都可访问
      http.host: 0.0.0.0
      http.port: 9600
      
      # 配置es的访问密码
      xpack.monitoring.enabled: true
      xpack.monitoring.elasticsearch.username: logstash_system
      xpack.monitoring.elasticsearch.password: logstash_system
      xpack.monitoring.elasticsearch.hosts: [“http://localhsot:9200"]

   2. 修改 pipelines配置文件

      • pipeline.id: gmp-logs
        queue.type: persisted
        path.config: “/home/elk/logstash-7.9.3/conf.d/*.config”

   3. 创建日志的config文件
      touch /home/elk/logstash-7.9.3/conf.d/logstash-beats.conf
      写入文件内容
      input {
      beats {
      port => 5044
      }
      }
      
      
      filter {
      grok {
      match => [
      “message”, “%{TIMESTAMP_ISO8601:timestamp_string}%{SPACE}%{GREEDYDATA:line}”
      ]
      }
      date {
      match => [“timestamp_string”, “ISO8601”]
      }
      mutate {
      remove_field => [message, timestamp_string]
      }
      }
      
      output {
      elasticsearch {
      hosts => [“http://localhost:9200"]
      user => elastic
      password => “elastic”
      }
      stdout {
      codec => rubydebug
      }
      }

   4. 启动Logstash(root用户)
      cd /home/elk/logstash-7.9.3/bin
      sh logstash -f ../conf.d/logstash-beats.conf &