2022-11 Leetcode简单难度算法Python版

Apitesting

# 2023-2-10

## docker原理

docker是一个cs架构的系统，一个创建容器的工具

想要搞懂docker看它两句口号就行：

> build， ship and Run # 搭建发送运行



> build once, Run any where # 搭建一次到处用

镜像：将代码、依赖库、配置、环境变量打包成独立软件包，它是静态的

容器：使用docker命令将镜像解压后的东西，它是动态的，可被创建、暂停、删除、启动

仓库：存放镜像的地方

```shell
systemctl start docker #启动docker
service docker restart #重启docker
docker ps # 查看容器
docker start
docker restart
docker logs
docker rm
docker pull #拉镜像
docker images # 列出镜像
docker image rm # 删除镜像

```



## docker底层技术原理

docker基于linux中LXC linux container linux虚拟容器技术实现，其有两大方法：

cgroup：control group

namespace：

两者区别：namespace为了隔离进程组之间的资源（组内资源可互相见，组外互相不可见），cgroup为了一组线程组统一资源监控和限制

## K8S Kubernetes原理

一个管理容器的工具，可以说大批量创建容器的工具

K8S包含：一个master节点（主节点）和一群node节点（计算节点）

master节点：

1. API Server：是K8S系统对外接口，供客户端和其他组件调用
2. Scheduler：对集群内部资源调度
3. Controller manager：负责管理控制器
4. etcd：

node节点：Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是**Pod**

1. docker：创建容器的
2. kubelet： 创建、修改、删除、监控它所在node上的pod
3. kube-proxy：为pod对象提供代理
4. fluentd：负责日志收集、存储、查询

```
kubectl get nodes
```

```
kubectl delete pods
```

```bash
kubectl logs -f my-pod 
```

# 2023-2-12

## chatgpt：列举一些常用的k8s命令

```shell
下面是一些常用的 Kubernetes 命令：

1. `kubectl get`：查询集群中的资源对象。
2. `kubectl describe`：获取资源对象的详细信息。
3. `kubectl apply`：更新集群中的资源对象。
4. `kubectl delete`：删除集群中的资源对象。
5. `kubectl create`：在集群中创建新的资源对象。
6. `kubectl exec`：在容器中执行命令。
7. `kubectl logs`：查询容器的日志。
8. `kubectl port-forward`：在本地端口上转发请求到容器。
9. `kubectl rollout`：管理部署的更新。
10. `kubectl top`：查询集群中资源的使用情况。
```

## 线程阻塞和死锁问题怎么去定位分析，有什么现象?

定位线程阻塞和死锁问题需要从以下几个方面入手：

1. 观察线程的状态：通常使用线程监控工具（如 jstack）来查看每个线程的状态，以确定是否有线程处于阻塞状态。
2. 查看线程栈：线程栈可以帮助您确定线程正在执行哪个方法，从而确定阻塞的原因。
3. 检查线程锁：如果多个线程在等待对同一个锁的访问，则可能存在死锁。可以使用线程监控工具（如 jstack）来查看锁的状态，以确定是否存在死锁。
4. 日志分析：查看日志文件以确定问题的时间和持续时间，并在该时间段内检查其他事件，以确定问题的根本原因。

此外，需要注意的是，线程阻塞和死锁问题会导致程序性能下降或完全停止，因此您可能会注意到以下现象：

- 应用程序的响应时间变慢
- 应用程序的性能下降
- 应用程序不响应或完全停止

利用上述信息可以帮助您定位线程阻塞和死锁问题，并找到合适的解决方案。为了预防这些问题，建议您在编写代码时遵循好的编程实践，如使用锁的适当使用方式，避免对同一个锁的无限等待，等等。

如果问题无法通过以上方法解决，可以考虑使用性能监测工具（如 JVisualVM）或分析工具（如 jmap）来获取更多信息，并找到更有效的解决方案。

## ui自动化，一个元素明明定位到了，点击无效（也没报错），如果解决？

如果在 UI 自动化测试中遇到了类似的问题，您可以试试以下解决方案：

1. 检查定位元素是否正确：确保定位到的元素是您想要点击的元素。
2. 等待元素可用：使用显式等待或隐式等待，等待元素出现并变得可操作。
3. 检查元素是否可见：确保定位到的元素是可见的，并且不被其他元素覆盖。
4. 调整坐标：如果元素被覆盖，可以通过调整元素的坐标来点击。
5. 检查元素是否被禁用：确保定位到的元素是启用的。

