技术 - DevOps on Loen blog

🧐 为什么 HttpServletRequest 的 Body 只能被读取一次？

Wed, 10 Dec 2025 13:26:48 +0800

它触及了 Java Web容器（Servlet规范） 处理 HTTP请求体（Request Body） 的核心机制，以及 输入/输出流（IO Stream） 的基本特性。

🧐 为什么 `HttpServletRequest` 的 Body 只能被读取一次？

核心原因在于 HTTP 协议和 Java I/O 流的本质，尤其是对于 流式数据 (Streamed Data) 的处理。

1. HTTP 请求体的本质是“输入流” (Input Stream)

在 Java Web 应用中，当服务器接收到一个 HTTP 请求时，请求的 Header（如方法、路径、Content-Type）会被解析成字符串/集合等对象，但请求的 Body（如 POST/PUT 请求中的 JSON、XML、文件内容）通常是一个 字节序列。

Web 容器（如 Tomcat）不会一次性将整个 Body 加载到内存中，而是将其暴露为一个 ServletInputStream（通过 request.getInputStream() 获取）。

流（Stream） 的概念就像水管里的水流：数据是按顺序从源头（客户端）流向目的地（服务器）的。
读取（Read） 意味着水被抽走了。一旦一个字节的数据被读取并处理，它就从流中消耗掉了，无法回溯。
这种设计是出于对 性能和内存 的优化，特别是处理 大文件上传 或 超大请求体 时。如果每次请求都必须把整个 Body 缓存起来，服务器很快就会耗尽内存（OOM）。

2. 对比 `List` 或 `Map` 等集合

您提到 List 和 Map 可以多次读取，这是因为它们是 内存中的数据结构 (In-Memory Data Structures)。

redis 中的lua脚本是如何执行的?

Tue, 09 Dec 2025 14:42:04 +0800

Redis 中 Lua 脚本的执行机制

1. Lua 脚本是如何执行的？

Redis 使用 EVAL 和 EVALSHA 命令执行 Lua 脚本：

1
2
3
4
5
6


-- EVAL 命令格式
EVAL "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 arg1 arg2

-- EVALSHA 使用脚本的 SHA1 校验和执行
SCRIPT LOAD "return 'hello'"
EVALSHA <sha1_hash> 0

执行特点：

原子性：脚本作为一个整体执行，期间不会被其他命令打断
单线程：Redis 单线程执行，避免并发问题
事务性：优于 Redis 事务（MULTI/EXEC），没有事务失败问题

2. Lua 脚本以什么形式存在于 Redis 中？

脚本在 Redis 中以两种形式存在：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- 1. 临时形式：EVAL 直接执行（不持久化）
EVAL "return redis.call('GET', 'foo')" 0

-- 2. 缓存形式：SCRIPT LOAD 后缓存在内存中
SCRIPT LOAD "return redis.call('GET', 'foo')"
-- 返回 SHA1: 6b1bf486c81ceb7edf3c093f4c48582e38c0e791
-- 脚本会缓存在服务器的脚本缓存字典中

-- 查看缓存中的所有脚本
SCRIPT EXISTS <sha1> <sha2>...

-- 清空脚本缓存
SCRIPT FLUSH

存储特点：

HTTP 响应html时body体的分块行为

Fri, 14 Nov 2025 13:29:49 +0800

你观察到的这个现象非常有意思！这通常是由以下几种情况造成的：

1. 分块传输编码（Chunked Transfer Encoding）

这是最常见的原因。当服务器使用 Transfer-Encoding: chunked 时，响应体会被分成多个块传输。

示例结构：

1
2
3
4
5
6
7


HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked

2000 ← 第一个块的大小（16进制，8192字节）
{...json数据...} ← 实际的数据内容
0 ← 结束块（大小为0）

Wireshark 显示示例：

1
2
3
4
5
6
7
8


HTTP/1.1 200 OK\r\n
Content-Type: text/html;charset=utf-8\r\n
Transfer-Encoding: chunked\r\n
\r\n
2000\r\n
{"status": "success", "data": [...]}\r\n
0\r\n
\r\n

2. 自定义的响应格式

有些框架或中间件会添加自定义的头部信息：

1
2
3
4


// 类似这样的服务器端代码可能产生这种格式
response.getWriter().println("2000"); // 自定义长度标识
response.getWriter().println(jsonData);
response.getWriter().println("0"); // 结束标识

3. 调试或监控信息

开发环境中的中间件可能添加调试信息：

mysql 分析执行计划

Sat, 30 Aug 2025 16:17:15 +0800

完全不用担心！记不住 EXPLAIN 的输出字段是非常正常的，因为它包含的信息确实很多。这其实不是一个需要死记硬背的东西，而是一个需要理解其核心思想并通过查看来熟练使用的工具。

