其他方面的内容

1.I/O密集型任务和CPU密集型任务的区别
I/O密集型任务（I/O-bound tasks）是指那些大部分时间都花费在等待输入/输出（I/O）操作完成的任务。这些I/O操作可能包括文件读写、网络通信、数据库访问等。由于这些操作通常涉及磁盘、网络或其他外部设备的访问，它们的执行速度相对较慢，因此CPU在等待这些操作完成时经常处于空闲状态。
I/O密集型任务的一个典型例子是Web服务器处理静态文件请求。当服务器收到一个对静态HTML文件的请求时，它可能需要从磁盘读取该文件，然后将其通过网络发送给客户端。在这个过程中，大部分时间都花费在磁盘读取和网络传输上，而不是CPU计算上。

CPU密集型任务（CPU-bound tasks）则是指那些需要大量CPU计算资源的任务（如视频编码、数学计算、图像处理）。这些任务通常涉及大量的数学运算、逻辑处理或数据转换等操作。由于这些操作在CPU上执行得相对较快，因此CPU密集型任务的主要瓶颈在于CPU的处理能力，而不是I/O操作的等待时间。
一个CPU密集型任务的例子是视频编码。视频编码过程需要对大量的视频帧进行复杂的数学运算，以便将其压缩成更小的文件大小。这个过程需要大量的CPU资源，并且通常很难通过并行化来加速（尽管现代处理器具有多核架构，但视频编码的某些部分可能仍然是串行的）。

区别
资源消耗：I/O密集型任务主要消耗I/O设备的带宽和CPU的等待时间，而CPU密集型任务则主要消耗CPU的计算资源。
性能瓶颈：I/O密集型任务的性能瓶颈通常在于I/O操作的等待时间，而CPU密集型任务的性能瓶颈则在于CPU的处理速度。
并行化潜力：由于I/O密集型任务在等待I/O操作时CPU处于空闲状态，因此它们通常更容易通过并行化来加速（例如，使用多线程或多进程）。相比之下，CPU密集型任务的并行化可能更加困难，因为它们的计算部分通常是串行的，并且受到CPU核心数量的限制。
应用场景：I/O密集型任务在Web服务器、数据库访问、网络通信等场景中很常见，而CPU密集型任务则更多地出现在科学计算、图像处理、视频编码等领域。

2.线程和进程的区别
多线程：线程依赖于进程存在，一个进程中的线程共享进程的资源，线程的创建和销毁开销相对较小。适用于I/O密集型任务，如网络请求、文件读写等。

多进程：进程是独立的执行实体，拥有自己的资源（内存、文件描述符等），进程之间互不干扰。进程的创建和销毁开销较大。适用于CPU密集型任务。

3.TCP和UDP的区别
TCP是面向连接的，UDP是无连接的
TCP是可靠的，UDP是不可靠的
TCP是面向字节流的，UDP是面向数据报文的
TCP只支持点对点通信，UDP支持一对一，一对多，多对多
TCP报文首部20个字节，UDP首部8个字节
TCP有拥塞控制机制，UDP没有
TCP协议下双方发送接受缓冲区都有，UDP并无实际意义上的发送缓冲区，但是存在接受缓冲区

