小菜鸟

log4j2动态修改日志级别

发表于 2024-08-05 更新于 2025-08-23 分类于日志阅读次数： Valine：
本文字数： 4.4k 阅读时长 ≈ 4 分钟

Log4j2 动态修改日志级别：线上问题排查的灵活工具

在生产环境中，日志级别通常设置为INFO或WARN以减少冗余输出，但排查问题时往往需要临时调低级别（如DEBUG）以获取更详细的日志。Log4j2 提供了Configurator工具类，支持在不重启应用的情况下动态修改日志级别，极大提升了线上问题排查的效率。

动态修改日志级别的核心原理

Log4j2 的日志级别配置通过LoggerContext管理，每个Logger（对应类或包）的级别信息存储在内存中。Configurator类提供了静态方法setLevel()，可直接修改指定Logger的级别，无需重新加载配置文件。

核心对象：
- LoggerContext：Log4j2 的上下文对象，管理所有Logger配置；
- Level：日志级别枚举（TRACE < DEBUG < INFO < WARN < ERROR < FATAL）。

动态修改日志级别的实现

核心 API

Log4j2 通过org.apache.logging.log4j.core.config.Configurator提供动态配置能力，关键方法：

方法	说明
`Configurator.setLevel(String loggerName, Level level)`	为指定名称的`Logger`（类或包）设置级别
`LogManager.getContext(false)`	获取当前应用的`LoggerContext`（非单例模式）
`loggerContext.getLogger(loggerName)`	获取指定名称的`Logger`实例

实现代码（Spring Boot 示例）

以下示例通过 HTTP 接口实现日志级别的查询与修改，便于线上操作：

阅读全文 »

python JSON解析

发表于 2024-08-05 更新于 2025-08-04 分类于 Python 阅读次数： Valine：
本文字数： 3k 阅读时长 ≈ 3 分钟

Python JSON 解析详解：日志分析实战

JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，在日志记录、API 交互等场景中广泛使用。Python 标准库 json 提供了简洁的 API 用于 JSON 数据的解析（字符串转字典）和序列化（字典转字符串）。本文将以日志分析为例，详细介绍 Python 处理 JSON 数据的方法。

JSON 解析核心方法

Python 的 json 模块提供了两个核心函数用于 JSON 处理：

方法	功能	适用场景
`json.loads(s)`	将 JSON 字符串 `s` 解析为 Python 字典 / 列表	处理内存中的 JSON 字符串（如日志行）
`json.dumps(obj)`	将 Python 字典 / 列表序列化为 JSON 字符串	将数据写入文件或通过网络传输
`json.load(f)`	从文件对象 `f` 中读取 JSON 数据并解析	直接读取 JSON 文件
`json.dump(obj, f)`	将 Python 对象序列化并写入文件 `f`	直接写入 JSON 文件

日志分析实战：筛选慢请求

以分析 JSON 格式的请求日志为例，假设日志文件 req_resp.log 中每行是一个 JSON 对象，包含 timeSpent（请求耗时，单位 ms）等字段。我们需要筛选出耗时超过 150ms 的请求。

完整代码实现

#!/usr/bin/python3
import json

# 日志文件路径
log_path = "/data/req_resp.log"

# 打开文件并逐行解析
with open(log_path, "r", encoding="utf-8") as f:
    for line_num, line in enumerate(f, 1):  # 枚举行号（从1开始）
        try:
            # 解析 JSON 字符串为字典
            log_data = json.loads(line.strip())  # strip() 去除换行符等空白
            
            # 检查是否包含 timeSpent 字段
            if "timeSpent" not in log_data:
                print(f"警告：第 {line_num} 行缺少 timeSpent 字段")
                continue
            
            # 获取耗时并筛选
            time_spent = log_data["timeSpent"]
            # 确保 timeSpent 是数字（避免类型错误）
            if isinstance(time_spent, (int, float)) and time_spent > 150:
                print(f"慢请求（耗时 {time_spent}ms）：{log_data}")
                
        except json.JSONDecodeError as e:
            # 处理 JSON 解析错误（如格式错误）
            print(f"解析错误（第 {line_num} 行）：{e}")
        except Exception as e:
            # 处理其他异常（如字段类型错误）
            print(f"处理错误（第 {line_num} 行）：{e}")

阅读全文 »

TCP拥塞控制

发表于 2024-08-04 更新于 2025-08-03 分类于网络阅读次数： Valine：
本文字数： 1k 阅读时长 ≈ 1 分钟

TCP 拥塞控制详解

TCP 拥塞控制的核心目标是避免网络因数据量过大而陷入拥塞状态，确保整个网络的传输效率。它与流量控制的区别在于：流量控制关注点对点的速率匹配（如 sender 与 receiver 之间），而拥塞控制则从全局视角出发，考虑整个网络的负载情况。

TCP 拥塞控制主要通过以下算法协同实现：

1. 慢启动算法（Slow Start）

核心思想：发送方刚建立连接时，对网络状况一无所知，因此从极小的发送速率开始，逐步增加数据量，避免突然发送大量数据导致网络拥塞。
具体机制：
- 引入拥塞窗口（cwnd，Congestion Window） 变量，控制发送方在未收到确认前最多能发送的字节数。
- 初始时，cwnd 取值较小（通常为 1~2 个 MSS，MSS 为最大报文段长度）。
- 每收到一个对新报文段的确认（ACK），cwnd 就加倍（指数增长）。例如：cwnd=1 → 收到 ACK 后→ cwnd=2 → 再收到 ACK→ cwnd=4，以此类推。
- 当 cwnd 增长到慢启动阈值（ssthresh，Slow Start Threshold） 时，慢启动阶段结束，进入拥塞避免阶段。

