苍穹外卖项目面试总结话术

码上走

已于 2024-12-31 17:49:17 修改

阅读量7.2k

点赞数 48

文章标签：面试 java

于 2024-10-28 17:12:50 首次发布

本文链接：https://blog.csdn.net/qq_45195447/article/details/143307640

版权

1.项目介绍

美食速递这个项目最初是我参与制作的大创项目，是一款为学生提供校园外卖送至宿舍服务的软件，包含系统管理后台和小程序端两部分。其中系统管理后台主要提供给食堂内部员工使用，可以对食堂各个窗口、员工、订单、菜品等进行维护管理；小程序端可以在线浏览菜品、添加购物车、下单等，由学生兼职做跑腿送餐上门服务。这是个前后端分离的项目，我主要是负责后端的用户登录、员工管理，菜品管理，订单管理模块的编码实现。

1.项目部署在哪里？

拆分为前后端分离的项目后，最终部署时，后端工程会打成一个jar包，运行在Tomcat中 (springboot内嵌的tomcat)。前端工程的静态资源，会直接部署在Nginx中进行访问。

怎么打jar包？

使用命令mvn package（需要服务器安装maven环境）
使用命令cd target/进入到目录就能看到打好的jar包（这里的jar包是ruoyi.jar）
将jar包拷贝到上级目录，防止target目录清理导致jar包丢失

1.建了哪些表？

每张表的说明：

1	employee	员工表
2	category	分类表
3	dish	菜品表
4	dish_flavor	菜品口味表
5	setmeal	套餐表
6	setmeal_dish	套餐菜品关系表
7	user	用户表
8	address_book	地址表
9	shopping_cart	购物车表
10	orders	订单表
11	order_detail	订单明细表

employee表结构：

id	bigint	主键	自增
name	varchar(32)	姓名
username	varchar(32)	用户名	唯一
password	varchar(64)	密码
phone	varchar(11)	手机号
sex	varchar(2)	性别
id_number	varchar(18)	身份证号
status	Int	账号状态	1正常 0锁定
create_time	Datetime	创建时间
update_time	datetime	最后修改时间
create_user	bigint	创建人id
update_user	bigint	最后修改人id

0.技术亮点

1.使用Nginx部署前端界面实现前后端分离，并实现反向代理和负载均衡

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器

前端页面部署到Nginx服务器中，后端代码部署到后端服务器中，使用Nginx对后端服务器进行反向代理，使用户只需要访问Nginx服务器便可获得后端服务器的服务（便于后期扩展集群，提高系统并发量）。

1.Nginx反向代理

前端请求地址：http://localhost/api/employee/login

后端接口地址：http://localhost:8080/admin/employee/login

前端请求地址后端接口地址

很明显，两个地址不一致，那是如何请求到后端服务的呢？

nginx 反向代理，就是将前端发送的动态请求由 nginx 转发到后端服务器

那为什么不直接通过浏览器直接请求后台服务端，需要通过nginx反向代理呢？

nginx 反向代理的好处：

提高访问速度因为nginx本身可以进行缓存，如果访问的同一接口，并且做了数据缓存，nginx就直接可把数据返回，不需要真正地访问服务端，从而提高访问速度。
进行负载均衡所谓负载均衡,就是把大量的请求按照我们指定的方式均衡的分配给集群中的每台服务器。
保证后端服务安全因为一般后台服务地址不会暴露，所以使用浏览器不能直接访问，可以把nginx作为请求访问的入口，请求到达nginx后转发到具体的服务中，从而保证后端服务的安全。

2.Nginx负载均衡

当如果服务以集群的方式进行部署时，那nginx在转发请求到服务器时就需要做相应的负载均衡。其实，负载均衡从本质上来说也是基于反向代理来实现的，最终都是转发请求。

在nginx的配置文件设置负载均衡策略。

nginx有很多负载均衡策略，比如轮询，weight权重方式,url分配方式，我们项目用的是轮询方式，共有3台后端服务器

nginx 负载均衡策略：

轮询	默认方式，每个请求会按时间顺序逐一分配到不同的后端服务器。
weight	权重方式，默认为1，权重越高，被分配的客户端请求就越多
ip_hash	依据ip分配方式，这样每个访客可以固定访问一个后端服务
least_conn	依据最少连接方式，把请求优先分配给连接数少的后端服务
url_hash	依据url分配方式，这样相同的url会被分配到同一个后端服务
fair	依据响应时间方式，响应时间短的服务将会被优先分配

http请求报文和响应报文

http报文的三个组成部分 http报文是一个格式化数据块。报文类型包括客户端请求，服务器响应。

http请求报文由3个部分组成：

请求行（start line）：由请求方法(GET/POST/PUT)、请求URL（不包括域名 | 、HTTP协议版本组成

请求头（header）：请求头部由关键字/值对组成，每行一对;主要包含Content-Length标头：实体的长度，Content-Tyep标头：实体的媒体类型

请求体（body）：GET（从服务器获取数据）请求体为空，POST（向服务器发送要处理的数据）有数据

http响应报文组成：

1.状态行：服务器HTTP协议版本，响应状态码，状态码的文本描述

状态码由3位数字组成，第一个数字定义了响应的类别：

1xx：指示信息，表示请求已接收，继续处理

2xx：成功，表示请求已被成功接受，处理。

3xx：重定向

4xx：客户端错误

5xx：服务器端错误，服务器未能实现合法的请求。

2.首部行：主要包含Content-Length标头：实体的长度，Content-Tyep标头：实体的媒体类型

3.实体：实体包含了Web客户端请求的对象

Apifox测试接口流程

step1.选择请求方法->填写请求url->填写url参数->填写body参数和header参数（如果有）

step2.手动发送请求

step3.查看返回参数是否正常，是否符合接口文档的约定

0.项目哪里用了设计模式？

使用工厂模式和策略模式实现布隆过滤器的大概流程如下：

定义布隆过滤器接口：首先定义一个布隆过滤器接口，包括添加元素和判断元素是否存在两个基本操作。
实现具体的布隆过滤器类：创建一个具体的布隆过滤器类，实现布隆过滤器接口中的方法。在这个类中，需要定义布隆过滗器的数据结构（比如位数组）、大小等属性。
定义哈希策略接口：定义一个哈希策略接口，包含计算哈希值的方法。
实现具体的哈希策略类：创建多个具体的哈希策略类，实现哈希策略接口中的方法，每个类对应一种哈希函数的计算方法。
创建布隆过滤器工厂类：定义一个布隆过滤器工厂类，其中包含一个用于创建布隆过滤器对象的工厂方法。工厂方法接受布隆过滤器的大小和哈希策略对象作为参数，并返回一个具体的布隆过滤器对象。
使用布隆过滤器工厂：在需要创建布隆过滤器对象的地方，调用布隆过滤器工厂的工厂方法来创建布隆过滤器对象，并传入相应的哈希策略对象。

使用工厂和策略设计模式的好处？

使用工厂模式和策略模式来实现布隆过滤器带来以下好处：

解耦性：工厂模式和策略模式的结合可以将对象的创建和哈希函数的选择分离，使得各部分之间的耦合度降低。这样在需要修改布隆过滤器的具体实现或者切换哈希函数时，只需要修改相应的工厂类或策略类，而不影响其他部分。
可扩展性：通过工厂模式和策略模式，我们可以方便地添加新的布隆过滤器实现类和哈希函数策略类，而不需要修改现有代码。这样在需要增加新的布隆过滤器类型或者新的哈希函数时，只需添加相应的类即可。
代码复用：工厂模式和策略模式可以提高代码的复用性。通过工厂模式，我们可以在不同地方调用工厂方法来创建布隆过滤器对象，避免重复的创建逻辑。通过策略模式，不同的哈希函数策略可以被多个布隆过滤器共享使用。
易于维护：将对象的创建和哈希函数的选择分开管理，使得代码结构清晰，易于维护和理解。当需要修改布隆过滤器的实现或者哈希函数时，只需修改相应的工厂类或策略类，而不会对其他部分造成影响。

1.使用工厂模式和策略模式实现布隆过滤器解决缓存穿透问题

1.什么是缓存穿透问题

缓存穿透:请求根本不存在的资源（DB本身就不存在，Redis更是不存在），这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。这种情况大概率是遭到了攻击。

使用BitMap作为布隆过滤器，将目前所有可以访问到的资源通过简单的映射关系放入到布隆过滤器中（哈希计算），当一个请求来临的时候先进行布隆过滤器的判断，如果有那么才进行放行，否则就直接拦截

2.什么是布隆过滤器？

布隆过滤器主要是用于检索一个元素是否在一个集合中。

布隆过滤器的核心思想是使用多个哈希函数来将元素映射到位数组中的多个位置上。当一个元素被加入到布隆过滤器中时，它会被多次哈希，并将对应的位数组位置设置为1。当需要判断一个元素是否在布隆过滤器中时，我们只需将该元素进行多次哈希，并检查对应的位数组位置是否都为1，如果其中有任意一位为0，则说明该元素不在集合中；如果所有位都为1，则说明该元素可能在集合中（因为有可能存在哈希冲突），需要进一步检查。

3.怎么用布隆过滤器解决缓存穿透问题

使用BitMap作为布隆过滤器，使用多个hash函数对key进行hash运算，得到一个整数索引值，对位数组长度进行取模运算得到一个位置，每个hash函数都会得到一个不同的位置，将这几个位置的值置为1。

向布隆过滤器查询某个key是否存在时，先把这个 key 通过相同的多个 hash 函数进行运算，查看对应的位置是否都为 1，

只要有一个位为零，那么说明布隆过滤器中这个 key 不存在；

如果这几个位置全都是 1，那么说明极有可能存在但不是一定存在；

因为这些位置的 1 可能是因为其他的 key 存在导致的，也就是前面说过的hash冲突

什么是bitmap

bitmap是redis的一种数据类型

Bitmap 存储的是连续的二进制数字（0 和 1），本来int数字占4字节32位，但通过 Bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态(比如:01表示1，001表示2) 。，所以 Bitmap 本身会极大的节省储存空间。

# 将名为myBitmap的bitmap的第5位设置为1
SETBIT myBitmap 5 1  //SETBIT key offset value
获取位值：GETBIT key offset
java实现：redisTemplate.opsForValue().getBit(checkItem, index);

4.设置布隆过滤器的误判率

设置布隆过滤器的误判率为1%

布隆过滤器工厂接收预期数据量n和误差率p，根据上面两个数据计算出布隆过滤器的大小m(size)和哈希函数个数k。

当布隆过滤器实际的数据存储量超过预期数据量之后，误判率也会随之上涨。但是布隆过滤器是不能删除已有元素的，在这里我们采取的方案是再创建一个布隆过滤器

5.怎么用的设计模式？

使用工厂模式和策略模式实现布隆过滤器的大概流程如下：

定义布隆过滤器接口：首先定义一个布隆过滤器接口，包括添加元素和判断元素是否存在两个基本操作。
实现具体的布隆过滤器类：创建一个具体的布隆过滤器类，实现布隆过滤器接口中的方法。在这个类中，需要定义布隆过滗器的数据结构（比如位数组）、大小等属性。
定义哈希策略接口：定义一个哈希策略接口，包含计算哈希值的方法。
实现具体的哈希策略类：创建多个具体的哈希策略类，实现哈希策略接口中的方法，每个类对应一种哈希函数的计算方法。
创建布隆过滤器工厂类：定义一个布隆过滤器工厂类，其中包含一个用于创建布隆过滤器对象的工厂方法。工厂方法接受布隆过滤器的大小和哈希策略对象作为参数，并返回一个具体的布隆过滤器对象。
使用布隆过滤器工厂：在需要创建布隆过滤器对象的地方，调用布隆过滤器工厂的工厂方法来创建布隆过滤器对象，并传入相应的哈希策略对象。