下面我给您一个超实用的 “三步速查指南” 和 核心字段详解，您以后遇到就翻出来看，看多了自然就熟了。

三步速查指南：如何快速判断SQL性能？

拿到一条 EXPLAIN 结果，不要一个个字段看晕了，按照这三个步骤来分析：

✅ 第一步：先看 `type` 列（访问类型）—— 这是最重要的指标！

这列告诉你 MySQL 如何查找数据。从好到坏排列，理想状态是尽量靠前：

类型 (值)	含义	性能	解读
`system`	系统表，只有一行数据	最佳	忽略，极少见。
`const`	通过主键或唯一索引一次就找到	极佳	`WHERE id = 1`，效率最高。
`eq_ref`	联表查询时，使用主键或唯一索引关联	极佳	常见于 `A JOIN B ON A.id = B.id`。
`ref`	使用普通非唯一索引查找	优秀	`WHERE name = 'Alice'`（name是普通索引）。
`range`	索引范围扫描	良好	`WHERE id > 100`，`BETWEEN`，`IN`。
`index`	全索引扫描	较差	比全表扫描好点，但需要扫描整个索引树。
`ALL`	全表扫描	最差	警报！性能杀手，需要优化。

您的例子解读： type: ALL -> 这是最坏的情况，说明MySQL正在对 com_order 表进行全表扫描，性能极差。

慢查询排行榜

Sat, 30 Aug 2025 15:31:24 +0800

事先申明这项目不是我写ヾ(o◕∀◕)ﾉヾ