4.http无状态
HTTP协议的无状态特性‌指的是HTTP协议在处理请求时，服务器不会保存任何关于客户端状态的信息，每次请求都是独立的，服务器不会记住之前的请求信息。这种设计使得每次请求都必须携带完成请求所需的所有信息，服务器不会根据之前的交互进行状态保持‌。
Cookie（不可跨域名）
Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来，当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。通常存储标识符（如Session ID），服务器通过标识符查询会话数据来判定用户状态。
Cookie保存登录信息有多种方案
方案一：最直接的是把用户名与密码都保持到Cookie中，下次访问时检查Cookie中的用户名与密码，与数据库比较。这是一种比较危险的选择，一般不把密码等重要信息保存到Cookie中。
方案二：是把密码加密后保存到Cookie中，下次访问时解密并与数据库比较。这种方案略微安全一些。如果不希望保存密码，还可以把登录的时间戳保存到Cookie与数据库中，到时只验证用户名与登录时间戳就可以了。
方案三：只在登录时查询一次数据库，以后访问验证登录信息时不再查询数据库。实现方式是把账号按照一定的规则加密后，连同账号一块保存到Cookie中。下次访问时只需要判断账号的加密规则是否正确即可。
Session
Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
Token
存储在客户端，通常作为HTTP请求头（如Authorization: Bearer <token>）或URL参数传递。可包含用户信息（如JWT的Payload），无需服务器查询数据库即可验证身份。支持跨域，因为token由客户端主动携带，不受浏览器同源策略限制。适合需要无状态认证（如API、微服务）的场景。
JWT是Token的一种实现方式，采用标准化格式（JSON（Header + Payload + Signature），其中Payload可携带用户信息）和加密签名机制。一般工作流程：1、用户登录。客户端发送用户名和密码到服务器，服务器验证通过后，生成JWT（包含用户信息和签名）。2、返回JWT。服务器将JWT返回给客户端（通常通过HTTP响应头或响应体）。3、客户端存储。客户端将JWT存储在localStorage、sessionStorage或cookie中。4、请求携带JWT。客户端在后续请求的HTTP请求头（如Authorization: Bearer <JWT>）中携带JWT。5、服务器验证。服务器解析JWT，验证签名和过期时间，提取用户信息。JWT一旦签发，无法直接撤销（除非实现黑名单机制），或提前设定好过期时间/生效时间。

5.Http Get和Post

GET‌：1、仅用于请求资源，不修改服务器数据，因此‌幂等且可缓存‌（重复请求结果一致）；2、传参附加在URL后（可见于地址栏）；3、‌参数受URL长度限制，且仅支持ASCII字符。
POST‌：1、用于提交数据（如新增/修改资源），‌非幂等且不可缓存‌（每次请求可能产生不同结果）；2、‌传参封装至请求体；3、传参无明确限制，且支持多种数据类型。

6.保证分布式事务一致性的方法
1. 两阶段提交（2PC, Two-Phase Commit）
原理：准备阶段（Prepare）：协调者向所有参与者发送预提交请求，参与者执行事务操作并记录日志，但暂不提交。提交阶段（Commit）：协调者根据参与者的反馈决定提交或回滚事务。如果所有参与者都准备成功，则发送提交请求；否则发送回滚请求。
优点：保证强一致性；实现相对简单。
缺点：单点故障：协调者是单点，可能成为瓶颈。阻塞问题：参与者需要等待协调者的最终决定，可能长时间阻塞。性能开销：需要多次网络通信，延迟较高。
适用场景：对一致性要求高、事务执行时间短的场景（如金融交易）。

2. 三阶段提交（3PC, Three-Phase Commit）
原理：3PC 是对 2PC 的改进，增加了超时机制和预提交阶段，分为三个阶段：CanCommit：协调者询问参与者是否可以执行事务。PreCommit：参与者执行事务操作并记录日志，但暂不提交。DoCommit：协调者根据参与者的反馈决定提交或回滚事务。
优点：解决了 2PC 的阻塞问题，参与者可以在超时后自动提交或回滚。降低了协调者故障的影响。
缺点：仍然存在单点故障问题。实现复杂度较高。
适用场景：对一致性要求高、需要减少阻塞的场景。

3. TCC（Try-Confirm-Cancel）模式
原理：TCC 是一种补偿型事务模式，将事务操作分为三个阶段：Try：尝试预留资源（如锁定库存、冻结金额）。Confirm：确认执行事务（如扣减库存、扣款）。Cancel：取消事务，释放预留资源（如解锁库存、解冻金额）。
优点：灵活性高，适用于复杂的业务场景。不依赖数据库事务，性能较好。
缺点：业务侵入性强，需要为每个操作实现 Try、Confirm、Cancel 方法。开发成本较高。
适用场景：高并发、业务逻辑复杂的场景（如电商订单、支付系统）。

(1) 选择强一致性的场景

• 核心业务：金融交易、支付系统、库存扣减等。
• 法规要求：如 GDPR 对数据一致性的严格要求。
• 技术方案：2PC、Paxos/Raft、分布式事务框架（如 Seata）。