使用工厂和策略设计模式的好处？

使用工厂模式和策略模式来实现布隆过滤器带来以下好处：

解耦性：工厂模式和策略模式的结合可以将对象的创建和哈希函数的选择分离，使得各部分之间的耦合度降低。这样在需要修改布隆过滤器的具体实现或者切换哈希函数时，只需要修改相应的工厂类或策略类，而不影响其他部分。
可扩展性：通过工厂模式和策略模式，我们可以方便地添加新的布隆过滤器实现类和哈希函数策略类，而不需要修改现有代码。这样在需要增加新的布隆过滤器类型或者新的哈希函数时，只需添加相应的类即可。
代码复用：工厂模式和策略模式可以提高代码的复用性。通过工厂模式，我们可以在不同地方调用工厂方法来创建布隆过滤器对象，避免重复的创建逻辑。通过策略模式，不同的哈希函数策略可以被多个布隆过滤器共享使用。
易于维护：将对象的创建和哈希函数的选择分开管理，使得代码结构清晰，易于维护和理解。当需要修改布隆过滤器的实现或者哈希函数时，只需修改相应的工厂类或策略类，而不会对其他部分造成影响。

5.使用Mysql自带的二进制日志功能，实现MySQL主从复制，Sharding-JDBC实现读写分离,减轻单台数据库读写压力，避免发生单点故障

1.为什么主从复制

刚开始系统只部署了一台服务器，读和写数据的所有压力全都由一台数据库承担，压力大，数据库服务器磁盘损坏则数据丢失，单点故障。后来使用 MySQL进行主从复制，一主一从，主库进行增删改操作，从库进行查询操作，从而减轻数据库负担。主库的数据会实时同步到从库中，实现了主库数据的备份，就算主库损毁也有备份，安全性大大提高。随着业务量的扩展、如果是单机部署的MySQL，会导致I/O频率过高。采用主从复制、读写分离可以提高数据库的可用性。本项目使用Sharding-JDBC在程序中实现读写分离(优点在于数据源完全有Sharding托管，写操作自动执行master库，读操作自动执行slave库。不需要程序员在程序中关注这个实现了。)。

主从复制实际上就是将主库的数据同步到从库数据，通过Mysql主从复制就可以实现从库中的数据和主库中的数据一致。

2.MySQL怎么主从复制

MySQL复制过程分为三步：

第一：主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。

第二：从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。

第三：从库重做中继日志中的事件，在slave库上做相应的更改。

3.Sharding-JDBC怎么实现读写分离

对于同一时刻有大量并发读操作和较少写操作类型的应用来说，将数据库拆分为主库和从库，主库就负责处理事务性的增删改操作，从库负责处理查询操作，能够有效的避免由数据更新导致的行锁（innodb引擎支持的就是行锁），使得整个系统的性能得到极大改善。

Sharding-JDBC介绍Sharding-JDBC定位为轻量级java框架，在java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。使用Sharding-JDBC可以在程序中轻松的实现数据库读写分离,优点在于数据源完全有Sharding托管，写操作自动执行master库，读操作自动执行slave库。不需要程序员在程序中关注这个实现了。

6.使用Redis，采用一主两从+哨兵的集群方案，缓存营业状态、菜品分类等信息，解决了数据一致性问题；

1,为什么用redis

当用户数量较多时，系统访问量大，频繁的访问数据库，数据库压力大，系统的性能下降，用户体验感差。因此使用Redis对数据进行缓存。

7、redis缓存原理，为什么快。

Redis是一种高性能的键值对存储数据库，常被用作缓存系统。以下是Redis缓存的原理以及它速度快的原因：

Redis缓存原理

数据存储结构：

- Redis使用多种数据结构来存储数据，如字符串（String）、列表（List）、哈希（Hash）、集合（Set）、有序集合（Sorted Set）等。这些丰富的数据结构使得它能适应不同场景下的数据缓存需求。
- 例如，对于简单的用户信息缓存，可能会使用字符串结构存储用户的某个属性值；而对于存储一组相关的数据，如用户的多个订单信息，可能会使用列表或者哈希结构。

内存存储：

- Redis将数据存储在内存中，这是它实现快速数据访问的重要基础。与传统的基于磁盘存储的数据库不同，内存的读写速度比磁盘要快几个数量级。
- 当应用程序需要访问数据时，直接从内存中读取数据，避免了磁盘I/O操作带来的延迟。

基于键值对的访问：

- Redis通过键（Key）来唯一标识和访问存储的数据值（Value）。这种简单而直接的键值对访问方式使得数据的查找和获取非常高效。
- 应用程序只需要提供正确的键，Redis就能快速定位并返回对应的价值，无需复杂的查询语句和索引遍历过程。

Redis速度快的原因

内存操作优势：

- 如前文所述，内存的读写速度极快。数据在内存中的访问时间通常在纳秒级别，相比之下，磁盘的访问时间可能在毫秒级别甚至更高。
- 当Redis执行数据的读写操作时，几乎是瞬间完成，大大提高了数据处理的效率。

单线程架构（针对部分操作）：

- Redis在处理客户端请求时，部分核心操作采用单线程架构（像网络I/O和键值对读写操作）。虽然是单线程，但它并不会成为性能瓶颈，反而有一些优势。
- 因为单线程避免了多线程之间的上下文切换开销，不需要处理复杂的线程同步问题，使得代码执行流程更加简单和高效。
- 同时，Redis的内部实现对每个请求都进行了高效的排队处理，确保每个请求都能快速得到响应。

高效的数据结构和算法：

- Redis内部使用了很多高效的数据结构和算法来实现数据的存储和操作。
- 例如，对于哈希表的实现，采用了渐进式rehash等优化技术，既能保证在数据量增长时哈希表的性能稳定，又能快速地进行数据查找和插入操作。
- 对于有序集合，采用了跳跃表等数据结构，在实现元素排序功能的同时，也保证了较好的查找和插入性能。

异步I/O机制：

- Redis采用了异步I/O机制来处理一些耗时的操作，比如数据持久化到磁盘（虽然数据主要存储在内存，但也会定期将数据持久化到磁盘以保证数据的安全性）。
- 在进行持久化操作时，Redis不会阻塞主线程的正常运行，而是通过异步方式在后台完成数据的写入磁盘工作，从而保证了对客户端请求的快速响应。

综上所述，Redis通过内存存储、高效的数据结构和算法、合适的架构以及异步I/O机制等多方面的因素，实现了快速的数据缓存和访问功能。

8、redis缓存淘汰机制是怎么样的？

Redis缓存淘汰机制用于在内存使用达到一定限制时，自动决定删除哪些键值对以释放空间，确保Redis能够持续稳定运行并有效利用内存资源。以下是Redis常见的缓存淘汰机制：

1. volatile-lru（Least Recently Used，最近最少使用）

原理：

- 针对设置了过期时间的键。它会根据键的最后一次访问时间来判断，将最近最少被使用的键优先淘汰。
- 也就是说，Redis会记录每个设置了过期时间的键的最后一次被访问时刻，当需要淘汰键时，就从这些设置过期时间的键当中找出最久未被使用的那个键并删除。

应用场景：

- 适用于缓存中既有带过期时间的热数据（经常被访问的数据），也有冷数据（很少被访问的数据）的情况。通过淘汰冷数据，保留热数据，来优化内存使用。例如在一个电商平台的商品缓存中，部分商品信息设置了过期时间，对于那些长时间未被访问的商品缓存信息，就可以采用volatile-lru机制进行淘汰。

2. volatile-ttl（Time To Live，存活时间）

原理：

- 同样是针对设置了过期时间的键。它会优先淘汰剩余存活时间最短的键。
- Redis会时刻关注设置了过期时间的键的剩余存活时间，当内存紧张需要淘汰键时，就选择剩余存活时间最短的那个键进行删除。

应用场景：

- 当希望尽快清除那些即将过期但又占用内存空间的键时比较适用。比如在一个限时促销活动的缓存场景中，活动相关的缓存信息设置了过期时间，随着活动接近尾声，那些剩余存活时间短的活动缓存就可以通过volatile-ttl机制优先被淘汰，以便为其他更重要的缓存腾出空间。

3. volatile-random（随机淘汰）

原理：

- 还是针对设置了过期时间的键。它会在设置了过期时间的键集合中随机选择一个键进行淘汰。
- 这种方式就是简单地在所有设置过期时间的键当中随机抽取一个来删除，没有特定的规律依据最后一次访问时间或者剩余存活时间等。

应用场景：

- 在对缓存淘汰的准确性要求不高，且希望以一种简单随机的方式来清理部分设置了过期时间的键占用的内存空间时可以使用。例如在一些简单的测试环境缓存设置中，不需要特别精准地控制淘汰哪些键，就可以采用volatile-random机制。

4. all-lru（Least Recently Used，最近最少使用）

原理：

- 不区分键是否设置了过期时间，会综合考虑所有键的最后一次访问时间，将整个Redis实例中最近最少被使用的键优先淘汰。
- 它把Redis中所有的键都纳入考察范围，通过记录每个键的最后一次访问情况，找出最久未被使用的键并删除，以释放内存空间。

应用场景：

- 适用于对整个Redis缓存空间进行统一管理，不希望因为键是否设置过期时间而区别对待淘汰策略的情况。比如在一个整体缓存性能优化项目中，希望以一种通用的方式来优化内存使用，就可以采用all-lru机制。

5. all-random（随机淘汰）

原理：

- 同样不区分键是否设置了过期时间，在整个Redis实例的所有键集合中随机选择一个键进行淘汰。
- 就是简单地从Redis的所有键当中随机抽取一个来删除，不考虑键的访问历史、存活时间等因素。

应用场景：

- 在对缓存淘汰策略的要求非常简单，只是想随机地清理掉一些键来腾出内存空间，且不关心具体淘汰哪个键对业务影响最小的情况下可以使用。例如在一些初步的缓存性能测试场景中，不需要精细的淘汰策略，就可以采用all-random机制。

6. noeviction（不淘汰）

原理：

- 当内存达到设置的限制时，Redis不会自动淘汰任何键，而是直接返回错误给客户端，告知内存不足无法执行相应操作。

应用场景：

- 适用于对数据完整性要求极高，不允许任何数据因为内存不足而被意外淘汰的情况。比如在一些关键业务数据的缓存场景中，数据的准确性和完整性至关重要，宁愿返回错误让业务流程暂停去处理内存问题，也不希望数据被错误淘汰。

Redis可以通过配置文件或者运行时命令来指定采用哪种缓存淘汰机制，以便根据具体的业务需求和内存管理要求来灵活运用。

8、redis的io多路复用是什么？

9、redis集群的数据一致性你是怎么解决的？

Redis的I/O多路复用（I/O Multiplexing）是一种高效的I/O处理机制，它在Redis实现高性能的网络通信和数据处理方面起到了关键作用。以下是关于Redis的I/O多路复用的详细介绍：

基本原理

在传统的网络编程模型中，当服务器要处理多个客户端的连接请求并进行数据交互时，常见的做法是为每个客户端连接创建一个单独的线程或者进程来负责处理该连接上的所有I/O操作（如读取客户端发送的数据、向客户端发送数据等）。这种方式在客户端数量较少时可能还能正常工作，但随着客户端数量的增加，会带来诸多问题：