如果以上方法都无效，您可以通过使用浏览器开发工具检查元素的 HTML 结构和 JavaScript 代码，以更好地了解元素的行为。



# 2023-2-25

## docker使用场景总结

windows安装docker问题：

1. C盘空间太小不够用，docker安装路径默认c盘不可选，如何解决？

> 在空间较大的目标盘下新建Program Files\Docker文件夹
>
> 使用powershell执行下面命令
>
> ```shell
> mklink /j "C:\Program Files\Docker" "D:\Program Files\Docker"
> ```



依据Dockerfile构建镜像：

```shell
docker build -t gitdocccker:v1 .
```

用上面打好的镜像部署到容器：

```shell
docker run -d -p 2001:2001 --name gitdocccker-v1 gitdocccker:v1
```

-d后台运行，-p端口映射，--name将容器命名为gitdocccker-v1其镜像从gitdocccker tag为v1的仓库部署

将上面打好的镜像推到个人帐号docker hub中:

```shell
docker push gitdocccker/test:v1
```

将

遇到端口冲突，本地2001端口被占用，如何腾出此端口呢？

```shell
netstat -ano | findstr ":2001" # windows平台使用此命令
netstat -tulpn | grep ":2001" # linux平台使用此命令
taskkill /PID <PID> /F #杀死被占用端口的应用
kill -9 <PID>
```

-tulpn    tcp、udp、listen、port、name  

命令行退出后如何重新进入docker容器？

```shell
docker ps #先列出正在运行的容器信息
docker exec -it <mycontainerID> bash #使用容器id或者名字进入
```

1.上传文件
docker cp /root/test.txt ecef8319d2c8:/root/

上传：本机文件在前，容器文件夹在后

将宿主机 root 目录下的文件test.txt拷贝到容器id为ecef8319d2c8的 root 目录下。



2.下载文件
docker cp ecef8319d2c8:/root/test.txt /root/

下载：容器文件在前，本机文件夹在后

将容器id为ecef8319d2c8的 root 目录下的文件test.txt拷贝到宿主机 root 下。

## Dockfile

```dockerfile
FROM python:3.8 as builder
WORKDIR /pythonAutomationFramework
ADD . /pythonAutomationFramework
COPY ./requirements.txt ./requirements.txt
RUN apt update -y \
    && apt upgrade -y \
    && apt install -y net-tools \
    && apt install -y wget \
    && apt install -y default-jre \
    && wget https://github.com/allure-framework/allure2/releases/download/2.21.0/allure_2.21.0-1_all.deb \
    && dpkg -i allure_2.21.0-1_all.deb \
    && pip install --no-cache-dir -r requirements.txt
CMD python run_api_test.py && python generate_api_test_report.py && tail -f /dev/null
```

第1行：环境指定python3.8

第2行：创建指定脚本运行所在文件夹

第3行：<.>这个点表示当前目录所有东西拷贝到pythonAutomationFramework文件夹

第4行：将requirements.txt依赖包拷贝到pythonAutomationFramework文件夹下

第5行：运行一堆系统依赖包，依据需求填写，多行参考\ && 写法，apt后面跟-y意思是确认执行的意思，不带这个命令的话，docker build会中断，先升级apt是升级docker内部软件数据库，这样可以方便后面下载指定的软件，由于allure需要依赖java，故下载jre

第13行：执行终端命令行运行脚本多个用 && 隔开，最后加入tail -f /dev/null语句是为了脚本结束容器不至于退出EXITED，为什么会退出？python脚本执行完后docker检测到没有前后台任务，就退出container

/dev/null文件是个linux黑洞，任何写入到此文件的东西都会被丢弃，

因此tail命令不会输出任何信息，这个tips稳定几乎不占内存，无需修改业务程序逻辑

**启动selenium-server**

```shell
java -jar selenium-server-standalone-3.141.0.jar -host 127.0.0.1 -port 4444
```

CICD

# 2023-2-7

## mysql索引底层机制

## B+ 树特性