(2) 选择最终一致性的场景

• 非核心业务：社交网络、日志记录、缓存系统等。
• 高并发场景：电商秒杀、用户行为日志等。
• 技术方案：消息队列（如 Kafka）、Gossip 协议、本地消息表。

(3) 折中方案

• 柔性一致性：如 TCC、Saga 模式，结合强一致性和最终一致性的优点。
  • 适用于复杂业务流程（如电商订单）。

7.数据库性能优化的方法

一、查询优化
1、索引优化：创建合适的索引，避免过度索引。注意：复合索引遵循最左前缀原则（如(a, b)索引支持a或a,b查询，但不支持单独b查询），避免在索引列上使用函数。
2、避免全表扫描：使用EXPLAIN分析查询计划，确认是否命中索引。限制返回数据量（如LIMIT 100）。只查询必要列。
3、优化join查询：确保join字段有索引。避免大表join大表。
4、减少子查询和临时表：可考虑把子查询改为join。特殊情况考虑使用exist。
二、数据库结构优化
1、分库分表：水平分表、垂直分表。
2、读写分离。
3、缓存策略：redis缓存。
三、硬件与网络优化

8、redis和es的适用场景

1. 选择 Redis 的场景：
   • 需要高性能缓存、实时计数、简单消息队列或会话管理。
   • 数据量较小，且以键值对形式存储。
2. 选择 ES 的场景：
   • 需要全文搜索、日志分析、复杂查询或地理空间搜索。
   • 数据量较大，且需要多维分析和聚合。

9、异步、多线程、并行、并发

并发是指系统在同一时间段内交替处理多个任务的能力，通常由多线程、异步、并行等技术实现。
多线程是指在单个进程中创建多个线程，每个线程独立执行代码块。
并行是并发的子集，通常通过任务分解，将大任务分解为多个小任务同时进行，需依赖多核cpu实现。

10、js将对象转为json在console展示
console.log(JSON.stringify(nestedArray, null, 2));

• **JSON.stringify()**：将 JavaScript 对象（这里是nestedArray）转换为 JSON 格式的字符串。
• **nestedArray**：待转换的嵌套数组（可以是任意复杂结构，如多维数组、对象数组等）。
• **null**：表示不使用替换函数（若需格式化部分数据可传入函数）。
• **2**：每层嵌套缩进空格数（控制输出的可读性）。

11、使用protoc.exe将proto文件转为java类：
protoc.exe --java_out=输出路径 --proto_path=protoc解压路径 xxx.proto文件路径

12、本地运行.sh脚本文件
1. 安装 [Git for Windows](https://git-scm.com/)，它自带 Git Bash（支持 `.sh` 脚本）。
2. 在 Git Bash 中导航到脚本所在目录。
3. 给脚本添加可执行权限并运行：
```bash
chmod +x build.sh
./build.sh

13、MobaXterm和Xshell的对比

14、延时队列和死信队列

15、dmq topic采用kafka协议和采用pulsar协议的区别

• Kafka协议=极简主义高性能日志管道，适合大数据、日志场景，功能单一但极致高效。

• Pulsar协议=全能型云原生消息平台，适合交易、多租户、复杂业务场景，功能丰富但架构稍复杂。

16、ZooKeeper和BookKeeper对比

两者是互补关系，而非竞争关系。在Pulsar中，ZooKeeper负责告诉BookKeeper"数据该存哪"，BookKeeper负责实际存数据。

17、前端基本概念

选 Vue：追求开发效率、中小型项目、团队熟悉模板语法。
选 React：需要高度灵活性、大型复杂应用、团队熟悉函数式编程。
选 Node.js：构建后端服务、实时应用、全栈开发。
npm 必学：Node.js 的默认包管理工具，用于安装、发布和管理 JavaScript 项目的依赖包。
nvm 必学：Node.js 版本管理工具，用于在同一台机器上安装、切换和管理多个 Node.js 版本。

18、Content-Type 类型详解与使用场景

一句话总结：API 接口用application/json，文件上传用multipart/form-data，传统表单用application/x-www-form-urlencoded。