Profile
Rank Query ID Response time Calls R/Call 
==== =================================== =============== ====== ======= 
 1 0x43213F365998840ACD9C3079B9E87DAE 857789.5898 ... 230501 3.7214 0.47 SELECT com_order
 2 0xDF3E01C0AD745FDFF16601E364C36572 107786.6011 ... 7621 14.1434 8.21 SELECT com_order_step
 3 0x8F9F477B37A66516C7CD43B477D3A270 68362.6915 ... 3105 22.0170 4.60 UPDATE com_order_detail
 4 0x4A0BE95958C84E7A96EDFB2C21FB67C1 61784.0898 ... 18351 3.3668 0.05 SELECT com_order
 5 0x118C6D89A59CD6963430E2D2D19BB258 47610.6692 ... 11604 4.1030 0.19 SELECT com_order
 6 0xE53F09B2262794BEC6E2688CAA143431 45380.2740 ... 12985 3.4948 0.06 SELECT com_order com_goods_co
 7 0x2C3A955FE023BE233878F80DEBE1C7F5 45306.2355 ... 10324 4.3884 2.03 SELECT com_order
 8 0x881AF4FC304C67F886CE7F4B92F5F836 32297.1495 ... 2164 14.9247 2.56 SELECT com_order com_goods co
 9 0xE2B66B13B936E38828F345F8840CB173 17972.5383 ... 943 19.0589 3.67 SELECT com_order com_goods co
 10 0xBA63E58F684365ED5EF9EBECF6211154 12255.0037 ... 633 19.3602 1.64 SELECT com_order com_goods co
 11 0x9AF174602EBD35D03339D52BD6BA454A 6755.3975 0.5% 976 6.9215 0.58 SELECT com_goods com_order
 12 0xAE8DB0A6FE47D628D931A483CCAE8A75 6587.3134 0.5% 737 8.9380 3.80 SELECT com_order com_goods co
 13 0x41CD552DAEB5C20B6442CE78748915D4 6388.0521 0.5% 1074 5.9479 0.38 SELECT com_goods com_order
 14 0x5821670C589337A3F5230781CA62B830 5463.3930 0.4% 1452 3.7627 0.88 UPDATE com_order
 17 0x29284E1C020294A86F3B5089534E1F25 3770.1613 0.3% 130 29.0012 0.02 SELECT com_order com_goods co
 18 0x4FD4F24768F143A7E142658B51C74256 3136.3929 0.2% 285 11.0049 5.74 SELECT com_order com_goods co
 19 0x7D5D8A24C7C014336145D6174DD83F54 3082.0708 0.2% 183 16.8419 1.81 SELECT com_order com_goods co
 20 0x827B61B85C77531BFAD687333071E9C2 2498.9570 0.2% 640 3.9046 1.01 SELECT com_goods com_order
 21 0x92DB913CB9BC963C7C2815C23F00603E 2251.8580 0.2% 75 30.0248 0.00 INSERT com_order_step
 22 0x1E42A48C29626389B6911D90A3C7BE41 2137.8542 0.2% 69 30.9834 1.65 INSERT com_order_detail
 23 0x55FA21C415B57A8C8BEE934489C5C092 2030.6716 0.1% 486 4.1783 0.17 SELECT com_order com_goods co
 24 0xB7098BC79C0AF47C49F17C710D3D3357 1920.8152 0.1% 64 30.0127 0.00 INSERT com_order
 25 0x3718B70A1AD6C2B67B67703C6EBE839C 1704.2796 0.1% 456 3.7375 0.01 SELECT com_order
 26 0x1FA49422BC44151C0D4FA0D8AA44BB27 1659.9687 0.1% 120 13.8331 0.01 SELECT com_order com_goods co
 27 0x5A7C30146FFACC7F55CC11096B93B354 1607.1963 0.1% 442 3.6362 0.28 SELECT com_order
 30 0x43D8E9778CDD92BE946D19B37645F74C 1196.9710 0.1% 218 5.4907 2.59 SELECT com_order_detail com_o
 31 0xFB9EE232DEF62B88A9E803150ABE2D9D 1163.1644 0.1% 52 22.3685 3.58 SELECT ers_cash_list com_orde
 32 0x342763F4807710266FE036FD2AC058B9 1137.1729 0.1% 59 19.2741 4.43 SELECT ers_cash_list com_orde
 33 0x37AE68F96E70CDFF548417176CAEB2AF 1002.2846 0.1% 209 4.7956 0.64 SELECT com_goods com_order
 34 0xCFD2BFF2205FD63DD0FF201E7734D7FD 865.9522 0.1% 178 4.8649 0.17 SELECT com_goods com_order
 35 0x6AF371BEED556B36FD41230774042645 810.7413 0.1% 27 30.0275 0.00 UPDATE com_order
 36 0xFB49BD352A70DA19A7B45E49CA0FB56A 755.3083 0.1% 82 9.2111 0.01 SELECT com_order com_goods co
 37 0x591DFEABF77D53A9DB97E97F66DB2BCC 686.2606 0.0% 173 3.9668 0.22 SELECT com_order com_goods co
 38 0xAD6FBF179A5CC50419715DCE46FC7EB1 682.1636 0.0% 182 3.7482 0.11 SELECT ers_cash_list com_orde
 39 0xE360E29586DD3B1FA65F5AE61988A6CB 676.1795 0.0% 141 4.7956 0.24 SELECT com_order com_goods co
 40 0xCB8BD72D494052A7A56DD28BDDFDCBDC 657.7839 0.0% 87 7.5607 0.47 SELECT com_order com_goods co
 41 0xB1E04439EF51C794A915EB4866531585 537.9265 0.0% 153 3.5159 0.01 SELECT com_order com_goods co
 42 0x594D5C2699347573F74DE0CDC2CEFC32 529.2930 0.0% 20 26.4647 0.55 SELECT ers_cash_list com_orde
 43 0x27D2F92EBA60A1D41619A371781312A2 503.5509 0.0% 96 5.2453 0.00 SELECT com_order com_goods co
 44 0xD3F5CCA83C841835CC79BAE5E68A8CFF 496.4855 0.0% 132 3.7613 0.10 SELECT ers_cash_list com_orde
 45 0x7D3AA779A8224BC6F6C452E880162A64 475.0059 0.0% 55 8.6365 1.97 SELECT com_order_detail com_o
 46 0xB5A0A353B20D286F197F13E71BBAFC81 444.7246 0.0% 117 3.8011 0.37 SELECT com_order
 47 0xC695CA39DA1088B7ED82E1BEB33B4B7B 419.5935 0.0% 15 27.9729 0.46 SELECT ers_cash_list com_orde
 48 0xB10F790621F5CA1C97B99EAA126E00B2 346.4819 0.0% 17 20.3813 4.26 SELECT ers_cash_list com_orde
 50 0x0C170F407F3F8F9BA2A097013DF2317A 333.6224 0.0% 24 13.9009 2.32 SELECT ers_cash_list com_orde

就贴出前五十个,留作纪念;

mysql慢日志分析--头部数据解读

Sat, 30 Aug 2025 14:58:52 +0800

起因:

领导突发奇想使用阿里云的dns解析做负载均衡,我感觉他之前可能只做过单机项目,所以想体验负载均衡,其实目前生产系统的业务量远远打不满的单机节点的,领导做事情不需要向大头兵解释,咱也不晓得他啥时候改的解析,事后来记录一下盘查慢日志的过程.

关于阿里云的域名dns

解析能配置多个ip,正常来说不会使用这种方式去做负载均衡,因为dns解析生效时间不可控,修改解析生效时间需要等待很长时间,阿里云要同步全球dns服务器,不同的客户端ip访问的dns服务器可能得到不同的结果.

特别是当你某台机器故障时,你是没办法即时清理掉这个故障节点的;

分析慢查询日志使用的工具是 pt-query-digest,下面是分析后的文件头部,汇总统计:

40.3s user time, 210ms system time, 68.71M rss, 263.14M vsz
Current date: Fri Aug 29 17:19:51 2025
Hostname: VM-0-13-centos
Files: mysql-slow.log
Overall: 308.93k total, 300 unique, 0.03 QPS, 0.15x concurrency ________
Time range: 2025-05-15T17:37:29 to 2025-08-29T09:19:39
Attribute total min max avg 95% stddev median
============ ======= ======= ======= ======= ======= ======= =======
Exec time 1384350s 3s 4979s 4s 6s 13s 4s
Lock time 230s 0 14s 743us 144us 61ms 103us
Rows sent 33.29M 0 2.37M 113.00 487.09 8.40k 0.99
Rows examine 629.53G 0 259.56M 2.09M 2.26M 1.90M 1.95M
Query size 46.40M 8 108.83k 157.50 271.23 308.67 124.25

这是一个MySQL慢查询日志分析报告的开头部分，逐行解释：

第2行 - 系统资源使用情况

1

# 40.3s user time, 210ms system time, 68.71M rss, 263.14M vsz

40.3s user time: 用户态CPU时间，表示分析工具本身运行了40.3秒
210ms system time: 内核态CPU时间，系统调用耗时210毫秒
68.71M rss: 常驻内存集大小，程序实际使用的物理内存约68.71MB
263.14M vsz: 虚拟内存大小，程序分配的虚拟内存约263.14MB

第3-6行 - 基本信息

1
2
3
4


# Current date: Fri Aug 29 17:19:51 2025
# Hostname: VM-0-13-centos
# Files: mysql-slow.log
# Overall: 308.93k total, 300 unique, 0.03 QPS, 0.15x concurrency ________

分析时间：2025年8月29日17:19:51
主机名：VM-0-13-centos
分析文件：mysql-slow.log
总体统计：
- 308.93k total: 总共308,930条慢查询记录
- 300 unique: 300种不同的查询模式
- 0.03 QPS: 平均每秒0.03个查询（非常低）
- 0.15x concurrency: 平均并发度0.15

第7行 - 时间范围

1

# Time range: 2025-05-15T17:37:29 to 2025-08-29T09:19:39

慢查询日志覆盖的时间范围：从2025年5月15日到8月29日，跨度约3个多月

pt-query-digest 完全指南：从入门到高级实战

Fri, 29 Aug 2025 17:35:34 +0800

一、什么是 pt-query-digest？

pt-query-digest 是 Percona Toolkit 中的明星工具，用于分析 MySQL 慢查询日志。它能够将庞大的慢日志文件转化为易懂的性能分析报告，帮助DBA快速定位数据库性能瓶颈。

二、安装与配置

安装方法

1
2
3
4
5
6
7
8


# CentOS/RHEL
sudo yum install percona-toolkit

# Ubuntu/Debian
sudo apt-get install percona-toolkit

# 使用docker
docker run -it --rm -v $(pwd):/data percona/percona-toolkit pt-query-digest --version

启用MySQL慢查询日志

1
2
3
4
5


-- 在MySQL中执行
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2; -- 超过2秒的查询记录
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL log_queries_not_using_indexes = 'ON';

三、基础使用

1. 基本分析

1
2
3
4
5
6
7
8


# 最简单的分析
pt-query-digest /var/log/mysql/slow.log

# 输出到文件
pt-query-digest slow.log > slow_report.txt

# 分析最近的文件
pt-query-digest /var/log/mysql/slow.log --since="24h"

2. 排序和限制

1
2
3
4
5
6
7
8


# 按执行时间排序，显示前10条
pt-query-digest slow.log --order-by=Query_time:sum --limit=10

# 按锁定时间排序
pt-query-digest slow.log --order-by=Lock_time:sum --limit=5

# 按执行次数排序
pt-query-digest slow.log --order-by=Count:sum --limit=10

3. 过滤特定查询

1
2
3
4
5
6
7
8


# 只分析SELECT语句
pt-query-digest slow.log --filter '$event->{arg} =~ m/^SELECT/i'

# 分析特定表的查询
pt-query-digest slow.log --filter '$event->{arg} =~ m/users/i'

# 排除特定用户
pt-query-digest slow.log --filter '$event->{user} !~ m/root/i'

四、中级应用

1. 生成不同类型的报告

1
2
3
4
5
6
7
8


# 生成HTML报告
pt-query-digest slow.log --report-format=html > report.html

# 生成JSON格式
pt-query-digest slow.log --report-format=json > report.json

# 详细查询报告
pt-query-digest slow.log --report-format=query_report

2. 时间范围分析

1
2
3
4
5
6
7
8


# 分析特定时间范围
pt-query-digest slow.log --since="2025-08-28 00:00:00" --until="2025-08-29 23:59:59"

# 分析最近12小时
pt-query-digest slow.log --since="12h"

# 分析特定时间段（每天9点到18点）
pt-query-digest slow.log --time-range="09:00-18:00"