![image-20230207182807860.png](https://trexshanghai.com/static/img/c95e4023705516f251da1cda0defa3db.image-20230207182807860.png)

平衡二叉树+双向链表=B+树



非叶子节点只存索引值，在最后一列也就是叶子节点的高度1上，存放行记录，这种在叶子节点存放整行记录的索引成为聚簇索引。

这种数据结构查询时间复杂度O(logn)，千万级的数据通过索引往往只需3次IO就能查到。

## mysql事务隔离级别，mvcc是什么？

MultiVersion Concurrency Control多版本并发控制，一般是对数据库并发访问，在编程语言中实现事务内存

数据库ACID（atomic，consistent, isolation，duration）

read uncommitted

read committed

repeatable read

serializable

## 锁类型

从数据库系统角度看：

**排他锁(写锁)**:当一个事务为数据加上写锁时，其他事务不能对其加任何锁，直到写锁释放，写锁的目的是在修改数据时候，不允许其他人读取和修改，避免脏数据问题

**共享锁(读锁)**:当一个事务对数据加上读锁后，其他事务只能对该数据加读锁，知道所有读锁释放后，别的事务才能加写锁，读锁主要为了支持并发的读取数据，读取时不能被修改

从编写代码角度看：

**悲观锁pessimistic concurrency control (pcc)**：

悲观的认为每次都会发生并发冲突，在可能出现并发的地方加上锁机制，按串行化处理

指数据被外界修改保持悲观，在整个数据处理过程中保持锁定。优点：数据处理安全，缺点：性能低、有o额外开销、有死锁可能

例子：在select后面加for update就是加了排他锁(写锁)

```mysql
select * from user for update;
```

**乐观锁optimisticconcurrency control (occ) **：

乐观的认为每次都不会发生并发冲突

```mysql
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
```

场景: 乐观锁适用多读场景（写比较少），悲观锁适用多写（读比较少）



## 死锁

应用中进程需要独占资源，如独占某个对象，当进程并发执行时可能会出现进程永远被阻塞现象，如两个进程分别等待对方所占资源，造成两者都不能执行下去处于永远等待状态成称为死锁

解决：重启；进程撤销：cpu消耗时间最少者、预计剩余执行时间最长者、



# 2023-2-8

## 什么是慢查询

```mysql
show_query_log	
```

开启：`

```mysql
set global slow_query_log = 1;
```

查询慢sql日志存放路径

```mysql
show_query_log_file
```

是否记录未使用所有的sql

```mysql
log_queries_not_using_indexes 
```

# 2023-2-9

## redis用途和场景

remote dictionary server

1. 解决应用服务器的cpu和内存压力
2. 减少IO的读操作，减轻IO压力

场景: 

充当缓存系统，为热点数据（读多写少）

计数器、限流器：限制一个手机发多少条短信、一个接口一分钟限制多少请求、一天内限制请求次数

消息队列系统、排行榜、社交网络、实时性高的系统（共享session、分布式锁）

限时业务：限时优惠活动、手机验证码

缓存、数据共享分布式、分布式锁、全局 ID、计数器、限流、购物车、消息队列、抽奖、点赞、签到、打卡等场景。

## redis击穿

当redis获取某一个key时，由于key失效或不存在，向DB请求称为redis击穿


![image-20230209101859031.png](https://trexshanghai.com/static/img/00ff39ac13d9f9c38a7ca1bf932d689a.image-20230209101859031.png)

引发击穿原因：第一次访问、恶意访问不存在的key、key过期

规避方案：

服务启动时，提前写入：

规范key命名，通过中间件拦截

对高频key，设置ttl永不过期，或者过期时间设置成加上随即数


![image-20230209115612926.png](https://trexshanghai.com/static/img/a2bb0885f67d2f4ef8f8315ea2a56d22.image-20230209115612926.png)

## redis穿透

业务查询的数据既不在redis也不在DB，成为穿透


![image-20230209115624168.png](https://trexshanghai.com/static/img/910e053081e0249f66a019abed2140f7.image-20230209115624168.png)

## redis雪崩

redis缓存层由于大量数据同时过期、redis故障宕机，所有请求都涌向储存层，短时高并发请求可能导致储存层宕机，

引起一系列连锁反应，造成整个系统崩溃

称之为redis雪崩，redis击穿是redis雪崩的一个子集

规避方案：对于大量数据同时过期：均匀的设置过期时间、互斥锁、双key策略、后台更新缓存

对于redis故障宕机：服务熔断、请求限流机制，使用redis高可用集群


![image-20230209120307392.png](https://trexshanghai.com/static/img/7bf5e04fd9192e422ea1e09b99531cdf.image-20230209120307392.png)

Database

# 2023-2-9

## MQ message queue

rocketMQ、RabbitMQ、Kafka、ActiveMQ

技术挑战不是特别高，用 RabbitMQ 是不错的选择，

电商、金融等对事务性要求很高的，可以考虑RocketMQ，

如果是大数据领域的实时计算、日志采集等场景可以考虑 Kafka。

## **mq如何测试：**



对于生产者：

- 生成的数据格式是否跟定义的一致
- 数据是否有成功推送到队列中对应topic
- 推送失败、重复推送如何处理
- 不同顺序推送，关注队列优先级
- 推送耗时，队列容量达到上限后，如何处理

对于消费者：

- 消费的消息是否来自对应订阅的topic，内容是否一致
- 优先级是否一致
- 消费者宕机，消息挤压，积压后超时如何处理
- 如何处理重复消息，幂等问题
- 消息处理失败，如加密的消息体消费者解密失败如何处理
- 消费消息耗时

对于队列本身：

- 宕机恢复后，消息是否丢失，不同的消息格式是否能正常识别及转发

## 怎么保障 mq 

## 消息的有序性、幂等性、可靠性

1. 有序性：队列有序，消息有序；队列无序，消息有序；队列有序，消息无序；队列无序，消息无序。 
2. 幂等性：消息的幂等性，可以通过消息的唯一标识（消息ID）来实现。
3. 可靠性：消息的可靠性，可以通过消息的持久化来实现。

## Redis remote dictionary server

远程字典服务是一个将数据存储在内存中速度非常快的非关系数据库

### 如何测试 Redis 缓存？

增：增加缓存，校验功能和数据是否正确符合业务DB和redis一致，过期时间和设计一致

删：删除缓存，校验功能和数据是否正确，再次请求缓存是否正确写入，DB和redis是否一致

改：更新缓存，校验功能和数据是否正确，DB和redis是否一致，过期时间和设计一致

查：

1. 校验数据在缓存和DB都存在时，系统是否正常
2. 校验数据在DB存在但缓存不存在，系统是否正常
3. 校验数据在缓存和DB都不存在，系统是否正常
4. 验证DB返回数据异常，系统有没有去查缓存

过期时间: 设置redis过期时间，校验缓存是否正常过期，再次写入时间是否被刷新

异常场景:

缓存超时: 缓存查询超时后，未能返回指定数据，系统反应是否符合预期

缓存穿透：查询一个DB和缓存中不存在的数据，验证数据是否返回空

缓存雪崩：设置大量key过期时间同时失效，系统指标是否正常，功能是否正常

缓存击穿：将一个key（缓存中存在，DB中也存在）删除，大并发访问刚刚删除的key，校验功能指标

缓存预热：在预热期间，系统接口是否正常

缓存上限：确认淘汰机制，然后将缓存数据增加到maxmemory，再请求查询数据返回正确，淘汰机制正确

缓存停服：关闭redis后，系统功能和性能情况，重启后数据未丢失损坏和DB一致

缓存并发：

- 并发请求缓存中有的数据，验证返回数据符合预期，性能ok
- 并发请求缓存中没有DB有的数据
- 并发请求缓存中没有DB中也没有的数据，验证返回数据为空

缓存性能测试：一般用 redis-benchmark

- 对比单机和集群redis的tps

生成环境的监控：缓存命中率、cpu、内存、是否有大key

## redis内存满了，会发生什么?

当redis内存到达某个阈值会触发内存淘汰机制。

八大内存淘汰机制：noeviction默认策略，内存慢了不淘汰数据不提供服务

***进行数据淘汰的策略***

针对「进行数据淘汰」这一类策略，又可以细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」这两类策略。 在设置了过期时间的数据中进行淘汰：

- **volatile-random**：随机淘汰设置了过期时间的任意键值；
- **volatile-ttl**：优先淘汰更早过期的键值。
- **volatile-lru**（Redis3.0 之前，默认的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最久未使用的键值；
- **volatile-lfu**（Redis 4.0 后新增的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最少使用的键值；

在所有数据范围内进行淘汰：

- **allkeys-random**：随机淘汰任意键值;
- **allkeys-lru**：淘汰整个键值中最久未使用的键值；
- **allkeys-lfu**（Redis 4.0 后新增的内存淘汰策略）：淘汰整个键值中最少使用的键值。

## redis用的是淘汰缓存还是更新缓存?

淘汰缓存：

1. 更新DB后，将缓存中记录删除
2. 查询数据时，无法从缓存获取数据，遂从DB获取后写入缓存
3. 第二次及之后查询该数据，直接从缓存读取

更新缓存：

1. 有缓存的调用者更新DB同时更新缓存
2. 查询该数据时，从缓存读取最新数据

**区别：淘汰缓存更新数据会有一次缓存穿透，更新缓存无此情况，但是更新缓存每次都同时更新缓存比较影响性能，大部分情况下修改数据成本高于一次缓存穿透，选用淘汰缓存更合理**

## redis用途和场景

remote dictionary server

1. 解决应用服务器的cpu和内存压力
2. 减少IO的读操作，减轻IO压力

场景: 

充当缓存系统，为热点数据（读多写少）

计数器、限流器：限制一个手机发多少条短信、一个接口一分钟限制多少请求、一天内限制请求次数

消息队列系统、排行榜、社交网络、实时性高的系统（共享session、分布式锁）

限时业务：限时优惠活动、手机验证码

缓存、数据共享分布式、分布式锁、全局 ID、计数器、限流、购物车、消息队列、抽奖、点赞、签到、打卡等场景。

## redis击穿

当redis获取某一个key时，由于key失效或不存在，向DB请求称为redis击穿

<img src="https://emptiness.me/static/img/00ff39ac13d9f9c38a7ca1bf932d689a.image-20230209101859031.png" alt="image-20230209101859031"  />

引发击穿原因：第一次访问、恶意访问不存在的key、key过期

规避方案：

服务启动时，提前写入：

规范key命名，通过中间件拦截

对高频key，设置ttl永不过期，或者过期时间设置成加上随即数

<img src="https://trexshanghai.com/static/img/a2bb0885f67d2f4ef8f8315ea2a56d22.image-20230209115612926.png" alt="image-20230209115612926" style="zoom: 50%;" />

## redis穿透

业务查询的数据既不在redis也不在DB，成为穿透

<img src="https://trexshanghai.com/static/img/910e053081e0249f66a019abed2140f7.image-20230209115624168.png" alt="image-20230209115612926" style="zoom: 50%;" />
## redis雪崩

redis缓存层由于大量数据同时过期、redis故障宕机，所有请求都涌向储存层，短时高并发请求可能导致储存层宕机，

引起一系列连锁反应，造成整个系统崩溃

称之为redis雪崩，redis击穿是redis雪崩的一个子集

规避方案：对于大量数据同时过期：均匀的设置过期时间、互斥锁、双key策略、后台更新缓存

对于redis故障宕机：服务熔断、请求限流机制，使用redis高可用集群


![image-20230209120307392.png](https://trexshanghai.com/static/img/7bf5e04fd9192e422ea1e09b99531cdf.image-20230209120307392.png)
# 2023-2-10

## mqtt的mosquito有哪些测试点

1. 连接测试：测试Mosquitto服务端是否可以连接上客户端，以及客户端是否可以正确发布和订阅消息。
2. 订阅测试：测试客户端是否能够正确订阅消息，以及客户端是否可以接收到相应的消息。
3. 发布测试：测试Mosquitto服务端是否能够接收和发布客户端发出的消息请求。
4. 流量测试：测试Mosquitto服务端在访问高峰期时能够承受多少流量。
5. 性能测试：测试Mosquitto服务端在多客户端访问情况下可以提供多少消息维护和传输性能。
6. 错误处理测试：测试Mosquitto服务端如何处理各种错误和异常情况。

## gRPC、websocket、tcp有哪些测试点

眨一下眼	一瞬间
口算29+55	几秒
烧一壶水	几分钟
睡一觉	几小时
完成一个项目	几天/几星期
地球到火星	几年

2022-11-16

算法

时间复杂度

2023-2-2

2022-10-24

安装ycharm问题：

2023-2-10

docker原理

2023-2-7

mysql索引底层机制

B+ 树特性

2023-2-9

MQ message queue

mq如何测试：