- 资源消耗大：创建和维护大量的线程或进程需要耗费大量的系统资源（如内存、CPU时间等），很容易导致系统资源耗尽，影响服务器的整体性能。
- 上下文切换频繁：多个线程或进程之间频繁地进行上下文切换（即从一个线程或进程的执行状态切换到另一个线程或进程的执行状态），这也会消耗大量的CPU时间，降低数据处理效率。

而Redis采用的I/O多路复用机制则不同，它通过一个单独的线程（在Redis中被称为I/O复用线程）来同时监控多个客户端连接的I/O状态（主要是可读状态和可写状态），而不需要为每个客户端连接单独创建线程或进程来处理I/O。具体来说：

- 注册事件：当客户端与Redis服务器建立连接后，Redis会将该客户端连接对应的I/O事件（如可读事件，表示客户端有数据发送过来；可写事件，表示服务器可以向客户端发送数据）注册到一个特定的I/O多路复用器（如在Linux系统下常用的select、epoll等实现方式）中。
- 监控状态：I/O复用线程会持续监控这些注册在I/O多路复用器中的所有客户端连接的I/O状态。一旦某个客户端连接的I/O状态发生变化（比如从不可读变为可读，或者从不可写变为可写），I/O复用线程就能及时发现。
- 处理事件：当发现某个客户端连接的I/O状态发生变化后，I/O复用线程就会根据具体的事件类型（可读事件或可写事件）通知Redis服务器的相应业务逻辑处理模块来对该客户端连接进行相应的处理（如读取客户端发送的数据、向客户端发送数据等）。

常见实现方式

在不同的操作系统平台上，Redis的I/O多路复用有不同的实现方式：

- select：这是一种比较早期的I/O多路复用实现方式，它可以同时监控多个文件描述符（在网络编程中，客户端连接对应的就是文件描述符）的I/O状态。但是，select有一些局限性，比如它能监控的文件描述符数量有限（一般默认最多16个，虽然可以通过修改系统参数来增加，但增加的幅度也有限），而且在监控大量文件描述符时，其性能会随着文件描述符数量的增加而下降。
- epoll：这是Linux系统特有的一种更为先进的I/O多路复用实现方式。与select相比，epoll具有以下优点：

- - 无限制的监控数量：epoll可以监控的文件描述符数量理论上是无限制的（实际上受限于系统内存等因素），这使得它在处理大量客户端连接时表现得更为出色。
  - 高效的性能：epoll采用了事件驱动的机制，它只关注那些发生了I/O状态变化的文件描述符，而不像select那样需要对所有监控的文件描述符进行逐一检查，从而大大提高了监控和处理I/O事件的效率。

- kqueue：这是FreeBSD、Mac OS X等操作系统采用的一种I/O多路复用实现方式，其原理和性能特点与epoll类似，也是通过事件驱动的机制来高效地监控和处理I/O事件。

优势

资源节约：通过使用I/O多路复用机制，Redis只需要一个单独的I/O复用线程来监控多个客户端连接的I/O状态，而不需要为每个客户端连接创建单独的线程或进程，从而大大节约了系统资源（如内存、CPU时间等）。
高效处理：I/O多路复用机制能够快速地发现客户端连接的I/O状态变化，并及时通知相应的业务逻辑处理模块进行处理，从而提高了数据处理的效率，使得Redis能够在短时间内处理大量的客户端连接和数据交互。

综上所述，Redis的I/O多路复用机制是一种通过一个单独的线程来同时监控多个客户端连接的I/O状态，并根据状态变化及时通知相应业务逻辑处理模块进行处理的高效I/O处理机制，它为Redis实现高性能的网络通信和数据处理提供了重要保障。

10、布隆过滤器是你自己写的还是第三方，自己写的误差知道是多少吗？有考虑过吗。

我并没有实际去编写布隆过滤器哦，我是字节跳动开发的人工智能，主要职责是给你讲解相关知识、回答各类问题等。

布隆过滤器如果自行编写实现，其误差（误判率）是可以通过相关公式进行理论计算和考虑的。

布隆过滤器原理及误差相关情况

原理：

- 布隆过滤器是由一个位数组和多个哈希函数构成。当要插入一个元素时，会使用这些哈希函数分别对元素进行哈希运算，得到多个哈希值，然后将位数组中对应这些哈希值的位置都置为1。当判断一个元素是否存在时，同样用这些哈希函数对该元素进行哈希运算，若得到的所有哈希值对应的位数组位置都为1，则认为该元素可能存在（注意这里是可能，因为存在误判情况）；若有任何一个位置为0，则确定该元素不存在。

误差情况（误判率）：

- 误判率主要和两个因素有关：一是位数组的大小m，二是哈希函数的个数k。其理论误判率公式为：
  
  其中，P是误判率，n是要插入元素的预计数量，m是位数组的大小，k是哈希函数的个数。
- 从公式可以看出，在实际自行编写布隆过滤器时，如果要降低误判率，可以适当增大位数组的大小m，同时合理选择哈希函数的个数k。但增大位数组大小会增加内存占用，增加哈希函数个数可能会导致计算成本增加，所以需要在误判率、内存占用和计算成本之间进行权衡。

在实际应用中，很多编程语言也都提供了现成的布隆过滤器库，这些库通常在性能和误判率控制方面都经过了优化，可以方便地被开发者使用，而不需要自己从头去编写并精细考虑误差等诸多问题。

11、考虑过商品超卖问题的解决方式吗？

商品超卖问题是电商等涉及库存管理场景中常见的一个挑战，以下是一些常见的解决方式：

数据库层面

悲观锁：

- 原理：在操作库存数据前，先对库存记录进行加锁，例如使用数据库的行级锁。这样在同一时间只有一个事务能获取到锁并对库存进行操作，其他事务需要等待锁释放后才能进行，从而有效防止了超卖现象。
- 示例：假设在一个MySQL数据库环境下，当用户下单购买商品时，在更新库存的SQL语句中可以使用 FOR UPDATE 语句来实现行级锁。如：

BEGIN;
SELECT * FROM inventory WHERE product_id = '具体商品ID' FOR UPDATE;
-- 这里进行库存判断，如果库存大于等于购买数量则更新库存
UPDATE inventory SET stock = stock - 购买数量 WHERE product_id = '具体商品ID';
COMMIT;

- **优缺点**：
    - **优点**：能非常可靠地防止超卖，保证数据的准确性。
    - **缺点**：加锁会导致并发性能下降，因为其他事务需要等待锁释放，在高并发场景下可能会造成系统响应变慢。

乐观锁：

- 原理：假设数据在并发操作过程中不会被其他事务修改，在更新库存时，先检查库存数据的版本号（或其他可用于标识数据更新情况的字段，如时间戳等）是否与自己最初读取时一致。如果一致，则说明数据未被其他事务修改过，可以正常更新库存并同时更新版本号；如果不一致，则说明数据已被其他事务修改过，此时需要根据业务逻辑决定是重试操作还是返回错误信息等。
- 示例：以版本号为例，库存表中除了有库存数量字段外，还有一个版本号字段。当用户下单时：

-- 首先读取库存及版本号
SELECT stock, version FROM inventory WHERE product_id = '具体商品ID';
-- 假设读取到的库存为stock_value，版本号为version_value
-- 然后在更新库存时进行版本号校验
UPDATE inventory SET stock = stock - 购买数量, version = version + 1 WHERE product_id = '具体商品ID' AND version = version_value;

- **优缺点**：
    - **优点**：在并发性能上相对悲观锁有优势，因为不需要长时间等待锁释放，大部分情况下可以直接进行操作，只有在数据被修改时才可能需要重试等处理。
    - **缺点**：如果并发冲突频繁，可能会导致较多的重试操作，增加系统开销，并且在某些极端情况下可能还是无法完全避免超卖（虽然概率较低）。

缓存层面

基于Redis：

- 库存预热：在系统启动或商品上架时，将库存数据缓存到Redis中。可以使用Redis的数据结构如哈希（Hash）来存储商品的库存信息，例如以商品ID为键，哈希内部存储库存数量、是否可售等信息。
- 分布式锁：当用户下单时，先在Redis中获取对应商品的分布式锁。只有获取到锁的用户才能对库存进行操作。可以使用Redis的SETNX（SET if Not eXists）命令来实现，例如：

import redis

r = redis.Redis()
lock_key = f"product_{具体商品ID}_lock"
while True:
    if r.setnx(lock_key, 1):
        r.expire(lock_key, 10)  # 设置锁的有效期为10秒
        try:
            # 在这里进行库存操作，如从Redis哈希结构中获取库存并更新
            stock_info = r.hgetall(f"product_{具体商品ID}")
            stock = int(stock_info[b'stock'])
            if stock >= 购买数量:
                r.hset(f"product_{具体商品ID}", "stock", stock - 购买数量)
                break
            else:
                print("库存不足")
        finally:
            r.delete(lock_key)  # 操作完成后删除锁
    else:
        time.sleep(0.1)  # 如果没获取到锁，等待0.1秒后重试

- **Lua脚本**：将库存判断和更新操作封装在一个Lua脚本中，提交给Redis执行。这样可以保证操作的原子性，即在Redis执行脚本过程中，不会被其他操作打断。例如：

-- 定义Lua脚本
local stock_key = KEYS[1]
local buy_amount = tonumber(ARGV[1])
local stock = tonumber(redis.call('hget', stock_key, 'stock'))
if stock >= buy_amount then
    redis.call('hset', stock_key, 'stock', stock - buy_amount)
    return 1
else
    return 0

- **优缺点**：
    - **优点**：Redis本身具有高性能、高并发的特点，通过上述方式可以在缓存层面有效地处理库存问题，提高系统的响应速度和并发处理能力。
    - **缺点**：需要额外考虑缓存与数据库的一致性问题，因为库存数据在缓存和数据库中都存在，当库存在缓存中更新后，还需要及时同步到数据库中，否则可能会出现数据不一致的情况。

队列层面

消息队列：当用户下单时，将订单信息放入消息队列（如RabbitMQ、Kafka等），而不是直接处理库存更新。然后由专门的消费者从消息队列中取出订单信息，按照一定的顺序依次处理库存更新操作。这样可以将并发的库存更新请求变成串行的处理方式，有效避免了超卖现象。

- 示例：以RabbitMQ为例，在用户下单时：

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='order_queue')

# 将订单信息发送到消息队列
order_info = {'product_id': '具体商品ID', 'buy_amount': 购买数量}
channel.send_to_queue('order_queue', json.dumps(order_info).encode('utf-8'))

connection.close()

然后在消费者端：

import pika
import json

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='order_queue')

def callback(ch, method, body):
    order_info = json.loads(body.decode('utf-8'))
    product_id = order_info['product_id']
    buy_amount = order_info['buy_amount']
    # 在这里进行库存操作，如从数据库或缓存中获取库存并更新
    # 假设从数据库获取库存并更新
    BEGIN;
    SELECT * FROM inventory WHERE product_id = product_id FOR UPDATE;
    UPDATE inventory SET stock = stock - buy_amount WHERE product_id = product_id;
    COMMIT;

channel.basic_consume(queue='order_queue', on_call_back=callback)
channel.start_consuming()

- **优缺点**：
    - **优点**：可以将高并发的库存更新请求进行有序处理，避免了超卖，同时也便于进行一些后续的业务处理，如订单的统计、发货等操作可以在消费者端统一进行。
    - **缺点**：增加了系统的复杂性，因为引入了消息队列，需要对其进行维护和管理，并且处理速度可能会相对较慢，因为订单信息需要在消息队列中排队等待处理。