3. 对比分析

1
2
3
4
5
6


# 两个时间段的对比
pt-query-digest slow.log --since="2025-08-20" --until="2025-08-25" > week1.txt
pt-query-digest slow.log --since="2025-08-26" --until="2025-08-29" > week2.txt

# 使用review模式存储历史数据
pt-query-digest slow.log --review h=localhost,D=monitor,t=query_review

五、高级实战技巧

1. 实时监控分析

1
2
3
4
5


# 实时分析当前进程
pt-query-digest --processlist h=localhost --interval 0.01 --print --no-stream

# 监控并只显示慢查询
pt-query-digest --processlist h=localhost --filter '$event->{Time} > 2' --interval 1

2. 高级过滤技巧

1
2
3
4
5
6
7
8


# 复合过滤：查询时间大于5秒且扫描行数大于10000
pt-query-digest slow.log --filter '$event->{Query_time} > 5 && $event->{Rows_examined} > 10000'

# 特定数据库和用户
pt-query-digest slow.log --filter '$event->{db} eq "mydb" && $event->{user} eq "app_user"'

# 错误查询分析
pt-query-digest slow.log --filter '$event->{Error} ne ""'

3. 生成可执行的优化建议

1
2


# 生成创建索引的建议
pt-query-digest slow.log --report-format=query_report --filter '$event->{Rows_examined} > 100000' | grep -A5 -B5 "SELECT\|UPDATE\|DELETE"

4. 与Explain结合分析

1
2
3
4
5


# 提取需要分析的SQL语句
pt-query-digest slow.log --order-by=Query_time:sum --limit=5 --output=slow_queries.sql

# 然后手动执行EXPLAIN分析
mysql -e "EXPLAIN SELECT * FROM users WHERE created_at > '2025-01-01';"

六、解读分析报告

报告关键指标解读

1
2
3
4
5
6
7
8


# Overall: 308.93k total, 300 unique, 0.03 QPS, 0.15x concurrency
# Time range: 2025-05-15T17:37:29 to 2025-08-29T09:19:39
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 1384350s 3s 4979s 4s 6s 13s 4s
# Lock time 230s 0 14s 743us 144us 61ms 103us
# Rows sent 33.29M 0 2.37M 113.00 487.09 8.40k 0.99
# Rows examine 629.53G 0 259.56M 2.09M 2.26M 1.90M 1.95M

Exec time: 查询执行时间，关注max和95%值
Rows examine: 扫描行数，值过大说明索引问题
Rows sent: 返回行数，与扫描行数比值越小越好
Lock time: 锁等待时间，过高可能有锁竞争

七、实战案例

案例1：分析并优化慢查询

1
2
3
4
5
6
7


# 1. 找出最耗时的查询
pt-query-digest slow.log --order-by=Query_time:sum --limit=3

# 2. 查看具体查询的执行计划
pt-query-digest slow.log --filter '$event->{fingerprint} =~ m/SELECT.*users/' --output=explain_queries.sql

# 3. 生成优化建议

案例2：监控生产环境实时性能

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


#!/bin/bash
# realtime_monitor.sh

while true; do
 echo "=== $(date) ==="
 pt-query-digest --processlist h=localhost \
 --filter '$event->{Time} > 2' \
 --order-by=Time:max \
 --limit=5
 sleep 30
done

案例3：每日性能报告

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


#!/bin/bash
# daily_report.sh

DATE=$(date +%Y%m%d)
REPORT_FILE="/tmp/mysql_report_$DATE.html"

pt-query-digest /var/log/mysql/slow.log \
 --since="24h" \
 --report-format=html \
 > $REPORT_FILE

# 发送邮件报告
mail -s "MySQL Daily Report $DATE" dba@company.com < $REPORT_FILE

八、常见问题排查

1. 内存不足处理

1
2


# 分析大文件时使用分段处理
pt-query-digest slow.log --memory-limit=1G --chunk-size=100000

2. 网络分析

1
2


# 分析远程数据库
pt-query-digest --processlist h=db-prod.example.com,u=monitor,p=password --interval=5

3. 批量处理多个文件

1
2


# 分析多个慢日志文件
pt-query-digest /var/log/mysql/slow.log*

九、最佳实践

定期分析：设置每天自动分析慢日志
建立基线：保存历史报告用于对比
重点关注：95%百分位的值比平均值更重要
结合监控：与Prometheus、Grafana等监控系统结合
团队协作：将报告分享给开发团队共同优化

十、总结

pt-query-digest 是MySQL性能优化不可或缺的工具。从简单的日志分析到复杂的性能监控，它都能提供有价值的见解。掌握这个工具，你就能：

mysql慢查询相关的属性

Fri, 29 Aug 2025 17:32:30 +0800