2. 拥塞避免算法（Congestion Avoidance）

核心思想：当网络接近拥塞阈值时，不再快速增加发送量，而是缓慢增长，试探性地提升速率，避免触发拥塞。
具体机制：
- 当 cwnd ≥ ssthresh 时，进入拥塞避免阶段。
- 此时，每收到一个 ACK，cwnd 不再加倍，而是加 1 个 MSS（线性增长）。例如：cwnd=10 → 收到 ACK 后→ cwnd=11，逐步提升。
- 该阶段持续到网络出现拥塞（如超时未收到 ACK），此时触发拥塞处理机制。

3. 拥塞发生后的处理：快重传与快恢复

当网络出现拥塞（如报文段丢失）时，TCP 会调整策略以快速恢复：

快重传（Fast Retransmit）：
- 若接收方收到失序的报文段（如预期收到 M3，却先收到 M4），会立即发送对已收到的最后一个有序报文段的重复 ACK（如重复确认 M2）。
- 若发送方连续收到3 个重复 ACK，则判断对应报文段（如 M3）已丢失，无需等待超时，立即重传该报文段，避免因超时导致的拥塞窗口骤降。
快恢复（Fast Recovery）：
- 配合快重传使用，当触发快重传时，发送方认为网络并未严重拥塞（只是个别报文丢失），因此不执行慢启动，而是：
  1. 将 ssthresh 设为当前 cwnd 的一半（ssthresh = cwnd / 2）；
  2. 将 cwnd 设为 ssthresh 的值（或 ssthresh + 3 ，补偿 3 个重复 ACK 已确认的报文）；
  3. 之后进入拥塞避免阶段，cwnd 线性增长。

TCP流量控制

发表于 2024-08-04 更新于 2025-08-03 分类于网络阅读次数： Valine：
本文字数： 766 阅读时长 ≈ 1 分钟

TCP 流量控制详解

TCP 的流量控制机制是为了防止发送方发送数据的速率过快，导致接收方因缓冲区不足而无法及时处理，最终造成数据丢失。其核心是通过滑动窗口机制动态调整发送方的发送速率，实现点对点的数据传输平衡。

滑动窗口的基本概念

窗口：指接收方当前能够接收的数据量（以字节为单位），由接收方告知发送方。
滑动：随着数据的接收和确认，窗口的范围会动态变化（向前 “滑动”）。

发送方的发送窗口大小受限于接收方的接收窗口大小，确保发送的数据量不超过接收方的处理能力。

接收窗口与发送窗口的交互

接收方的接收窗口（rwnd）
接收方在 TCP 报文中的窗口字段（Window Size）告知发送方自己的接收缓冲区剩余容量。例如：
- 接收方初始缓冲区大小为 1000 字节，已用 300 字节，则rwnd = 700，表示最多还能接收 700 字节。
发送方的发送窗口
发送方的发送窗口大小 ≤ 接收方的接收窗口大小（rwnd）。发送方只能发送窗口内的数据，未被确认的数据需暂存，等待接收方确认后才能从窗口中移除。
窗口滑动的触发
- 接收方处理完数据后，缓冲区空闲空间增加，会通过 ACK 报文更新 rwnd。
- 发送方收到新的 rwnd 后，调整发送窗口大小并 “滑动” 窗口（将已确认的数据移出窗口，未发送的新数据纳入窗口）。

零窗口与窗口探测

零窗口（rwnd=0）：当接收方缓冲区满时，会告知发送方rwnd=0，此时发送方需暂停发送数据。
窗口探测：发送方在收到零窗口后，会定期发送窗口探测报文（携带 1 字节数据），接收方若缓冲区有空闲，会在回复中更新 rwnd，发送方据此恢复发送。

与拥塞控制的区别

流量控制：仅关注接收方的处理能力（点对点），通过接收窗口（rwnd）调节。
拥塞控制：关注网络链路的负载（全局），通过慢启动、拥塞避免等算法调节发送速率。

两者结合确保 TCP 在复杂网络环境中既能高效传输，又能避免数据丢失。

OpenFeign集成OkHttp

发表于 2024-07-29 更新于 2025-08-20 分类于微服务阅读次数： Valine：
本文字数： 4k 阅读时长 ≈ 4 分钟

OpenFeign 集成 OkHttp：提升服务调用性能的实践

OpenFeign 默认使用 JDK 原生的HttpURLConnection作为 HTTP 客户端，但其缺乏连接池支持，频繁创建和关闭连接会导致性能损耗。通过集成 OkHttp（一款高效的 HTTP 客户端），可利用连接池复用 TCP 连接，显著提升微服务间调用的效率。

为什么选择 OkHttp？

OkHttp 作为成熟的 HTTP 客户端，相比HttpURLConnection有以下优势：

连接池支持：复用 TCP 连接，减少三次握手开销；
异步请求：支持非阻塞 IO，提升并发处理能力；
自动重连：对 transient 错误（如连接超时）自动重试；
拦截器机制：便于添加日志、加密等统一处理逻辑；
高效的缓存策略：支持 HTTP 缓存，减少重复请求。

OpenFeign 集成 OkHttp 的步骤

1. 引入依赖

在pom.xml中添加feign-okhttp依赖（OpenFeign 与 OkHttp 的桥接组件）：

<dependency>
    <groupId>io.github.openfeign</groupId>
    <artifactId>feign-okhttp</artifactId>
    <!-- 版本由Spring Cloud依赖管理自动匹配，无需手动指定 -->
</dependency>

2. 开启 OkHttp 支持

在配置文件中启用 OpenFeign 对 OkHttp 的支持（默认关闭）：

阅读全文 »