这些解决方式各有优缺点，在实际应用中往往需要根据具体的业务场景、并发程度、系统性能要求等因素综合考虑并选择合适的方案来解决商品超卖问题。

12、讲讲乐观锁。

乐观锁是一种并发控制机制，常用于数据库管理和多线程编程等场景，以实现对共享资源的合理访问和数据的一致性维护。以下是关于乐观锁的详细介绍：

基本原理

乐观锁基于一个乐观的假设：在并发操作期间，认为数据被其他事务修改的概率相对较低。所以它不会像悲观锁那样在操作数据之前就对数据进行加锁限制其他事务的访问。
而是在更新数据时，先检查数据的某些特定属性（如版本号、时间戳等）是否与自己最初读取时一致。如果这些属性一致，就说明数据在自己读取之后到准备更新之前这段时间内没有被其他事务修改过，此时便可以正常进行数据更新操作；如果这些属性不一致，那就意味着数据已经被其他事务修改过了，这时就需要根据具体的业务逻辑来决定后续的处理方式，比如重试操作、返回错误信息告知用户数据已更新等。

常见实现方式

基于版本号的乐观锁：

- 在数据表中额外添加一个版本号字段（通常命名为version之类的）。当一个事务要对某条记录进行操作时，首先读取该记录，同时获取到当前的版本号。
- 例如，在一个电商库存管理的场景中，库存表中有商品ID、库存数量、版本号三个字段。当用户下单准备更新库存时：

- - 先执行查询语句读取库存数量以及对应的版本号：

SELECT stock, version FROM inventory WHERE product_id = '具体商品ID';

    - 假设读取到的库存为stock_value，版本号为version_value。然后在更新库存时，会在更新语句中加入版本号的校验条件：

UPDATE inventory SET stock = stock - 购买数量, version = version + 1 WHERE product_id = '具体商品ID' AND version = version_value;

    - 如果更新语句成功执行，说明在读取数据到更新数据这段时间内，库存数据没有被其他事务修改过，库存更新成功且版本号也相应更新了；如果更新语句执行失败，因为版本号校验不通过，就说明库存数据已经被其他事务修改过了，此时可能需要根据业务逻辑决定是重试操作（比如重新读取最新数据并再次尝试更新）还是返回错误信息给用户（比如告知用户库存不足等情况）。

基于时间戳的乐观锁：

- 类似基于版本号的乐观锁，只是这里使用记录的创建时间或最后修改时间（即时间戳）来作为判断数据是否被修改的依据。
- 例如，在一个文档编辑系统中，文档表中有文档ID、文档内容、最后修改时间等字段。当多个用户同时编辑一篇文档时：

- - 一个用户先读取文档内容以及对应的最后修改时间：

SELECT content, last_modified_time FROM document WHERE document_id = '具体文档ID';

    - 假设读取到的文档内容为content_value，最后修改时间为last_modified_time_value。然后在更新文档内容时，会在更新语句中加入时间戳的校验条件：

UPDATE document SET content = content + '新添加的内容', last_modified_time = CURRENT_TIMESTAMP WHERE document_id = '具体文档ID' AND last_modified_time = last_modified_time_value;

    - 如果更新语句成功执行，说明在读取数据到更新数据这段时间内，文档内容没有被其他事务修改过，文档内容更新成功且最后修改时间也相应更新了；如果更新语句执行失败，因为时间戳校验不通过，就说明文档内容已经被其他事务修改过了，此时可能需要根据业务逻辑决定是重试操作（比如重新读取最新数据并再次尝试更新）还是返回错误信息给用户（比如告知用户文档已被其他修改等情况）。

优缺点

优点：

- 高并发性能较好：由于不需要在操作数据之前加锁，所以在并发场景下，大部分事务可以直接进行操作，只有当数据被其他事务修改时才可能需要进行重试等处理，相比悲观锁，不会因为长时间等待锁释放而导致系统响应变慢，能更好地适应高并发环境。
- 死锁风险低：因为不存在对数据的预先加锁，所以不会出现像悲观锁那样因为多个事务互相等待对方释放锁而导致的死锁情况。

缺点：

- 可能存在多次重试：如果并发冲突比较频繁，即数据被其他事务修改的情况经常发生，那么可能会导致事务需要多次重试操作，这会增加系统的开销，包括额外的数据库查询、网络传输等成本。
- 无法完全避免数据不一致：虽然乐观锁通过版本号或时间戳等方式尽量保证数据的一致性，但在某些极端情况下，比如在非常短的时间内多个事务同时修改数据且都通过了版本号或时间戳的校验（虽然这种情况概率较低），还是可能会出现数据不一致的情况。

乐观锁在很多需要处理并发操作的场景中都有广泛应用，通过合理利用其特性并结合具体业务逻辑，可以有效地维护数据的一致性和提高系统的并发处理能力。

13、乐观锁是sql实现还是逻辑实现？

乐观锁既可以通过SQL语句来实现，也可以在应用程序的逻辑层面进行实现，以下是具体说明：

SQL实现方式

基于版本号的SQL实现：

- 这种方式是在数据库表中添加一个专门用于记录版本信息的字段（通常命名为“version”等）。
- 例如，有一个“products”表用于存储商品信息，其中包含“product_id”（商品ID）、“stock”（库存数量）和“version”（版本号）三个字段。
- 当要对商品库存进行更新操作（比如用户下单购买商品）时，首先通过一条SQL语句读取商品的库存数量以及当前的版本号：

SELECT stock, version FROM products WHERE product_id = '具体商品ID';

- 假设读取到的库存为“stock_value”，版本号为“version_value”。然后在更新库存的SQL语句中，会加入版本号的校验条件，确保在读取数据到更新数据这段时间内，商品的库存数据没有被其他事务修改过：

UPDATE products SET stock = stock - 购买数量, version = version + 1 WHERE product_id = '具体商品ID' AND version = version_value;

- 如果这条更新语句成功执行，说明库存数据在读取之后到更新之前没有被其他事务修改过，库存更新成功且版本号也相应更新了；如果更新语句执行失败，由于版本号校验不通过，就说明库存数据已经被其他事务修改过了，此时可能需要根据业务逻辑决定是重试操作（比如重新读取最新数据并再次尝试更新）还是返回错误信息给用户（比如告知用户库存不足等情况）。

基于时间戳的SQL实现：

- 与基于版本号的实现类似，不过这里是利用数据库表中记录的创建时间或最后修改时间（即时间戳）作为判断数据是否被修改的依据。
- 例如，在一个“documents”表用于存储文档信息，其中包含“document_id”（文档ID）、“content”（文档内容）和“last_modified_time”（最后修改时间）三个字段。
- 当多个用户同时编辑一篇文档时，一个用户先通过如下SQL语句读取文档内容以及对应的最后修改时间：

SELECT content, last_modified_time FROM documents WHERE document_id = '具体文档ID';

- 假设读取到的文档内容为“content_value”，最后修改时间为“last_modified_time_value”。然后在更新文档内容的SQL语句中，会加入时间戳的校验条件：

UPDATE documents SET content = content + '新添加的内容', last_modified_time = CURRENT_TIMESTAMP WHERE document_id = '具体文档ID' AND last_modified_time = last_modified_time_value;

- 如果更新语句成功执行，说明在读取数据到更新数据这段时间内，文档内容没有被其他事务修改过，文档内容更新而最后修改时间也相应更新了；如果更新语句执行失败，由于时间戳校验不通过，就说明文档内容已经被其他事务修改过了，此时可能需要根据业务逻辑决定是重试操作（比如重新读取最新数据并再次尝试《尝试重新读取最新数据并再次尝试更新》）还是返回错误信息给用户（比如告知用户文档已被其他修改等情况）。

逻辑实现方式

在应用程序的逻辑层面实现乐观锁，通常是在代码中模拟出类似SQL实现中基于版本号或时间戳的校验机制。
以基于版本号为例，假设在一个Java应用程序中，有一个“Product”类用于表示商品，其中包含“productId”（商品ID）、“stock”（库存数量）和“version”（版本号）等属性。
当用户下单购买商品时：

- 首先在代码中通过调用数据库访问层的方法来读取商品的库存数量和版本号，比如：

Product product = productDao.readProductById(productId);
int stock = product.getStock();
int version = product.getVersion();

- 然后在更新库存的代码逻辑中，会进行版本号的校验，类似SQL实现中的做法：

if (productDao.updateProductStock(productId, stock - 购买数量, version + 1, version) == 1) {
    // 库存更新成功
} else {
    // 库存更新失败，可能需要根据业务逻辑决定是重试操作还是返回错误信息给用户
}

- 这里的“productDao.updateProductStock”方法内部会执行类似下面的SQL语句来更新库存并校验版本号：

UPDATE products SET stock = stock - 购买数量, version = version + 1 WHERE product_id = '具体商品ID' AND version = version;

同样，对于基于时间戳的逻辑实现，也是在代码中模拟出基于时间戳的校验机制，通过在代码中获取和处理数据的创建时间或最后修改时间等属性来实现。

综上所述，乐观锁既可以通过SQL语句在数据库层面直接实现，也可以在应用程序的逻辑层面通过代码来模拟实现，具体采用哪种方式取决于具体的业务需求、开发团队的习惯以及系统的整体架构等因素。

14、ThreadLocal你为什么要用这个？

以下是一些使用ThreadLocal的常见原因：

1. 实现线程范围内的数据隔离

在多线程环境下，不同线程可能需要访问和处理一些特定的数据，但又不希望这些数据在不同线程之间相互干扰。ThreadLocal就提供了这样一种机制，使得每个线程都能拥有一份独立的数据副本。
例如，在一个Web应用程序中，可能有多个线程同时处理不同用户的请求。每个请求可能都需要记录一些特定于该请求的上下文信息，比如当前用户的ID、请求的开始时间等。通过使用ThreadLocal，就可以为每个线程（也就是每个用户请求对应的线程）单独设置和获取这些上下文信息，确保不同线程之间的数据不会混淆。

2. 避免线程安全问题

当多个线程共享访问某些数据时，如果处理不当，很容易引发线程安全问题，比如数据不一致、并发冲突等。而如果将某些数据设置为通过ThreadLocal在每个线程内独立存在，那么就不需要担心多个线程同时修改同一份数据而导致的这些问题。
比如，有一个简单的计数器类，多个线程可能会同时对其进行递增操作。如果直接共享这个计数器对象，就需要采取额外的线程安全措施（如加锁等）来保证数据的正确更新。但如果使用ThreadLocal为每个线程创建一个独立的计数器副本，那么每个线程就可以在自己的副本上进行递增操作，无需考虑其他线程的影响，从而避免了线程安全问题。

3. 方便传递特定于线程的参数

在一些复杂的程序逻辑中，可能需要在一个线程的不同方法之间传递某些特定于该线程的参数。使用ThreadLocal可以很方便地实现这一点。
假设在一个数据库访问的场景中，需要在多个与数据库操作相关的方法中使用当前线程对应的数据库连接。可以将数据库连接对象通过ThreadLocal设置在每个线程内，这样在该线程执行的任何与数据库操作相关的方法中，都可以直接从ThreadLocal中获取到这个特定于线程的数据库连接，而不需要在每个方法之间显式地传递这个参数，简化了代码的实现和维护。

4. 提高性能