– 查看慢查询日志是否开启以及日志文件位置 SHOW VARIABLES LIKE ‘slow_query_log%’;

– 查看慢查询的时间阈值（单位：秒） SHOW VARIABLES LIKE ’long_query_time';

– 查看是否记录未使用索引的查询（即使它们执行得很快） SHOW VARIABLES LIKE ’log_queries_not_using_indexes';

– 查看慢查询日志的输出方式（FILE 或 TABLE） SHOW VARIABLES LIKE ’log_output';

慢查询sql分析工具:percona-toolkit安装

Fri, 29 Aug 2025 17:29:42 +0800

方法一：添加Percona官方Yum源（推荐）

1. 安装Percona的yum仓库

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 下载并安装Percona的yum源
sudo yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

# 启用Percona Toolkit仓库
sudo percona-release enable tools release

# 更新yum缓存
sudo yum makecache

# 安装percona-toolkit
sudo yum install percona-toolkit

方法二：使用EPEL仓库

1. 首先安装EPEL仓库

1
2
3
4
5


# 安装EPEL仓库
sudo yum install epel-release

# 再次尝试安装
sudo yum install percona-toolkit

方法三：直接下载RPM包安装

1. 手动下载并安装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 查看系统架构
arch

# 如果是x86_64架构，下载对应的RPM包
wget https://repo.percona.com/yum/release/7/RPMS/x86_64/percona-toolkit-3.5.5-1.el7.x86_64.rpm

# 安装下载的RPM包
sudo yum install percona-toolkit-3.5.5-1.el7.x86_64.rpm

# 或者使用rpm命令直接安装
sudo rpm -ivh percona-toolkit-3.5.5-1.el7.x86_64.rpm

方法四：使用tar包安装（无需root权限）

1. 下载二进制tar包

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 下载最新版本的tar包
wget https://www.percona.com/downloads/percona-toolkit/3.5.5/binary/tarball/percona-toolkit-3.5.5_x86_64.tar.gz

# 解压
tar -zxvf percona-toolkit-3.5.5_x86_64.tar.gz

# 进入目录
cd percona-toolkit-3.5.5

# 直接使用pt-query-digest
./bin/pt-query-digest --help

# 或者添加到PATH
echo 'export PATH=$PATH:/path/to/percona-toolkit-3.5.5/bin' >> ~/.bashrc
source ~/.bashrc

验证安装

安装完成后验证：

redis配置文件--gemini解读

Wed, 27 Aug 2025 16:07:41 +0800

好的，这是您提供的 Redis 配置文件（redis.conf）中注释部分的中文翻译。我将按照原文的结构和段落，为您逐一翻译。

配置注释翻译

文件头部（General）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 请注意，为了读取配置文件，Redis 必须以文件路径作为第一个参数启动：
#
# ./redis-server /path/to/redis.conf

# 单位说明：当需要指定内存大小时，可以使用常见的形式，如 1k, 5GB, 4M 等：
#
# 1k => 1000 字节
# 1kb => 1024 字节
# 1m => 1000000 字节
# 1mb => 1024*1024 字节
# 1g => 1000000000 字节
# 1gb => 1024*1024*1024 字节
#
# 单位不区分大小写，因此 1GB、1Gb 和 1gB 都表示相同的值。

模块 (MODULES)

深入浅出 TCP 协议：从水管到数据包的奇妙旅程

Fri, 22 Aug 2025 13:46:42 +0800

深入浅出 TCP 协议：从水管到数据包的奇妙旅程

今天我们深入探讨了 TCP (传输控制协议) 这一互联网基石的奥秘，从宏观的连接概念到微观的数据流转，希望能帮助大家更好地理解这个“幕后英雄”。

1. TCP 与应用层协议：自定义的挑战

问：如果我想基于 TCP 做一套自己的应用层协议需要具备哪些能力？

答：要在 TCP 之上构建自己的应用层协议，你需要深入理解网络编程基础、具备强大的协议设计能力，并考虑安全和性能。

核心能力包括：

网络编程基础： 熟练掌握 Socket 编程（创建、绑定、监听、连接、收发数据、关闭），并理解 TCP 的面向连接、可靠传输、流量控制、拥塞控制等特性。
协议设计能力： 这是核心。你需要定义：
- 消息格式： 明确消息头（包含类型、长度、序列号等元数据）和消息体。
- 消息边界： 解决 TCP 的“粘包”问题，常用方法是使用长度前缀或特殊结束符。
- 协议语义： 定义消息类型、操作、请求/响应模式、错误处理、会话管理（如心跳）等。
- 序列化/反序列化： 如何将数据结构转换为字节流发送，以及如何将字节流解析回数据结构（例如使用 JSON、Protocol Buffers 或自定义二进制格式）。
并发和多线程/多进程编程： 服务器端需要处理大量并发连接，你需要选择合适的并发模型（如多线程、多进程、事件驱动/异步 I/O）。
安全考虑： 如果处理敏感数据，需要考虑加密（建议直接使用 TLS/SSL）、认证、授权和数据完整性。
性能优化与可伸缩性： 包括数据压缩、连接池、负载均衡、缓存等。
工具与调试： 熟练使用 Wireshark 等抓包工具，并做好日志记录和测试。

