1

docs/study/back/API网关/APISIX.md

@@ -232,25 +232,32 @@ enabled = true
 allow_embedding = true
 ```
 
+
+使用prometheus收集apisix的指标信息，除了收集也可以有简单的web界面、图表展示
+
 ```shell
 #
 docker pull prom/prometheus
 #
 docker run -d \
 --name prometheus \
 -p 9090:9090        \
-prom/prometheus:24.9.27 
+-v /etc/localtime:/etc/localtime \
+prom/prometheus:latest 
 #
 vi /etc/prometheus/prometheus.yml 
-#
+# 进入容器增加
 - job_name: 'apisix'
     scrape_interval: 10s
     metrics_path: '/apisix/prometheus/metrics'
     static_configs:
       - targets: ['10.0.101.150:9091']
 ```
+
+需要apisix打开直销信息收集接口
+
 ```shell
-#
+# 修改apisix的配置文件 打开Prometheus
 vi config-default.yaml
 #
 enable_export_server: true              # Enable the Prometheus export server.

docs/study/back/API网关/APISIX高并发优化.md

@@ -0,0 +1,68 @@
+### 配置上游服务的keep-alive
+
+```shell
+# 如果使用的SpringBoot的undertow 单位为毫秒
+server.undertow.always-set-keep-alive=true
+server.undertow.keep-alive-timeout=5000000
+```
+
+需要确保上游服务有足够多的CPU和内存，否则性能跑不起来
+
+### apisix的路由增加keep-alive
+
+```shell
+# 需要在upstream增加如下
+# size参数定义了连接池的大小，即连接池中最多可以保存的连接数量。这里设置为 32，表示最多有 32 个与上游服务器的连接可以被复用。
+# requests参数指定了一个连接可以被复用的最大请求次数。当一个连接被使用的请求次数达到这个值后，连接将被关闭并重新建立。这里设置为 1000。
+# idle_timeout参数定义了连接在空闲状态下可以存活的时间（单位是秒）。如果一个连接在idle_timeout秒内没有被使用，它将被关闭。这里设置为 60 秒。
+,"keepalive_pool":{"idle_timeout":60,"requests":1000,"size":32}
+# 然后更新
+./etcdctl put /apisix/routes/00000000000000000956 '{"upstream":{"timeout":{"connect":180,"read":180,"send":180},"keepalive_pool":{"idle_timeout":60000,"requests":1000,"size":320},"nodes":{"10.0.102.139:20001":100},"pass_host":"node","type":"roundrobin","scheme":"https","hash_on":"vars"},"status":1,"priority":0,"vars":[["http_X-SW-Authorization-TenantCode","==","tenant"],["http_X-SW-Authorization-AppCode","IN",["","testapp"]]],"name":"tenant_加解密服务_tenant_业务","plugins":{},"uris":["/pki/*"],"id":"00000000000000000956","create_time":1729748682,"update_time":1729818639}'
+```
+
+{
+    "upstream": {
+        "timeout": {
+            "connect": 180,
+            "read": 180,
+            "send": 180
+        },
+        "keepalive_pool": {
+            "idle_timeout": 60,
+            "requests": 1000,
+            "size": 320
+        },
+        "nodes": {
+            "10.0.102.139:20001": 100
+        },
+        "pass_host": "node",
+        "type": "roundrobin",
+        "scheme": "https",
+        "hash_on": "vars"
+    },
+    "status": 1,
+    "priority": 0,
+    "vars": [
+        [
+            "http_X-SW-Authorization-TenantCode",
+            "==",
+            "tenant"
+        ],
+        [
+            "http_X-SW-Authorization-AppCode",
+            "IN",
+            [
+                "",
+                "testapp"
+            ]
+        ]
+    ],
+    "name": "tenant_加解密服务_tenant_业务",
+    "plugins": {},
+    "uris": [
+        "/pki/*"
+    ],
+    "id": "00000000000000000956",
+    "create_time": 1729748682,
+    "update_time": 1729818639
+}

docs/study/back/JavaWeb服务器/Jetty优化.md

@@ -0,0 +1 @@
+Jetty

docs/study/back/JavaWeb服务器/Tomcat优化.md

@@ -0,0 +1 @@
+Tomcat

docs/study/back/JavaWeb服务器/Undertow优化.md