在某些情况下，相比于采取其他线程安全措施（如加锁等）来处理多线程共享数据的情况，使用ThreadLocal可以提高性能。
因为加锁操作会带来一定的开销，包括线程的等待时间、上下文切换等成本。而使用ThreadLocal，每个线程可以独立地处理自己的数据，无需进行加锁和解锁操作，从而减少了这些额外的开销，使得程序在多线程环境下能够更高效地运行。

总之，使用ThreadLocal主要是为了在多线程环境中实现数据隔离、避免线程安全问题、方便传递特定于线程的参数以及提高性能等目的。

15、你们公司之前用这个出现过脏读问题，你变量是怎么清除。

16、讲讲 ThreadLocal的底层原理。

ThreadLocal是Java中的一个类，用于实现线程局部变量，让每个线程都可以拥有一个独立于其他线程的变量副本，其底层原理主要涉及以下几个方面：

数据结构

ThreadLocal内部维护了一个静态的内部类ThreadLocalMap，它是一个类似于哈希表的结构，用于存储每个线程与对应变量值的映射关系。
ThreadLocalMap的底层实现类似于Java中的HashMap，但也有一些区别。它使用了一种自定义的散列算法，并且在处理哈希冲突时采用了开放定址法（Open Addressing）中的线性探测法（Linear Probing），而不是像HashMap那样使用链表法（Linked List）或红黑树法（Red Black Tree）来处理哈希冲突。

与线程的关联

在Java中，每个线程对象内部都有一个成员变量threadLocals，它的类型就是ThreadLocalMap。当在一个线程中创建并使用一个ThreadLocal变量时，实际上是将该ThreadLocal变量对应的键值对（键为该ThreadLocal实例本身，值为要存储的变量值）存储到了该线程内部的threadLocals这个ThreadLocalMap中。
也就是说，不同线程的threadLocals成员变量是相互独立的，各自存储着本线程所使用的ThreadLocal变量及其对应的值，从而实现了线程之间的数据隔离。

设置变量值的过程

当调用一个ThreadLocal实例的set方法来设置变量值时，比如：

ThreadLocal<Integer> threadLocal = new ThreadLocal<>();
threadLocal.set(10);

首先，它会获取当前线程对象，通过 Thread.currentThread() 方法可以得到当前线程。
然后，获取当前线程内部的threadLocals成员变量（即ThreadLocalMap）。如果这个threadLocals为空，即当前线程还没有使用过任何ThreadLocal变量，那么会先创建一个新的ThreadLocalMap并赋值给threadLocals。
接着，将当前ThreadLocal实例作为键，要设置的变量值作为值，通过调用threadLocals（即ThreadLocalMap）的put方法将键值对存入其中。在put方法中，会根据键（ThreadLocal实例）进行哈希计算，以确定在ThreadLocalMap中的存储位置。如果发生哈希冲突，就按照线性探测法依次寻找下一个可用的存储位置，直到找到合适的位置将键值对存入。

获取变量值的过程

当调用一个ThreadLocal实例的get方法来获取变量值时，例如：

ThreadLocal<Integer> threadLocal = new ThreadLocal<>();
threadLocal.set(10);
int value = threadLocal.get();

同样先获取当前线程对象，再获取当前线程内部的threadLocals成员变量（即ThreadLocalMap）。
如果threadLocals不为空，就以当前ThreadLocal实例作为键，通过调用threadLocals（即ThreadLocalMap）的getEntry方法来查找对应的键值对。在getEntry方法中，根据键进行哈希计算，找到对应的存储位置，然后判断该位置上的键是否与要查找的键（当前ThreadLocal实例）一致，如果一致则返回对应的值；如果不一致，且存在哈希冲突，就按照线性探测法依次检查相邻的存储位置，直到找到匹配的键值对或者确定不存在匹配的键值对为止。
如果threadLocals为空，或者在查找过程中没有找到匹配的键值对，那么会返回null（或者根据具体情况执行一些默认的初始化操作，比如在使用ThreadLocal时设置了初始值，那么会返回初始值）。

内存管理与清除机制

ThreadLocalMap中的键值对并不会一直存在，为了避免内存泄漏等问题，需要对其进行合理的内存管理和清除。
当一个线程结束时，它内部的threadLocals成员变量（即ThreadLocalMap）所占用的内存会随着线程的结束而自动释放，因为线程对象本身的生命周期结束了。
然而，在一些特殊情况下，比如在使用线程池的情况下，线程是可重复使用的，那么在每次使用完一个ThreadLocal变量后，就需要手动清除它，以防止下一次使用该线程时出现数据混乱等问题。这通常通过调用ThreadLocal实例的remove方法来实现，当调用remove方法时，会以当前ThreadLocal实例作为键，在当前线程内部的threadLocals（即ThreadLocalMap）中找到对应的键值对并删除，从而保证了内存的清洁和数据的准确。

综上所述，ThreadLocal通过在每个线程内部设置独立的ThreadLocalMap来存储与本线程相关的变量值，利用自定义的散列算法和线性探测法处理哈希冲突，以及合理的内存管理和清除机制，实现了线程局部变量的功能，使得每个线程都能拥有独立于其他线程的变量副本。

17、浮点数精度丢失问题考虑过吗？

浮点数精度丢失问题是在计算机编程和数据处理领域经常会遇到的情况，以下是关于这个问题的详细分析以及一些常见的应对考虑：

问题产生原因

二进制表示与有限精度：计算机中的浮点数采用二进制的科学计数法来表示。例如，对于单精度浮点数（32位）和双精度浮点数（64位），它们的二进制格式分别被划分为符号位、指数位和尾数位等几个部分。然而，由于二进制能够精确表示的十进制数是有限的，很多十进制的小数在转换为二进制小数时，可能会变成无限循环小数。但计算机存储浮点数的位数是有限的，所以只能对这些无限循环二进制小数进行近似截断处理，这就导致了精度的丢失。
运算过程中的舍入误差：在进行浮点数的运算时，如加法、减法、乘法、除法等，也会因为舍入规则而产生精度丢失问题。例如，在进行加法运算时，两个浮点数的指数可能不同，需要先对它们进行对齐操作（使指数相同），然后再相加。在这个对齐和相加的过程中，就可能会因为舍入规则（如四舍五入、向零舍入等）而导致最终结果与实际的精确结果存在偏差。

常见影响场景

金融领域：在涉及金额计算、利率计算、财务报表等方面，浮点数精度丢失可能会导致严重的后果。比如在计算一笔贷款的利息时，如果因为精度丢失使得计算出的利息金额不准确，可能会影响到借贷双方的利益。
科学计算领域：在物理、化学、数学等学科的数值计算中，精度丢失可能会使实验结果或理论计算结果出现偏差，影响对科学现象的准确理解和研究。例如在进行一些高精度的物理模拟计算时，浮点数精度丢失可能会导致模拟结果与实际情况不符。

应对措施

使用高精度数据类型：

- 在一些编程语言中，提供了比普通浮点数精度更高的数据类型。例如，在Java中，除了常规的float（单精度浮点数）和double（双精度浮点数）外，还有BigDecimal类。BigDecimal可以精确地表示和处理十进制数，它通过将数字以字符串的形式存储，并按照特定的算法进行运算，从而避免了因为二进制表示和舍入误差导致的精度丢失问题。在需要高精度计算的场景下，如金融领域的金额计算，可以使用BigDecimal来代替普通的浮点数进行运算。例如：

import java.math.BigDecimal;

public class BigDecimalExample {
    public static void main(String[] args) {
        BigDecimal num1 = new BigDecimal("1.23456789");
        BigDecimal num2 = new BigDecimal("9.87654321");
        BigDecimal result = num1.add(num2);
        System.out.println(result);
    }
}

合理设置舍入模式：

- 对于一些编程语言中允许设置舍入模式的情况，可以根据具体的需求选择合适的舍入模式来尽量减少精度丢失的影响。例如，在Java的BigDecimal类中，可以设置不同的舍入模式，如ROUND_HALF_UP（四舍五入）、ROUND_HALF_DOWN（五舍六入）、ROUND_UP（向上舍入）、ROUND_DOWN（向下舍入）等。在某些场景下，根据业务需求合理选择舍入模式可以使计算结果更符合实际情况。例如，在计算商品总价时，如果希望对小数部分进行四舍五入处理，可以设置为ROUND_HALF_UP舍入模式：

import java.math.BigDecimal;
import java.math.RoundingMode;

public class RoundingExample {
    public static void main(String[] args) {
        BigDecimal num1 = new BigDecimal("1.2345");
        BigDecimal num2 = new BigDecimal("2.3456");
        BigDecimal sum = num1.add(num2);
        sum = sum.setRoundingMode(RoundingMode.ROUND_HALF_UP);
        System.out.println(sum);
    }
}

避免不必要的浮点数运算：

- 在一些情况下，可以通过调整算法或者数据处理方式来避免不必要的浮点数运算，从而减少精度丢失的可能性。例如，在一些简单的比例计算中，如果可以通过整数运算来实现相同的目的，就优先选择整数运算。假设要计算一个班级中男生占总人数的比例，总人数为100人，男生人数为40人，原本可以用浮点数运算来计算比例（40.0 / 100.0），但也可以通过整数运算（40 / 100）得到相同的结果（0.4），这样就避免了浮点数运算带来的精度丢失问题。

浮点数精度丢失问题在很多领域都有着重要影响，通过上述应对措施可以在一定程度上缓解这个问题，确保计算结果的准确性和可靠性。

19、如何解决精度丢失问题？

以下是一些解决浮点数精度丢失问题的常见方法：

1. 使用高精度数据类型

BigDecimal（Java）：

- 在Java中，BigDecimal类可用于精确表示和处理十进制数，有效避免因二进制表示和舍入误差导致的精度丢失。它将数字以字符串形式存储，并依据特定算法进行运算。
- 示例：

import java.math.BigDecimal;

public class BigDecimalExample {
    public static void main(String[] args) {
        BigDecimal num1 = new BigDecimal("1.23456789");
        BigDecimal num2 = new BigDecimal("9.87654321");
        BigDecimal result = num1.add(num2);
        System.out.println(result);
    }
}

decimal（Python）：

- 在Python中，decimal模块提供了Decimal类，其功能类似Java中的BigDecimal，能精确处理十进制数，避免精度丢失。
- 示例：

from decimal import Decimal

num1 = Decimal('1.23456789')
num2 = Decimal('9.87654321')
result = num1 + num2
print(result)

2. 合理设置舍入模式

Java中的BigDecimal：

- 在Java的BigDecimal类中，可以设置不同的舍入模式来尽量减少精度丢失影响。常见舍入模式有ROUND_HALF_UP（四舍五入）、ROUND_HALF_DOWN（五舍六入）、ROUND_UP（向上舍入）、ROUND_DOWN（向下舍入）等。
- 示例：

import java.math.BigDecimal;
import java.math.RoundingMode;

public class RoundingExample {
    public static void main(String[] args) {
        BigDecimal num1 = new BigDecimal("1.2345");
        BigDecimal num2 = new BigDecimal("2.3456");
        BigDecimal sum = num1.add(num2);
        sum = sum.setRoundingMode(RoundingMode.ROUND_HALF_UP);
        System.out.println(sum);
    }
}

3. 避免不必要的浮点数运算

通过调整算法或数据处理方式，优先选择整数运算来实现相同目的，从而减少精度丢失可能性。
例如，计算一个班级中男生占总人数的比例，总人数为100人，男生人数为40人。

- 原本用浮点数运算：40.0 / 100.0 = 0.4
- 可改用整数运算：40 / 100 = 0.4
- 这样就避免了浮点数运算带来的精度丢失问题。