问：HTTP 协议已被广泛使用，浏览器都支持。如果是我自定义的应用层协议，浏览器肯定不认识。例如我定义一个 HKKP 协议，首先肯定要有一套客户端发起请求的规范，消息体的数据结构如何定义，然后服务端要有对应的解码规范，我这样理解对吗？

答：你的理解完全正确！

构建自定义应用层协议的核心挑战就在于：

浏览器不认识： 浏览器只支持标准协议如 HTTP(S)。自定义协议需要你自己编写专门的客户端程序来“说”这种语言。
客户端规范： 你需要详细定义客户端如何构造 HKKP 请求，包括：
- 基于 TCP 建立连接。
- 请求的结构（例如：包含方法、路径、请求头、请求体等概念）。
- 字段的含义和数据编码方式（文本或二进制）。
服务端解码规范： 服务端必须严格按照客户端发送时的编码规范来解码和解析收到的字节流，才能正确理解请求内容。

简而言之，客户端和服务器必须遵循同一套你定义的“语言”规则，才能进行有效的通信。

tcpdump命令详解

Fri, 22 Aug 2025 13:45:16 +0800

tcpdump 是 Linux/Unix 系统中一款强大的命令行网络抓包工具，可实时捕获网络接口上的数据包并解析，常用于网络故障排查、协议分析、流量监控等场景。以下从基本语法、核心选项、过滤规则、高级用法及实用案例等方面详细讲解。

一、基本语法

tcpdump 的核心语法结构为：

1

tcpdump [选项] [过滤表达式]

选项：控制抓包的行为（如指定接口、输出格式、保存文件等）。
过滤表达式：筛选需要捕获的数据包（如指定主机、端口、协议等）。

二、核心选项详解

选项用于调整抓包的范围和输出方式，常用选项如下：

选项	作用	示例
-i <接口>	指定抓包的网络接口（如 eth0、lo）；-i any表示所有接口	tcpdump -i eth0（抓 eth0 接口的包）
-n	不进行 DNS 解析（直接显示 IP，不转主机名）	tcpdump -n（输出 IP 而非域名）
-nn	不解析 IP 和端口（端口显示数字，不转服务名如 80 不显示 http）	tcpdump -nn（IP 和端口均为数字）
-v/-vv/-vvv	增加输出详细程度（v：基本详情；vv：更多协议细节；vvv：最详细）	tcpdump -vv（显示较详细的包信息）
-c <数量>	只捕获指定数量的数据包后退出	tcpdump -c 10（抓 10 个包后停止）
-w <文件>	将捕获的原始数据包保存到文件（不解析，需用-r读取）	tcpdump -w traffic.pcap（保存到 traffic.pcap）
-r <文件>	从保存的文件中读取数据包（用于离线分析）	tcpdump -r traffic.pcap（读取 pcap 文件）
-s <长度>	设置抓包的 “快照长度”（默认 65535 字节，足够捕获完整包）	tcpdump -s 0（捕获完整包，0 等价于 65535）
-A	以 ASCII 码显示数据包内容（适合查看 HTTP 等文本协议）	tcpdump -A（直观查看数据包的文本内容）
-X	同时以十六进制和 ASCII 码显示数据包内容（兼顾二进制和文本）	tcpdump -X（十六进制 + ASCII 混合显示）
-e	显示数据链路层信息（如 MAC 地址、VLAN 标签）	tcpdump -e（输出包含源 / 目的 MAC）
-t	不显示时间戳	tcpdump -t（去掉输出中的时间）
-tttt	显示完整时间戳（格式：年 - 月 - 日时：分: 秒。微秒）	tcpdump -tttt（精确到微秒的时间）

三、过滤表达式（核心功能）

过滤表达式是 tcpdump 的灵魂，用于精准筛选目标数据包。表达式由 “类型 + 方向 + 协议” 组合而成，支持逻辑运算（and/or/not）。

MySQL与Oracle的主要区别1

Fri, 22 Aug 2025 13:39:26 +0800

MySQL和Oracle都是流行的关系型数据库管理系统，但它们在多个方面存在显著差异：

1. 公司所有权与许可

MySQL：最初由MySQL AB开发，现为Oracle公司所有，开源(GPL许可)和商业许可双模式
Oracle：Oracle公司专有商业软件，需要购买许可证

2. 架构与性能