@@ -0,0 +1,5 @@
+Undertow 是一个灵活的、高性能的 Web 服务器，它可以作为独立的服务器运行，也能很好地嵌入到 Java 应用程序中，如 Spring Boot 应用。它是基于 Java NIO（Non - Blocking I/O）实现的，这使得它能够高效地处理大量并发连接，提供了出色的性能。
+
+与传统的 Tomcat 服务器相比，Undertow 在处理高并发场景下的性能表现更为出色。Tomcat 在默认情况下采用阻塞式 I/O 模型，虽然也可以通过配置来实现非阻塞 I/O，但相对而言，Undertow 从设计之初就专注于高性能的非阻塞处理。例如，在***处理大量的短连接请求***（如 RESTful API 请求）时，Undertow 的响应速度更快，资源消耗更少。
+
+与 Jetty 服务器相比，Undertow 在内存占用和性能上也有一定的优势。Jetty 也是一个优秀的 Java Web 服务器，但 Undertow 在某些场景下，如处理大量的静态资源请求或者高并发的 WebSocket 连接时，能够提供更好的性能和更低的内存占用。

docs/study/back/Keepalived.md

@@ -0,0 +1,5 @@
+### 概述
+
+定义与功能：Keepalived 是一个基于 VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）实现的高可用解决方案。它的主要功能是通过在多台服务器之间共享一个虚拟 IP 地址，来提供服务器的故障转移和高可用性。当主服务器出现故障时，备份服务器可以快速接管虚拟 IP 地址以及对应的服务，对用户来说，几乎感觉不到服务的中断。例如，在一个 Web 服务器集群中，使用 Keepalived 可以确保用户始终能够访问网站，即使其中一台服务器出现故障。
+
+应用场景：广泛应用于各种需要高可用性的网络服务场景，如 Web 服务器（如 Apache、Nginx）、数据库服务器（如 MySQL）等。在负载均衡集群（如 LVS）中，Keepalived 也常被用于提供负载均衡器的高可用性。比如，在一个电商网站的架构中，为了保证用户能够持续地访问商品信息和进行交易，前端的 Web 服务器和负载均衡器通常会使用 Keepalived 来防止单点故障。

docs/study/db/NoSQL/Redis.md

@@ -54,8 +54,31 @@ redis 的主从同步是异步进行的，这意味着主从同步不会影响
 在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。但是从服务器仍然可以接受 CONFIG 等指令，所以还是不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此，那可以考虑给重要指令进行重命名，来避免命令被外人误执行。
 
 #### 哨兵
+
+启动多个哨兵进程监控主节点的状态，一旦多个哨兵（至于几个是可以配置的）认为主节点不可用，将切换某个从节点为主节点。
+
+客户端例如java需要去连接哨兵而不是直接连接主节点，否则主节点切换，客户端并不知晓。
+
+哨兵模式是无法保证Redis数据的一致性的，那是因为Redis从机是异步同步数据的，会存在一定的时间延迟导致从机的数据还没来得及同步。
+
 #### 集群
 
+集群中的每个节点存储哪些key值是根据key的hash值和节点的数量算出来的。
+
+定义：Redis 集群是一个提供在多个 Redis 节点间共享数据的分布式解决方案。它通过将数据分散存储在多个节点上，实现数据的分片存储，并且在部分节点出现故障时，依然能够保证集群的可用性和数据的完整性，以此来满足高并发、大数据量的应用场景。
+
+数据分片原理：Redis 集群采用哈希槽（hash slot）的方式来进行数据分片。整个集群共有 16384 个哈希槽，数据的键（key）通过 CRC16 算法计算出一个哈希值，然后对 16384 取模，得到这个键对应的哈希槽编号。每个节点负责一部分哈希槽，这样就将数据分散到了不同的节点上。例如，假设有 3 个节点，节点 A 负责 0 - 5460 号哈希槽，节点 B 负责 5461 - 10922 号哈希槽，节点 C 负责 10923 - 16383 号哈希槽。当客户端要访问一个键时，先计算其哈希槽编号，然后就知道应该向哪个节点发送请求。
+
+### 如何识别主从
+
+```shell
+#
+./bin/redis-cli --help
+./bin/redis-cli --tls --insecure -h 10.0.102.137 -a xxxx
+# INFO 用于获取关于 Redis 服务器的各种信息。
+# ROLE
+```
+
 
 ### 参考资料
 

