Browse Source

更新了面经的笔记

seamew 1 year ago
parent
commit
1da622d418
3 changed files with 73 additions and 2 deletions
  1. 52 0
      算法/多线程/三个线程打印ABC.md
  2. 20 1
      面经/问答/计网.md
  3. 1 1
      面经/项目/中煤项目.md

+ 52 - 0
算法/多线程/三个线程打印ABC.md

@@ -0,0 +1,52 @@
+```java
+public void print(String str, int target) throws InterruptedException {
+    for (int i = 0; i < n; i++) {
+        synchronized (obj) {
+            while (state % 3 != target) {
+                try {
+                    obj.wait();
+                } catch (InterruptedException e) {
+                    e.printStackTrace();
+                }
+            }
+            state++;
+            System.out.print(str);
+            obj.notifyAll();
+        }
+    }
+}
+
+public void print(String str, int target) throws InterruptedException {
+    for (int i = 0; i < n; ) {
+        synchronized (obj) {
+            while (state % 3 != target) {
+                obj.wait();
+            }
+            state++;
+            i++;
+            System.out.print(str);
+            obj.notifyAll();
+        }
+    }
+}
+```
+
+```java
+public void print(String str, int target) throws InterruptedException {
+    for (int i = 0; i < n; ) {
+        try {
+            lock.lock();
+            while (state % 3 == target) {
+                System.out.print(str);
+                state++;
+                i++;
+            }
+        } finally {
+            lock.unlock();
+        }
+    }
+}
+```
+
+
+

+ 20 - 1
面经/问答/计网.md

@@ -102,12 +102,20 @@ TCP 是**面向连接的、可靠的、基于字节流**的传输层通信协议
 
 ## TCP三次握手
 
-这个问题可以理解为为什么TCP不是两次握手,因为主要原因是两次握手只能确定一方的状态
+### 为什么需要三次握手
 
 - 三次握手才可以阻止重复历史连接的初始化(主要原因)
+
+**在两次握手的情况下,服务端没有中间状态给客户端来阻止历史连接,导致服务端可能建立一个历史连接,造成资源浪费**。
+
 - 三次握手才可以同步双方的初始序列号
+
+TCP 协议的通信双方, 都必须维护一个「序列号」, 序列号是可靠传输的一个关键因素。**一来一回,才能确保双方的初始序列号能被可靠的同步。**
+
 - 三次握手才可以避免资源浪费
 
+如果客户端发送的 `SYN` 报文在网络中阻塞了,重复发送多次 `SYN` 报文,那么服务端在收到请求后就会**建立多个冗余的无效链接,造成不必要的资源浪费。**
+
 需要注意的是**第三次握手是可以携带数据的,前两次握手是不可以携带数据的**
 
 ![image-20230509151944605](assets/image-20230509151944605.png)
@@ -245,3 +253,14 @@ TCP 的 Keepalive 这东西其实就是 **TCP 的保活机制**
 - 固定长度的消息:这种是最简单方法,即每个用户消息都是固定长度的,比如规定一个消息的长度是 64 个字节,当接收方接满 64 个字节,就认为这个内容是一个完整且有效的消息。
 - 特殊字符作为边界:我们可以在两个用户消息之间插入一个特殊的字符串,这样接收方在接收数据时,读到了这个特殊字符,就把认为已经读完一个完整的消息。
 - 自定义消息结构:我们可以自定义一个消息结构,由包头和数据组成,其中包头包是固定大小的,而且包头里有一个字段来说明紧随其后的数据有多大。
+
+## 从输入 URL 到页面展示到底发生了什么?(非常重要)
+
+总体来说分为以下几个过程:
+
+1. DNS解析
+2. TCP连接
+3. 发送HTTP请求
+4. 服务器处理请求并返回HTTP报文
+5. 浏览器解析渲染页面
+6. 连接结束

+ 1 - 1
面经/项目/中煤项目.md

@@ -4,7 +4,7 @@
 
 该模块主要采集传感器生成的实时数据,为了保证数据的有序,所以要保证数据的顺序消费,因为采集的数据将按照时间顺序存入到hbase中。在生产者那一端可以从mysql或者kafka管道中收集数据实时数据,为了保证顺序消费,综合考虑将重试次数设置为0,因为这个系统更多的是在意吞吐量,对于消息是否丢失不是很在意。在消费者那一端则采用线程池对消费的数据进行多线程处理,主要采取策略模式,按照选择的不同策略进行计算,例如区间或者压强的简单计算,或者是数值替换,也支持三方jar包,然后通过futuer收集数据。最后存储到hbase中。为了保证消息的等幂性,消费者端我们采取redis进行缓存分区偏移量,缓存超时时间默认为3分钟,手动提交ACK。等方式保证消息顺序消费。
 
-我完成的第二个模块就是kafka监控模块,主要监控kafka集群的状态,与kafka-egale类似。主要操作就是调用kafka提供的kafka-admin-client接口和JMX进行操作,这里进行了相应的优化,主要包括复用同一个连接,使用工厂模式,生产一个admin-client,这里主要加了饿汉式单例来保证线程安全,利用redis缓存topic的速率。最后对于该模块,采用热启动的方式优化,例如自动建表,提前获取相关admin-client链接等
+我完成的第二个模块就是kafka监控模块,主要监控kafka集群的状态,与kafka-egale类似。主要操作就是调用kafka提供的kafka-admin-client接口和JMX进行操作,这里进行了相应的优化,主要包括复用同一个连接,使用工厂模式,生产一个admin-client,这里主要加了汉式单例来保证线程安全,利用redis缓存topic的速率。最后对于该模块,采用热启动的方式优化,例如自动建表,提前获取相关admin-client链接等
 
 ```java
 import redis.clients.jedis.Jedis;