4. 以整数形式存储和运算（在适用场景下）

在一些场景中，如果数据可以以整数形式进行存储和运算，且后续能通过一定方式还原出实际所需的数值表现形式，那么可以采用这种方式来避免精度丢失。
比如在处理货币金额时，将金额以分为单位存储（假设货币是元），即把1.23元存储为123分，在进行计算时都是以整数分进行运算，最后再将结果转换回以元为单位的形式展示给用户。

5. 进行多次运算时注意中间结果的精度保持

在进行一系列复杂的浮点数运算时，要特别注意中间结果的精度保持。比如在计算一个复杂的数学公式，涉及多个浮点数的加、减、乘、除等运算。
可以采用上述提到的高精度数据类型来确保每个中间结果的精度，避免因为中间结果的精度丢失而导致最终结果出现较大偏差。

通过综合运用这些方法，可以在很大程度上解决浮点数精度丢失问题，确保计算结果的准确性和可靠性。

20、jwt验证流程

JWT（JSON Web Token）是一种开放标准（RFC 7519），用于在各方之间安全地传输信息，通常用于身份验证和授权。以下是JWT验证流程的详细介绍：

生成JWT

在介绍验证流程之前，先简要了解下JWT的生成过程，因为它与验证流程紧密相关。
步骤一：定义负载（Payload）

- 负载是JWT中包含的实际信息部分，它是一个JSON对象，可以包含用户的一些标识信息，如用户ID、用户名、角色等，以及其他一些自定义的信息，比如过期时间（exp）、签发时间（iat）等。
- 例如：

{
    "sub": "123456",
    "name": "John Doe",
    "roles": ["user", "admin"],
    "exp": 1690527600,
    "iat": 1690527000
}

- 这里的“sub”表示主题（通常是用户ID），“name”是用户名，“roles”是用户的角色，“exp”是过期时间的时间戳，“iat”是签发时间的时间戳。

步骤二：选择签名算法并生成签名

- 常用的签名算法有HS256（基于HMAC-SHA256）、RS256（基于RSA-SHA256）等。
- 以HS256为例，首先需要有一个密钥（Secret Key），这个密钥只有签发JWT的一方（如服务器端）知道。
- 然后将负载信息进行Base64编码，得到编码后的负载部分（通常称为Payload Base64）。
- 接着使用选定的签名算法和密钥，对编码后的负载以及头部信息（Header，通常包含签名算法等元信息，也进行Base64编码）进行签名操作，得到签名部分（Signature）。

步骤三：组合成JWT

- 将Base64编码后的头部（Header Base64）、Base64编码后的负载（Payload Base64）和签名部分（Signature）按照“.”的顺序连接起来，就形成了一个完整的JWT，例如：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTYiLCJuYW1lIjoiSm9obmQgRG9lIiwicm9sZXMiO

- 这里“eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9”是头部Base64编码部分，“eyJzdWIiOiIxMjM0NTYiLCJuYW1lIjoiSm9obmQgRG9lIiwicm9sZXMiO”是负载Base64编码部分，后面省略的部分是签名部分。

JWT验证流程

步骤一：获取JWT

- 客户端在向服务器发送请求时，会将JWT包含在请求中，通常是放在请求头（如Authorization头，格式一般为“Bearer ”）中，服务器首先要做的就是从请求中获取到这个JWT。

步骤二：拆分JWT

- 服务器获取到JWT后，会按照“.”的顺序将其拆分成三个部分：头部Base64编码部分（Header Base64）、负载Base64编码部分（Payload Base64）和签名部分（Signature）。

步骤三：解码头部和负载

- 对头部Base64编码部分和负载Base64编码部分分别进行Base64解码，得到头部信息（Header）和负载信息（Payload）。
- 检查头部信息中的签名算法是否是服务器支持的算法，如果不是，则验证失败。

步骤四：验证签名

- 根据头部信息中指定的签名算法，重新生成签名。
- 以HS256为例，如果头部信息指定的签名算法是HS256，那么服务器会使用自己保存的密钥（与签发JWT时使用的密钥相同），对解码后的头部信息和负载信息进行Base64编码，然后按照HS256的签名算法进行签名操作，得到一个新的签名。
- 将重新生成的签名与从JWT中拆分出来的签名部分进行比较，如果两者一致，则说明签名是有效的，否则验证失败。

步骤五：检查负载信息

- 对负载信息中的各项内容进行检查，比如查看用户ID是否存在、角色是否符合要求、过期时间是否已经超过等。
- 如果负载信息中的任何一项不符合要求，比如过期时间已经超过，那么验证失败。

如果经过上述所有步骤，JWT都通过了验证，那么服务器就可以认为客户端发送的请求是合法的，并且可以根据负载信息中的用户ID、角色等内容来进行后续的授权等操作。

21、jwt的参数是什么样的，有什么意义

22、密文密码能被存入负载中吗？为什么？

一般情况下，密文密码不应该被存入JWT（JSON Web Token）的负载中，以下是详细原因：

安全风险方面

密钥泄露风险：即使密码是以密文形式存在，但如果将其放入JWT负载中，那么在JWT的整个生命周期内（包括在网络传输过程中、在客户端和服务器端存储及处理等环节），密码密文就多了很多暴露的机会。一旦JWT的相关加密机制（如签名算法对应的密钥等）出现漏洞被破解，或者JWT本身被恶意获取并通过某种方式解密（虽然难度较大，但并非完全不可能），那么密文密码就有可能被还原出明文，从而导致用户密码泄露，带来严重的安全隐患。
增加攻击面：将密文密码放入负载中，会使得JWT成为一个更具吸引力的攻击目标。攻击者可能会集中精力尝试破解JWT以获取其中的密文密码，进而尝试破解密码密文获取明文。相比于不存放密码密文，这种做法无疑增加了系统遭受攻击的可能性和风险程度。

功能实现角度

身份验证机制冲突：JWT本身主要用于身份验证和授权，其验证流程是基于负载中的一些标识信息（如用户ID、角色等）以及签名的有效性来判断请求的合法性。在通常的身份验证场景中，用户在登录时提交密码（一般是明文形式，不过现在更多是通过哈希等方式处理后提交），服务器端对密码进行验证后，会生成一个包含用户相关标识信息的JWT返回给客户端，后续客户端凭借这个JWT来证明自己的身份。如果在这个JWT中再放入密文密码，就会与这种常规的身份验证机制产生冲突，使得整个身份验证和授权流程变得混乱且不合理。
授权逻辑复杂化：当涉及到授权操作时，服务器通常是根据JWT负载中的用户ID、角色等信息来判断客户端是否有相应的权限。如果加入了密文密码，在进行授权判断时，还需要额外考虑密码相关的因素，这会使授权逻辑变得复杂且难以维护，增加了系统开发和运维的难度。

合规性方面

在很多行业的安全规范和标准中，都明确规定不允许将密码以任何形式（包括密文）存储在类似JWT这样的可传输且可能被多方获取的介质中。例如在金融行业、医疗行业等对数据安全要求极高的行业，遵循相关合规性要求是非常重要的，将密文密码存入JWT负载显然不符合这些要求。

综上所述，出于安全风险、功能实现以及合规性等多方面的考虑，密文密码不应该被存入JWT的负载中。

23、payload中的信息会被解密吗？

JWT（JSON Web Token）中Payload（负载）里的信息本身是经过一定处理的，但严格意义上来说不是传统的“解密”操作，以下是具体情况：

生成过程中的处理

在生成JWT时，Payload部分首先是被构建成一个JSON对象，其中包含了如用户ID、用户名、角色、过期时间、签发时间等各种信息。
然后这个JSON对象会进行Base64编码操作。Base64编码并不是一种加密方式，它只是一种将二进制数据转换为可打印字符的编码格式，目的是为了能方便地在网络等环境中传输数据，并且保证数据的完整性（不会因为字符集等问题导致数据丢失或变形）。

验证过程中的操作

当服务器收到包含JWT的请求并进行验证时，会对JWT按“.”拆分出Payload的Base64编码部分，然后进行Base64解码操作，将其还原成原本的JSON对象形式。
这个过程只是把之前为了传输方便而进行编码的信息还原回来，以便能查看和检查其中的各项内容，比如查看用户ID是否存在、角色是否符合要求、过期时间是否已经超过等，并不是真正意义上对加密信息进行解密的操作。

所以，Payload中的信息在正常的JWT使用流程中主要是经历Base64编码和解码的过程，而不是被加密然后再解密的过程，不过其内容在传输和存储过程中是基于JWT整体的安全性机制（如签名等）来保障其保密性、完整性和可用性的。

24、反向代理和正向代理的区别

反向代理和正向代理是网络代理中的两种不同类型，它们在功能、服务对象、部署位置等方面存在明显区别，以下是详细介绍：

服务对象

正向代理：主要服务于客户端。它是客户端为了访问某些被限制访问的资源，或者为了隐藏自身真实IP地址、提高访问速度等目的而设置的代理服务器。例如，在一个企业内部网络中，员工想要访问外部被封锁的网站，就可以通过企业设置的正向代理服务器来实现访问；或者当用户担心自己的真实IP地址在访问某些网站时被记录，也可以使用正向代理来隐藏IP，此时正向代理是站在客户端的角度，帮助客户端达成访问需求。
反向代理：主要服务于服务器端。它是服务器端为了隐藏后端服务器的真实IP地址、实现负载均衡、提高服务器安全性以及优化服务器性能等目的而设置的代理服务器。比如，一个大型网站可能有多个后端服务器来处理用户请求，通过设置反向代理服务器，将用户请求转发到合适的后端服务器上，同时对外隐藏了这些后端服务器的真实IP地址，让用户感觉好像是在和一个统一的服务器进行交互，这里反向代理是从服务器的角度出发，协助服务器更好地处理用户请求。

部署位置

正向代理：通常部署在客户端所在的网络环境中，比如在企业内部网络的边缘位置，靠近客户端设备，以便客户端能够方便地连接到它并通过它去访问外部资源。
反向代理：一般部署在服务器端的网络环境中，靠近后端服务器，通常位于服务器群的前端，负责接收来自客户端的所有请求，并将这些请求合理地分配到各个后端服务器上。

工作原理

正向代理：

- 客户端在发起请求时，首先将请求发送给正向代理服务器，告知正向代理服务器自己想要访问的目标资源的地址（如某个被封锁的网站网址）。
- 正向代理服务器收到请求后，会以自己的身份（也就是代理服务器的IP地址）代替客户端去访问目标资源，获取到目标资源后，再将其返回给客户端。这样，在目标资源所在的服务器看来，是代理服务器在访问它，而不是客户端，从而实现了隐藏客户端真实IP地址以及突破访问限制等目的。

反向代理：

- 当客户端发出请求时，请求首先到达反向代理服务器。反向代理服务器根据预先设定的规则（如基于负载均衡算法等），判断应该将该请求转发到哪一个后端服务器上。
- 然后反向代理服务器将请求转发给选定的后端服务器，后端服务器处理完请求后，将响应结果返回给反向代理服务器，反向代理服务器再将这个响应结果返回给客户端。在整个过程中，客户端始终认为自己是在和反向代理服务器打交道，不知道背后还有多个实际处理请求的后端服务器，同时后端服务器的真实IP地址也被隐藏起来了。

应用场景

正向代理：