docs/study/devops/Linux运维-GRUB.md

@@ -0,0 +1,9 @@
+### GRUB
+
+/etc/default/grub是一个在基于 Linux 的系统（如 Ubuntu、Debian 等）中用于配置 GRUB（GRand Unified Bootloader）引导加载程序的重要文件。GRUB 是大多数 Linux 系统用于引导操作系统内核启动的工具，它可以识别不同的操作系统和内核版本，并在启动时提供一个菜单让用户选择启动项。
+
+这个文件包含了许多用于定制 GRUB 行为的配置选项，这些选项会在系统启动过程中被读取并应用，以确定如何加载和启动内核以及相关的初始化程序。
+
+可以设置内核参数
+
+如果Docker info返回WARNING: No swap limit support 可以通过此设置解决

docs/study/devops/Linux运维-自启.md

@@ -1,16 +1,22 @@
-# Linux运维-自启
-
-systemd和init是Linux系统中用于启动和管理系统的两个不同工具。
-
-### init
-
-它是Linux内核启动后的第一个用户进程，用于初始化和管理系统服务和守护进程。init使用service命令来管理服务，如启动、停止和重启服务。init的主要缺点是启动时间长，因为它在启动过程中是串行的，这意味着必须依次启动每个服务。此外，init的配置脚本较为复杂，需要自行处理各种情况，这可能导致脚本变得很长。
-
-### systemd
-
-它是较新的Linux系统守护进程管理工具，在CentOS 7及更高版本中，systemd取代了init作为系统的默认进程管理器。systemd提供了并行启动服务的能力，使用socket和D-Bus激活机制，这显著提高了系统的启动速度。systemd还支持SysV和LSB初始化脚本，并能够管理系统的各项功能，如日志记录、网络配置、电源管理等。systemd的核心概念包括基于依赖关系的服务控制和统一任务定义，这使得管理更加高效和简化。
-
-### Docker systemd
-
-- [Docker服务systemd配置文件详解](https://blog.csdn.net/qq_46207024/article/details/134006150)
-- [配置 Docker 的 cgroup driver 为 systemd](https://zhuanlan.zhihu.com/p/633832183)
+# Linux运维-自启
+
+systemd和init是Linux系统中用于启动和管理系统的两个不同工具。
+
+### init
+
+它是Linux内核启动后的第一个用户进程，用于初始化和管理系统服务和守护进程。init使用service命令来管理服务，如启动、停止和重启服务。init的主要缺点是启动时间长，因为它在启动过程中是串行的，这意味着必须依次启动每个服务。此外，init的配置脚本较为复杂，需要自行处理各种情况，这可能导致脚本变得很长。
+
+### systemd
+
+它是较新的Linux系统守护进程管理工具，在CentOS 7及更高版本中，systemd取代了init作为系统的默认进程管理器。systemd提供了并行启动服务的能力，使用socket和D-Bus激活机制，这显著提高了系统的启动速度。systemd还支持SysV和LSB初始化脚本，并能够管理系统的各项功能，如日志记录、网络配置、电源管理等。systemd的核心概念包括基于依赖关系的服务控制和统一任务定义，这使得管理更加高效和简化。
+
+### Docker systemd
+
+- [Docker服务systemd配置文件详解](https://blog.csdn.net/qq_46207024/article/details/134006150)
+- [配置 Docker 的 cgroup driver 为 systemd](https://zhuanlan.zhihu.com/p/633832183)
+
+### 进程管理工具 supervisord
+
+Supervisord 是一个用 Python 编写的进程管理工具，主要用于在类 Unix 系统（如 Linux、macOS 等）下对长时间运行的进程进行管理。它可以方便地启动、停止、重启一个或多个进程，并且能够在进程意外退出时自动重启，确保进程的持续运行。例如，在一个 Web 服务器环境中，它可以管理如 Nginx、uWSGI 等进程；在数据处理场景下，能管理数据采集、清洗等长时间运行的进程。
+
+官网 http://supervisord.org/

docs/study/docker/docker-mysql.md

@@ -1,34 +1,34 @@
-# docker-mysql
-
-```shell
-# 如果还没安装docker服务的话(centos)
-yum install docker
-# 如果还没启动docker服务的话
-systemctl start docker
-#
-docker pull mysql:8.0.33
-# 纯粹学习使用
-docker run -d \
--p 13306:3306 \
---privileged=true \
--e TZ=Asia/Shanghai \
--e MYSQL_ROOT_PASSWORD=Aa0123 \
---name mysql-study \
-mysql:8.0.33
-
-
-docker exec -it mysql-study bash
-
-mysql -u root -p
-
-use mysql
-update user set authentication_string ='' where user = 'root';
-flush privileges;
-ALTER user 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'Aa0123';
-ALTER user 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'Aa0123';
-flush privileges;
-
-
-docker stop mysql-study
-docker rm mysql-study
-```
+# docker-mysql
+
+```shell
+# 如果还没安装docker服务的话(centos)
+yum install docker
+# 如果还没启动docker服务的话
+systemctl start docker
+#
+docker pull mysql:8
+# 纯粹学习使用
+docker run -d \
+-p 13306:3306 \
+--privileged=true \
+-e TZ=Asia/Shanghai \
+-e MYSQL_ROOT_PASSWORD=Aa0123 \
+--name mysql-study \
+mysql:8
+
+#
+docker exec -it mysql-study bash
+#
+mysql -u root -p
+#
+use mysql
+update user set authentication_string ='' where user = 'root';
+flush privileges;
+ALTER user 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'Aa0123';
+ALTER user 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'Aa0123';
+flush privileges;
+
+#
+docker stop mysql-study
+docker rm mysql-study
+```

docs/study/system/操作系统内核.md

@@ -50,6 +50,12 @@ lsb_release -a
 cat /etc/os-release
 ```
 
+### Linux内核
+
+https://www.kernel.org/
+
+https://docs.kernel.org/ 内核文档，这个要是能读一遍就很厉害了
+
 ### 参考
 
 - [lxlinux-Linux 内核调优](https://www.lxlinux.net/311.html)

docs/study/system/进程调度CPU调度.md

@@ -0,0 +1,19 @@
+### CFS 
+
+定义与作用：CFS 是 Linux 内核中用于进程调度的一种调度器，它的主要目标是公平地分配 CPU 时间给各个进程。这意味着在多任务环境下，每个进程都能根据其优先级和对 CPU 的需求，合理地获得 CPU 资源，从而避免某个进程长时间占用 CPU 而导致其他进程 “饥饿” 的情况。
+
+设计理念：CFS 基于公平性原则，它不像一些早期的调度器那样按照固定的时间片来分配 CPU，而是采用了一种虚拟运行时间（virtual runtime）的概念。简单来说，每个进程都有一个虚拟运行时间，CFS 会根据这个虚拟运行时间来决定下一个应该运行的进程，使得所有进程在一段时间内获得的 CPU 时间大致相同。
+
+### RT 实时调度
+
+分类与应用场景：
+
+SCHED_FIFO（先进先出实时调度）：这是一种简单的实时调度策略。按照进程进入就绪队列的顺序来分配 CPU，一旦一个高优先级的实时进程开始运行，它将一直运行直到结束、阻塞或者被更高优先级的实时进程抢占。主要用于对延迟要求极高的硬实时任务，如工业控制中的某些紧急控制任务、航空航天中的关键飞行控制系统等。
+
+SCHED_RR（时间片轮转实时调度）：类似于 SCHED_FIFO，但增加了时间片的概念。每个实时进程在获得 CPU 后会运行一个固定的时间片，时间片用完后，将 CPU 让给同优先级的下一个实时进程。这种调度策略适用于对实时性要求较高且需要公平共享 CPU 的软实时任务，如多媒体播放系统中的音频和视频处理任务，需要在一定时间内完成处理，同时也需要相对公平的资源分配。
+
+### BFS
+
+设计理念与目标：BFS 是为了解决 Linux 在高负载和多核心环境下的调度性能问题而设计的。它的目标是减少调度延迟，提高系统的响应速度，尤其是在处理大量线程的复杂场景下。
+
+工作方式的创新点：BFS 采用了一种不同的调度层次结构和队列管理方式。它将所有的线程组织在一个单一的运行队列中，通过一种快速的调度算法来选择下一个要运行的线程。这种方式与传统的调度器（如 CFS）将线程分散在多个队列中的方式不同，能够更有效地利用多核资源，减少线程在队列之间的迁移和等待时间。不过，BFS 目前没有被广泛应用于主流 Linux 发行版，仍处于研究和实验阶段。