MySQL：
轻量级设计
适合中小型应用
读写操作通常较快
支持有限的分区功能
Oracle：
企业级架构
针对大规模、高并发环境优化
高级分区选项(范围、列表、哈希、复合分区)
更复杂的优化器

3. 功能对比

存储过程/函数：
Oracle有更强大的PL/SQL
MySQL的存储过程功能相对简单
事务支持：
Oracle：完全ACID兼容，高级并发控制
MySQL：只有InnoDB引擎支持完整ACID
复制与高可用：
MySQL：主从复制简单易用
Oracle：Data Guard、RAC等企业级解决方案

4. 扩展性与集群

MySQL：
主要通过主从复制扩展
分片需要应用层实现
Oracle：
Real Application Clusters(RAC)支持多节点共享存储
自动存储管理(ASM)
高级数据分区

5. 安全性

Oracle提供更细粒度的安全控制：
虚拟私有数据库(VPD)
细粒度审计
数据加密选项更丰富

6. 成本

MySQL：社区版免费，企业版需付费
Oracle：许可证费用昂贵，按CPU核心计费

7. 使用场景

MySQL适合：
Web应用
中小型系统
需要快速开发的项目
预算有限的情况
Oracle适合：
大型企业应用
需要高可用性和灾难恢复的关键系统
复杂事务处理
数据仓库和大数据分析

8. SQL语法差异

两者在SQL语法上有一些不同，例如：

分页查询语法
日期函数
字符串处理函数
序列/自增字段的实现方式

技术 - DevOps on Loen blog

🧐 为什么 HttpServletRequest 的 Body 只能被读取一次？

🧐 为什么 HttpServletRequest 的 Body 只能被读取一次？

1. HTTP 请求体的本质是“输入流” (Input Stream)

2. 对比 List 或 Map 等集合

redis 中的lua脚本是如何执行的?

Redis 中 Lua 脚本的执行机制

1. Lua 脚本是如何执行的？

2. Lua 脚本以什么形式存在于 Redis 中？

HTTP 响应html时body体的分块行为

1. 分块传输编码（Chunked Transfer Encoding）

2. 自定义的响应格式

3. 调试或监控信息

mysql 分析执行计划

三步速查指南：如何快速判断SQL性能？

✅ 第一步：先看 type 列（访问类型）—— 这是最重要的指标！

慢查询排行榜

事先申明 这项目不是我写ヾ(o◕∀◕)ﾉヾ

mysql慢日志分析--头部数据解读

起因:

关于阿里云的域名dns

特别是当你某台机器故障时,你是没办法即时清理掉这个故障节点的;

分析慢查询日志使用的工具是 pt-query-digest,下面是分析后的文件头部,汇总统计:

这是一个MySQL慢查询日志分析报告的开头部分，逐行解释：

第2行 - 系统资源使用情况

第3-6行 - 基本信息

第7行 - 时间范围

pt-query-digest 完全指南：从入门到高级实战

一、什么是 pt-query-digest？

二、安装与配置

安装方法

启用MySQL慢查询日志

三、基础使用

1. 基本分析

2. 排序和限制

3. 过滤特定查询

四、中级应用

1. 生成不同类型的报告

2. 时间范围分析

3. 对比分析

五、高级实战技巧

1. 实时监控分析

2. 高级过滤技巧

3. 生成可执行的优化建议

4. 与Explain结合分析

六、解读分析报告

报告关键指标解读

七、实战案例

案例1：分析并优化慢查询

案例2：监控生产环境实时性能

案例3：每日性能报告

八、常见问题排查

1. 内存不足处理

2. 网络分析

3. 批量处理多个文件

九、最佳实践

十、总结

mysql慢查询相关的属性

慢查询sql分析工具:percona-toolkit安装

方法一：添加Percona官方Yum源（推荐）

1. 安装Percona的yum仓库

方法二：使用EPEL仓库

1. 首先安装EPEL仓库

方法三：直接下载RPM包安装

1. 手动下载并安装

方法四：使用tar包安装（无需root权限）

1. 下载二进制tar包

验证安装

redis配置文件--gemini解读

配置注释翻译

深入浅出 TCP 协议：从水管到数据包的奇妙旅程

深入浅出 TCP 协议：从水管到数据包的奇妙旅程

1. TCP 与应用层协议：自定义的挑战

问：如果我想基于 TCP 做一套自己的应用层协议需要具备哪些能力？

tcpdump命令详解

一、基本语法

二、核心选项详解

三、过滤表达式（核心功能）

MySQL与Oracle的主要区别1

1. 公司所有权与许可

🧐 为什么 `HttpServletRequest` 的 Body 只能被读取一次？

2. 对比 `List` 或 `Map` 等集合

✅ 第一步：先看 `type` 列（访问类型）—— 这是最重要的指标！

事先申明这项目不是我写ヾ(o◕∀◕)ﾉヾ