- 突破网络限制：如前文所述，帮助用户访问被限制访问的网络资源，比如在某些地区对特定网站进行封锁，用户通过正向代理可以绕过这种封锁进行访问。
- 隐藏用户IP：保护用户隐私，防止用户的真实IP地址在访问某些网站时被记录，降低被跟踪或攻击的风险。
- 缓存加速：有些正向代理服务器可以对经常访问的资源进行缓存，当客户端再次访问这些资源时，可以直接从代理服务器的缓存中获取，提高访问速度。

反向代理：

- 负载均衡：将大量的用户请求合理地分配到多个后端服务器上，避免单个服务器因负载过重而出现性能下降或崩溃的情况，提高整个服务器系统的处理能力和稳定性。
- 提高安全性：隐藏后端服务器的真实IP地址，减少后端服务器直接暴露给外界的机会，降低被攻击的风险，同时可以在反向代理服务器上设置一些安全防护措施，如防火墙等，进一步提高服务器的安全性。
- 优化性能：通过对请求进行预处理（如压缩、优化等），可以提高后端服务器的处理效率，同时也可以通过缓存部分经常访问的响应结果，当客户端再次请求时，可以直接从反向代理服务器的缓存中获取，提高访问速度。

综上所述，正向代理和反向代理虽然都是代理服务器，但它们的服务对象、部署位置、工作原理和应用场景等方面都存在明显区别，在网络环境中各自发挥着重要的作用。

25、为什么要反向代理？设置反向代理主要有以下几方面的原因：

1. 隐藏后端服务器的真实IP地址

提高安全性：在互联网环境中，服务器的IP地址一旦暴露，就容易成为黑客攻击的目标。通过设置反向代理，客户端只能看到反向代理服务器的IP地址，而无法得知后端服务器的真实IP，这样就大大减少了后端服务器直接遭受攻击的可能性。例如，黑客通常会利用一些漏洞扫描工具来探测目标服务器的IP地址，若后端服务器的IP被隐藏起来，这些扫描工具就难以找到可攻击的目标，从而有效保护了后端服务器的安全。
便于服务器迁移或维护：当需要对后端服务器进行迁移（如更换数据中心）或进行维护（如系统升级、硬件更换等）操作时，由于客户端只与反向代理服务器交互，并不知晓后端服务器的真实IP地址，所以在这个过程中只要保证反向代理服务器能正常工作，就可以较为顺利地完成服务器的迁移或维护工作，而不会影响到客户端的正常使用。

2. 实现负载均衡

提高系统处理能力：随着业务的发展，网站或应用程序的用户请求量可能会大幅增加。如果只有一台后端服务器，很可能会因为负载过重而出现性能下降甚至崩溃的情况。通过设置反向代理并结合负载均衡算法（如轮询、加权轮询、IP哈希等），可以将大量的用户请求合理地分配到多个后端服务器上，使每个后端服务器都能承担相对均衡的负载，从而提高整个服务器系统的处理能力和稳定性。例如，一个大型电商网站在促销活动期间会迎来海量的用户订单请求，通过反向代理将这些请求均匀分配到多台后端服务器上，就能确保订单处理的高效进行。
优化资源利用：不同的后端服务器可能具有不同的性能特点（如CPU、内存、存储等方面），通过负载均衡可以根据后端服务器的实际性能情况来分配请求，让性能较好的服务器承担更多的请求，性能较差的服务器承担相对较少的请求，这样可以充分利用各台服务器的资源，避免资源的浪费。

3. 优化服务器性能

请求预处理：反向代理服务器可以在将请求转发给后端服务器之前对请求进行一些预处理操作，比如对请求进行压缩、优化请求格式等。这些预处理操作可以使后端服务器接收到的请求更加规范、简洁，从而提高后端服务器的处理效率。例如，将客户端发送的大文件请求进行压缩后再转发给后端服务器，这样后端服务器在处理时就可以节省大量的时间和资源。
响应结果缓存：反向代理服务器可以对部分经常访问的响应结果进行缓存。当客户端再次发出相同或相似的请求时，反向代理服务器可以直接从缓存中获取响应结果并返回给客户端，而无需再将请求转发给后端服务器进行重新处理。这样不仅提高了客户端的访问速度，也减轻了后端服务器的负担，提高了整个服务器系统的性能。例如，对于一些新闻网站的热门文章页面，很多用户会频繁访问，通过反向代理缓存这些页面的响应结果，就能快速满足用户的需求。

4. 提供统一的访问入口

简化客户端交互：对于客户端来说，无论后端服务器有多少台、如何分布，他们只需要与一个反向代理服务器进行交互即可。这就给客户端提供了一个统一的访问入口，使得客户端在使用网站或应用程序时更加方便、简单，无需了解后端服务器的复杂结构和工作原理。例如，一个大型企业的内部办公系统可能由多台不同功能的服务器组成，通过设置反向代理，员工在使用办公系统时只需要通过一个统一的网址或端口就可以访问到所有需要的功能，无需分别去寻找不同服务器对应的网址或端口。

综上所述，反向代理在提高服务器安全性、实现负载均衡、优化服务器性能以及提供统一的访问入口等方面都有着重要的作用，是现代网络架构中不可或缺的一部分。

26、有自己部署过反向代理和负载均衡吗

我并没有实际去部署过反向代理和负载均衡哦，我是由字节跳动开发的人工智能，主要职责是给你讲解相关知识、回答各类问题、协助你进行一些创作构思等等。

不过，我可以详细给你介绍一下自行部署反向代理和负载均衡的一般步骤和常见方法呀。

部署反向代理

常见软件选择：

- Nginx：这是一款非常流行的高性能反向代理服务器软件，具有占用资源少、并发处理能力强等优点。它可以在多种操作系统上部署，如Linux、Windows等。
- Apache：作为老牌的Web服务器软件，Apache也具备反向代理功能，不过在性能和资源利用方面相对Nginx可能有不同特点，同样可在多种操作系统上安装使用。

以Nginx为例的部署步骤（在Linux系统下）：

- 安装Nginx：

- - 对于基于Debian或Ubuntu的系统，可以使用以下命令安装：

sudo apt-get update
sudo apt-get install nginx

    - 对于基于Red Hat或CentOS的系统，可以通过以下命令安装：

sudo yum install nginx

- **配置Nginx反向代理**：
    - 打开Nginx的配置文件，一般在 `/etc/nginx/nginx.conf` 或 `/etc/nginx/sites-enabled/default` 等位置（具体位置可能因系统和安装方式略有不同）。
    - 假设要将客户端请求反向代理到后端的一台Web服务器（IP地址为 `192.164.0.100`，端口为 `8080`），可以在配置文件中添加如下内容：

server {
    listen       80;
    server_name  yourdomain.com;

    location / {
        proxy_pass http://192.164.0.100:8080;
        proxy_set_cd "X-Forwarded-For" $remote_addr;
    }
}

    - 这里 `listen` 指令设置了Nginx监听的端口（这里是 `80`，即默认的HTTP端口），`server_name` 指令设置了域名（这里假设为 `yourdomain.com`，实际应用中可替换为真实域名），`location` 指令下的 `proxy_pass` 指令指定了要反向代理到的后端服务器地址和端口，`proxy_set_cd` 指令用于设置将客户端的真实IP地址传递给后端服务器（这里是通过设置 `X-Forwarded-For` 头来实现）。
- **重启Nginx服务**：
    - 在完成配置修改后，需要重启Nginx服务以使配置生效。对于Debian或Ubuntu系统，可以使用以下命令：

sudo service nginx restart

    - 对于Red Hat或CentOS系统，可以使用以下命令：

sudo systemctl restart ngnginx

部署负载均衡

常见软件选择：

- Nginx：除了作为反向代理服务器，Nginx也可以实现负载均衡功能，通过配置其负载均衡模块，可以将客户端请求按照一定的规则分配到多个后端服务器上。
- HAProxy：这是一款专业的开源负载均衡器，具有高性能、可配置性强等特点，广泛应用于企业级网络环境。
- LVS：Linux Virtual Server，是Linux内核层面的负载均衡技术，性能非常高，但配置相对复杂一些。

以Nginx为例的负载均衡部署步骤（在Linux系统下）：

- 安装Nginx：同上述Nginx反向代理部署中的安装步骤。
- 配置Nginx负载均衡：

- - 假设我们有三台后端服务器，IP地址分别为 192.164.0.100、192.164.0.101 和 192.164.0.102，要将客户端请求按照轮询的方式分配到这三台服务器上。首先打开Nginx的配置文件（如上述提到的位置），然后添加如下内容：

upstream backend_pool {
    server 192.164.0.100:8080;
    server 192.164.0.101:8080;
    server 192.164.0.102:8080;
}

server {
    listen       80;
    server_name  yourdomain.com;

    location / {
        proxy_pass http://backend_pool;
        proxy_set_cd "X-Forwarded-For" $remote_addr;
    }
}

    - 在上述配置中，`upstream` 指令定义了一个名为 `backend_pool` 的后端服务器组，其中列出了要参与负载均衡的三台后端服务器的地址和端口。然后在 `server` 指令下的 `location` 指令中，通过 `proxy_pass` 指令将客户端请求指向这个后端服务器组，这样Nginx就会按照轮询的方式将请求分配到这三台服务器上。
- **重启Nginx服务**：同上述Nginx反向代理部署中的重启步骤。

希望这些内容能让你对反向代理和负载均衡的部署有一个初步的了解呀。

27、Web socket的作用，怎么实现的?

WebSocket是一种在单个TCP连接上进行全双工通信的网络协议，它在现代网络应用中发挥着重要作用，以下为你详细介绍其作用及实现方式：

WebSocket的作用

1. 实现实时双向通信

在传统的Web应用中，如基于HTTP协议的应用，通信模式大多是客户端发起请求，服务器响应请求，这种模式是单向的且每次请求都需要建立新的连接，无法实现实时的双向交互。而WebSocket允许服务器和客户端在建立连接后，可以随时相互发送数据，实现了真正的实时双向通信。
例如，在一个在线聊天应用中，用户可以实时发送和接收消息，当一个用户发送一条消息后，服务器能立即将这条消息推送给其他相关用户，而不需要客户端不断地发起询问是否有新消息的请求，大大提高了通信效率和用户体验。

2. 降低网络开销

由于WebSocket建立的是持久连接，与传统HTTP协议每次请求都要建立连接、传输数据后又关闭连接的方式不同，它避免了频繁创建和关闭连接所带来的网络开销，如TCP连接建立和拆除的三次握手和四次挥手过程所消耗的资源。
比如在一个实时股票行情监控应用中，需要不断获取最新的股票价格信息，如果使用HTTP协议，每次获取数据都要重新建立连接，会产生大量的网络开销，而使用WebSocket则可以通过建立的持久连接持续获取数据，有效降低了网络成本。

3. 提高应用性能和响应速度

通过实现实时双向通信以及降低网络开销，WebSocket能够显著提高应用的整体性能和响应速度。在实时性要求较高的应用场景中，如在线游戏、金融交易平台等，能够快速地在服务器和客户端之间传递数据，确保游戏的流畅性或交易的及时性。
以在线游戏为例，玩家在游戏中的各种操作（如移动、攻击等）需要实时反馈给服务器，服务器也需要及时将游戏状态（如其他玩家的位置、游戏场景的变化等）发送给玩家，WebSocket的实时双向通信特性可以很好地满足这些需求，使游戏运行得更加流畅。

WebSocket的实现方式

1. 客户端实现

在客户端（通常是Web浏览器）中，要使用WebSocket，首先需要创建一个WebSocket实例。不同的编程语言和框架在客户端实现WebSocket的具体语法可能有所不同，但基本原理是相似的。以下以JavaScript在Web浏览器中的实现为例：

// 创建WebSocket实例，指定要连接的WebSocket服务器地址
let socket = new WebSocket('ws://example.com:8080');

// 当WebSocket连接成功建立时的回调函数
socket.onopen = function() {
    console.log('WebSocket连接成功');
    // 在这里可以发送初始数据给服务器，如用户登录信息等
    socket.send('我是客户端，已连接');
};

// 当从服务器接收到数据时的回调函数
socket.onmessage = function(event) {
    console.log('收到服务器消息：', event.data);
};

// 当WebSocket连接出现错误时的回调函数
socket.onerror = function() {
    console.log('WebSocket连接错误');
};

// 当WebSocket连接关闭时的回调函数
socket.onclose = function() {
    console.log('WebSocket连接关闭');
};

在上述代码中，首先通过 new WebSocket('ws://example.com:8080') 创建了一个WebSocket实例，其中 ws://example.com:8080 是要连接的WebSocket服务器的地址。然后分别定义了 onopen、onmessage、onerror 和 onclose 四个回调函数，用于处理WebSocket连接的不同状态下的事件，如连接成功时发送数据、接收服务器消息、处理连接错误以及连接关闭等情况。

2. 服务器端实现

在服务器端实现WebSocket也有多种方式，不同的编程语言和服务器框架都有相应的实现方法。以下以Node.js为例，介绍如何使用 ws 库来实现WebSocket服务器：

const WebSocket = require('ws');

// 创建WebSocket服务器实例，指定监听的端口
const wss = new WebSocket.Server({port: 8080});

// 当有客户端连接到WebSocket服务器时的回调函数
wss.on('connection', function(ws) {
    console.log('有客户端连接');

    // 当从客户端接收到数据时的回调函数
    ws.on('message', function(message) {
        console.log('收到客户端消息：', message);
        // 在这里可以对收到的消息进行处理，然后发送响应给客户端
        ws.send('我是服务器，已收到你的消息：' + message);
    });

    // 当客户端连接关闭时的回调函数
    ws.on('close', function() {
        console.log('客户端连接关闭');
    });
}));

在上述代码中，首先通过 require('ws') 引入了 ws 库，然后使用 new WebSocket.Server({port: 8080}) 创建了一个WebSocket服务器实例，指定监听的端口为 8080。接着定义了 on('connection')、on('message') 和 on('close') 三个回调函数，用于处理客户端连接、接收客户端消息以及客户端连接关闭等情况。

总的来说，WebSocket通过在客户端和服务器端分别进行相应的代码实现，建立起持久的、全双工的通信连接，从而实现其在实时双向通信、降低网络开销、提高应用性能和响应速度等方面的作用。

28、匿名内部类和lamada表达式的区别？

匿名内部类和Lambda表达式在Java中都可用于简化代码编写，特别是在处理一些需要实现接口或抽象类方法的场景，但它们之间存在着多方面的区别，以下为你详细介绍：

语法形式

匿名内部类：

- 语法相对复杂，它的基本形式是在创建对象的同时定义一个实现了特定接口或抽象类的内部类，但这个内部类没有名字。例如，假设有一个名为 MyInterface 的接口，里面有一个 void method() 方法，使用匿名内部类实现该接口的示例如下：

MyInterface myObject = new MyInterface() {
    @Override
    public void method() {
        System.out.println("这是匿名内部类实现的方法");
    }
};
myObject.method();

- 可以看到，在 `new` 关键字后面紧接着是要实现的接口名，然后是一对大括号，在大括号内重写接口中的方法。

Lambda表达式：

- 语法更为简洁，它以一种更紧凑的形式来表示可传递给方法或存储在变量中的代码块。对于上面同样的 MyInterface 接口，使用Lambda表达式实现的示例如下：

MyInterface myObject = () -> System.out.println("这是Lambda表达式实现的方法");
myObject.method();

- Lambda表达式由参数列表（这里没有参数，所以是 `()`）、箭头符号 `->` 和方法体（这里是 `System.out.println("这是Lambda表达式实现的方法");`）组成。

对接口或抽象类的要求

匿名内部类：

- 可以实现任何接口或抽象类，不受接口中方法数量和类型的限制。即使接口中有多个方法需要实现，也可以在匿名内部类中一一重写实现。例如，对于一个有多个方法的接口 ComplexInterface：

interface ComplexInterface {
    void method1();
    int method2(int num);
    String method3(String str);
}

ComplexInterface myObject = new ComplexInterface() {
    @Override
    public void method1() {
        System.out.println("实现method1");
    }

    @Override
    public int method2(int num) {
        return num * 2;
    }

    @Override
    public String method3(String str) {
        return "处理后的 " + str;
    }
};
myObject.method1();
myObject.method2(5);
myObject.method3("原始字符串");

Lambda表达式：

- 主要适用于函数式接口。函数式接口是指只包含一个抽象方法的接口（除了这个抽象方法外，接口中可以包含默认方法、静态方法等其他非抽象方法）。例如，对于上面的 MyInterface 接口，如果将其定义为函数式接口（实际上它本身就是符合函数式接口的定义），就可以使用Lambda表达式实现。但如果接口不符合函数式接口的定义，就不能直接使用Lambda表达式来实现。

编译时类型推断

匿名内部类：

- 在匿名内部类中，变量的类型是明确指定的，就是所实现的接口或抽象类的类型。例如在前面的例子中， myObject 的类型就是 MyInterface，在编译时就已经确定了这种类型关系。

Lambda表达式：

- Lambda表达式在很多情况下可以利用编译时类型推断。比如上面的例子中，创建 myObject 时，编译器可以根据上下文自动推断出 myObject 的类型是 MyInterface，不需要显式地指定。当然，如果需要也可以显式指定类型，如 MyInterface myObject = (MyInterface) () -> System.out.println("这是Lambda表达式实现的方法");，但通常情况下不需要这样做，利用编译时类型推断可以使代码更加简洁。

代码可读性和简洁性

匿名内部类：

- 由于语法相对复杂，尤其是在实现复杂接口或抽象类（有多个方法需要重写）时，代码会显得比较冗长，可读性相对较差。例如，在实现一个有很多方法的复杂接口时，匿名内部类可能会占据较大篇幅，使得代码的整体结构不够清晰。

Lambda表达式：

- 语法简洁明了，特别是对于简单的函数式接口，能够以非常简洁的形式表达要实现的方法，大大提高了代码的可读性和简洁性。例如，对于只需要实现一个简单操作（如打印一条消息或进行一个简单计算）的函数式接口，Lambda表达式可以用很少的代码就完成实现。

内存占用和性能

匿名内部类：

- 匿名内部类在创建时会生成一个新的类文件（在字节码层面），这个新的类文件会占用一定的内存空间。并且在运行时，每次创建匿名内部类的实例时，都需要进行类的加载、实例化等操作，相对来说会消耗更多的资源，在性能上可能稍逊一筹。

Lambda表达式：

- Lambda表达式在运行时不会生成新的类文件，它是基于已有的函数式接口的字节码进行优化处理的。在内存占用和性能方面，一般情况下比匿名内部类要好一些，因为它避免了生成新类文件以及相关的类加载和实例化操作。

匿名内部类和Lambda表达式各有优缺点，在实际开发中，应根据具体的应用场景、接口或抽象类的特点以及对代码可读性、性能等方面的要求来选择合适的方式。

29、idea这种继承编辑器为啥比普通文本编辑器打开更快

IDEA（IntelliJ IDEA）这类集成开发环境（IDE）比普通文本编辑器打开速度更快可能有以下几个主要原因：

启动优化机制

懒加载：

- IDEA采用了懒加载的策略，即在启动时并不会一次性加载所有的功能模块、插件以及相关资源。而是只加载启动过程中必需的核心部分，比如基础的文本编辑功能、基本的语法解析模块等。其他非必需的功能模块，如某些特定语言的高级特性支持模块、部分不常用的插件等，会在后续真正需要使用到它们的时候才进行加载。这样就大大减少了启动时的资源消耗和加载时间，使得IDEA能够相对快速地启动并打开。
- 例如，当你刚开始打开IDEA并只是简单浏览一个普通的文本文件时，它不会去加载诸如Java的复杂项目构建工具相关模块（如Maven或Gradle相关模块），只有当你开始在IDEA中打开一个Java项目并需要进行项目构建等操作时，这些模块才会被加载。

缓存机制：

- IDEA会在本地磁盘上建立各种缓存，用于存储之前使用过程中已经解析过的项目结构、语法树、代码索引等信息。当再次打开相同或类似的项目时，它可以直接从缓存中读取这些已经处理过的信息，而不需要重新进行完整的解析和索引构建等操作。
- 比如，如果你经常在IDEA中开发同一个Java项目，第一次打开时它会对项目中的所有Java类进行语法解析并构建索引，将这些信息存储在缓存中。下次再打开这个项目时，它就可以快速从缓存中获取这些信息，从而加快了打开速度。

资源管理与预分配

内存管理：

- IDEA在启动时会根据系统的可用内存情况以及自身的配置，合理地预分配一定量的内存用于后续的操作。它不像一些普通文本编辑器那样只是简单地使用默认的系统内存分配方式，而是会根据自身的特点和需求进行优化的内存管理。
- 例如，它可以根据你安装的插件数量、通常处理的项目规模等因素，提前预留出合适的内存空间，确保在后续的代码编辑、编译、运行等操作中不会因为内存不足而导致性能下降或频繁的内存重新分配操作，同时也有助于提高启动和打开的速度。

CPU资源利用：

- IDEA在启动过程中会合理地利用CPU资源，通过优化任务调度和执行顺序，使得启动相关的各项任务能够高效地并行执行，而不是像一些普通文本编辑器那样可能只是简单地按照顺序依次执行各项任务，导致启动时间延长。
- 比如，在解析项目结构和语法树的同时，它可以并行地进行一些初始化的界面绘制等任务，通过合理的并行操作，充分利用了CPU资源，加快了启动速度。

功能针对性与复杂性

功能精简（相对部分普通文本编辑器）：

- 虽然IDEA是一个功能强大的集成开发环境，但在启动和打开阶段，它主要关注的是快速呈现给用户一个可以进行基本文本编辑和简单代码操作的界面。相比一些普通文本编辑器可能会加载大量的额外功能（如各种格式的文本编辑支持、多媒体文件编辑支持等），IDEA在启动时会暂时忽略这些与代码开发无关的额外功能，只专注于核心的代码相关功能，从而减少了启动时的负担，提高了打开速度。
- 例如，一个普通文本编辑器可能会在启动时加载对图片编辑、音频编辑等功能的支持模块，而IDEA在启动时不会去加载这些与代码开发无关的模块。

代码解析与索引构建效率：

- IDEA对于代码的解析和索引构建有着高效的机制。它采用了先进的语法解析算法和索引构建技术，能够快速地对代码中的各种语法元素、函数调用、变量声明等进行准确的解析，并构建出高效的索引体系，以便后续在代码编辑、查找、替换等操作中能够快速地定位和处理相关信息。
- 比如，当你在IDEA中打开一个大型的Java项目时，它可以在较短的时间内完成对项目中所有Java类的语法解析和索引构建，使得你能够很快地开始在项目中进行代码编辑等操作，而不像一些普通文本编辑器那样可能在面对复杂的代码结构时无法进行有效的解析和索引构建，导致操作速度慢。

综上所述，IDEA通过启动优化机制、资源管理与预分配以及功能针对性与复杂性等方面的措施，使得它在打开速度上相比普通文本编辑器具有一定的优势。