SSpiritsの秘密基地

网络抓包分析案例：SNI 阻断

Thu, 01 May 2025 11:02:00 +0800

背景

某客户反馈其部分终端设备无法访问我方服务，故障现象呈现设备选择性断连的特征，需要我们协助排查。好在该问题可以稳定复现，所以我们请客户在测试环境中复现问题并进行抓包，于是便开始了本次排查之旅

mTLS 认证排查

因为客户使用 mTLS 进行认证和加密连接，并且只有部分设备出现问题。所以优先怀疑设备客户端证书非法或者过期。我们的服务端实现了对客户端证书链的校验逻辑，在证书校验不通过时会记录审计日志。所以我们请客户在测试环境中复现问题并进行抓包，希望能够拿到用户设备使用的证书以便于我们进行排查：

设备侧网络抓包

看到这个抓包文件就发现事情并不这么简单：报文中并没有证书交换的过程，只有一个 Client Hello 报文，然后收到了 RST 报文导致连接重置。这说明服务端在没有接收到客户端证书的情况下断开了连接，我们在服务端的审计日志中没有在用户抓包时段看到任何证书校验失败的记录也佐证了这点

由于应用层无有效信息，需要进一步在服务端执行网络抓包以定位问题

网络链路分析

在开始服务端抓包之前首先需要梳理一下网络链路：客户的设备通过公网访问我们的服务，用户侧没有网关设备。但是在服务侧有接入网关和负载均衡器，用户的设备通过自定义的域名 CNAME 解析到我们的接入网关，接入网关会将请求转发到应用服务器。整个链路大致如下：

用户终端设备
 |
 | 公网
 |
公网接入网关
 |
 | 内网
 |
L4 负载均衡器
 |
 | 内网
 |
应用服务器

直觉上怀疑用户网络环境上的 DNS 配置有问题，导致流量没有打到我们服务的接入网关上，而是被劫持到其他地方。但是通过对比用户侧正常的设备和异常的设备的抓包，发现 DNS 解析的结果是一样的，说明 DNS 解析没有问题

接下来我们在应用服务器上进行抓包，验证客户设备的请求是否正常抵达，以排除网络路由的问题

抓包分析

通过和用户约定时间同时抓包发现，确实有请求到达了我们的应用服务器：

服务端网络抓包

但是对比客户端抓包，并没有出现 Client Hello 报文，并且更奇怪的是服务端抓包显示 RST 报文来自对端！也就是说客户端和服务端均认为对方发了 RST 报文，那么大概率就是“中间人”同时向两侧发的 RST 报文

那么怎么快速判断所谓的“中间人”是哪一侧的网络设备呢？这里有个小技巧，可以通过 TTL 来判断：

服务端的流量记录：收到了三个来自客户端的报文

SYN：TTL=52
ACK：TTL=52
RST：TTL=52

客户端的流量记录：这里客户端收到了三个来自服务端的报文

SYN, ACK：TTL=50
RST：TTL=64

可以看到客户端收到的报文的 TTL 值改变了，这说明客户端收到的 RST 报文不是服务端发的，而且相比于服务端的 TTL 值更大。可以推测出这个 RST 报文可能是来自于靠近用户侧的网络设备发出

结论

考虑到用户使用公网自定义域名访问，并且在发出 Client Hello 报文后就被重置连接，怀疑是遭遇了 SNI 阻断。向用户反馈了这个情况后，用户和他们的运营商进行了联系发现是运营商一侧的网络配置问题导致，本次事件也算是圆满解决了

MCP with GraphQL —— LLM 大模型高效访问异构数据源

Sat, 29 Mar 2025 23:25:00 +0800

在 RocketMQ 的日常运维中，我们经常需要访问不同的数据源来获取诊断信息。传统的方式往往需要编写复杂的查询语句，或者在多个系统之间切换，效率低下

为了解决这个问题，我们使用 LLM 结合 MCP 来实现高效的数据访问。通过这种方式，可以用自然语言一站式查询所需的信息，提高运维效率

传统方法对比大模型

前言

在 RocketMQ 的日常运维中，我们经常需要访问不同的数据源来获取诊断信息。下图是我们诊断问题时需要访问的常见数据源和他们提供的查询接口：

flowchart TD subgraph Observability direction LR Metrics["Metrics (WebUI/PromQL)"] Logs["Logs (WebUI/SQL)"] Trace["Trace (WebUI/gRPC)"] end subgraph External Storage direction LR ObjectStorage["Object Storage (WebUI/S3 API)"] DB["Database (WebUI/SQL)"] ConfigCenter["Config Center (WebUI/REST API)"] end subgraph Runtime Data direction LR NameServer["RocketMQ NameServer (CLI/Binary Protocol)"] Broker["RocketMQ Broker (CLI/Binary Protocol)"] end subgraph IaaS Data direction LR Kubnetes["Kubernetes (WebUI/K8S API)"] end

一般来说运维人员如果想要获取某个数据源的信息，通常需要先登录到对应的系统，然后编写查询语句，最后再解析返回的结果。这不但需要运维人员熟悉每个数据源的查询语法，还需要在不同的系统之间切换，效率低下

聪明的团队会开发一个“运营系统”，提供统一的查询界面。但是仍然没有解决反复切换工具，查询碎片化的问题；更进一步可以将常见的排查过程中用到的工具串联到一起，形成一个“查询流水线”。但是这样的系统往往需要排查问题的专家经验沉淀、大量的开发和维护工作，且难以适应快速变化的需求

为了解决这个问题，我们可以使用 LLM 结合 MCP 来实现高效的数据访问。通过这种方式，用自然语言一站式查询所需的信息，提高问题诊断的效率

Talk is cheap, show me the demo!

LLM Workflow

借助 LLM + Chatbox + MCP + GraphQL 的组合，用自然语言查询 RocketMQ 集群的状态、Topic 的信息、消息的内容等

查询集群和节点

查询 Topic

查询消息

Awesome！理论上只要是在我们系统内的信息，都可以通过一次自然语言交互查出来，并且可以连续追问直到找到问题根因。再也不需要访问一大堆服务，编辑命令行参数/SQL 或者在前端界面之间跳来跳去了

实现原理

LLM 大语言模型

在这个组合（LLM + Chatbox + MCP + GraphQL）中，LLM 充当了自然语言处理的核心组件。用户通过 Chatbox 输入自然语言查询，LLM 将其转换为 GraphQL 查询语句，并通过 MCP （大模型调用工具的协议，这里可以认为是 GraphQL 客户端）提交到后端服务。后端服务返回的 JSON 格式查询结果又会被 LLM 转换为人类更易懂的格式，从而实现了自然语言与数据源之间的高效交互

Chatbox 中的对话

对应的 GraphQL 查询和结果

图中的 introspect-schema 用来获取 GraphQL 的 schema 信息，帮助 LLM 理解数据结构和字段

实际上只需要在开始对话的时候调用一次即可，这里每次交互都调用是因为博主使用的 Chatbox 没有正确使用 MCP 协议，换成支持 MCP Resources 的工具例如 Claude Desktop 就可以避免多次请求 schema

通过 LLM 来组织查询相比于传统的运营系统，可以节约开发大量页面的成本，能够按需获取想要查询的字段，并且自适应数据结构的演进。为了最大化利用 LLM 的查询灵活性，我们引入了 GraphQL 作为数据查询的中间层

道理我都懂，为什么是 GraphQL？

GraphQL 是一种用于提供 API 的查询语言，它允许客户端指定所需的数据结构和字段。我们使用 GraphQL 作为连接 LLM 和所有数据源的桥梁： LLM 使用 GraphQL 描述要查询的数据，在一次查询中访问多种数据源

回忆一下本文开头列出的多种数据源，我们取其中 Runtime Data 中的 RocketMQ Broker 数据源为例，它的数据模型大致如下所示：

flowchart TD subgraph Cluster direction LR Broker_One -->|包含| Topic_A Broker_One -->|包含| Topic_B Broker_One -->|包含| Group_X subgraph Topic direction LR Topic_A -->|包含| Queue_A1 Topic_A -->|包含| Queue_A2 Topic_B -->|包含| Queue_B1 Queue_A1 -->|包含| Message_A1 Queue_A2 -->|包含| Message_A2 Queue_B1 -->|包含| Message_B1 end subgraph Group direction LR Group_X -->|包含| Consumer_A Group_X -->|包含| Consumer_B Consumer_A -->|消费| Message_A1 Consumer_B -->|消费| Message_B1 Consumer_B -->|消费| Message_A2 end end

我们将这个数据模型组织成一个树状的结构，GraphQL 的查询语法非常适合这种树状结构的查询：可以通过 GraphQL 的嵌套查询来获取 Broker、Topic、Queue 和 Message 之间的关系

例如，我们可以通过以下的 GraphQL 查询语句来获取 Broker_One 中 Topic_A 的队列 0 的相关信息：

query {
 # 查询 Broker节点 Broker_One
 brokers(name: "Broker_One") {
 # 查询该 Broker 节点的接入点
 addr

 # 查询 Broker 节点的配置项 messageIndexEnable
 config(name: "messageIndexEnable") {
 name
 value
 }

 # 查询该 Broker 节点的 Topic 信息：Topic_A
 topics(name: "Topic_A") {

 # 查询该 Topic 的队列 0
 queues(id: 0) {
 # 查询该队列的消息数（maxOffset - minOffset）
 minOffset
 maxOffset

 # 查询该队列的第 100 条消息
 messages(offset: 100) {
 id
 payload
 }
 }
 }
 }
}

这个查询会被翻译成对 RocketMQ Broker 数据源以下接口的调用：

Broker 信息（接入点）
Broker 配置项（messageIndexEnable）
Topic 信息（队列数）
Topic 队列的信息（minOffset、maxOffset）
Topic 的消息（该队列第 100 条消息）

也就是说，我们通过 GraphQL 的嵌套查询语法将 5 个查询组合在一起。上面只是一个简单的例子，实际上可以组合面向不同数据源的查询。不管他们提供的是 REST API 还是 Binary Protocol 都可以合并到一个 GraphQL 查询中。对于 LLM 来说这样做尤其有意义：

简化开发：不需要为每种数据源编写单独的 MCP Server，统一使用 GraphQL 作为数据查询的中间层，用 GraphQL 的 schema 来帮助 LLM 理解数据结构
简化查询：LLM 只需要理解 GraphQL 的查询语法，而不需要了解每个数据源的具体实现细节。对于复杂的查询可以有效降低 LLM 的理解难度，减少出错的概率
减少查询次数：通过一次 GraphQL 查询，可以获取多个数据源的信息，减少了多次 LLM 调用的 Token 开销
降低上下文开销：不需要组织多次查询，也不需要输入多种 MCP tools 的参数和用法。可以将 LLM 有限的上下文用于描述问题的本质
灵活变更数据结构：GraphQL 自带 schema，对于 LLM 来说可以通过 schema 来获取数据的字段和不同数据结构之间的关系。简而言之我们提供的查询接口是自描述的，可以随时增加新的数据结构，LLM 也能自动适应

总结与后续展望

通过 LLM + Chatbox + MCP + GraphQL 的组合，我们实现了对多个异构数据源的高效查询。用户不需要具备大量的排查经验和对系统的深入理解，只需要用自然语言描述所需的信息，系统就能自动生成查询语句并返回结果。这种方式不仅提高了排查问题效率，还降低了对运维人员的技术要求

目前我们实现了 LLM 高效访问数据，并且通过 GraphQL 的 schema 能够理解多种数据结构之间的关联。下一步我们将继续迭代这个系统，将我们问题排查的专家经验以知识库的形式输入到 LLM 中，帮助 LLM 不仅能理解数据，更能理解问题的本质。最终实现一个一站式问题排查系统，让 LLM 能够自动化地完成问题排查的工作

Java 应用内存占用异常排查思路

Thu, 23 Nov 2023 16:00:00 +0800

本文用一个线上问题的排查过程来介绍 Java 应用的内存管理，以及 Linux 内存分析工具的使用，供读者排查 Java 应用的内存泄露和 OOM 问题时参考

前情提要

博主自信满满压测一晚，结果隔天早上查看监控发现 Java 进程占用内存远超预期，于是便开始了本文艰辛的排查之旅

这个场景的技术栈是 Java 17 + ZGC，但是本文介绍的方法也适用于排查其他版本 Java 应用的内存泄露和 OOM 问题

我们知道 Java 应用的内存可以分为三种：

堆内存：Java 对象分配的空间
堆外内存：方法区、线程栈、Direct Buffer 等
非 JVM 内存：native library 分配的内存

博主的应用使用了 NIO ByteBuffer + Netty + RocksDB 可谓是五毒俱全，所以我们需要先确认内存泄露发生在哪个内存区域

分析堆内存溢出

堆内存泄露问题最容易分析：设置 VM 参数 -XX:+HeapDumpOnOutOfMemoryError 在应用崩溃时 dump 堆内存，或者使用 jmap -dump:format=b,file=heap.bin <pid> 手动 dump 堆内存。然后通过 MAT/JProfiler 等工具对大对象进行引用分析即可得知内存泄露的原因

不幸的是博主的应用没有生成堆转储文件，通过 JVM 监控也可以得知在运行期间，堆内存使用率几乎没有增长，那么泄漏必然是在堆外发生

分析堆外内存溢出

方法区、线程栈导致的堆外内存溢出会导致 JVM 崩溃并在运行目录下产生 hs_err_pid<pid>.log 文件，查看报错的线程栈可以分析出 VM 参数设置不合理或开启线程过多等原因

另外一种堆外内存是 DirectByteBuffer / FileChannel.map 等分配的内存，这部分内存可以使用 -XX:MaxDirectMemorySize=size 限制，但是这个选项只会影响到 java.nio 包下的内存分配，详见 JDK 的文档：

-XX:MaxDirectMemorySize=size

Sets the maximum total size (in bytes) of the java.nio package, direct-buffer allocations. Append the letter k or K to indicate kilobytes, m or M to indicate megabytes, or g or G to indicate gigabytes. By default, the size is set to 0, meaning that the JVM chooses the size for NIO direct-buffer allocations automatically.

博主应用的缓存池使用了 Netty 提供的 ByteBuf，底层正是使用 java.nio.DirectByteBuffer

堆外内存也受 JVM 管控，可以使用 JVM 提供的 Native Memory Tracking 来分析。添加 VM 参数 -XX:NativeMemoryTracking=[off | summary | detail] 来开启 NMT，重启 JVM 后即可使用 jcmd 工具来查看 NMT 数据：

jcmd <pid> VM.native_memory [summary | detail | baseline | summary.diff | detail.diff | shutdown] [scale= KB | MB | GB]

NMT 会输出类似下面的报告：

jcmd 1713702 VM.native_memory summary scale=MB
1713702:

Native Memory Tracking:

(Omitting categories weighting less than 1MB)

Total: reserved=207768MB, committed=6213MB
 malloc: 1823MB #670978
 mmap: reserved=205945MB, committed=4390MB

- Java Heap (reserved=196608MB, committed=4096MB)
 (mmap: reserved=196608MB, committed=4096MB)

- Class (reserved=260MB, committed=14MB)
 (classes #17028)
 ( instance classes #16123, array classes #905)
 (malloc=4MB #74947) 
 (mmap: reserved=256MB, committed=11MB)
 ( Metadata: )
 ( reserved=128MB, committed=82MB)
 ( used=82MB)
 ( waste=0MB =0.43%)
 ( Class space:)
 ( reserved=256MB, committed=11MB)
 ( used=10MB)
 ( waste=0MB =4.21%)

- Thread (reserved=472MB, committed=50MB)
 (thread #472)
 (stack: reserved=471MB, committed=49MB)
 (malloc=1MB #2839) 
 (arena=1MB #941)

- Code (reserved=248MB, committed=83MB)
 (malloc=6MB #23199) 
 (mmap: reserved=242MB, committed=77MB)

- GC (reserved=8336MB, committed=176MB)
 (malloc=112MB #48322) 
 (mmap: reserved=8224MB, committed=64MB)

- Compiler (reserved=4MB, committed=4MB)
 (malloc=4MB #2150) 

- Internal (reserved=6MB, committed=6MB)
 (malloc=6MB #57737) 

- Other (reserved=1658MB, committed=1658MB)
 (malloc=1658MB #613) 

- Symbol (reserved=18MB, committed=18MB)
 (malloc=16MB #432773) 
 (arena=2MB #1)

- Native Memory Tracking (reserved=11MB, committed=11MB)
 (malloc=1MB #7935) 
 (tracking overhead=10MB)

- Shared class space (reserved=16MB, committed=12MB)
 (mmap: reserved=16MB, committed=12MB)

- Serviceability (reserved=1MB, committed=1MB)
 (malloc=1MB #14544) 

- Metaspace (reserved=128MB, committed=83MB)
 (mmap: reserved=128MB, committed=82MB)

Java 11 之后 DirectByteBuffer 使用的内存被归入 Other 中（之前是 Internal），我们需要关注的是其中的 committed 部分，代表了真实使用的物理内存。这里可以发现 DirectByteBuffer 只占用了 1658MB 内存，并不是发生内存泄露的原因

根据 JDK 和操作系统版本的不同，committed 的数值可能会大于等于操作系统计算的 RSS。具体原因和修复方案可以参考 JDK-8191369 和 JDK-8249666

分析非 JVM 内存溢出

通过上述排查流程，我们已经确认了泄露的内存并不受 JVM 的管控，这就需要深入到对操作系统内存分配情况的分析

换用 jemalloc

Java 默认使用 glibc 的 malloc，有时会出现碎片问题，可以使用 jemalloc 替代并开启分析功能：

apt install libjemalloc-dev
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
# 每分配 128K 内存记录堆栈信息，每分配 1GB 内存输出到文件
export MALLOC_CONF=prof:true,lg_prof_interval:30,lg_prof_sample:17

重启应用后在运行目录下会生成类似 jeprof.<pid>.0.i0.heap 的文件，我们可以使用 jeprof 来输出内存分配情况

jeprof --svg `which java` jeprof*.heap > jeprof.svg

Jemalloc Prof

这里看到分配内存占比 89% 的函数是 Unsafe_AllocateMemory0。但是 jemalloc 不能进一步分析 java 虚拟机的堆栈，我们需要进一步配合 async-profler 生成火焰图：

# 可以将 Unsafe_AllocateMemory0 换成其他任何想观测的函数名
./profiler.sh -d <duration> -e Unsafe_AllocateMemory0 -f unsafe_allocate.html <pid>

Flame Graph

生成的火焰图中可以看到 Unsafe_AllocateMemory0 分配的内存实际上是 DirectByteBuffer 使用的，这和 NMT 的报告中显示的占用量基本一致，并不是导致内存占用异常的元凶

Other (reserved=1658MB, committed=1658MB)
 (malloc=1658MB #613)

分析内存分布

既然应用运行中没有明显的内存泄露，那么就需要看下消耗的内存用在了哪里：

cat /proc/2031108/status
Name: java
...
RssAnon: 805844 kB
RssFile: 38036 kB
RssShmem: 12582912 kB

占用内存最多的 RssShmem 有 12G，这是个很不同寻常的情况，一般来说 page cache 以及 mmap 进行文件映射都会算到 RssFile 上。接下来需要进一步找到这 12G 的内存用在了哪里，我们可以使用 pmap 来查看内存分布：

pmap -x 2031108
Address Kbytes RSS Dirty Mode Mapping
0000040000000000 4194304 4194304 4194304 rw-s- memfd:java_heap (deleted)
0000040100000000 62914560 0 0 ----- [ anon ]
0000080000000000 4194304 4194304 4194304 rw-s- memfd:java_heap (deleted)
0000080100000000 62914560 0 0 ----- [ anon ]
0000100000000000 4194304 4194304 4194304 rw-s- memfd:java_heap (deleted)
0000100100000000 62914560 0 0 ----- [ anon ]

很容易发现疑似的内存区域，java 堆被映射到了三个虚拟内存地址上：40000000000、80000000000、100000000000。博主应用的堆大小设置为 4G，理论上映射了三次就产生了 12G 的 RssShmem 占用。为了验证这个猜想接下来 dump 这三段内存比较其中的内容：

dd if="/proc/2031108/mem" of="/dev/stdout" bs=1 skip=$((0x40000000000)) count=128 | hexdump
128+0 records in
128+0 records out
128 bytes copied, 0.000292939 s, 437 kB/s
0000000 0001 0000 0000 0000 1550 0000 0003 0000
0000010 e938 0005 0400 0000 e970 0005 0400 0000
0000020 e9c0 0005 0400 0000 0001 0000 0000 0000
0000030 1550 0000 0007 0000 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
*
0000070 0001 0000 0000 0000 1550 0000 0020 0000
0000080

dd if="/proc/2031108/mem" of="/dev/stdout" bs=1 skip=$((0x80000000000)) count=128 | hexdump
128+0 records in
128+0 records out
128 bytes copied, 0.000298448 s, 429 kB/s
0000000 0001 0000 0000 0000 1550 0000 0003 0000
0000010 e938 0005 0400 0000 e970 0005 0400 0000
0000020 e9c0 0005 0400 0000 0001 0000 0000 0000
0000030 1550 0000 0007 0000 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
*
0000070 0001 0000 0000 0000 1550 0000 0020 0000
0000080

dd if="/proc/2031108/mem" of="/dev/stdout" bs=1 skip=$((0x100000000000)) count=128 | hexdump
128+0 records in
128+0 records out
128 bytes copied, 0.000330489 s, 387 kB/s
0000000 0001 0000 0000 0000 1550 0000 0003 0000
0000010 e938 0005 0800 0000 e970 0005 0800 0000
0000020 e9c0 0005 0800 0000 0001 0000 0000 0000
0000030 1550 0000 0007 0000 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
*
0000070 0001 0000 0000 0000 1550 0000 0020 0000
0000080

可以发现这些内容是完全一致的，那么就找到了罪魁祸首：正是这三个堆内存映射造成了内存占用飙高的问题

知其所以然

我们发现了元凶首恶，但是还需要进一步分析为什么映射的内存会被算为 RssShmem 以及为什么会出现三次映内存映射

匿名文件映射

首先来看一下映射的文件 memfd:java_heap (deleted)，其中 memfd 是 Linux 的一个特性，可以创建一个匿名文件驻留在内存中。这个文件不会出现在文件系统中，只能通过 /proc/<pid>/fd 查看，映射的内容会在进程退出时被释放

这个文件的 fd 和普通的 fd 并无二致，自然也能使用 mmap 来创建文件映射，多次映射同一个文件会共享同一块物理内存，可以通过类似下面的代码来实现：

// 1G
static int SIZE = 1024 * 1024 * 1024;

int fd = syscall(SYS_memfd_create, "shma", 0);
ftruncate(fd, SIZE);

void *ptr0 = mmap(NULL, SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
memset(ptr0, 'A', SIZE);

void *ptr1 = mmap(NULL, SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
memset(ptr1, 'B', SIZE);

void *ptr2 = mmap(NULL, SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
memset(ptr2, 'C', SIZE);

这段代码会创建一个匿名文件，然后映射三次并分别写入 A、B、C 三种字符：

cat /proc/2306924/status
Name: memfd_create
...
RssAnon: 96 kB
RssFile: 1320 kB
RssShmem: 3145540 kB

pmap -x 2306924
2306924: ./memfd_create
Address Kbytes RSS Dirty Mode Mapping
00007f1b16ee7000 1048576 1048576 1048576 rw-s- memfd:shma (deleted)
00007f1b56ee7000 1048576 1048576 1048576 rw-s- memfd:shma (deleted)
00007f1b96ee7000 1048576 1048576 1048576 rw-s- memfd:shma (deleted)

dd if="/proc/2306924/mem" of="/dev/stdout" bs=1 skip=$((0x00007f1b16ee7000)) count=128
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC128+0 records in
128+0 records out
128 bytes copied, 0.000432721 s, 296 kB/s

可以看到创建的匿名文件被映射了三次，并且对应进程的 RssShmem 也是 3G

ZGC 中堆内存映射

需要回答的下一个问题是：为什么 Java 将堆内存映射三次？这源于 ZGC 引入的指针染色技术，即用对象指针中的某几位来作为 GC 标记，这样就不需要额外的对象头空间来记录 GC 标记了。比如我们用 16 进制下的对象指针最高位来作为 GC 标记，那么指向 0x13210 的对象 GC 标记是 0x1，地址是 0x3210

对于计算机来说，可以用掩码实现从对象指针中提取 GC 标记和对象地址：

Pointer value: 0x13210 : 0001 0011 0010 0001 0000
Metadata mask: & 0xf0000 : 1111 0000 0000 0000 0000
Metadata bits: 0x1 : 0001

Pointer value: 0x13210 : 0001 0011 0010 0001 0000
Address mask: & 0x0ffff : 0000 1111 1111 1111 1111
Address bits: 0x3210 : 0011 0010 0001 0000

每次访问对象时，都需要将 GC 标记位清零以得到真实的地址，这是不可忽略的开销。ZGC 使用多重映射技术巧妙的避免了这个问题。考虑到 0x13210、0x23210 都指向同一个对象，那么我们可以将这两个地址映射到同一块物理内存上，这样就可以避免每次访问对象时的掩码操作：

+-----------+ 0x10000
| |
| X | 0x13210 -----+ +----------------------+
| | \ | |
+-----------+ 0x20000 +---> | X @ offset 0x3210 |
| | / | |
| X | 0x23210 -----+ +----------------------+
| |
+-----------+ 0x30000

我们将堆映射到 0x10000~0x20000 和 0x20000~0x30000 这两个虚拟内存空间上。只要相对于 0x10000 和 0x20000 的偏移量相同，就能访问到同一块物理内存

这是一种空间换时间的做法。实际上浪费的空间是虚拟内存的空间，用页表的开销换取了每次对象访问时的掩码操作，是一个非常值得的 trade off

更详细的设计可以参考 OpenJDK Wiki

观测真实内存占用

Linux 中一个进程占用的内存有多种统计方式，可以分为 VSS、RSS、PSS、USS：

VSS：Virtual Set Size，进程申请的虚拟内存大小
RSS：Resident Set Size，进程的常驻内存大小，包括代码段、堆、栈、共享库、映射文件等
PSS：Proportional Set Size，进程的比例内存大小，RSS 中的共享内存按照比例分摊到各个进程
USS：Unique Set Size，进程独占的内存大小，RSS 中的共享内存不计入 USS

我们可以通过 PSS 来观测真实的内存占用情况，这里使用了 /proc/[pid]/smaps_rollup 来查看 PSS：

cat /proc/2306924/smaps_rollup
5626d2e58000-7ffca670f000 ---p 00000000 00:00 0 [rollup]
Rss: 3147164 kB
Pss: 1048716 kB
Pss_Anon: 100 kB
Pss_File: 40 kB
Pss_Shmem: 1048575 kB
Shared_Clean: 1324 kB
Shared_Dirty: 3145728 kB
Private_Clean: 12 kB
Private_Dirty: 100 kB
Referenced: 3147164 kB
Anonymous: 100 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
FilePmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB

可以发现 Pss_Shmem 是 RssShmem 的三分之一，更能反应真实内存占用

RocketMQ 多级存储设计与实现

Sun, 26 Feb 2023 10:45:00 +0800

随着 RocketMQ 5.1.0 的正式发布，多级存储作为 RocketMQ 一个新的独立模块到达了 Technical Preview 里程碑：允许用户将消息从本地磁盘卸载到其他更便宜的存储介质，可以用较低的成本延长消息保留时间。本文详细介绍 RocketMQ 多级存储设计与实现

设计总览

RocketMQ 多级存储旨在不影响热数据读写的前提下将数据卸载到其他存储介质中，适用于两种场景：

冷热数据分离：RocketMQ 新近产生的消息会缓存在 page cache 中，我们称之为热数据；当缓存超过了内存的容量就会有热数据被换出成为冷数据。如果有少许消费者尝试消费冷数据就会从硬盘中重新加载冷数据到 page cache，这会导致读写 IO 竞争并挤压 page cache 的空间。而将冷数据的读取链路切换为多级存储就可以避免这个问题
延长消息保留时间：将消息卸载到更大更便宜的存储介质中，可以用较低的成本实现更长的消息保存时间。同时多级存储支持为 topic 指定不同的消息保留时间，可以根据业务需要灵活配置消息 TTL

RocketMQ 多级存储对比 Kafka 和 Pulsar 的实现最大的不同是我们使用准实时的方式上传消息，而不是等一个 CommitLog 写满后再上传，主要基于以下几点考虑：

均摊成本：RocketMQ 多级存储需要将全局 CommitLog 转换为 topic 维度并重新构建消息索引，一次性处理整个 CommitLog 文件会带来性能毛刺
对小规格实例更友好：小规格实例往往配置较小的内存，这意味着热数据会更快换出成为冷数据，等待 CommitLog 写满再上传本身就有冷读风险。采取准实时上传的方式既能规避消息上传时的冷读风险，又能尽快使得冷数据可以从多级存储读取

Quick Start

多级存储在设计上希望降低用户心智负担：用户无需变更客户端就能实现无感切换冷热数据读写链路，通过简单的修改服务端配置即可具备多级存储的能力，只需以下两步：

修改 Broker 配置，指定使用 org.apache.rocketmq.tieredstore.TieredMessageStore 作为 messageStorePlugIn
配置你想使用的储存介质，以卸载消息到其他硬盘为例：配置 tieredBackendServiceProvider 为 org.apache.rocketmq.tieredstore.provider.posix.PosixFileSegment，同时指定新储存的文件路径：tieredStoreFilepath

可选项：支持修改 tieredMetadataServiceProvider 切换元数据存储的实现，默认是基于 json 的文件存储

更多使用说明和配置项可以在 GitHub 上查看多级存储的 README

技术架构

architecture

接入层：TieredMessageStore/TieredDispatcher/TieredMessageFetcher
接入层实现 MessageStore 中的部分读写接口，并为他们增加了异步语意。TieredDispatcher 和 TieredMessageFetcher 分别实现了多级存储的上传/下载逻辑，相比于底层接口这里做了较多的性能优化：包括使用独立的线程池，避免慢 IO 阻塞访问热数据；使用预读缓存优化性能等
容器层：TieredCommitLog/TieredConsumeQueue/TieredIndexFile/TieredFileQueue
容器层实现了和 DefaultMessageStore 类似的逻辑文件抽象，同样将文件划分为 CommitLog、ConsumeQueue、IndexFile，并且每种逻辑文件类型都通过 FileQueue 持有底层物理文件的引用。有所不同的是多级存储的 CommitLog 改为 queue 维度
驱动层：TieredFileSegment
驱动层负责维护逻辑文件到物理文件的映射，通过实现 TieredStoreProvider 对接底层文件系统读写接口(Posix、S3、OSS、MinIO 等)。目前提供了 PosixFileSegment 的实现，可以将数据转移到其他硬盘或通过 fuse 挂载的对象存储上

消息上传

RocketMQ 多级存储的消息上传是由 dispatch 机制触发的：初始化多级存储时会将 TieredDispatcher 注册为 CommitLog 的 dispacher。这样每当有消息发送到 Broker 会调用 TieredDispatcher 进行消息分发，TieredDispatcher 将该消息写入到 upload buffer 后立即返回成功。整个 dispatch 流程中不会有任何阻塞逻辑，确保不会影响本地 ConsumeQueue 的构建

TieredDispatcher

TieredDispatcher 写入 upload buffer 的内容仅为消息的引用，不会将消息的 body 读入内存。因为多级储存以 queue 维度构建 CommitLog，此时需要重新生成 commitLog offset 字段

upload buffer

触发 upload buffer 上传时读取到每条消息的 commitLog offset 字段时采用拼接的方式将新的 offset 嵌入到原消息中

上传进度控制

每个队列都会有两个关键位点控制上传进度：

dispatch offset：已经写入缓存但是未上传的消息位点
commit offset：已上传的消息位点

upload progress

类比消费者，dispatch offset 相当于拉取消息的位点，commit offset 相当于确认消费的位点。commit offset 到 dispatch offset 之间的部分相当于已拉取未消费的消息

消息读取

TieredMessageStore 实现了 MessageStore 中的消息读取相关接口，通过请求中的逻辑位点（queue offset）判断是否从多级存储中读取消息，根据配置（tieredStorageLevel）有四种策略：

DISABLE：禁止从多级存储中读取消息
NOT_IN_DISK：不在 DefaultMessageStore 中的消息从多级存储中读取
NOT_IN_MEM：不在 page cache 中的消息即冷数据从多级存储读取
FORCE：强制所有消息从多级存储中读取，目前仅供测试使用

/**
 * Asynchronous get message
 * @see #getMessage(String, String, int, long, int, MessageFilter) getMessage
 *
 * @param group Consumer group that launches this query.
 * @param topic Topic to query.
 * @param queueId Queue ID to query.
 * @param offset Logical offset to start from.
 * @param maxMsgNums Maximum count of messages to query.
 * @param messageFilter Message filter used to screen desired messages.
 * @return Matched messages.
 */
CompletableFuture<GetMessageResult> getMessageAsync(final String group, final String topic, final int queueId,
 final long offset, final int maxMsgNums, final MessageFilter messageFilter);

需要从多级存储中读取的消息会交由 TieredMessageFetcher 处理：首先校验参数是否合法，然后按照逻辑位点（queue offset）发起拉取请求。TieredConsumeQueue/TieredCommitLog 将逻辑位点换算为对应文件的物理位点从 TieredFileSegment 读取消息

// TieredMessageFetcher#getMessageAsync similar with TieredMessageStore#getMessageAsync
public CompletableFuture<GetMessageResult> getMessageAsync(String group, String topic, int queueId,
 long queueOffset, int maxMsgNums, final MessageFilter messageFilter)

TieredFileSegment 维护每个储存在文件系统中的物理文件位点，并通过为不同存储介质实现的接口从中读取所需的数据

/**
 * Get data from backend file system
 *
 * @param position the index from where the file will be read
 * @param length the data size will be read
 * @return data to be read
 */
CompletableFuture<ByteBuffer> read0(long position, int length);

预读缓存

TieredMessageFetcher 读取消息时会预读一部分消息供下次使用，这些消息暂存在预读缓存中

protected final Cache<MessageCacheKey /* topic, queue id and queue offset */,
SelectMappedBufferResultWrapper /* message data */> readAheadCache;

预读缓存的设计参考了 TCP Tahoe 拥塞控制算法，每次预读的消息量类似拥塞窗口采用加法增、乘法减的机制控制：

加法增：从最小窗口开始，每次增加等同于客户端 batchSize 的消息量
乘法减：当缓存的消息超过了缓存过期时间仍未被全部拉取，在清理缓存的同时会将下次预读消息量减半

预读缓存支持在读取消息量较大时分片并发请求，以取得更大带宽和更小的延迟

某个 topic 消息的预读缓存由消费这个 topic 的所有 group 共享，缓存失效策略为：

所有订阅这个 topic 的 group 都访问了缓存
到达缓存过期时间

故障恢复

上文中我们介绍上传进度由 commit offset 和 dispatch offset 控制。多级存储会为每个 topic、queue、fileSegment 创建元数据并持久化这两种位点。当 Broker 重启后会从元数据中恢复，继续从 commit offset 开始上传消息，之前缓存的消息会重新上传并不会丢失

classDiagram class TopicMetadata TopicMetadata: +int topicId TopicMetadata: +String topic TopicMetadata: +long reserveTime TopicMetadata: +int status TopicMetadata: +long updateTimeStamp class QueueMetadata QueueMetadata: +MessageQueue queue QueueMetadata: +long minOffset QueueMetadata: +long maxOffset QueueMetadata: +long updateTimeStamp

classDiagram class FileSegmentMetadata FileSegmentMetadata: +MessageQueue queue FileSegmentMetadata: +int status FileSegmentMetadata: +int type FileSegmentMetadata: +long baseOffset FileSegmentMetadata: +String path FileSegmentMetadata: +long size FileSegmentMetadata: +long createTimestamp FileSegmentMetadata: +long beginTimestamp FileSegmentMetadata: +long endTimestamp FileSegmentMetadata: +long sealTimestamp

开发计划

面向云原生的存储系统要最大化利用云上存储的价值，而对象存储正是云计算红利的体现。 RocketMQ 多级存储希望一方面利用对象存储低成本的优势延长消息存储时间、拓展数据的价值；另一方面利用其共享存储的特性在多副本架构中兼得成本和数据可靠性，以及未来向 Serverless 架构演进

tag 过滤

多级存储拉取消息时没有计算消息的 tag 是否匹配，tag 过滤交给客户端处理。这样会带来额外的网络开销，计划后续在服务端增加 tag 过滤能力

广播消费以及多个消费进度不同的消费者

预读缓存失效需要所有订阅这个 topic 的 group 都访问了缓存，这在多个 group 消费进度不一致的情况下很难触发，导致无用的消息在缓存中堆积

需要计算出每个 group 的消费 qps 来估算某个 group 能否在缓存失效前用上缓存的消息。如果缓存的消息预期在失效前都不会被再次访问，那么它应该被立即过期。相应的对于广播消费，消息的过期策略应被优化为所有 Client 都读取这条消息后才失效

和高可用架构的融合

目前主要面临以下三个问题：

元数据同步：如何可靠的在多个节点间同步元数据，slave 晋升时如何校准和补全缺失的元数据
禁止上传超过 confirm offset 的消息：为了避免消息回退，上传的最大 offset 不能超过 confirm offset
slave 晋升时快速启动多级存储：只有 master 节点具有写权限，在 slave 节点晋升后需要快速拉起多级存储断点续传

高级消息类型

事务消息

事务半消息回查用到了 commitLog offset，而多级存储对消息的 commitLog offset 做了重新映射会导致兼容问题。当前默认禁止上传事务半消息 topic RMQ_SYS_TRANS_HALF_TOPIC 中的消息，确保其生命周期小于本地消息保留时间

定时消息

本节中的定时消息特指在 RIP-43 中引入的基于时间轮的定时消息实现

为了支持超过消息保留时间的定时时长，基于时间轮的定时消息会在按照 timerRollWindowSlots 配置指定的时间滚动定时消息。比如 broker 配置的消息保留时间为 3 天，timerRollWindowSlots 配置的滚动间隔为 2 天，消息的定时时间为 7 天，那么每隔两天消息会重复写入.所以只要 timerRollWindowSlots 配置的时间小于消息保留时间即可

为了避免消息频繁滚动带来的写放大，下一步计划在多级存储中实现多级时间轮机制，即将大于消息保留时间的定时消息写入多级存储中，在消息定时到期时读取回本地处理

RocketMQ 可观测性之 Metrics

Tue, 15 Nov 2022 11:16:09 +0800

从消息的生命周期看可观测能力

在进入主题之前先来看一下 RocketMQ 生产者、消费者和服务端交互的流程：

message produce and consume process

RocketMQ 的消息是按照队列的方式分区有序储存的，这种队列模型使得生产者、消费者和读写队列都是多对多的映射关系，彼此之间可以无限水平扩展。对比传统的消息队列如 RabbitMQ 是很大的优势，尤其是在流式处理场景下能够保证同一队列的消息被相同的消费者处理，对于批量处理、聚合处理更友好

接下来我们来看一下消息的整个生命周期中需要关注的重要节点：

message life cycle

首先是消息发送：发送耗时是指一条消息从生产者开始发送到服务端接收到并储存在硬盘上的时间。如果是定时消息，需要到达指定的定时时间才能被消费者可见

服务端收到消息后需要根据消息类型进行处理，对于定时/事务消息只有到了定时时间/事务提交才对消费者可见。RocketMQ 提供了消息堆积的特性，即消息发送到服务端后并不一定立即被拉取，可以按照客户端的消费能力进行投递

从消费者的角度上看，有三个需要关注的阶段：

拉取消息：消息从开始拉取到抵达客户端的网络和服务端处理耗时
消息排队：等待处理资源，即从消息抵达客户端到开始处理消息
消息消费：从开始处理消息到最后提交位点/返回 ACK

消息在生命周期的任何一个阶段，都可以清晰地被定义并且被观测到，这就是 RocketMQ 可观测的核心理念。而本文要介绍的 Metrics 就践行了这种理念，提供覆盖消息生命周期各个阶段的监控埋点。借助 Metrics 提供的原子能力我们可以搭建适合业务需要的监控系统：

日常巡检与监控预警
宏观趋势/集群容量分析
故障问题诊断

RocketMQ 4.x Metrics 实现 – Exporter

RocketMQ 团队贡献的 RocketMQ exporter 已被 Prometheus 官方的开源 Exporter 生态所收录，提供了 Broker、Producer、Consumer 各个阶段丰富的监控指标

exporter metrics spec

Exporter 原理解析

RocketMQ expoter 获取监控指标的流程如下图所示，Expoter 通过 MQAdminExt 向 RocketMQ 集群请求数据。获取的数据转换成 Prometheus 需要的格式，然后通过 /metics 接口暴露出来

rocketmq exporter

随着 RocketMQ 的演进，exporter 模式逐渐暴露出一些缺陷：

无法支持 RocketMQ 5.x 中新加入的 Proxy 等模块的可观测需求
指标定义不符合开源规范，难以和其他开源可观测组件搭配使用
大量 RPC 调用给 Broker 带来额外的压力
拓展性差，增加/修改指标需要先修改 Broker 的 admin 接口

为解决以上问题，RocketMQ 社区决定拥抱社区标准，在 RocketMQ 5.x 中推出了基于 OpenTelemtry 的 Metrics 方案

RocketMQ 5.x 原生 Metrics 实现

基于 OpenTelemtry 的 Metrics

OpenTelemetry 是 CNCF 的一个可观测性项目，旨在提供可观测性领域的标准化方案，解决观测数据的数据模型、采集、处理、导出等的标准化问题，提供与三方 vendor 无关的服务

在讨论新的 Metrics 方案时 RocketMQ 社区决定遵守 OpenTelemetry 规范，完全重新设计新 metrics 的指标定义：数据类型选用兼容 Promethues 的 Counter、Guage、Histogram，并且遵循 Promethues 推荐的指标命名规范，不兼容旧有的 rocketmq-exporter 指标。新指标覆盖 broker、proxy、producer、consumer 等各个 module，对消息生命周期的全阶段提供监控能力

指标上报方式

我们提供了三种指标上报的方式：

Pull 模式：适合自运维 K8s 和 Promethues 集群的用户
Push 模式：适合希望对 metrics 数据做后处理或接入云厂商的可观测服务的用户
Exporter 兼容模式：适合已经在使用 Exporter 和有跨数据中心（或其他网络隔离环境）传输 metrics 数据需求的用户

Pull

Pull 模式旨在与 Prometheus 兼容。在 K8s 部署环境中无需部署额外的组件，prometheus 可以通过社区提供的 K8s 服务发现机制（创建 PodMonitor、ServiceMonitor CDR）自动获取要拉取的 broker/proxy 列表，并从他们提供的 endpoint 中拉取 metrics 数据

pull mode

Push

OpenTelemetry 推荐使用 Push 模式，这意味着它需要部署一个 collector 来传输指标数据

push mode

OpenTelemetry 官方提供了 collector 的实现，支持对指标做自定义操作如过滤、富化，可以利用社区提供的插件实现自己的 collector。并且云厂商提供的可观测服务（如 AWS CloudWatch、阿里云 SLS）大多已经拥抱了 OpenTelemetry 社区，可以直接将数据推送到它们提供的 collector 中，无需额外的组件进行桥接

OpenTelemetry collector

兼容 RocketMQ Exporter

新的 Metrics 也提供对 RocketMQ Exporter 的兼容，现在使用 exporter 的用户无需变更部署架构即可接入新 Metrics。而且控制面应用（如 Promethues）和数据面应用（如 RocketMQ）有可能隔离部署。因此借助 Exporter 作为代理来获取新的 Metrics 数据也不失为一种好的选择

RocketMQ 社区在 Exporter 中嵌入了一个 OpenTelemetry collector 实现，Broker 将 Metrics 数据导出到 Exporter，Exporter 提供了一个新的 endpoint（下图中的 metrics-v2）供 Prometheus 拉取

exporter mode

构建监控体系最佳实践

丰富的指标覆盖与对社区标准的遵循使得可以轻而易举的借助 RocketMQ 的 Metrics 能力构建出适合业务需求的监控体系，这个章节主要以一个典型的流程介绍构建监控体系的最佳实践：

集群监控/巡检 -> 触发告警 -> 排查分析

集群状态监控与巡检

我们将指标采集到 Promethues 后就可以基于这些指标配置监控，这里给出一些示例：

接口监控：
监控接口调用情况，可以据此快速抓出异常的请求对症下药
下图给出一些相关示例：所有 RPC 的耗时（avg、pt90、pt99 等）、成功率、失败原因、接口调用与返回值分布情况等

rpc metrics

客户端监控：
监控客户端的使用情况，发现非预期的客户端使用如超大消息发送、客户端上下线、客户端版本治理等
下图给出一些相关示例：客户端连接数、客户端语言/版本分布、发送的消息大小/类型分布

client metrics

Broker 监控：
监控 Broker 的水位和服务质量，及时发现集群容量瓶颈
下图给出一些相关示例：Dispatch 延迟、消息保留时间、线程池排队、消息堆积情况

broker metrics

以上的示例只是 Metrics 的冰山一角，需要根据业务需要灵活组合不同的指标配置监控与巡检

告警配置

有了完善的监控就可以对需要关注的指标配置告警，比如可以配置 Broker 监控中 Dispatch 延迟这个指标的告警：

broker alert

收到告警后可以联动监控查看具体原因，关联发送接口的失败率可以发现有 1.7% 的消费发送失败，对应的报错是没有创建订阅组：

promblem analysis

问题排查分析

最后以消息堆积这个场景为例来看一下如何基于 Metrics 分析线上问题

从消息生命周期看堆积问题

正如本文开篇所述，排查 RocketMQ 的问题需要结合消息的生命周期综合分析，如果片面的认定是服务端/客户端的故障未免会误入歧途

对于堆积问题，我们主要关注消息生命周期中的两个阶段：

就绪消息：就绪消息是可供消费但还未被拉取的消息，即在服务端堆积的消息
处理中消息：处理中的消息是被客户端拉取但是还未被消费的消息

consume lag

多维度指标分析堆积问题

对于堆积问题，RocketMQ 提供了消费延迟相关指标 rocketmq_consumer_lag_latency 可以基于这个指标配置告警。告警的阈值需要根据当前业务对消费延迟的容忍程度灵活指定

触发告警后就需要对消息堆积在还是就绪消息和处理中消息进行分析，RocketMQ 提供了 rocketmq_consumer_ready_messages 和 rocketmq_consumer_inflight_messages 这两个指标，结合其他消费相关指标与客户端配置综合分析即可判断出消息堆积的根因：

case 1：就绪消息持续上涨，处理中消息达到客户端堆积上限

这是最常见的堆积场景，客户端处理中的消息量 rocketmq_consumer_inflight_messages 达到了客户端配置的阈值，即消费者的消费能力低于消息发送量。如果业务要求尽可能实时的消费消息就需要增加消费者机器数量，如果业务对消息延迟不是很敏感可以等待业务高峰过去后再消化堆积的消息

case 2：就绪消息几乎为 0，处理中消息持续上涨

这个 case 多出现在使用 RocketMQ 4.x 客户端的场景，此时消费位点是顺序提交的，如果某条消息的消费卡住会导致位点无法提交。看起来的现象是消息在客户端大量堆积，即处理中消息持续上涨。可以结合消费轨迹和 rocketmq_process_time 这个指标抓出消费慢的消息分析上下游链路，找到根因优化消费逻辑

case 3: 就绪消息持续上涨，处理中消息几乎为 0

此种场景说明客户端没有拉取到消息，一般有如下几种情况：

鉴权问题：检查 ACL 配置，如果使用公有云产品请检查 AK、SK 配置
消费者 hang 住：尝试打印线程堆栈或 gc 信息判断是否是进程卡死
服务端响应慢：结合 RPC 相关指标查看拉取消息接口调用量与耗时、硬盘读写延迟。检查是否为服务端问题，如硬盘 IOPS 被打满了等等

使用 K3s 搭建基于 Kubernetes 环境的 HomeLab

Mon, 07 Nov 2022 15:42:00 +0800

博主在和朋友搭建游戏私服的时候不幸将家里的虚拟化平台搞挂了（论备份的重要性）正好最近有用 Kubernetes 的需求，就把 HomeLab 做一次架构升级，水一篇文章记录下这次客串 SRE 的经验和踩过的坑

技术选型： K3s（Kubernetes） + Rancher（Kubernetes Dashboard） + Traefik（Gateway）

安装 K3s

K3s 是一个轻量级的 Kubernetes 发行版，只需要一行命令即可安装完整的 Kubernetes 环境

curl -sfL https://get.k3s.io | sh -s - server

安装好的 K3s 服务端只有一个可执行文件：

# 通过 k3s server 或 k3s agent 启动
root@k3s-server:~# ls /usr/local/bin/
crictl ctr k3s k3s-killall.sh k3s-uninstall.sh kubectl

K3s 占用的资源也很低，只需 1 核 CPU 和 512M 内存即可跑起来，详细分析见官方文档：最低需求和资源分析

安装 K3s Server

Kubernetes 由 Master 和 Worker 节点组成，对应 K3s 的 server 和 agent，即需要在一台机器上安装 K3s Server 作为 Master Node，其他机器上安装 K3s Agent 作为 Worker Node

后续会安装 Rancher 来管理 K3s，所以这里需要使用受支持的 K3s 版本。可以从Rancher 文档中找到 Rancher 支持的 Kubernetes 版本列表

然后使用环境变量 INSTALL_K3S_VERSION 来安装指定版本的 K3s server

curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="***" sh -s - server

安装完成后就可以使用 kubectl 来查看 K3s 集群：

root@k3s-server:~# kubectl get node
NAME STATUS ROLES AGE VERSION
k3s-server Ready control-plane,master 4d4h v1.24.7+k3s1

安装 K3s 会附带 csictl 和 kubectl，前者可以管理 Node 上的镜像和容器；后者应该无需多介绍了，默认使用的 kubeconfig 为 /etc/rancher/k3s/k3s.yaml

安装 K3s Agent

K3s agent 的安装也十分简单，去掉上述安装命令中的 server 参数即可

此外，还需要两个额外的环境变量来指定 K3s agent 如何连接到 server：

K3S_URL：K3s server 提供的 API server 地址，默认为 https://server-ip:6443
K3S_TOKEN：K3s server 安装时指定或生成的 token：默认在 /var/lib/rancher/k3s/server/node-token

curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="***" K3S_URL="api-server-url" K3S_TOKEN="server-token" sh -

安装完成后再来看一下 Node 列表，可以发现 worker 节点已经添加到集群中了

root@k3s-server:~# kubectl get node
NAME STATUS ROLES AGE VERSION
k3s-server Ready control-plane,master 1m v1.24.7+k3s1
k3s-worker-0 Ready <none> 1m v1.24.7+k3s1

安装 Rancher

Rancher 是一个帮你管理 K3s 集群中的各种资源的 dashboard，功能十分丰富但是占用的资源也比较多。如果你只想要一个轻量的 Kubernetes dashboard 来浏览资源可以略过本节并参考这篇文档 Configure the Kubernetes Dashboard on K3s

Rancher 可以在 Docker 或者 Kubernetes 中安装，我们这里介绍使用 Helm 将 Rancher 安装到上面创建好的 K3s 集群中

安装 cert-manager

Rancher 使用 cert-manager 来生成和管理证书，如果要自行上传证书也可以跳过这一节

首先来安装 Helm，不同的 Linux 发行版的安装方式略有区别，非 Debian/Ubuntu 可以参考官方文档进行安装

apt install helm

使用 Helm 来安装 cert-manager，注意这里的版本 v1.10.0 可以根据需要进行替换

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.10.0/cert-manager.crds.yaml

helm repo add jetstack https://charts.jetstack.io

helm repo update

helm install cert-manager jetstack/cert-manager \
 --namespace cert-manager \
 --create-namespace \
 --version v1.10.0

签发 letsencrypt 证书

Rancher 默认会使用 cert-manager 创建自签名证书。如果你希望使用能通过浏览器校验的合法证书，也可以用 cert-manager 获取 letsencrypt 签发的证书

使用 cert-manager 签发证书的流程分为以下几步：

创建 Issuer

cert-manager 使用 ACME 来签发证书，支持 HTTP01 和 DNS01 两种方式进行校验

博主这里使用的是 letsencrypt + DNS01 校验方式，DNS 提供商为 Cloudflare。如果你也希望使用同样的校验方式，修改下面配置中的 your-api-key 和 admin@example.com 即可

apiVersion: v1
kind: Secret
metadata:
 name: cloudflare-api-key-secret
 namespace: cert-manager
type: Opaque
stringData:
 api-key: <your-api-key>

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: letsencrypt-prod
 namespace: cert-manager
spec:
 acme:
 email: admin@example.com
 server: https://acme-v02.api.letsencrypt.org/directory
 privateKeySecretRef:
 name: letsencrypt-prod
 solvers:
 - dns01:
 cloudflare:
 email: admin@example.com
 apiKeySecretRef:
 name: cloudflare-api-key-secret
 key: api-key

如果想将这个 Issuer 设置为默认使用，可以用如下命令升级 cert-manager

helm upgrade cert-manager jetstack/cert-manager --set 'extraArgs={--default-issuer-name=letsencrypt-prod,--default-issuer-kind=ClusterIssuer}' -n cert-manager

创建证书

首先需要创建一个 namespace cattle-system，这也会用在后续的 Rancher 安装中

kubectl create namespace cattle-system

然后就可以使用上面创建的 Issuer letsencrypt-prod 签发证书了，将 rancher.example.com 替换成你的域名即可

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: tls-rancher-ingress
 namespace: cattle-system
spec:
 secretName: tls-rancher-ingress
 commonName: rancher.example.com
 dnsNames:
 - rancher.example.com
 issuerRef:
 name: letsencrypt-prod
 kind: ClusterIssuer

证书的 secretName 需要指定为 tls-rancher-ingress，这样 Rancher 才能找到这个证书

Debug

如果你创建证书的过程一番风顺，那么恭喜你可以直接安装 Rancher 了，但是如果 Certificate 一直是 Pending 状态那么就得看看是哪出了问题

创建证书的流程分为 Certificate -> CertificateRequest -> Order -> Challenge，分别对应定义资源 -> 生成 CSR -> 提交签发证书请求 -> 校验域名所有权。上述的每个步骤都是一种 CRD，debug 的流程就是 describe 每种 CRD 的资源看看有什么报错

比如博主遇到的问题是校验域名时卡在

Waiting for dns-01 challenge propagation: DNS record for "rancher.example.com" not yet propagated

这是因为 K3s 使用的 DNS 有问题，不能正确获取 DNS Challenge 中设置的 TXT 记录，使用如下命令指定 cert-manager 使用的 DNS 即可正常签发证书

# https://cert-manager.io/docs/configuration/acme/dns01/#setting-nameservers-for-dns01-self-check
helm upgrade cert-manager jetstack/cert-manager --set 'extraArgs={--dns01-recursive-nameservers-only,--dns01-recursive-nameservers=8.8.8.8:53\,1.1.1.1:53' -n cert-manager

安装 Rancher

使用 Helm 安装 Rancher，需要将 rancher.example.com 改为上面证书的域名并设置好域名解析

helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

kubectl create namespace cattle-system

helm install rancher rancher-latest/rancher \
 --namespace cattle-system \
 --set hostname=rancher.example.com \
 --set replicas=1 \
 --set bootstrapPassword=<admin-password> \
 --set ingress.tls.source=secret

安装完成后即可访问 rancher.example.com 来使用 Rancher

如果你跳过了签发 letsencrypt 证书这个步骤并且也没有自行上传证书需要去掉 --set ingress.tls.source=secret，这样 Rancher 会使用 cert-manager 来创建自签名证书

安装你的应用

安装应用的部分就靠读者各显神通了，博主是使用 Kompose 将之前的 docker-compose 文件转换为转换为 Kubernetes 资源描述，这里给出遇到的两个问题的解法

挂载储存

K3s 默认只提供 host-path 这一个 CSI。使用 host-path 会使你的数据和 Node 强绑定，这显然很不云原生。博主这里推荐两个 CSI：nfs-subdir-external-provisioner 和 longhorn

nfs-subdir-external-provisioner 可以帮你最简单的实现储存计算分离，只要你的储存池支持 NFS 就可以让 Pod 可以在不同的 Node 间飘移
longhorn 是真正的分布式文件系统，提供多副本和备份/还原等能力

分配应用到指定的 Node

如果你只想使用 host-path 或者有应用和 Node 绑定的需求可以尝试使用 nodeAffinity，有 required 和 preferred 两种规则，这里直接给出官方文档中的示例

apiVersion: v1
kind: Pod
metadata:
 name: with-node-affinity
spec:
 affinity:
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: topology.kubernetes.io/zone
 operator: In
 values:
 - antarctica-east1
 - antarctica-west1
 preferredDuringSchedulingIgnoredDuringExecution:
 - weight: 1
 preference:
 matchExpressions:
 - key: another-node-label-key
 operator: In
 values:
 - another-node-label-value
 containers:
 - name: with-node-affinity
 image: registry.k8s.io/pause:2.0

对外暴露你的应用

Kubernetes Overlay 网络

首先来看一下运行应用 Pod 的信息：

root@k3s-server:~/service/k8s# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
media-index-754bc9dfdd-6cbkl 4/4 Running 12 (25h ago) 27h 10.42.1.27 k3s-worker-0 <none> <none>

可以发现 Pod 获取到的 ip 10.42.1.26，和它所在的 Node ip 192.168.1.2 完全不在一个网段中，也就是说无法从 Kubernetes 外部直接访问我们的应用

root@k3s-server:~/service/k8s# kubectl get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
k3s-server Ready control-plane,master 4d12h v1.24.7+k3s1 192.168.1.1 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-19-amd64 containerd://1.6.8-k3s1
k3s-worker-0 Ready <none> 32h v1.24.7+k3s1 192.168.1.2 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-19-amd64 containerd://1.6.8-k3s1

我们将 Node 所在的网络称为 Underlay 网络，是真实的底层物理网络；而将 Pod 所在的网络称为 Overlay 网络，是由软件定义的逻辑网络。这样做的好处是打通了不同 Node 间的网络，即使 Node 在不同的子网下（甚至是不同的云服务商）也可为 Pod 提供一致的网络环境。K3s 默认使用 Flannel 通过 VXLAN 技术构建 Overlay 网络，相关文章可以阅读

所以应用部署完成后想要分配一个域名并对外提供服务就需要使用 Kubernetes 的 Ingress 网关，我们先来看一下官方文档中对 Ingress 的说明：

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

ingress

即我们访问应用实际是先访问到 Kubernetes 的 Ingress 网关，然后 Ingress 根据我们配置的规则把流量路由到对应的 Service 上，最后由 Service 关联的 Pod 提供服务

使用 Traefik Ingress

K3s 默认使用 Traefik 作为 Ingress Controller，Traefik 会自动将 Ingress 和 IngressRoute（Traefik 提供的 CRD）转换为路由规则，我们下面以 Traefik dashboard 为例看下如何对外暴露服务

签发证书 tls-traefik-ingress 并且将 traefik.example.com 替换为你的域名即可在 Kubernetes 外访问 Traefik dashboard

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
 name: traefik-dashboard
 namespace: kube-system
spec:
 entryPoints:
 - websecure
 routes:
 - match: Host(`traefik.example.com`) && (PathPrefix(`/`) || PathPrefix(`/dashboard`) || PathPrefix(`/api`))
 kind: Rule
 services:
 - name: api@internal
 kind: TraefikService
 tls:
 secretName: tls-traefik-ingress

这个 yaml 的 spec 主要分为 entryPoints、routes、services 三个部分

entryPoints：指定服务的接入点，有两个预置的 entryPoint：web 和 websecure，前者对应 80 端口的 http 服务，后者对应 443 端口的 https 服务。如果使用 websecure 需要配置 tls，否者会使用 Traefik 默认的自签名证书
routes：指定路由规则，其中 match 字段用于匹配对何种流量应用本规则
services：指定后端服务，Kind 字段可以为 Service 或 TraefikService 两种。我这里使用的 api@internal 是 Traefik 预置的 TraefikService

更详细的说明可以参考官方文档：Traefik & Kubernetes

代理非 Kubernetes 应用

前面提到 Traefik 根据我们配置的规则把流量路由到对应的 Service 上，实际上是获取 Service 对应的 Endpoints 的 ip：

root@k3s-server:~# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
index ClusterIP 10.43.218.102 <none> 8989/TCP,7878/TCP,9117/TCP 41h

root@k3s-server:~# kubectl get endpoints
NAME ENDPOINTS AGE
index 10.42.1.27:7878,10.42.1.27:8989,10.42.1.27:9117 41h

root@k3s-server:~/service/k8s# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
media-index-754bc9dfdd-6cbkl 4/4 Running 12 (25h ago) 27h 10.42.1.27 k3s-worker-0 <none> <none>

可以发现 Endpoints 中的 ip 就是应用 Pod 的 ip，Kubernetes 会根据 Service 中配置的 selector 来找到关联的 Pod 并创建 Endpoints

apiVersion: v1
kind: Service
metadata:
 name: index
 namespace: media
spec:
 ports:
 - name: sonarr
 port: 8989
 - name: radarr
 port: 7878
 - name: jackett
 port: 9117
 selector:
 app: index

所以让 Traefik 代理非 Kubernetes 应用就需要手动创建 Endpoints 并且不在 Service 中指定 selector：

apiVersion: v1
kind: Endpoints
metadata:
 name: downloader
 namespace: media
subsets:
- addresses:
 - ip: 192.168.1.1
 hostname: downloader
 ports:
 - name: downloader
 port: 8080
 protocol: TCP

---
apiVersion: v1
kind: Service
metadata:
 name: downloader
 namespace: media
spec:
 ports:
 - name: downloader
 port: 8080

---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
 name: downloader
 namespace: media
spec:
 entryPoints:
 - websecure
 routes:
 - match: Host(`downloader.example.com`)
 kind: Rule
 services:
 - name: downloader
 namespace: media
 port: 8080

配置跳转 https

Traefik 的路由规则支持正则匹配，我们可以借此配置一些默认规则：http 自动跳转 https、静态资源缓存策略、CORS 规则等等

这里给出一个使用 Middleware 将所有网站的 http 请求跳转到 https 的例子：

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
 name: redirect-to-https
 namespace: kube-system
spec:
 redirectScheme:
 scheme: https
 permanent: true

---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
 name: default-redirect-http-to-https
 namespace: kube-system
spec:
 entryPoints:
 - web
 routes:
 - match: HostRegexp(`{alldomain:.*}`)
 kind: Rule
 services:
 - name: ping@internal
 kind: TraefikService
 middlewares:
 - name: redirect-to-https

配置默认证书

Traefik 不支持使用 cert-manager 自动申请证书，我们可以手动申请泛域名证书并且配置为 Traefik 的默认证书，这样就不必为每个网站手动配置证书

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: tls-example-default
 namespace: kube-system
spec:
 secretName: tls-example-default
 commonName: '*.example.com'
 dnsNames:
 - '*.example.com'
 - example.com
 issuerRef:
 name: letsencrypt-prod
 kind: ClusterIssuer

---
apiVersion: traefik.containo.us/v1alpha1
kind: TLSStore
metadata:
 name: default
 namespace: kube-system
spec:
 defaultCertificate:
 secretName: tls-example-default

创建名为 default 的 TLSStore 会覆盖 Traefik 的默认 tls 配置

配置 Strict SNI

有了泛域名证书我们就可以对外提供多个网站的 https 服务，但是这样有存在一个风险：如果你的服务器暴露在公网中，并且不幸被脚本小子扫到，那么他访问 443 端口就可以拿到你的网站信息：

root@k3s-server:~# curl https://192.168.1.1 -v
...
* Server certificate:
* subject: CN=*.example.com
* start date: Nov 4 14:01:21 2022 GMT
* expire date: Feb 2 14:01:20 2023 GMT
...

这就是由 SNI 导致的域名泄露，我们可以通过设置 Strict SNI 来拒绝掉非法域名的访问：

apiVersion: traefik.containo.us/v1alpha1
kind: TLSOption
metadata:
 name: default
 namespace: kube-system

spec:
 sniStrict: true

配置了 Strict SNI 会使得默认证书失效，需要为每个网站显式指定证书
关于 SNI 的详细介绍可以阅读 Cloudflare 的文章

使用对象存储代替硬盘文件系统最佳实践

Sun, 28 Aug 2022 02:00:00 +0800

博主最近使用对象存储作为硬盘等块存储文件系统的冷存储替代方案，节约数据储存成本。本文介绍这个方案实现过程中的踩坑记录，以及阿里云 OSS 的几种使用方式的最佳实践与性能分析

项目背景

随着我们系统的数据量越来越大，昂贵的 SSD 硬盘在机器成本中占了大头。但是绝大多数数据随着保存时间的增长会变成“冷数据”，即很少有读取需求。如果我们能将这些冷数据转移到更便宜的储存介质中就可以大幅降低成本

下面是阿里云几种文件存储服务的对比：

类型	规格	延迟	带宽（MB/s）	价格（元/GB/月）
块存储	普通云盘	微秒级	30~40	0.3
块存储	高效云盘	微秒级	140	0.35
块存储	SSD云盘	微秒级	300	1
NAS	通用型	10ms	150	0.3
NAS	极速型	2ms	600	1.62
OSS	标准型	见下文性能分析	见下文性能分析	0.12

其中 OSS 拥有极为明显的价格优势，是我们目前使用的 SSD 价格的 12%，是通用型 NAS 的 40%。如果将 1T 的 SSD 数据盘换成 OSS 节省的成本相当于一台 8C32G 的 ECS

因为技术选型原因，博主使用阿里云 OSS 提供的对象存储服务，下文中“对象存储”与“阿里云 OSS”可以等价互换

OSS 读写方式

块储存和 NAS 原生支持挂载为文件系统，对现有系统无侵入。OSS 的读写方式则比较特殊，主要有以下几种：

API

OSS API

使用 OSS 的客户端或者自行封装 OSS 提供的 Open API 即可使用 OSS 提供的对象存储服务，文档链接：OSS API 参考

这里不得不吐槽下 OSS 官方 SDK，都 2202 年了还不提供异步接口，人家 AWS S3 早几年就支持了……

S3 API

OSS 兼容部分 S3 API，基本覆盖了上传、下载和查询元数据接口，相关文档：AWS S3兼容性

理论上支持 S3 的工具也可在 OSS 上使用

挂载文件系统

Linux fuse

得益于 OSS 支持 S3 API，可以使用 S3FS 来将 OSS 挂载为本地目录

S3FS 使用 Linux fuse 技术在用户空间构建文件系统，部分兼容 POSIX。换句话说就是可以当成一块硬盘挂载使用，相关使用限制可以阅读项目文档 limitations 部分

S3FS 是一个纯粹的开源软件，主要贡献者是 Google 和 Yahoo 的两个老哥。缓存等功能还不成熟，稳定性既没有商业公司背书也没有找到大规模生产使用的案例

虚拟文件系统

基于对象储存构建的分布式文件系统，比如 JuiceFS。它主要解决了三个问题：

完全兼容 POSIX、HDFS
支持通过 fuse、csi 挂载到服务器或 k8s pod 中，也可使用 S3 client、WebDAV client、Hadoop client 访问
托管文件元数据，解决元数据访问的性能问题

JuiceFS 官方文档中有与 S3FS 的对比：JuiceFS vs. S3FS

JuiceFS 上储存的文件会被拆分成为一个个 4MB 的 Block 储存在对象储存中，这意味着不再能直接从 OSS 读取文件，必须依赖 JuiceFS server 的转换

JuiceFS 文件储存格式

OSS 性能分析

将 OSS 挂载为文件系统的方案各有缺点，我们只能赤膊上阵用 OSS API 来改造我们的现有系统。首先要做的工作就是性能测试，看下 OSS 的性能是否能满足我们的需要。做性能分析之前需要先了解对象存储的特性，对其能达到的性能有一个预期：

无限的储存空间
文件一旦写入无法修改（Appendable 的文件可追加写入）
仅支持有限的 API：元数据操作如遍历文件性能差、无法重命名（相当于重新上传）、无法监听文件变更等等
IOPS/QPS 很低且受限，需尽量 batch 上传/下载，但访问延迟与每次请求的数据量正相关
单线程带宽有限，如需更高带宽要并发请求
计费方式为按储存容量和 API 调用次数计费

基于对象存储的以上特性，在访问的数据量一定时延迟、带宽、成本构成三元悖论，需要针对不同场景做出权衡：

每次请求上传/下载更多的数据可以提高带宽但是带来更大的延迟，反之可以降低延迟但是减少带宽
多个连接并发请求可以提升带宽并降低延迟，但是会提高请求的 QPS 进而提高成本

三元悖论

上传

OSS 提供三种上传 API：

AppendObject
MultipartUpload
PutObject

其中 MultipartUpload 在所有分片全部上传完之前整个文件是不可见的，这种方式不适用于我们的场景首先 pass 掉

剩下 AppendObject 和 PutObject 对比：AppendObject 更加灵活，只不过是一些版本控制、加密等功能无法使用，并且 AppendObject 的写入性能相比 PutObject 更高：

AppendObject：60MB/s
PutObject：50MB/s

以上数据的测试方法均为阿里云 ECS 上使用 OSS 的内网接入点上传 1G 随机内容的文件。下文对下载性能的测试使用类似方法不再赘述

下载

三种上传 API 分别对应三种文件类型：

Appendable
Multipart
Normal

这三种类型的文件均可使用 GetObject API 来下载某个区间的数据，Appendable 和 Normal 类型的文件下载性能测试如下：

Appendable：
- 单线程 6.6MB/s
- 5 线程 27.9MB/s
- 20 线程 108.0MB/s
Normal：
- 单线程 35.9MB/s
- 5 线程 85.0MB/s
- 20 线程 152.9MB/s

Normal 文件和 Appendable 文件下载性能相比于上传差距要大得多。特别是在并发线程数少的场景，Normal 文件相比于 Appendable 有巨大的性能优势。可见 Appendable 文件适合读写比小（读取与写入量的比值。这个值越低说明对读取的需求越小，即对读取性能要求更低）的文件

元数据操作

考虑到 OSS 不能重新写入文件，所以一但上传失败/中断就需要重新上传整个文件。为了避免失败重传整个大文件，我们需要将本地文件分割成一个个较小的文件切片再上传

分割后的文件也不能过于小，否则会影响 OSS 内部的预读策略

但是这种方案会导致 OSS 上的文件数量急剧增多，而且 ListObjects API 获取文件元数据性能差且每次最多只能返回 1000 个文件。我们最终采用本地管理元数据的方案：即本地维护一份 OSS 上文件路径、大小等信息。读取请求先遍历本地元数据，找到相应的文件路径后再从 OSS 获取数据

总结

最后总结下我们的系统如何平衡成本和性能：

读写比小的文件使用 AppendObject 追加上传，读取时加大并发换取更大的带宽
读写比大的文件本地缓存起来，攒够一定大小使用 PutObject 上传，保证性能的同时节约成本
元数据本地管理进一步降低 API 调用费

从 Kubernetes Pod 内存占用谈 Linux 内存管理

Fri, 10 Jun 2022 09:54:00 +0800

本文对一个线上 k8s 内存水位误报警深入分析 Linux 内存管理中各种内存指标计算的原理

TLDR：如果你的应用会涉及较多的文件读写，可以将 k8s 内存水位告警指标由 container_memory_working_set_bytes 改为 container_memory_rss。这样可以防止 page cache 占用空闲内存带来的误报警

问题描述

前些天我们的 k8s 线上集群触发内存水位报警，报警显示某个 Pod 的内存使用率高达 85%。然而登陆到 pod 上发现应用实际占用的内存占用只有 50%，但是用 free 命令看到的内存占用又是符合报警水位（total 31G，free 2.6G）

free 命令输出

再细看一下 free 打印出的信息发现 buff/cache 占用有 12G，这部分内存用到哪里了？10G 的 available 是不是指这些 cache 中有 10G 是可以释放的？那不能释放的 2G 是用来做什么的？应用真实内存占用应该看哪个指标？接下来我们依次回答这些问题

Linux 内存分类

我们知道 Linux 中一个非常重要的概念是万物皆文件，Linux 的内存实际上是外存上各种文件的缓存。也就是说我们申请的内存实际上对应一个真实的文件（各种设备/Socket），这种内存被称为 page cache

我们来看看 Linux 权威文档中是如何介绍这种内存的：

The physical memory is volatile and the common case for getting data into the memory is to read it from files. Whenever a file is read, the data is put into the page cache to avoid expensive disk access on the subsequent reads. Similarly, when one writes to a file, the data is placed in the page cache and eventually gets into the backing storage device. The written pages are marked as dirty and when Linux decides to reuse them for other purposes, it makes sure to synchronize the file contents on the device with the updated data.
——The Linux kernel user’s and administrator’s guide

其中最关键的一句话：每当读取一个文件，数据会被缓存在 page cache 中以避免后续访问时重复读取磁盘带来的昂贵开销。也就是说我们平时访问文件（read 或 mmap 系统调用）都会创建对应的 page cache，这部分内存由操作系统管理，并不记录在用户程序的内存开销中

这个文档中同时也介绍了另外一种内存类型：匿名内存（anonymous memory）

The anonymous memory or anonymous mappings represent memory that is not backed by a filesystem. Such mappings are implicitly created for program’s stack and heap or by explicit calls to mmap(2) system call. Usually, the anonymous mappings only define virtual memory areas that the program is allowed to access. The read accesses will result in creation of a page table entry that references a special physical page filled with zeroes. When the program performs a write, a regular physical page will be allocated to hold the written data. The page will be marked dirty and if the kernel decides to repurpose it, the dirty page will be swapped out.
——The Linux kernel user’s and administrator’s guide

这里的匿名指的是不需要手动指定对应的文件，系统会为其指定一个填充为 0 的特殊文件（/dev/zero）。程序的堆栈就属于这种内存，此外还有一种匿名映射（anonymous mappings）也属于匿名内存

mmap 设置 flag 为 MAP_PRIVATE 时创建的内存才属于匿名内存，注意与 MAP_ANONYMOUS 区分

MAP_ANONYMOUS 作用是不显式指定映射的文件（默认为 /dev/zero）
MAP_PRIVATE 作用是使内存的修改对其他进程不可见（即 copy on write 模式）并且不会将脏页写回文件

MAP_ANONYMOUS 一般和 MAP_SHARED 或 MAP_PRIVATE 同时使用：
mmap 的 flag 设置为 MAP_ANONYMOUS|MAP_SHARED 时创建的内存属于 page cache，常用于在相关进程间共享内存
mmap 的 flag 设置为 MAP_ANONYMOUS|MAP_PRIVATE 时创建的内存属于匿名内存，常用于内存分配（glibc 分配大块内存）

现在可以回答第一个问题，buff/cache 占用的 12G 内存都用在哪里：我们的系统使用 mmap 映射了很多文件，buff/cache 占用的 12G 内存就是这些文件 page cache 占用的空间

这里的 buffer 指的是 buffer cache 块设备缓存，而 page cache 是页缓存。从名字就可以发现它们的数据是一样的，现代 Linux 中这两者也是融合的：buffer cache 的数据直接储存在 page cache 中

Linux 内存回收策略

按照我们朴素的观点只有匿名内存是不可回收的， cache 都是可回收的。但是为什么 free 打印出的信息中 available(10G) 小于 buffer/cache(12G) 的值？

我们可以按照 Linux 文档的说明尝试清除 page cache（echo 1 > /proc/sys/vm/drop_caches）来验证这个假设

Writing to this will cause the kernel to drop clean caches, as well as reclaimable slab objects like dentries and inodes. Once dropped, their memory becomes free.

To free pagecache:
    echo 1 > /proc/sys/vm/drop_caches
To free reclaimable slab objects (includes dentries and inodes):
    echo 2 > /proc/sys/vm/drop_caches
To free slab objects and pagecache:
    echo 3 > /proc/sys/vm/drop_caches

This is a non-destructive operation and will not free any dirty objects. To increase the number of objects freed by this operation, the user may run `sync’ prior to writing to /proc/sys/vm/drop_caches. This will minimize the number of dirty objects on the system and create more candidates to be dropped.
——Documentation for /proc/sys/vm/*

我们发现 free 命令看到的 buff/cache 并没有全部被回收。文档中也给出了解释：脏页并不会回收（will not free any dirty objects），这里说的脏页分为以下几种：

被修改但未写回磁盘的 page cache：用 sync 强制脏页落盘后再尝试 drop cache 即可回收
tmpfs/shmem：tmpfs 和共享内存（SysV shared memory 和 POSIX shared memory）
shared anonymous mmap：使用 flag 为 MAP_ANONYMOUS|MAP_SHARED 的 mmap 获得的内存

后两者在 free 命令的输出中既属于 buff/cache，也属于 shared。这些内存在主动释放前不能被回收

除了脏页外还有一些特殊的不可回收的页面：

内核使用的页面：DMA buffer 等
标记为 unreclaimable 的页面：如使用 mlock 锁定的内存

内核使用的页面也有可回收的，比如文件系统元数据（dentries/inodes）这种可以从存储设备中重新读取的页面。这些页面被称为 SReclaimable，可以使用 echo 2 > /proc/sys/vm/drop_caches 进行回收

Linux 内存水位控制与可用内存计算

既然但是为什么 available 的值不等于 reclaimable + free？我们继续从 Linux 文档中寻找答案

When the system is not loaded, most of the memory is free and allocation requests will be satisfied immediately from the free pages supply. As the load increases, the amount of the free pages goes down and when it reaches a certain threshold (low watermark), an allocation request will awaken the kswapd daemon. It will asynchronously scan memory pages and either just free them if the data they contain is available elsewhere, or evict to the backing storage device (remember those dirty pages?). As memory usage increases even more and reaches another threshold - min watermark - an allocation will trigger direct reclaim. In this case allocation is stalled until enough memory pages are reclaimed to satisfy the request.
——The Linux kernel user’s and administrator’s guide

这里提到了两个 watermark：

low watermark：当 free 内存低于 low watermark 时触发异步内存回收
min watermark：当内存低于 min watermark 时暂停内存分配，立即进行内存回收

也就是说系统中剩余的内存不能低于 min watermark，这是一个操作系统的保护机制：预留一部分内存给内存回收等关键程序使用。这些程序使用 PF_MEMALLOC 标识忽略 watermark 的限制，在需要的时候不必等待内存回收就可以立刻获得内存

可以通过 cat /proc/zoneinfo 看到 min watermark 的取值，单位是页。下面这个示例中系统预留了 10478 页，也就是大约 40M 的内存

cat /proc/zoneinfo

...
Node 0, zone Normal
 pages free 780839
 min 10478
 low 13097
...

所以 free 的内存并不都是可分配的，需要减去系统保留内存，即 available = reclaimable + free - reversed

available 内存计算

除了 watermark 以外还有 min_free_kbytes 和 watermark_scale_factor 等参数影响系统保留内存的计算，这部分内存本文中统称为 reversed 不再详述

k8s 内存监控

上文中说的 buff/cache、free、available 都是从 free 命令看到的结果，而 k8s 的内存相关监控指标略有不同

free 命令是从 /proc/meminfo 中取值计算，相关原理和各字段解释可以阅读这篇文章： /PROC/MEMINFO之谜
k8s cadvisor metrics 指标是从 /sys/fs/cgroups/memory/memory.stat 中取值计算，可以阅读这篇文章来验证：验证 Pod cgroup 限制

这里给出部分 k8s cadvisor metrics 指标的解释：

cadvisor 指标	取值
container_memory_usage_bytes	分配的总内存
container_memory_working_set_bytes	分配的总内存 - 不活跃的 page cache
container_memory_rss	使用的匿名内存
container_memory_cache	page cache 占用内存

container_memory_working_set_bytes 是最常用的内存监控指标，也是判断 limit 的依据。

回到文章开头的问题，我们线上使用的报警指标就是 container_memory_working_set_bytes，这个指标是包含了一部分 page cache 的所以要偏高一些。用这个指标来配置告警如果应用使用 page cache 较多（比如打开大量文件）就会产生误报

监控内存水位是为了及时发现应用存在 OOM 的风险，实际上我们应该关心的是 available 指标。但是 k8s 又没有提供和 available 等价的 metrics，只能迂回使用 container_memory_rss 来配置告警，这个指标是应用真实占用的内存即 unreclaimable 部分

巧用 DNS 实现国内外域名 ip 分流上网

Fri, 03 Jun 2022 21:03:00 +0800

这篇文章记录了对几种分流上网方案（iptables、OSPF、DNS 等）的尝试与优劣比较，文中会详细介绍博主目前使用的基于 DNS 的分流方案的原理与配置教程

前言

本文适合使用软路由做透明代理的同学阅读，并且需要有一定的网络基础知识。如果你是一个小白那么直接跳到极简配置部分照着操作即可

博主尝试过如下几种思路实现策略路由（PBR, Policy Based Routing）

iptables 给链接打标
OSPF 等路由协议
Clash、V2ray 等代理工具
DNS 分流

前两者的思路类似，都是使用中国 ip 白名单来将国外 ip 转发到旁路由等透明代理设备上。但是无论是 iptables 还是 OSPF 配置都非常复杂，特别是 OSPF 等路由协议科班出身的人都不一定玩得转。我们配置家庭网络追求的是简单好用，使用这样复杂的方案前期调试以及后期更新 ip 列表都很不方便

使用代理工具的分流功能做策略路由简单实用，Clash、V2ray 等客户端都会有开箱即用的配置提供。但是缺点也很明显：所有的流量都会经过代理程序，无法做到分设备代理，对于有有 BT、PCDN 等需求只想部分设备走代理的同学不太适用

使用 DNS 分流方案拥有 iptables 和 OSPF 做策略路由的丰富功能，并且兼具使用代理工具分流配置简单的优点

丰富的分流策略：可以按国内外 ip 分流也可以按域名分流
配置简单：最简单的使用方法只需修改 Clash 的配置即可
去广告：可以阻断广告域名的 DNS 解析来禁止广告加载
分设备代理：对需要代理的设备使用分流 DNS 转发到代理服务器，其他设备使用上游公共 DNS 直连出公网

但是这个方案也有缺点，对于直接使用 ip 的软件就无能为力了。当然这种情况非常罕见（目前博主只发现 Telegram），而且只需额外添加一条静态路由即可解决

什么？你问我 DNS 是啥玩意？那我建议你~~关掉本文~~，或者阅读这篇文章：详解 DNS 与 CoreDNS 的实现原理

网络架构

需要两个额外组件（极简配置下这两个组件合二为一）：

做透明代理的软路由，可以是主路由也可以是旁路由
分流 DNS

原理其实很简单：分流 DNS 劫持 DNS 请求，需要走代理的域名返回透明代理 ip，无需走代理的域名直接返回真实 ip

DNS 分流配置

极简配置

使用 fake-ip 模式的 Clash 既作为透明代理又作为 DNS Server，这种方式配置非常简单，只需要一个能运行 Clash 的设备即可

首先你需要部署好 Clash（请自行寻找教程，作为主路由、旁路由都可以，使用虚拟机、docker、lxc 没限制）然后修改如下配置：

dns:
 enable: true
 // 开启 fake-ip 模式
 enhanced-mode: fake-ip
 // 选择保留 ip 段，一般保持默认即可
 fake-ip-range: 198.18.0.1/16
 // 指定 Clash DNS 监听地址
 listen: 0.0.0.0:53
 // 指定上游公共 DNS
 nameserver:
 - 223.5.5.5:53
 // 添加需要直连的国内域名
 fake-ip-filter:
 - baidu.com
 - ...

tun:
 enable: true
 stack: system
 // 自动为 fake-ip-range 中的 ip 段添加路由
 auto-route: true

这个配置做了三件事

开启 dns 服务并指定为 fake-ip 模式，监听 53 端口
对于 fake-ip-filter 中的国内域名直接返回真实 ip，这些域名的流量不再经过代理
开启 tun 模式并自动添加路由，将发往 fake-ip 的请求交给 clash 处理

最关键的是需要将常见国内域名加入到 fake-ip-filter 中，这里推荐一个每日更新国内域名的项目：felixonmars/dnsmasq-china-list

你可以自行下载 accelerated-domains.china.conf 文件并为其中的域名加上 +. 前缀然后添加到 fake-ip-filter 中。如果你恰好使用 openclash 可以用博主的脚本，可以自动下载国内域名列表并写入 openclash 的配置文件中

rm -f accelerated-domains.china.conf
wget https://raw.githubusercontent.com/felixonmars/dnsmasq-china-list/master/accelerated-domains.china.conf -O /root/accelerated-domains.china.conf

echo '
#LAN
*.lan
*.localdomain
*.example
*.invalid
*.localhost
*.test
*.local
*.home.arpa
#放行NTP服务
time.*.com
time.*.gov
time.*.edu.cn
time.*.apple.com
ntp.*.com
*.time.edu.cn
*.ntp.org.cn
+.pool.ntp.org
time1.cloud.tencent.com
*.cn
' > /etc/openclash/custom/openclash_custom_fake_filter.list

awk -F / '{print "+."$2}' /root/accelerated-domains.china.conf >> /etc/openclash/custom/openclash_custom_fake_filter.list

echo fake-ip-filter: > /tmp/openclash_fake_filter.list
awk '{print " - '\''"$1"'\''"}' /etc/openclash/custom/openclash_custom_fake_filter.list >> /tmp/openclash_fake_filter.list

看到这里恭喜你全部配置已经完成，是不是很简单？接下来将需要走代理的设备 DNS 改为 Clash DNS 的地址即可享受分流上网

如果你的 clash 运行在旁路由上，还需要在主路由的路由表中添加一项，将 fake-ip 指向旁路由

# 198.18.0.1/16 是 fake-ip-range 配置的 ip 段
# 192.168.2.254 是旁路由 ip
route add -net 198.18.0.1/16 gw 192.168.2.254

除非你熟悉 linux 网络配置，否则尽量使用原生 clash 而不是 openclash 之类的周边项目，它们往往会添加 iptables 规则将经过本机的连接都转发到 clash

在运行 clash 的服务器上使用 mtr 或 traceroute 来验证分流策略是否生效：如果 mtr 的结果显示无需代理的域名不止一跳并且没有经过 fake-ip-range 的 ip 段则分流配置正确；也可以观察 Clash 控制台，看看是否有无需走代理域名连上来

# 配置有误
root@OpenWrt:~# mtr -r --tcp www.baidu.com
Start: 2022-06-09T21:37:36+0800
HOST: OpenWrt Loss% Snt Last Avg Best Wrst StDev
 1.|-- 198.18.0.19(fake-ip) 0.0% 10 0.2 0.1 0.1 0.2 0.0

# 配置正确
root@OpenWrt:~# mtr -r --tcp ntp.aliyun.com
Start: 2022-06-09T21:40:51+0800
HOST: OpenWrt Loss% Snt Last Avg Best Wrst StDev
 1.|-- <主路由 ip> 0.0% 10 0.1 0.1 0.1 0.2 0.0
 2.|-- <公网出口 ip> 10.0% 10 6.0 5.2 3.1 9.5 1.9
 3.|-- 117.49.47.202 0.0% 10 4.1 5.0 4.0 6.5 1.0
 4.|-- 116.251.94.198 0.0% 10 10.0 11.0 10.0 13.0 1.0
 5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
 6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
 8.|-- 203.107.6.88 0.0% 10 24.7 24.7 24.4 26.2 0.5

精准分流配置

使用 Clash DNS 的方案虽然配置非常简单，但是毕竟不可能将所有国内域名都统计出来，还需要根据 ip 进行更精准的分流

多数系统不支持指定 DNS 端口，所以分流 DNS 和 Clash DNS 最好分配不同的 ip（可以在单网卡上分配多个内网 ip）

博主选用 IrineSistiana/mosdns-cn 作为分流 DNS，这里引用 mosdns-cn 官方文档上介绍的分流规则

分流模式
mosdns-cn 会根据用户提供的数据采用以下分流模式。

配置了 –local-ip 本地 IP

如果请求的域名匹配到 –local-domain 本地域名。则直接使用 –local-upstream 本地上游。结束。

如果请求的域名匹配到 –remote-domain 远程域名。则直接使用–remote-upstream 远程上游。结束。

非 A/AAAA 类型的请求将直接使用 –local-upstream 本地上游。结束。

同时转发至本地和远程上游获取应答。

如果本地上游的应答包含 –local-ip 本地 IP。则直接采用本地上游的结果。结束。

否则采用远程上游的结果。结束。

只配置了 –local-domain 本地域名

如果请求的域名匹配到 –local-domain 本地域名。则直接使用 –local-upstream 本地上游。结束。

其他所有请求会使用 –remote-upstream 远程上游。结束。

只配置了 –remote-domain 远程域名

如果请求的域名匹配到 –remote-domain 远程域名。则直接使用–remote-upstream 远程上游。结束。

其他所有请求会使用 –local-upstream 本地上游。结束。

Github 上有详细使用教程，这里给出博主使用的启动脚本，每次启动时拉取最新的国内外域名/ip 数据

RELEASE_URL=$(curl -s https://api.github.com/repos/Loyalsoldier/v2ray-rules-dat/releases/latest | grep browser_download_url)
GEOSITE_URL=$(echo "$RELEASE_URL" | grep geosite.dat\" | cut -d'"' -f4)
GEOIP_URL=$(echo "$RELEASE_URL" | grep geoip.dat\" | cut -d'"' -f4)

if [ -z $GEOSITE_URL ];
then
 echo "GEOSITE_URL required!"
 exit 1
fi

if [ -z $GEOIP_URL ];
then
 echo "GEOIP_URL required!"
 exit 1
fi

echo $GEOSITE_URL
echo $GEOIP_URL
echo

wget $GEOSITE_URL -O geosite.dat
wget $GEOIP_URL -O geoip.dat

mosdns-cn -s :53 --blacklist-domain "geosite.dat:category-ads-all" --local-upstream 223.5.5.5:53 --local-domain "geosite.dat:cn" --local-ip "geoip.dat:cn" --remote-upstream https://8.8.8.8/dns-query --remote-domain "geosite.dat:geolocation-!cn"

去广告/DNS 解析统计配置

mos-dns 支持配置黑名单域名直接给出空响应，可以使用这一机制阻断广告域名的访问：mosdns-cn --blacklist-domain "geosite.dat:category-ads-all"

但是目前少有大佬分享适配 mosdns-cn 的去广告规则，这种专业的事情还是交给 Adguard Home 来做：

将 Adguard Home 放在 mosdns-cn 和 Clash DNS 的上游还有其他好处，可以借助它的仪表盘和日志分析出整个网络访问的网站

Adguard Home 仪表盘

Adguard Home 的部署教程网上有很多，能看到这里的人肯定也不用我赘述了。这里推荐一个博主自用的过滤规则，有了它就不需要其他规则了：BlueSkyXN/AdGuardHomeRules

其他配置

自动设置设备的 DNS 服务器

在极简配置中博主提到将需要走代理的设备 DNS 改为分流 DNS，这一步可以手动改也可以借助 DHCP 自动配置：DHCP Option 6 的作用就是指定客户端使用的 DNS，在 Openwrt LAN 接口的高级设置中即可找到该设置

Openwrt DHCP Option 配置

为直接使用 IP 的 APP 设置路由

直接使用 ip 的软件没有经过 DNS 自然就无法获取到 Clash 的 fake-ip，对于这种情况需要在主路由上添加静态路由将这些软件使用的 ip 的下一跳路由改为 Clash 的 fake-ip

目前我只发现 Telegram 存在这种情况，需要添加的路由如下：

# 192.18.1.254 是 fake-ip，可以从 fake-ip-range 中随便选择一个
route add -net 91.108.4.0/22 gw 192.18.1.254
route add -net 91.108.8.0/22 gw 192.18.1.254
route add -net 91.108.12.0/22 gw 192.18.1.254
route add -net 91.108.16.0/22 gw 192.18.1.254
route add -net 91.108.56.0/22 gw 192.18.1.254
route add -net 149.154.160.0/20 gw 192.18.1.254

PVE 虚拟化黑苹果显卡直通及远程访问教程

Wed, 13 Apr 2022 17:14:00 +0800

PVE 虚拟化黑苹果显卡直通教程（核显&独显通用），低延迟远程访问方案：VNC、ARD、ToDesk、ParSec、Jump Desktop 等远程桌面协议/软件测试横评

适用场景

博主曾经用笔记本装黑苹果做过一段时间的主力机，但是因为有使用 Windows 的强需求，双系统切换不方便所以最终换回的 Windows。当时就在想如果有一台服务器跑着 MacOS，随时可以从主力机 Windows 远程访问岂不是两全其美。但是近年矿潮显卡价格虚高，实在是没有入手的欲望，最近趁矿难显卡价格下跌入手一块 AMD RX460 实践一下这个想法

阅读本文需要的前置步骤：

一台运行 PVE 的主机
在 PVE 上成功安装黑苹果（使用）
至少进入黑苹果一次开启 设置->共享->屏幕共享（显卡直通可能会导致 PVE 自带的 VNC 卡在白苹果界面）

黑苹果能否成功运行和硬件以及驱动有很大的关系，而使用 PVE 使用的 KVM 虚拟化技术可以最大程度上屏蔽硬件的差异提高成功率，借助 KVM-Opencore 项目提供的驱动可以做到开箱即用，不用折腾

PVE 和黑苹果安装教程这里推荐两篇博客，写的非常详细

对于国光这篇文章有一处勘误，文章中说到 PVE 7.1 不能显卡直通，实际上我测试是可以的，读者可以在下文中找到我使用的软件版本

主要配置

硬件配置

CPU: i5 10400
GPU: UHD630、AMD RX460

其他硬件均虚拟化

软件版本

虚拟化平台：PVE

主要软件包版本：

~ pveversion -v
proxmox-ve: 7.1-1 (running kernel: 5.13.19-6-pve)
pve-manager: 7.1-12 (running version: 7.1-12/b3c09de3)
pve-kernel-helper: 7.1-14
pve-kernel-5.13: 7.1-9
...

MacOS 版本：macOS Monterey 12.3.1(21E258)（使用 OSX-KVM 项目制作镜像）
OpenCore&EFI 版本：KVM-Opencore v16

显卡直通

因为我是通过远程访问使用黑苹果，所以并没有把要直通的 GPU 设置为主 GPU，这是本文和其他直通教程的主要区别。这样做的好处是可以用 PVE 的后台直接查看黑苹果启动情况、进入 Recovery 模式等

参考 Arch Linux wiki

启用 IOMMU

这里引用 Arch Linux wiki 中对 IOMMU 的介绍：

IOMMU 是 Intel VT-d 和 AMD-Vi 的通用名称。
VT-d 指的是直接输入/输出虚拟化(Intel Virtualization Technology for Directed I/O)，不应与 VT-x(x86 平台下的 Intel 虚拟化技术，Intel Virtualization Technology)混淆。VT-x 可以让一个硬件平台作为多个“虚拟”平台，而 VT-d 提高了虚拟化的安全性、可靠性和 I/O 性能。

首先在 BIOS 中开启 VT-d

然后修改内核参数开启 IOMMU：

- GRUB_CMDLINE_LINUX_DEFAULT="quiet"
+ GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream video=efifb:off"

这里解释下这几个参数的作用：

intel_iommu=on：开启 IOMMU，对于 AMD CPU 需要使用 amd_iommu=on
iommu=pt：pt 是 passthrough 的缩写，可以提高性能
pcie_acs_override=downstream: 可以将同一 Group 中的设备分开直通
video=efifb:off：禁用 efifb 驱动，防止出现报错 BAR 3: cannot reserve [mem]

更新内核参数

update-grub

重启后可以用以下脚本测试

bash -c "$(curl -fsSL https://gist.githubusercontent.com/ShadowySpirits/018ea8675100baf768afff0d835e7862/raw/8e1c12f5766f0d308628ad1373b2f8603c523480/check_iommu.sh)"

如果你遇到网络问题可以直接复制并执行以下脚本内容：

#!/bin/bash
shopt -s nullglob
for g in $(find /sys/kernel/iommu_groups/* -maxdepth 0 -type d | sort -V); do
 echo "IOMMU Group ${g##*/}:"
 for d in $g/devices/*; do
 echo -e "\t$(lspci -nns ${d##*/})"
 done;
done;

看到类似以下信息说明 IOMMU 开启成功

IOMMU Group 0:
 00:00.0 Host bridge [0600]: Intel Corporation Comet Lake-S 6c Host Bridge/DRAM Controller [8086:9b53] (rev 05)
IOMMU Group 1:
 00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 05)

...

IOMMU Group 6:
 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:a394] (rev f0)
 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] [1002:67ef] (rev cf)
 03:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1002:aae0]

如果上面没有开启 pcie_acs_override=downstream 就只能将整个 Group 下的设备都直通给某个虚拟机

隔离 GPU

我们需要使用占位驱动程序（vfio）接管显卡，这样才能后续将显卡分配给虚拟机

在 PVE 宿主机的 /etc/modules 中添加 vfio 模块

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

修改 /etc/modprobe.d/vfio.conf 将显卡的供应商-设备 ID 传递给 vfio 驱动，供应商-设备 ID 可以在上面脚本的输出的 [] 中找到，多个设备用 , 分隔

options vfio-pci ids=device_id1,device_id2 disable_vga=1

以我的 RX460 为例，它的供应商-设备 ID 是 1002:67ef 和 1002:aae0

IOMMU Group 6:
 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:a394] (rev f0)
 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] [1002:67ef] (rev cf)
 03:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1002:aae0]

所以需要添加的内容是：

options vfio-pci ids=1002:67ef,1002:aae0 disable_vga=1

然后在 PVE 宿主机的 /etc/modprobe.d/blacklist.conf 中禁用其他显卡驱动，防止这些驱动在 vfio 前加载

# NVIDIA
blacklist nvidiafb
blacklist nouveau
blacklist nvidia
blacklist snd_hda_intel

# Intel
blacklist snd_hda_codec_hdmi
blacklist i915

# AMD
blacklist radeon

最后应用更改并重启

update-initramfs -u

分配显卡

重启后就可以将显卡分配给虚拟机了：

在设备中选择添加 PCI 设备，然后选择你要添加的显卡即可（独显核显都可以）

pve 直通选项

不同的显卡这里选择的选项不太一样，根据我的试验：
直通 UHD630 只需要勾选 全功能（All Functions）
直通 AMD RX460 除了 主 GPU（Primary GPU） 外的选项都需要勾选

直通之后 PVE 自带的 VNC 可能会卡在白苹果界面，其实系统已经正常启动，可以使用 MacOS 自带的 VNC 进行连接

白苹果

远程访问

分辨率调整

当你通过 PVE 自带的 VNC 连接黑苹果的时候会发现有一个分辨率为 1080p 的内置显示器，并且没有其他分辨率的选项，所以需要一些奇技淫巧来强制修改分辨率：

这里用到两个软件：BetterDummy 和 SwitchResX

首先使用 BetterDummy 创建一个和你物理显示器比例一致的虚拟显示器并设为主显示器

创建虚拟显示器

然后使用 SwitchResX 修改虚拟显示器分辨率为你物理显示器的原生分辨率

修改分辨率

不推荐使用带有 HiDPI 的分辨率，因为 HiDPI 是一种超采样技术（HiDPI 原理可以参考这篇文章）靠渲染更多的像素来使图像“看起来”更清晰。但是大部分远程桌面软件都会将原生分辨率压缩为当前物理屏幕分辨率进行传输，所以开启 HiDPI 除了会浪费计算资源、增加延迟外没有任何意义

（可选）使用 SwitchResX 关闭默认显示器
这个步骤不是必须的，如果你的远程桌面软件无法选择用于串流的显示器（比如 VNC Viewer）可以关闭默认显示器来强制软件使用虚拟显示器

关闭默认显示器

原生方案

MacOS 原生提供 VNC 和 ARD 两种协议进行远程访问，可以在 设置->分享 中开启

VNC

自带的 VNC 是阉割版的，体验上做的很差：不支持调整画质、分辨率，不支持选择显示器（多显示器会横向拼接显示内容）从 Windows 访问键位映射有问题并且无法修改，卡顿严重，拖动窗口的时候尤其明显。唯一的优点是画质非常好，是本文介绍的所有方案中唯一一个使用原生分辨率传输（开启 HiDPI 画质明显提升）

ARD

ARD 属于是 VNC 套壳，可以使用 Apple 官方的 Apple Remote Desktop 软件（售价高达 518，不会真有冤大头会买吧。。。）连接黑苹果主机。相比于 VNC，ARD 支持选择显示器，提供 4 挡可调的图像质量，在保证画质的前提下提供不错的延迟表现。并且除了远程桌面以外还提供命令执行、系统报告、文件传输等系统管理功能，缺点是只支持 MacOS（Windows 下可以使用支持 VNC 协议的软件连接，但是会退化成和原生 VNC 一样的垃圾体验）

自建 VNC Server

既然自带的 VNC 如此不堪使用，ARD 又不提供 Windows 客户端，我们只能求助于第三方软件来提供满血版 VNC 协议支持。这里推荐 Real VNC，可以兼具 VNC 高画质和 ARD 的低延迟，除了不支持 HiDPI 外基本上能提供和连接显示器一致的体验

第三方软件/私有协议

ToDesk

ToDesk 在我的体验中卡顿非常严重。除了提供免费的内网穿透以外，相比其他方案基本上毫无优势可言，如果你有公网 IP 的话不要选择它。所以名气大的（尤其是国产软件）不一定真的好用。。。

ParSec

ParSec 的原本用途是游戏串流，提供精细的配置项可供选择，细节上体验很舒适。相比于其他方案它的延迟和画面质量很稳定，不会在画面快速变化时卡顿或者糊掉，并且支持播放被控主机声音。可能是现在 Mac 版还处于 Beta 阶段的原因，ParSec 对性能要求很高，RX460 在 2560×1440 分辨率下延迟 20ms 左右，3440×1440（2k 带鱼屏）分辨率下延迟 40ms 左右

Jump Desktop

Jump Desktop 是老牌 mac 远程桌面应用，使用私有的 Fluid 协议。延迟低、带宽占用低，但是画面也是最糊的，特别是窗口拖动等画面快速变化的场景涂抹感非常严重。Jump Desktop 支持自定义任何按键或是组合键的映射，和 ParSec 一样也支持播放被控主机声音

总结与性能测试

测试环境：

GPU：直通 RX460 GeekBench 5 Metal 分 21000 左右，性能大致相当于 M1 核显
网络：内网（网络延迟 <1ms）
分辨率：3440x1440（非 HiDPI）
软件版本：各软件均使用当前最新免费/试用版，画质选择最高一档

软件/协议	延迟	画质	按键映射	多显示器	声音	文件传输	连接方式
原生 VNC	高	最好（支持 HiDPI）	不支持修改	拼接所有显示器	不支持	不支持	直连
RealVNC	低（2ms）	最好	自定义任何按键映射	服务端配置	不支持	支持	直连
ARD	中等	一般（滚动时画面会糊）	不支持修改	客户端选择	不支持	支持	直连
ToDesk	高	一般（有明显涂抹感）	自定义功能键映射	客户端选择	不支持	支持	免费内网穿透
ParSec	中等（40ms）	较好（有轻微涂抹感）	不支持修改	客户端选择	支持	不支持	直连（自动 UPNP）
Jump Desktop	低（10ms）	差（画面最糊）	自定义任何按键映射	客户端选择	支持	不支持	直连（自动 UPNP）

除 ToDesk 外的方案若想要通过公网访问均需要被控端具备公网 IP 并配置端口映射或自行搭建内网穿透
ParSec 和 Jump Desktop 会通过 UPNP 帮你自动映射端口，并且登陆它们的账号可以直接看到你的被控端主机，不用通过 IP 手动添加主机，尤其适用于你的公网 IP 是动态 IP 的情况

RocketMQ 负载均衡时机和影响

Mon, 28 Mar 2022 17:15:00 +0800

本文综合 RocketMQ client 与 broker 的源码介绍负载均衡机制发生的时间、客户端发生负载对消费的影响（消息堆积/消费毛刺等）并且给出一些最佳实践的推荐

写在前面

网上大多数讲 RocketMQ 负载均衡的文章只介绍几种分配 MessageQueue 的策略或是长篇大论分析客户端 RebalanceService 的代码。但是其实负载均衡是客户端与服务端互相配合的过程，本文综合服务端和客户端代码回答如下三个问题：

何时会发生负载均衡
负载均衡对消费有何影响
如何减少负载均衡对消费的影响

如果不想看详细分析，这里直接给出结论：

负载均衡时机：

主动负载均衡
1. 启动时立即进行负载均衡
2. 定时（默认 20s）负载均衡一次
被动负载均衡（收到 broker 通知）
1. 客户端上下线
- 上线
  1. 新客户端发送心跳到 broker
- 下线
  1. 客户端发送下线请求到 broker
  2. 底层连接异常：响应 netty channel 的 IDLE/CLOSE/EXCEPTION 事件
1. 订阅关系变化：订阅新 topic 或有旧的 topic 不再订阅

负载均衡对消费的影响：

对于新分配的队列可能会重复消费，这也是官方要求消费要做好幂等的原因
对于不再负责的队列会短时间消费停止，如果原本的消费 TPS 很高或者正好出现生产高峰就会造成消费毛刺

消费毛刺（绿色是正常消费曲线，黄色为出现毛刺的消费曲线）

源码分析

首先明确下上下文：源码分析基于 RocketMQ release-4.9.3 分支的代码以及集群消费模式的 push 消费者。广播模式不在本文的讨论范围内

Client 主动触发

在同一个 JVM 中不管创建多少 consumer，它们总是共享同一个 MQClientInstance，这个 MQClientInstance 接管和所有 consumer 和 broker 的交互以及协调负载均衡

classDiagram class MQProducer <<interface>> MQProducer MQProducer <|-- DefaultMQProducer ClientConfig <|-- DefaultMQProducer DefaultMQProducer: +DefaultMQProducerImpl defaultMQProducerImpl DefaultMQProducer: +start() DefaultMQProducer ..> DefaultMQProducerImpl: use DefaultMQProducerImpl: +MQClientInstance mQClientFactory DefaultMQProducerImpl: +start() class MQConsumer <<interface>> MQConsumer MQConsumer <|-- DefaultMQPushConsumer ClientConfig <|-- DefaultMQPushConsumer DefaultMQPushConsumer: +DefaultMQPushConsumerImpl defaultMQPushConsumerImpl DefaultMQPushConsumer: +start() DefaultMQPushConsumer ..> DefaultMQPushConsumerImpl: use DefaultMQPushConsumerImpl: +MQClientInstance mQClientFactory DefaultMQPushConsumerImpl: +start() DefaultMQProducerImpl ..> MQClientInstance: use DefaultMQPushConsumerImpl ..> MQClientInstance: use MQClientInstance: +start()

MQClientInstance 有两个负载均衡相关的方法：rebalanceImmediately 和 doRebalance
前者在消费者启动和收到 Broker 通知时唤醒 RebalanceService 进行负载均衡，而 RebalanceService 调用后者执行负载均衡逻辑
跟踪 doRebalance 方法，我们发现实际的负载均衡逻辑在 RebalanceImpl#rebalanceByTopic 中实现：

private void rebalanceByTopic(final String topic, final boolean isOrder) {
 // 获取所有 MessageQueue
 Set<MessageQueue> mqSet = this.topicSubscribeInfoTable.get(topic);
 // 获取当前 group 所有在线的消费者
 List<String> cidAll = this.mQClientFactory.findConsumerIdList(topic, consumerGroup);

 ...

 // 排序
 Collections.sort(mqAll);
 Collections.sort(cidAll);

 // 获取当前客户端配置的负载均衡策略
 AllocateMessageQueueStrategy strategy = this.allocateMessageQueueStrategy;

 List<MessageQueue> allocateResult = null;

 ...

 // 根据指定的负载均衡策略计算自己要负责的队列
 allocateResult = strategy.allocate(
 this.consumerGroup,
 this.mQClientFactory.getClientId(),
 mqAll,

 ...

 // 根据计算结果创建 ProcessQueue （用于拉取、消费消息的数据结构）
 boolean changed = this.updateProcessQueueTableInRebalance(topic, allocateResultSet, isOrder);
 if (changed) {
 ...

 // 如果 ProcessQueue 有更新则进行一些处理工作
 this.messageQueueChanged(topic, mqSet, allocateResultSet);
 }
}

通过分析以上代码我们可以看出负载均衡的实际工作是计算出当前客户端分配的 MessageQueue，并且保持 ProcessQueue 与分配到的 MessageQueue 一一对应，创建 ProcessQueue 的具体流程在 RebalanceImpl#updateProcessQueueTableInRebalance 方法中：

private boolean updateProcessQueueTableInRebalance(final String topic, final Set<MessageQueue> mqSet, final boolean isOrder) {
 // 删除不再负责的 MessageQueue 对应的 ProcessQueue
 Iterator<Entry<MessageQueue, ProcessQueue>> it = this.processQueueTable.entrySet().iterator();
 while (it.hasNext()) {
 Entry<MessageQueue, ProcessQueue> next = it.next();
 MessageQueue mq = next.getKey();
 ProcessQueue pq = next.getValue();

 if (mq.getTopic().equals(topic)) {
 if (!mqSet.contains(mq)) {
 // 停止 ProcessQueue 的消费
 pq.setDropped(true);
 // 向 Broker 更新 offset，如果是顺序消费会释放申请的锁
 if (this.removeUnnecessaryMessageQueue(mq, pq)) {
 it.remove();
 changed = true;
 log.info("doRebalance, {}, remove unnecessary mq, {}", consumerGroup, mq);
 }
 }
 }
 }

 // 为新分配的 MessageQueue 创建 ProcessQueue
 List<PullRequest> pullRequestList = new ArrayList<PullRequest>();
 for (MessageQueue mq : mqSet) {
 if (!this.processQueueTable.containsKey(mq)) {
 ...

 ProcessQueue pq = new ProcessQueue();

 ...

 if (nextOffset >= 0) {
 ProcessQueue pre = this.processQueueTable.putIfAbsent(mq, pq);
 }
 ...
 }
 }
}

Broker 通知触发

通过上文我们知道除了 RebalanceService 定时进行负载均衡以外，还可以调用 MQClientInstance#rebalanceImmediately 方法立刻触发负载均衡。这个方法会在消费者启动和收到 Broker 通知时调用（ClientRemotingProcessor#notifyConsumerIdsChanged）
而 Broker 会在如下几个方法中发送通知：

Broker 通知

我们依次分析这三个方法：

ConsumerManager#registerConsumer 方法处理来自客户端的心跳请求

public boolean registerConsumer(final String group, final ClientChannelInfo clientChannelInfo,
 ConsumeType consumeType, MessageModel messageModel, ConsumeFromWhere consumeFromWhere,
 final Set<SubscriptionData> subList, boolean isNotifyConsumerIdsChangedEnable) {

 ...

 // 是否是新客户端
 boolean r1 = consumerGroupInfo.updateChannel(clientChannelInfo, consumeType, messageModel, consumeFromWhere);

 // 更新订阅数据，当订阅新 topic 或有旧的 topic 不再订阅时返回 true
 boolean r2 = consumerGroupInfo.updateSubscription(subList);

 if (r1 || r2) {
 // 可以在 BrokerConfig 中配置，默认为 true
 if (isNotifyConsumerIdsChangedEnable) {
 // 通知客户端进行负载均衡
 this.consumerIdsChangeListener.handle(ConsumerGroupEvent.CHANGE, group, consumerGroupInfo.getAllChannel());
 }
 }

 ...
}

ConsumerManager#unregisterConsumer 方法处理来自客户端的下线请求，和 ConsumerManager#registerConsumer 类似，不再赘述

ConsumerManager#doChannelCloseEvent 方法在如下三个方法中调用

Channel Close

这三个方法在 NettyRemotingAbstract#run 中调用，处理 netty channel 的事件：

@Override
public void run() {
 ...

 final ChannelEventListener listener = NettyRemotingAbstract.this.getChannelEventListener();

 while (!this.isStopped()) {
 try {
 NettyEvent event = this.eventQueue.poll(3000, TimeUnit.MILLISECONDS);
 if (event != null && listener != null) {
 switch (event.getType()) {
 case IDLE:
 listener.onChannelIdle(event.getRemoteAddr(), event.getChannel());
 break;
 case CLOSE:
 listener.onChannelClose(event.getRemoteAddr(), event.getChannel());
 break;
 case CONNECT:
 listener.onChannelConnect(event.getRemoteAddr(), event.getChannel());
 break;
 case EXCEPTION:
 listener.onChannelException(event.getRemoteAddr(), event.getChannel());
 break;
 default:
 break;

 }
 }
 } catch (Exception e) {
 log.warn(this.getServiceName() + " service has exception. ", e);
 }
 }
}

也就是说 channel 事件 IDLE/CLOSE/EXCEPTION 都会触发重新负载均衡，除了底层连接的变化外 Broker 也会在长时间没收到客户端心跳时主动断开连接触发负载均衡，详见 ConsumerManager#scanNotActiveChannel：

public void scanNotActiveChannel() {
Iterator<Entry<Channel, ClientChannelInfo>> itChannel = channelInfoTable.entrySet().iterator();
 ...

 while (itChannel.hasNext()) {
 Entry<Channel, ClientChannelInfo> nextChannel = itChannel.next();
 ClientChannelInfo clientChannelInfo = nextChannel.getValue();
 long diff = System.currentTimeMillis() - clientChannelInfo.getLastUpdateTimestamp();
 // 默认两分钟
 if (diff > CHANNEL_EXPIRED_TIMEOUT) {
 // 关闭连接
 RemotingUtil.closeChannel(clientChannelInfo.getChannel());
 itChannel.remove();
 }
 }

 ...
}

最后总结一下在如下场景 Broker 会主动通知客户端触发负载均衡：

客户端上下线
- 上线
  1. 新客户端发送心跳到 broker
- 下线
  1. 新客户端发送下线请求到 broker
  2. 底层连接异常：响应 netty channel 的 IDLE/CLOSE/EXCEPTION 事件
订阅关系变化：订阅新 topic 或有旧的 topic 不再订阅

最佳实践

避免频繁上下线

从上述源码分析可以看出，负载均衡是一个非常频繁的操作，并不是每一次负载均衡都会对消费产生影响。负载均衡对客户端的影响反映在对 ProcessQueue 的变更上。因为没有一个协调机制确保新旧 ProcessQueue 的创建顺序，所以可能会发生两种情况：

旧 ProcessQueue 销毁早于新 ProcessQueue 创建：此时消费短暂停止，会造成消费延迟
新 ProcessQueue 创建早于旧 ProcessQueue 销毁：此时会有短暂的时间两个消费者同时消费同一个队列，会消费位点回退或重复消费，这也是官方要求消费要做好幂等的原因

所以为了避免负载均衡的影响应该尽量减少客户端的上下线，同时做好消费幂等

在有应用重启或下线前要调用 shutdown 方法，这样 Broker 收到客户端的下线请求后会立刻触发负载均衡

选择合适的负载均衡策略

前文已经介绍了负载均衡对客户端的影响反映在对 ProcessQueue 的变更上，每次需要变更的 ProcessQueue 的数量和受到影响的客户端数量是由负载均衡策略决定的

如果我们有 4 个客户端，24 个队列，当第二个客户端下线时：

以默认的负载均衡策略（AllocateMessageQueueAveragely）为例，重建 ProcessQueue 的队列数量为 8
默认的负载均衡策略能将队列尽量均衡的分配到每个客户端，但是每次负载均衡重建 ProcessQueue 数量较多，尤其是在客户端数量很多的场景

客户端	队列分配变化	队列数变化
Client1	1~6 -> 1~8	6 -> 8
Client2	7~12 -> -	6 -> 0
Client3	13~18 -> 9~16	6 -> 8
Client4	19~24 -> 17~24	6 -> 8

以一致性哈希算法（AllocateMessageQueueConsistentHash）为例，重建 ProcessQueue 的队列数量为 6（不考虑虚拟节点）
基于一致性哈希算法的负载均衡策略每次负载均衡会重建尽可能少的 ProcessQueue 数量，但是可能会出现负载不均的情况

客户端	队列分配变化	队列数变化
Client1	1~6 -> 1~9	6 -> 9
Client2	7~12 -> -	6 -> 0
Client3	13~18 -> 10~18	6 -> 9
Client4	19~24 -> 19~24	6 -> 8

以上两个示例是对简单情况的模拟，在生产中需要根据需要选择合适的负载均衡策略

客户端参数保持一致

RocketMQ 的负载均衡是每个客户端独立进行计算，所以务必要保证每个客户端的负载均衡算法和订阅语句一致

负载均衡策略不一致会导致多个客户端分配到相同队列或有客户端分不到队列
订阅语句不一致会导致有消息未能消费

Spring + Kotlin ORM 框架 Exposed 教程

Sat, 19 Mar 2022 16:34:00 +0800

本教程包括 Kotlin ORM 框架 Exposed 的使用方法和一些进阶技巧，并介绍 Exposed 与 Spring 集成的方法以及博主踩过的一些坑

Exposed 介绍

Exposed 是 JetBrains 官方出品的 Kotlin ORM 框架，有如下优点：

支持多种数据库：H2、MySQL、PostgreSQL、SQL Server、SQLite 等
提供两套 API：SQL DSL 和 DAO API（不知道什么是 DSL 可以阅读我的之前的文章：Kotlin DSL 简介）
JetBrains 官方出品，文档完善，易于使用

基本概念

连接数据库

首先需要引入依赖：

<dependency>
 <groupId>org.jetbrains.exposed</groupId>
 <artifactId>exposed-core</artifactId>
 <version>0.37.3</version>
</dependency>
<dependency>
 <groupId>org.jetbrains.exposed</groupId>
 <artifactId>exposed-dao</artifactId>
 <version>0.37.3</version>
</dependency>
<dependency>
 <groupId>org.jetbrains.exposed</groupId>
 <artifactId>exposed-jdbc</artifactId>
 <version>0.37.3</version>
</dependency>

然后建立数据库连接：
关于数据库和数据源的更多说明查看官方 WIKI

Database.connect("jdbc:h2:mem:test", driver = "org.h2.Driver")

最后开启事务操作数据库：
不论是 SQL DSL 还是 DAO API 都需要在 transaction 块中执行

transaction {
 addLogger(StdOutSqlLogger)
 // Do something
 commit()
 // Do something
 rollback()
}

事务支持返回结果：
Blob、text 以及一对多/多对一的字段不能在事务外使用，更多说明查看官方 WIKI

val result = transaction {
 QueryEntity.findById(1)
}

Table/DAO

建表：
如下的 Queries 类创建一个名为 query 的表，并添加了 4 个字段

object Queries : IntIdTable("query") {
 val title = varchar("title", 1024)
 val userId = varchar("userId", 256)
 val type = varchar("type", 256)
 val createTime = timestamp("createTime")
}

Exposed 不会自动生成 migration，但是可以使用 SchemaUtils#create 来在数据库中运行建表语句
官方提供一个 gradle 插件来根据数据库结构生成 Table 代码：exposed-intellij-plugin

创建实体类：
如果要使用 Exposed 的 DAO API，需要创建表对应的实体（Queries -> QueryEntity）

class QueryEntity(id: EntityID<Int>) : IntEntity(id) {
 companion object : IntEntityClass<QueryEntity>(Queries)

 var title by Queries.title
 var userId by Queries.userId
 var type by Queries.type
 var createTime by Queries.createTime
}

CRUD

这里给出两种 API 的简单示例：

SQL DSL：
文档

transaction {
 Queries.insert {
 it[title] = "title"
 it[userId] = "123"
 it[type] = "type"
 it[createTime] = Instant.now()
 }

 Queries.select { Queries.id eq 1 }

 Queries.update {
 it[title] = "titleUpdate"
 it[userId] = "456"
 it[type] = "typeUpdate"
 it[createTime] = Instant.now()
 }

 Queries.deleteWhere { Queries.id eq 1 }
}

DAO API：
文档

transaction {
 QueryEntity.new {
 title = "title"
 userId = "123"
 type = "type"
 createTime = Instant.now()
 }

 val result = QueryEntity.findById(1)

 result?.title = "titleUpdate"
 result?.userId = "456"
 result?.type = "titleUpdate"
 result?.createTime = Instant.now()

 result?.delete()
}

进阶使用

索引

Exposed 支持创建单列/多列索引：

object Queries : IntIdTable("query") {
 ...

 val userId = varchar("userId", 256).index()
 val userId = varchar("userId", 256).uniqueIndex()
 val userId = varchar("userId", 256).index("index_userId_unique", true)

 val index = index("index_title_userId_unique",true, title, userId)
 ...
}

一对多/多对一

首先创建外键：

object Histories : IntIdTable("history") {
 ...
 val queryId = reference("query_id", Queries, onDelete = ReferenceOption.CASCADE)
}

然后在实体类上添加相应的字段：

class QueryEntity(id: EntityID<Int>) : IntEntity(id) {
 ...
 // 一对多
 val histories by HistoryEntity referrersOn Histories.queryId
}

class HistoryEntity(id: EntityID<Int>) : IntEntity(id) {
 ...
 // 多对一
 var query by QueryEntity referencedOn Histories.queryId
}

在查询中即可直接访问对应字段：

transaction {
 // 使用 load 提前加载 histories 字段，避免 N+1 问题
 QueryEntity.findById(1)
 ?.load(QueryEntity::histories)
 ?.histories
 ?.forEach {
 // do something
 }
}

upsert

Exposed 并没有提供开箱即用的 upsert 功能（类似 MySQL 的 ON DUPLICATE KEY UPDATE），需要自己拓展（详见这个 Issue）

这里推荐一个库帮我们实现了 upsert：exposed-upsert

transaction {
 // 也可以使用 conflictIndex 指定自行创建的唯一索引
 Queries.upsert(conflictColumn = Queries.userId,
 insertBody = {
 it[title] = queryData.title
 it[userId] = queryData.userId
 it[type] = queryData.type
 it[createTime] = Instant.now()
 }, updateBody = {
 it[title] = queryData.title
 it[type] = queryData.type
 })
}

Exposed 与 Spring 集成

官方提供 Exposed Spring Boot Starter，用 Exposed 替换 Hibernate

配置

引入依赖：

<dependencies>
 <dependency>
 <groupId>org.jetbrains.exposed</groupId>
 <artifactId>exposed-spring-boot-starter</artifactId>
 <version>0.37.3</version>
 </dependency>
</dependencies>

配置数据库：

spring:
 datasource:
 url: jdbc:h2:mem:testdb
 driverClassName: org.h2.Driver
 exposed:
 # 自动在数据库中建表
 generate-ddl: true

transaction

Exposed 的两种 API 都需要在 transaction 块中执行：

transaction {
 QueryEntity.all()
}

在 spring 中可以用 Transactional 注解代替 transaction 块：

@Transactional
fun all(): List<QueryEntity> {
 return QueryEntity.all().toList()
}

如果需要调用 rollback、commit 等方法需要使用 TransactionManager#current 获取当前 Transaction 实例

@Transactional
fun rollback() {
 // Do something
 TransactionManager.current().rollback()
}

json 转换

这里以 spring 默认使用的 json 库 jackson 为例，gson 或 fastjson 原理上是一样的

首先回顾下我们之前创建的实体类 QueryEntity：

class QueryEntity(id: EntityID<Int>) : IntEntity(id) {
 companion object : IntEntityClass<QueryEntity>(Queries)

 var title by Queries.title
 var userId by Queries.userId
 var type by Queries.type
 var createTime by Queries.createTime

 val histories by HistoryEntity referrersOn Histories.queryId
}

可以发现实体类 QueryEntity 继承自 IntEntity，序列化/反序列化时我们只需要非 IntEntity 类的字段，而 IntEntity 又继承自 Entity，我的做法是让 jackson 忽略所有属于 Entity 或 IntEntity 类的字段：

@Configuration
class JacksonConfig : Jackson2ObjectMapperBuilderCustomizer {
 override fun customize(jacksonObjectMapperBuilder: Jackson2ObjectMapperBuilder) {
 jacksonObjectMapperBuilder.modulesToInstall(object :Module() {
 override fun version(): Version = Version(0, 0, 0,"")

 override fun getModuleName(): String = ""

 override fun setupModule(context: SetupContext) {
 context.insertAnnotationIntrospector(object : JacksonAnnotationIntrospector() {
 override fun hasIgnoreMarker(m: AnnotatedMember): Boolean {
 return m.declaringClass == IntEntity::class.java
 || m.declaringClass == Entity::class.java
 || super.hasIgnoreMarker(m)
 }
 })
 }
 })
 }
}

不能直接使用 Jackson2ObjectMapperBuilder#annotationIntrospector 注入 annotationIntrospector，否则会使 KotlinModule 的 annotationIntrospector 失效

如果需要序列化 id 字段，需要允许 id 和 getId 字段参与序列化。因为 id 字段不是 Int 或 String 等基础类型，所以我们还需要自定义序列化器：

@Configuration
class JacksonConfig : Jackson2ObjectMapperBuilderCustomizer {
 override fun customize(jacksonObjectMapperBuilder: Jackson2ObjectMapperBuilder) {
 jacksonObjectMapperBuilder.serializerByType(EntityID::class.java, object: JsonSerializer<EntityID<*>>() {
 override fun serialize(value: EntityID<*>?, gen: JsonGenerator, serializers: SerializerProvider) {
 if (value == null) {
 gen.writeNull();
 } else if (value.value is Int) {
 gen.writeNumber(value.value as Int);
 } else if (value.value is Long) {
 gen.writeNumber(value.value as Long);
 } else {
 gen.writeString(value.value.toString())
 }
 }
 })

 jacksonObjectMapperBuilder.modulesToInstall(object :Module() {
 override fun version(): Version = Version(0, 0, 0,"")

 override fun getModuleName(): String = ""

 override fun setupModule(context: SetupContext) {
 context.insertAnnotationIntrospector(object : JacksonAnnotationIntrospector() {
 override fun hasIgnoreMarker(m: AnnotatedMember): Boolean {
 return (m.name != "id" && m.name != "getId" && m.declaringClass == IntEntity::class.java)
 || (m.name != "id" && m.name != "getId" && m.declaringClass == Entity::class.java)
 || super.hasIgnoreMarker(m)
 }
 })
 }
 })
 }
}

因为委托属性不可以直接使用 JsonIgnore、JsonInclude 等注解，需要使用 @get:JsonIgnore

class QueryEntity(id: EntityID<Int>) : IntEntity(id) {
 ...
 @get:JsonIgnore
 val histories by HistoryEntity referrersOn Histories.queryId
}

RocketMQ 消息堆积算法详解与优化

Thu, 16 Sep 2021 15:39:06 +0800

背景

消息堆积是消息中间件的一大特色，也是消息中间件的核心能力。但是消息堆积也是消费滞后的一种表现形式，过量的堆积难免会影响上下游的业务。所以对消费堆积量和延迟时间的监控意义重大，本文详解 RocketMQ 消费堆积量和消息消费延时这两个重要指标的含义和算法实现，说明其在对消息延时要求较高和启用消息过滤等场景中的局限并给出优化方法

本文适用于集群消费模式下使用 DefaultMQPushConsumer 进行消费的情况

消费位点的管理：ConsumerOffset、PullOffset 和 MaxOffset

RocketMQ 中每个 Topic 都会创建若干个 ConsumerQueue。消费者订阅某个 Topic 实际上会分配到一个或几个 ConsumerQueue，然后消费 ConsumerQueue 上的消息，所以 RocketMQ 对消费位点的管理也是基于 ConsumerQueue 的

ConsumerQueue

上图中展示了三个和消费进度有关的位点：

ConsumerOffset：消费者确认消费成功的位点，也称为 CommitOffset
PullOffset：消费者拉取消息的位点
MaxOffset：消费者可以消费到的最大位点

下面详细解释这三个位点的计算方法

ConsumerOffset

消费者在每次拉取消息的请求中都会设置一个 commitOffset 字段（PullMessageRequestHeader#commitOffset）Broker 根据这个字段调用 ConsumerOffsetManager#commitOffset 来更新 offsetTable。offsetTable 的储存结构如下：

{
 "offsetTable": {
 // topic@consumerGroup
 "test-topic@test-group": {
 // queueId: consumerOffset
 "0": 88526,
 "1": 88528
 }
 }
}

下面我们来分析一下消费者拉取请求中的 PullMessageRequestHeader#commitOffset 字段是如何计算出来的：

PullMessageRequestHeader 是在 PullAPIWrapper#pullKernelImpl 方法中构造的，而这个方法被 DefaultMQPushConsumerImpl#pullMessage 调用：

long commitOffsetValue = 0L;
if (MessageModel.CLUSTERING == this.defaultMQPushConsumer.getMessageModel()) {
 commitOffsetValue = this.offsetStore.readOffset(pullRequest.getMessageQueue(), ReadOffsetType.READ_FROM_MEMORY);
 if (commitOffsetValue > 0) {
 commitOffsetEnable = true;
 }
}

this.pullAPIWrapper.pullKernelImpl(
 pullRequest.getMessageQueue(),
 subExpression,
 subscriptionData.getExpressionType(),
 subscriptionData.getSubVersion(),
 pullRequest.getNextOffset(),
 this.defaultMQPushConsumer.getPullBatchSize(),
 sysFlag,
 commitOffsetValue,
 BROKER_SUSPEND_MAX_TIME_MILLIS,
 CONSUMER_TIMEOUT_MILLIS_WHEN_SUSPEND,
 CommunicationMode.ASYNC,
 pullCallback,
 subProperties
);

消费者在内存中维护了一个 offsetStore，每次拉取消息时从 offsetStore 中读取 commitOffset 发送给 Broker

那么问题就变成了 offsetStore 是如何维护位点信息的：集群模式下 offsetStore 的实现是 RemoteBrokerOffsetStore，消费者处理消费结果时 ConsumeMessageConcurrentlyService#processConsumeResult 会调用 RemoteBrokerOffsetStore#updateOffset 方法更新位点：

long offset = consumeRequest.getProcessQueue().removeMessage(consumeRequest.getMsgs());
if (offset >= 0 && !consumeRequest.getProcessQueue().isDropped()) {
 this.defaultMQPushConsumerImpl.getOffsetStore().updateOffset(consumeRequest.getMessageQueue(), offset, true);
}

分析上面代码可以看出更新的位点通过调用 ProcessQueue#removeMessage 获取。ProcessQueue 持有一个 TreeMap 作为消息本地缓存，消费者每次拉取的消息都会先缓存在 ProcessQueue 中，当消费完成时再从 ProcessQueue 中移除对应的消息：

/**
* message list, contains message in waiting & consuming list
*/
private final TreeMap<Long, MessageExt> msgTreeMap = new TreeMap<Long, MessageExt>();

public long removeMessage(final List<MessageExt> msgs) {
 // 省略消息删除过程
 return msgTreeMap.isEmpty() ? (this.queueOffsetMax + 1) : msgTreeMap.firstKey();
}

ProcessQueue#removeMessage 的返回值是当前缓存的消息中最小的位点，也就是说消费者每次更新的 commitOffset 是当前还未消费的第一个消息的位点：

ProcessQueue#msgTreeMap

如上图所示的情况下更新的位点应该为 1 而不是 6

PullOffset

Broker 在回复消费者拉取消息的响应中有 nextBeginOffset 字段（PullResult#nextBeginOffset）这个字段也就是 PullOffset

分析 PullMessageProcessor#processRequest 可以发现 nextBeginOffset 字段是从 DefaultMessageStore#getMessage 方法的返回值中提取的：

getMessageResult = this.brokerController.getMessageStore().getMessage(requestHeader.getConsumerGroup(),
 requestHeader.getTopic(), requestHeader.getQueueId(), requestHeader.getQueueOffset(),
 requestHeader.getMaxMsgNums(), messageFilter);

responseHeader.setNextBeginOffset(getMessageResult.getNextBeginOffset());

分析 DefaultMessageStore#getMessage 方法发现 nextBeginOffset 是当前拉取到的消息的下一条消息的位点，这段源码太复杂就不贴出来了

MaxOffset

RocketMQ 的消息是先储存在 CommitLog 中然后由 ReputMessageService 异步构建 ConsumerQueue 和 IndexFile，最终调用 ConsumeQueue#putMessagePositionInfo 写入磁盘

this.byteBufferIndex.flip();
this.byteBufferIndex.limit(CQ_STORE_UNIT_SIZE); // CQ_STORE_UNIT_SIZE = 20
this.byteBufferIndex.putLong(offset);
this.byteBufferIndex.putInt(size);
this.byteBufferIndex.putLong(tagsCode);

MappedFile mappedFile = this.mappedFileQueue.getLastMappedFile(expectLogicOffset);
if (mappedFile != null) {
 return mappedFile.appendMessage(this.byteBufferIndex.array());
}

这里可以发现 ConsumeQueue 的每个 item 都是固定长度 20 字节。所以 MaxOffset 的计算就很简单了，用 ConsumeQueue 文件大小除以 20 即可

消费堆积算法

有了上述位点就可以很容易的算出三种消息堆积量：

$$ \begin{aligned} 未确认的消息量：ConsumerLag &= &MaxOffset\ -\ &ConsumerOffset \\ 正在消费的消息量：InflightMessageCount &= &PullOffset\ -\ &ConsumerOffset \\ 等待拉取的消息量：AvailableMessageCount &= &MaxOffset\ -\ &PullOffset \end{aligned} $$

RocketMQ 中默认的消费堆积是上式中的 ConsumerLag

消息延时的算法类似，将上式中的 offset 换成对应位点消息的时间即可

堆积计算优化

消息延时要求较高的场景

通过对 ConsumerOffset 计算方法的分析可以看出 ConsumerOffset 的更新是存在延迟的，这个延迟分为两个方面：

拉取延时：ConsumerOffset 在每次拉取新消息时更新，而 RocketMQ 是使用长轮询方式更新消息，每次长轮询的默认超时时间是 30s。也就是说如果没有足够数量的消息产生，ConsumerOffset 要 30s 才能更新一次
消费延时：消费者每次提交的 commitOffset 字段是当前还未消费的第一个消息的位点而不是最后一个消费成功的消息的位点。之前的消息未能结束消费的情况下后面已经消费完的消息位点就迟迟得不到更新

所以在消息数量很少但是消费速度很慢的场景下由 ConsumerOffset 计算出来的消息的堆积量和延迟时间的指标就会虚高，但是实际上这些消息已经被消费者拉取到并进行处理了。这时就应该使用 PullOffset 来计算堆积量

开启消息过滤时的堆积计算

因为堆积量是通过位点直接计算得来的，在消费者开启消息过滤时这种算法不能正确处理将被过滤掉的消息，所以会导致堆积量偏高。这种情况下可以计算一下当前 topic 中命中过滤规则的消息占总消息的比例，然后用这个比例乘以堆积量来估计一下真实的堆积量

Cloudflare or Vercel —— 网站托管与函数计算服务选择

Sun, 22 Aug 2021 15:08:44 +0800

在上一篇文章从 Typecho 到 Hugo 的选择与迁移中提到了 Hugo 很适合使用 Serverless 的方式部署并拓展功能。本文就通过博主 Cloudflare 和 Vercel 的使用经验对他们的网站托管（Cloudflare pages vs Vercel）和函数计算（Cloudflare workers vs Vercel function）服务进行简单的介绍和对比

网站托管

Cloudflare pages 和 Vercel 都是十分强大的网站托管服务，提供以下基本特性：

支持从 Github、GitLab 等导入代码
支持多种预设框架自动构建，没有预置的框架可以手动提供构建命令和输出路径
支持绑定自定义域名
支持 CDN
支持生成预览版本

Cloudflare pages

集成 Cloudflare Access，可以自定义访问策略
集成 Cloudflare Web Analytics，提供开箱即用的访问统计
其他 Cloudflare 提供的功能，详情可以参考我之前写过的一篇文章：个人网站 CDN 选用指北

Cloudflare pages 提供的功能简单但是一般情况下已经足够了，它的主要优点是可以和 Cloudflare 的其他服务结合使用，如 DNS、CDN、WAF、Apps 等

Vercel

丰富的可配置项：可以通过配置文件修改缓存规则、响应头、url 格式等，甚至配置路由规则（类似 Nginx 的 redirect 和 rewrite）
提供多种插件：Slack、MongoDB、Logtail 等
集成 Analytics，但是仅支持 Next.js、Nuxt.js、Gatsby
预览构建结果：提供文件管理器查看构建出的文件
提供易读易记的域名：格式类似这样：projectname-git-branch-username.vercel.app，在调试的时候很方便

Vercel 提供的功能要比 Cloudflare 丰富一些，但是它最吸引我的地方是它在国内的访问速度，下面放一下我的博客在 Cloudflare pages 和 Vercel 的访问速度对比图：

Cloudflare pages 速度测试

Vercel 速度测试

可以看出 Vercel 要远比 Cloudflare pages 快，甚至 Vercel 最慢的响应时间比 Cloudflare pages 平均响应时间还短。。。

另外 Vercel 支持配置无限量的路由规则，相比之下 Cloudflare pages 免费版只支持 5 条

函数计算

Cloudflare workers

提供在线编辑器，可以方便的调试代码
添加新的 worker 无需重新部署网站
提供详细的用量、性能统计
支持 cron 触发器
提供开箱即用的 KV 存储

只支持 js

如果你只使用 js 的话 Cloudflare workers 比 Vercel function 要方便和好用很多

Vercel function

支持多种语言：nodejs、php、python、ruby、go
支持包管理工具引入第三方库，如 go mod
提供实时 log 查看

必须重新部署整个网站才能发布对 function 的新增或修改
不提供在线编辑器，只能部署好后通过 log 调试
存储功能需要第三方服务支持

Vercel function 在对语言的支持上要强大很多，借助于对第三方数据库的集成你甚至可以部署 Typecho 或 WordPress。缺点是 Vercel function 与网站托管功能强耦合，必须重新部署整个网站才能发布对 function 的新增或修改，并且 function 不能使用独立的域名

从 Typecho 到 Hugo 的选择与迁移

Fri, 20 Aug 2021 17:03:40 +0800

本站最近从 Typecho 迁移到 Hugo，写这篇文章分析一下 Typecho 和 Hugo 各自的优缺点，给读者在这两者之间选择提供参考。最后记录一下我的迁移过程供后来者参考：Typecho 在服务器已经挂掉的情况下如何恢复所有的文章，然后保存为 Hugo 的文件组织方式

Hugo 与 Typecho 比较

Hugo

优点：

静态博客生成器：生成静态 HTML，性能好，部署方便，很多 serverless 服务商支持一键部署 Hugo
使用模板语法和 shortcodes 实现灵活的内容组装
使用 Hugo pipeline 自动化处理资源文件：SCSS 生成 CSS、minify js、压缩或生成不同尺寸的图片
提供一系列现代化功能：输出 JSON 或 AMP 页面、拓展的 Markdown 语法、接入 Google Analytics、i18n 等
文档完善，社区活跃

缺点：

DIY 门槛比较高，学习曲线比较陡峭
主题数量比较少，大多都是英文主题，并且主题提供的功能或可以自定义的选项比较少
很难实现一些拓展功能，比如博主开发的几款 Typecho 插件就很难在 Hugo 上实现类似的功能
没有评论系统。虽然支持集成 disqus，但是由于众所周知的原因 disqus 在中国不能访问

Typecho

优点：

主题丰富：有很多漂亮的中文主题，并且提供很多 DIY 选项
插件丰富：有第三方插件市场，提供丰富的拓展功能
新手友好：中文社区中教程很多，出问题也有很多大佬可以请教
提供管理后台，支持注册用户、发布文章等

缺点：

早已停止功能更新，只进行维护
Typecho 是基于 php 的动态博客系统，性能不如静态博客
部署比较麻烦，需要部署 web server、php、database，很难使用 serverless 的方式部署

Typecho 与 Hugo 选择我之见

博主从 Typecho 迁移到 Hugo 的主要动力是之前白嫖的服务器到期了。。。相比于 Typecho 用的 php 我对 Hugo 的 go 语言更熟悉一些，而且 Hugo 完善的文档更是极大程度上方便于我的 DIY 大业。

Hugo 作为一个静态博客系统最主要的缺点( 优点 )是没有( ~~不需要~~ )后端，但是这可以通过各家云厂商的函数计算来弥补。函数计算+云上托管的数据库就可以实现一切你想实现的插件功能，本文评论系统的 api 就使用了 Vercel 提供的 function 服务。当然，以上构想需要你具备一定的编程知识，这恐怕不是简单的照猫画虎可以快速掌握的。

博主这里给出一些 Hugo 和 Typecho 的选择建议供读者参考：

如果你对静态博客生成器有强需求，那我估计你也不会读到这 qwq
如果你有编程背景，熟悉云服务，崇尚 GitOps，那么选择 Hugo
如果你想 DIY 并且原意折腾，反复调试各种错误并乐此不疲，那么选择 Hugo
如果你追求极值的访问速度/没有也不想有自己的服务器/有多语言等依赖于 Hugo 特性的需求，那么选择 Hugo
如果你是小白或有一定的 DIY 需求但是并不想折腾，那么选择 Typecho
如果你想有一个在线写作/方便的更新文章的平台，那么选择 Typecho
如果你想一劳永逸的部署/有一个用户&评论系统/有收费等特殊的插件需求，那么选择 Typecho

从 Typecho 到 Hugo

网上有一些 Typecho 迁移插件可以将 Typecho 的文章和附件导出为 Hugo 的文件组织方式，但是我的服务器已经挂掉了没法用这些插件，只能进行手动迁移

迁移文章

直接从数据库的 typecho_contents 表中提取文章标题和内容等信息，这里给出一个示例 sql 语句：

SELECT * FROM blog.typecho_contents where type="post";

可以写一个脚本来将所有文章输出到以各自文章名命名的文件中

迁移图片等附件

我的博客使用了又拍云的对象储存来保存图片等附件，所以只需要把他们下载下来就好。比较麻烦的是修改这些图片在文章中的链接，如果要手动一个个改太耗时间。推荐在 Hugo 的 static 文件夹中新建一个和之前的图片目录结构一样的文件夹，这样就不用修改链接了

Hugo 目录结构

我的 Hugo 文件夹结构如图所示：

tree content/post
.
├── solutions-to-certificate-invalidation-after-android-7
│   ├── cal-hash.jpg
│   ├── index.md
│   ├── install-ca-certificate.jpg
│   └── ssl-handshake-failed.jpg
└── web-font-optimization
 ├── blog_title.jpg
 ├── font_type.jpg
 ├── index.md
 ├── sign.jpg
 └── woff2_support.jpg

每个文章新建一个以文章的 slug 命名的文件夹，将文章用到的图片包括文章头图都放在这个文件夹下。在主题中可以用 .Context.Resources.GetMatch 得到图片的 resource 对象，这样既便于管理，也能将图像交给 Hugo 进行处理。比如 ssl-handshake-failed.jpg 这张图片就会生成以下几个版本：

ls resources/_gen/images/post/solutions-to-certificate-invalidation-after-android-7
...
ssl-handshake-failed.2a74b1a908dba312f29b1f3f15095116_hu9d2358b8f64836a3db846b7dbcdad0ac_92801_250x150_fill_q75_box_smart1.jpg
ssl-handshake-failed_hu9d2358b8f64836a3db846b7dbcdad0ac_92801_1024x0_resize_q75_box.jpg
ssl-handshake-failed_hu9d2358b8f64836a3db846b7dbcdad0ac_92801_480x0_resize_q75_box.jpg

反码和补码的数学原理

Mon, 16 Aug 2021 19:18:16 +0800

本文介绍了使用反码和补码的加法代替减法，并分析了这样做背后的数学原理

本文公式较多，建议使用电脑或平板阅读

反码与补码的表示

原码的表示方法：
符号位加上它的绝对值，即用第一位表示符号，其余位表示值。如果是 $8$ 位二进制：

$$ \begin{array}{l} [+1] = [00000001]_原 \\ [-1] = [10000001]_原 \end{array} $$
反码的表示方法：
正数的反码是其本身
负数的反码是在其原码的基础上，符号位不变，其余各个位取反.

$$ \begin{array}{l} [+1] = [00000001]_原 = [00000001]_反 \\ [-1] = [10000001]_原 = [11111110]_反 \end{array} $$
补码的表示方法：
正数的补码就是其本身
负数的补码是在其原码的基础上，符号位不变，其余各位取反，最后 $+1$. (即在反码的基础上 $+1$)

$$ \begin{array}{l} [+1] = [00000001]_原 = [00000001]_反 = [00000001]_补 \\ [-1] = [10000001]_原 = [11111110]_反 = [11111111]_补 \end{array} $$

反码和补码的意义

我在上一篇文章由 Math.abs 谈负数转换与绝对值运算中有提到补码的作用：

对于计算机来说加减是最基础的运算要设计的尽量简单，而减法相当于加上一个负数，所以完全可以使用加法来代替减法。但是这就出现了如何处理符号位的问题，short、int、long 的位数不同符号位自然也不同，为了避免运算前还需要判断符号位的位置，前人提出了将符号位也引入计算的机制，也就是补码。

确切的说，用反码就可以实现加法来代替减法，其中唯一特殊的是 $0$：

$$ \begin{split} &1 - 1 \\ &= 1 + (-1) \\ &= [0000 0001]_原 + [1000 0001]_原 \\ &= [0000 0001]_反 + [1111 1110]_反 \\ &= [1111 1111]_反 \\ &= [1000 0000]_原 \\ &-0 \end{split} $$

这样算出来的结果是 $-0$，然而对于 $0$ 来说正负号是无意义的，并且 $-0$ 的表示方法使得 $0$ 出现了两个编码
此外，用反码加法代替减法需要循环进位：

$$ \begin{split} &4 - 2 \\ &= 4 + (-2) \\ &= [0000 0100]_原 + [1000 0010]_原 \\ &= [0000 0100]_反 + [1111 1101]_反 \\ \end{split} $$

这里如果按正常的二进制加法计算 $0000 0100 + 1111 1101$ 会得出 $0000 0001$ 即 $1$ 的错误结果。正确的做法是将溢出的进位再加到最低位上，得到正确结果 $0000 0010$ 即 $2$

为了解决 $0$ 有两个编码并且需要循环进位的问题，出现了补码:
补码用 $[00000000]_补$ 表示 0，而 $[10000000]_补$ 表示 $-128$，这样就消除了歧义

$$ \begin{split} &1 - 1 \\ &= 1 + (-1) \\ &= [0000 0001]_原 + [1000 0001]_原 \\ &= [0000 0001]_补 + [1111 1111]_补 \\ &= [0000 0000]_补 \\ &= [0000 0000]_原 \\ &= 0 \end{split} $$

综上所述反码和补码的意义在于可以让符号位参与计算，从而可以用加法代替减法的数学原理。接下来我们接下来我们探讨一下可以这样做背后的数学原理

用反码和补码的加法代替减法的数学原理

首先我们来介绍两个数学概念：

取模运算

取模运算公式：

$$ x \bmod y = x - y \lfloor x / y \rfloor $$

以 $ -3 \bmod 2 $ 为例:

$$ \begin{split} &-3 \bmod 2 \\ &= -3 - 2 \times \lfloor -3/2 \rfloor \\ &= -3 - 2 \times \lfloor -1.5 \rfloor \\ &= -3 - 2 \times (-2) \\ &= -3 + 4 \\ &= 1 \end{split} $$

这里给出一个取模的算法实现：

public int mod(int a, int b) {
 return (a % b + b) % b;
}

同余

两个整数 a，b，若它们除以整数 m 所得的余数相等，则称 a，b 对于模 m 同余

记作 $ a \equiv b \pmod m $，读作 a 与 b 关于模 m 同余

$$ \begin{split} \left. \begin{gathered} 4 \bmod 12 &= 4 \\ 16 \bmod 12 &= 4 \end{gathered} \right\} \implies 4 \equiv 16 \pmod{12} \end{split} $$

同余具有的性质：

自反性，对称性，传递性

$$ \begin{align} &a \equiv a \pmod m \\ &a \equiv b \pmod m \iff b \equiv a \pmod m \\ &a \equiv b \pmod m \text{ 且 } b \equiv c \pmod m \implies a \equiv c \pmod m \\ \end{align} $$

线性运算

$$ \begin{split} a \equiv b \pmod m \text{ 且 } c \equiv d \pmod m \implies \left\{ \begin{gathered} a \pm c &\equiv b \pm d \pmod m \\ a \times c &\equiv b \times d \pmod m \end{gathered} \right. \end{split} $$

同余的除法的性质与加减乘法不同：
$$ a \equiv b \pmod m \quad 且 \quad c \equiv d \pmod m \implies a \equiv b\left(\bmod \frac{m}{\operatorname{gcd}(c, m)}\right) $$

幂运算
$$ a \equiv b \pmod m \implies a^{n} \equiv b^{n} \pmod m $$

证明

我们还是以 $ 4 - 2 $ 为例，根据同余数的性质我们很容易得出这样的结论：

$$ \begin{split} \left. \begin{gathered} 4 &\equiv 4 \pmod{7} \\ -2 &\equiv 5 \pmod{7} \\ \end{gathered} \right\} \implies 4 - 2 \equiv 4 + 5 \pmod{7} \end{split} $$

也就是说我们计算 $ 4 - 2 $ 就相当于计算 $ (4 + 5) \bmod 7 $
如果我们将 $-2$ 和 $5$ 换成二进制会发现 $-2$ 的反码的数值部分正好等于 $5$，也就是说补码的计算实际上是求其模数为当前数制的上限（这个例子中为 $7$）的同余数

$$ \begin{split} -2 &= [1010]_原 = [1101]_反 \\ 5 &= [0101]_原 = [0101]_反 \end{split} $$

这样循环进位就相当于溢出的数对当前数制的上限（这个例子中为 $7$）取模后再与原结果相加

$$ (4 + 5) \bmod 7 = 8 \bmod 7 + 1 = 2 $$

这里的 $8$ 相当于进位

而补码的计算相比于反码只不过是增加了模的值：这时我们计算 $ 4 - 2 $ 就相当于计算 $ (4 + 6) \bmod 8 $

$$ (4 + 6) \bmod 8 = 8 \bmod 8 + 2 = 2 $$

因为进位 $ 8 \bmod 8 = 0 $ 所以不需要循环进位

另一种数学推导可以看这篇文章：反码与补码加法的理解

由 Math.abs 谈负数转换与绝对值运算

Mon, 16 Aug 2021 15:53:15 +0800

本文通过分析一个 Java 中 Math.abs() 误用引发的 bug 介绍了计算机中数的储存、负数转换与绝对值运算

背景

最近遇到了一个奇妙深刻的 bug：我们的系统中使用了一个 int 型的变量来计数，这个计数器变量的绝对值取模作为某个 list 的 index，但是今天出现了异常 IndexOutOfBoundsException

// 满足某些条件计数器自增
int count = 0;
count++；

int index = Math.abs(count) % list.size();
// java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1
list.get(index);

Math.abs 遇上 Integer.MIN_VALUE

我们知道 int 是用 32 位二进制储存的，其中最高位是符号位。上述代码不断自增 count 变量最终会使其超过上限从而反转成负数（Integer.MAX_VALUE + 1 == Integer.MIN_VALUE 会返回 true）我们预料到了这种情况发生所以使用 Math.abs(count) 来确保取模的结果为正数，但是结果事与愿违

我们查看报错信息发现 -2147483648 正好是 Integer.MIN_VALUE，所以我们先试一下 Math.abs(Integer.MIN_VALUE) 结果居然是 -2147483648，这显然不符合我们的预期，让我们先来看一下 Math.abs() 的实现：

 /**
 * Returns the absolute value of an {@code int} value.
 * If the argument is not negative, the argument is returned.
 * If the argument is negative, the negation of the argument is returned.
 *
 * <p>Note that if the argument is equal to the value of
 * {@link Integer#MIN_VALUE}, the most negative representable
 * {@code int} value, the result is that same value, which is
 * negative.
 *
 * @param a the argument whose absolute value is to be determined
 * @return the absolute value of the argument.
 */
 @HotSpotIntrinsicCandidate
 public static int abs(int a) {
 return (a < 0) ? -a : a;
 }

注释中说明了如果 a 是 Integer.MIN_VALUE 那么返回值也是负数。到这里就破案了，只要把 Math.abs(count) % list.size() 改为 (count % list.size() + list.size()) % list.size() 即可，下面分析一下为什么会出现这种情况

改为 (count % list.size() + list.size()) % list.size() 而不是 Math.abs(count % list.size()) 是因为前者符合取余的数学定义
详情可以看我的另一篇文章反码和补码的数学原理

运算符 - 的原理

分析 Math.abs() 的代码可以发现问题出在运算符 - 上，也就是说 -Integer.MIN_VALUE == Integer.MIN_VALUE，显然出现这种情况说明运算符 - 的作用不可能是简单的将符号位取反。

要继续分析就要先了解数在计算机中的储存原理：对于计算机来说加减是最基础的运算要设计的尽量简单，而减法相当于加上一个负数，所以完全可以使用加法来代替减法。但是这就出现了如何处理符号位的问题，short、int、long 的位数不同符号位自然也不同，为了避免运算前还需要判断符号位的位置，前人提出了将符号位也引入计算的机制，也就是补码。

补码的表示方法是:

正数的补码就是其本身
负数的补码是在其原码的基础上符号位不变，其余各位取反，最后 +1

计算机中计算 1 - 1 的原理：

$$ \begin{split} &1 - 1 \\ &= 1 + (-1) \\ &= [0000 0001]_原 + [1000 0001]_原 \\ &= [0000 0001]_补 + [1111 1111]_补 \\ &= [0000 0000]_补 \\ &= [0000 0000]_原 \\ &= 0 \end{split} $$

所以运算符 - 的原理是进行求其补码的运算，即按位取反然后 +1，于是我们来分析 -Integer.MIN_VALUE 的运算过程

-Integer.MIN_VALUE = ~Integer.MIN_VALUE + 1 = ~0x80000000 + 1 = 0x7fffffff + 1 = 0x80000000

可以发现在 0x7fffffff + 1 的过程中发生了溢出，所以最后的结果还是 0x80000000 也就是 Integer.MIN_VALUE

总结

通过以上分析我们可以知道，使用 Math.abs() 对 Short.MIN_VALUE、Integer.MIN_VALUE、Long.MIN_VALUE 取绝对值都得不到正确的结果。那有没有方法可以得到正确的结果呢？答案是 Integer.MIN_VALUE 的绝对值在 Integer 的范围内无法表示，因为 0 的存在 Integer. MAX_VALUE 比 Integer.MIN_VALUE 的绝对值小 1。如果确实要得到 Integer.MIN_VALUE 的绝对值可以先转换为 Long：Math.abs(Long.valueOf(Integer.MIN_VALUE))

对一个并发问题的思考

Wed, 13 Nov 2019 22:29:00 +0800

遇到了一个并发问题，将对锁的设计的思考记录一下：

这个问题的逻辑是：需要根据 id 获取数据库中指定的一行数据，如果这行数据的某个字段为 null 则请求远程接口来获取数据（每次请求接口这个数据都会更新），然后将获取的值写入到数据库中

关键的问题在于如何能在高并发的情况下保证最后数据库中存的是最新获取的数据，显然我们可以用 synchronized 锁来解决。但是这个方法中有三个耗时操作，如果这样粗暴的解决肯定是行不通的，所以要考虑如何减小锁的粒度。

我的解决方案是使用一个 HashMap 来为每个 id 生成一把锁（采用 lazyload 策略，尝试获取锁时再生成）这样只有对多个 id 的连续请求才会阻塞

但是这样随之而来的是另一个新问题：HashMap 会无限地新增锁，如果 id 的数量过多那岂不是得被挤爆内存，所以我这里新开一个线程去删除暂时不用的锁

这个删除逻辑又有两个问题：

如何保证前一个线程执行完下一个线程有机会获取锁
如何保证删除的锁真的是没人用的

第一个问题通过把删除线程睡眠 3s 来解决，第二个问题我通过重新读取 lock 来解决，并且获取 map 的锁来保证没有其他线程能在检测过程中能访问 map 以及获得新 lock、检测是否占用、从 map 中删除这三个操作的原子性

 // private static final ReentrantLock mapLock = new ReentrantLock();
 // private static final HashMap<Long, ReentrantLock> map = new HashMap<>();
 private int checkAndUpdate(int id) {
 mapLock.lock();
 ReentrantLock lock = map.getOrDefault(id, new ReentrantLock());
 mapLock.unlock();
 lock.lock();
 // check and update
 lock.unlock();
 new Thread(() -> {
 try {
 Thread.sleep(3000);
 mapLock.lock();
 ReentrantLock newLock = map.get(id);
 if (newLock != null && !newLock.isLocked()) {
 map.remove(id);
 }
 mapLock.unlock();
 } catch (InterruptedException e) {

 }
 }).start();
 }

可以优化的点：

采用线程池来执行删除逻辑
获取到 lock 后先判断是否已经加锁，如果已经加了则直接放弃更新，否则尝试加锁
因为如果竞争锁失败那么说明已经有线程在尝试更新这个为 null 的值了，如果更新成功那这个值不再为 null 就不用再次更新了，如果更新失败那显然要提示用户失败，用户会再次尝试。所以还是直接放弃的好

Nginx SSL/TLS 配置优化

Sun, 06 Oct 2019 18:38:00 +0800

本文描述的优化技巧基于 Nginx 1.17、OpenSSL 1.1.1d、TLS1.2 和 TLS1.3

TLS1.2 Session 复用

session 复用有两种方式，我选择的是 Session Identifier，下面讨论下这两种方式的机制：

Session Identifier

客户端保存 session ID，在发起 Client Hello 时将上次使用的 session ID 发送给服务端，服务端根据收到的 session ID 找到保存好的对称密钥。

nginx 中的配置：

# 指定缓存大小为 30m
ssl_session_cache shared:SSL:30m;
# 指定缓存时间为 1 天
ssl_session_timeout 1d;
# 这里需要关闭默认开启的 ssl_session_tickets
ssl_session_tickets off;

这里有两个问题：

服务器缓存 session 信息会对服务器性能造成影响

不支持分布式部署，缓存只在单机上保存。这个问题可以使用 OpenResty 配合 Redis 解决：

ssl_session_fetch_by_lua_file lua/session_fetch.lua;
ssl_session_store_by_lua_file lua/session_store.lua;
ssl_session_timeout 1d;
ssl_session_tickets off;

Session Ticket

服务器将 session 信息加密后保存在 session ticket 中交由客户端保存，客户端会在 client hello 的拓展中加上 session ticket，服务器解密后就可以恢复会话信息

这个方式安全性要差一些：

Nginx 和 Apache 都只在重启后才会更改加密使用的密钥
session ticket 不具有前向保密性，并且一旦 session ticket 被解密会使 TLS 的前向保密性机制完全失效。相关讨论可以参考这篇文章：

TLS1.3 Early data（0-RTT）

TLS 1.3 中抛弃了之前的两种 session 复用方式，转而采用 PSK 复用：

和 TLS1.2 的对比：

	TLS1.2 首次连接	TLS1.2 会话复用	TLS1.3 首次连接	TLS1.3 会话复用
DNS 解析	1-RTT	0-RTT	1-RTT	0-RTT
TCP 握手	1-RTT	1-RTT	1-RTT	1-RTT
TLS 握手	2-RTT	1-RTT	1-RTT	0-RTT
HTTP Request	1-RTT	1-RTT	1-RTT	1-RTT
总计	5-RTT	3-RTT	4-RTT	2-RTT

实现机制

第一次连接建立后服务器向客户端发送 New Session Ticket 包，其中的 early_data 拓展指定了是否能使用 Early data（0-RTT 连接）及其参数

New Session Ticket

第二次连接客户端发送 Client Hello 时同时发送 Early data

Early data

可以使用 openssl 测试：

openssl s_client -connect :443 -tls1_3 -sess_in session.pem -early_data request.txt

完整测试脚本

更多细节参考 RFC 8446：https://tools.ietf.org/html/rfc8446#section-2.3

这种方式虽然可以省下一个 RTT 但是牺牲了前向安全性和抵抗重放攻击的能力

在 nginx 中开启 Early data 的方式：

ssl_early_data on;
# 可选项，表示此 HTTP 请求在 Early data 中发送
proxy_set_header Early-Data $ssl_early_data;

OCSP stapling

OCSP stapling 是一项 TLS 的拓展：

服务器将 OCSP response 缓存在服务器中，然后把它们作为 TLS 握手的一部分发送给客户端。因此，客户端在和一个支持 OCSP Stapling 技术的服务器通信时，它可以同时接收到服务器证书和该证书的状态

这项技术有效的保护了用户的隐私同时保证了 OCSP 的可用性

Nginx 中开启 OCSP stapling：

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 1.0.0.1 8.8.8.8 8.8.4.4 208.67.222.222 208.67.220.220 valid=60s;
resolver_timeout 2s;

要注意的是如果你的 CA 提供的 OCSP 需要验证的话，必须用 ssl_trusted_certificate 指定 CA 的中级证书和根证书（PEM 格式，放在一个文件中）的位置，否则会报错 [error] 17105#17105: OCSP_basic_verify() failed

Strict SNI

为 Nginx 开启严格的 SNI 匹配，防止使用 ip 或错误域名的访问暴露证书

Nginx 本身不提供这个功能，1.15.10 以后的版本可以使用这个 patch：

# run in nginx directory
curl https://github.com/hakasenyang/openssl-patch/blob/master/nginx_strict-sni_1.15.10.patch | patch -p1

然后在 http 模块中开启

strict_sni on;
strict_sni_header on;

使用 ECC 证书

ECC 证书即使用 ECDSA（Elliptic Curve Digital Signature Algorithm）的证书，拥有更小的密钥长度和与主流算法相比更好的加密强度（相当于 RSA 3072）

下图即是一个 ECC 证书：

ECC 证书

密码套件选择

我选用的服务器偏好密码套件：

密钥交换算法：ECDH （具有前向安全性并且比 DH 资源消耗低）

签名算法：ECC

对称加密算法：AES-GCM （是一种 AEAD 算法并且加密解密均可并行计算）

完整配置：

ssl_ecdh_curve X25519:P-256:P-384:P-224:P-521;
ssl_ciphers [TLS_AES_256_GCM_SHA384|TLS_AES_128_GCM_SHA256|TLS_CHACHA20_POLY1305_SHA256]:[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

等价加密算法组

上文中 [XXX|XXX] 是等价密码组的写法，在开启 ssl_prefer_server_ciphers on 的情况下给予客户端在有限的几种密码套件之间选择最合适的一种

本站使用这项技术为不支持 AES-NI 的设备自动协商 CHACHA20-POLY1305 算法
OpenSSL 中不支持此项技术，可以使用 boringssl 或打上这个 patch：

PS. ARMv8 中就提供了 AES 指令集支持，都 9102 年了，新手机基本上没有不支持的

DH 参数

为上文中 DHE 和 ECDHE 指定一个更强的参数（这里是 4096 位）

step 1. 使用 openssl 生成 dhparam.pem 文件

openssl dhparam -out dhparam.pem 4096

step 2. 配置 nginx 参数

ssl_dhparam path-to-dhparam-file

Nginx 编译安装脚本

Fri, 23 Aug 2019 11:20:00 +0800

此脚本适用于 Ubuntu，自动编译安装 nginx

为什么需要此脚本

安装 Nginx 最新 Mainline version
对 nginx 和 OpenSSL 打补丁
- 为 nginx 添加 SPDY、FULL HPACK、Dynamic TLS Record 支持
- 为 nginx 提供选择 TLS 1.3 密码套件的功能
- 为 openssl 添加等价密码组、chacha 草案支持
使用 jemalloc 优化内存管理
使用 Cloudflare 优化的 zlib，提升性能
添加 brotli 压缩支持
添加 Strict-SNI 支持
添加 Lua 支持
可选项：nginx 流媒体支持（Rmtp、HLS、Dash）、简易的 web 应用防火墙（lua_waf）

使用方法

GitHub 仓库：ShadowySpirits/vps-setup

运行此行代码即可

curl https://raw.githubusercontent.com/ShadowySpirits/vps-setup/master/nginx_install.sh | bash

运行脚本时添加以下参数开启可选功能：

–with-vod : 添加 nginx-vod-module（nginx 流媒体支持）
–enable-mkv : 开启 nginx-vod-module 的 mkv 格式支持 (实验性功能)
–with-waf : 添加 lua_waf （简易的 web 应用防火墙）

使用以下命令开启、关闭或重启服务

sudo service nginx start/stop/restart

此脚本依赖的代码仓库多位于国外服务器，如安装失败请检查是否是网络问题

Deluge 2.0.3 修改 user-agent 和 peer-id 教程

Fri, 23 Aug 2019 10:57:00 +0800

本文提供一种修改 Deluge 的 user-agent 和 peer-id 的方法，用于伪装其他 BT 下载工具，绕过某些限制

PS：附部分 BT 下载工具 user-agent 和 peer-id 列表

如果你不知道如何安装 Deluge 请先阅读 Deluge 一键安装脚本

TL;DR

可以使用 dzhuang 打包好的 docker iamge: dzhuang/docker-deluge

在设置中直接修改 user-agent 和 peer-id

config

dzhuang 提供了源码仓库，请使用者自行评估

修改 user-agent

打开文件 /usr/lib/python3/dist-packages/deluge/core/core.py

修改 123 行左右：

# Start the libtorrent session.
- user_agent = 'Deluge/{} libtorrent/{}'.format(DELUGE_VER, LT_VERSION)
+ user_agent = 'Transmission/2.11'

修改 peer-id

修改 291 行左右：

peer_id = substitute_chr(peer_id, 6, release_chr)

- return peer_id
+ return '-TR2110-'

虽然这是 Deluge 2.0.3 的教程，但 Deluge 其他版本修改方式大同小异，搜索字符串 user_agent 和 peer_id 也能找到关键代码位置

部分 BT 下载工具 user-agent 和 peer-id 列表

name	user-agent	peer-id
utorrentMac 1.6.4	uTorrentMac/1640(27255)	-UM1640-
utorrent 2.2.1	uTorrent/2210(25110)	-UT2210-
Transmission 2.11	Transmission/2.11	-TR2110-
Deluge 1.3.5	Deluge/1350	-DE1350-

Deluge 一键安装脚本

Fri, 23 Aug 2019 10:26:00 +0800

此脚本适用于 Ubuntu，自动安装 deluged 和 deluge-webui

为什么需要此脚本

自动安装 deluge 最新稳定版
创建 deluge 用户以运行 deluge 程序
创建 deluged 和 deluge-web 服务，开机自启动

使用方法

GitHub 仓库：ShadowySpirits/vps-setup

运行此行代码即可

curl https://raw.githubusercontent.com/ShadowySpirits/vps-setup/master/deluge_install.sh | sudo bash

使用以下命令开开启、关闭或重启服务

sudo service deluged start/stop/restart
sudo service deluge-web start/stop/restart

然后访问 http://your-ip:8112 就可以进入 Deluge WebUI

输入默认密码 deluge 后，点击 connect 就可以连接上服务器，开始使用了

使用 Kotlin DSL 代替 Builder 模式

Mon, 29 Apr 2019 23:22:00 +0800

本文旨在介绍如何用 Kotlin DSL 来代替 Builder 模式，如果你不知道什么是 DSL 或者不了解 Kotlin 中的 DSL 可以阅读我的上一篇文章：Kotlin DSL 简介

举个例子

我们想编写一个 HTML 构建器输出如下：

<html>
 <head>
 <title>HTML encoding with Kotlin</title>
 </head>
 <body>
 <h1>HTML encoding with Kotlin</h1>
 <p>this format can be used as an alternative markup to HTML</p>
 <a href="http://jetbrains.com/kotlin"> Kotlin </a>
 <p>some text</p>
 </body>
</html>

如果使用 Builder 模式代码类似这样：

val html = HTMLBuilder().addHead(
 HeadBuilder().addTitle(TitleBuilder("HTML encoding with Kotlin").build())
 ).addBody(
 BodyBuilder().addH1(H1Builder("HTML encoding with Kotlin"))
 .addP(PBuilder("this format can be used as an alternative markup to HTML").build())
 .addA(ABuilder("Kotlin")
 .setHerf("http://jetbrains.com/kotlin")
 .build()
 ).addP(PBuilder("some text").build())
 ).build()
println(result)

写这些 XXXBuilder 就很麻烦了，而且代码十分臃肿，可读性很差。再来看看 Kotlin DSL 的写法：

fun main(args: Array<String>) {
 val result =
 html {
 head {
 title { +"HTML encoding with Kotlin" }
 }
 body {
 h1 { +"HTML encoding with Kotlin" }
 p { +"this format can be used as an alternative markup to HTML" }

 // an element with attributes and text content
 a(href = "http://jetbrains.com/kotlin") { +"Kotlin" }
 p { +"some text" }
 }
 }
 println(result)
}

显然更加清晰明了，并且代码量要少的多。

具体实现

我们来分析一下这段 Kotlin DSL 实现：构造标签使用的是类似 html { … } 这样的函数，这个函数接收一个 Lambda 表达式作为参数，并返回一个 HTML 对象：

inline fun html(init: HTML.() -> Unit): HTML {
 val html = HTML()
 html.init()
 return html
}

这里使用内联函数来避免 Lambda 表达式的开销

其他标签同理，所以我们可以构建一个泛型函数：

abstract class Tag() {
 val children = arrayListOf<Tag>()

 inline protected fun <T: Tag> initTag(tag: T, init: T.() -> Unit): T {
 tag.init()
 children.add(tag)
 return tag
 }

 ....

}

然后传入对应的标签类型即可创建不同的标签：

class HTML(): Tag() {
 fun head(init: Head.() -> Unit) = initTag(Head(), init)

 fun body(init: Body.() -> Unit) = initTag(Body(), init)
}

这样我们就完成了一个简单的 HTML Builder，完整的代码见此：HTML Builder。

限制作用域

思考如下代码：

html {
 +"html scope"
 head {
 +"head scope"
 head {
 +"head scope"
 }
 }
}

显然 head 标签中嵌套另一个 head 标签是没有意义的，而且编译却不会报错。这是因为 Kotlin 会隐式推断接收者为最顶层 Lambda 表达式中 this 指向的 HTML 对象。所以我们要修正这个问题就要禁止这种隐式推断：

@DslMarker
annotation class HtmlTagMarker

@HtmlTagMarker
abstract class Tag() {
 ....
}

使用 @DslMarker 声明一个注解 @HtmlTagMarker，然后为所有标签的基类 Tag 加上这个注解即可。再次尝试使用这种不规范的写法就会报错：

'fun head(init: Head.() -> Unit): Head' can't be called in this context by implicit receiver.

但是我们仍通过指定的接收者进行调用：

html {
 +"html scope"
 head {
 +"head scope"
 this@html.head {
 +"head scope"
 }
 }
}

Kotlin DSL 简介

Mon, 29 Apr 2019 11:38:00 +0800

什么是 DSL

DSL(Domain Specific Language) 中文名称特定领域专用语言，与 GPL(General Purpose Language) 即通用编程语言相对。

维基百科中对 DSL 的定义如下：

A domain-specific language (DSL) is a computer languagespecialized to a particular application domain.

也就是说，DSL 是一种表达能力有局限的语言。相比于常见的 C、Java、PHP 等语言，DSL 并不能解决所有问题；相反，DSL 的优势在于高效、跨平台。

常见的 DSL 语言：

Regex
SQL
HTML & CSS

以前端开发为例，一般都是使用 HTML 或 XML 描述界面，然后用 js (Web) 或 java/kotlin (Android) 等语言编写逻辑。你会发现 DSL 描述界面比用代码创建组件要方便的多，而且写出的 HTML 或 XML 文件在任何语言任何系统下都可以解析。

在 Kotlin 中使用 DSL

上一节提到的 DSL 是作为一门单独的语言存在的 External DSL，某些语言为了引入 DSL 的特性加入了 Internal DSL 这种东西。比如在 Kotlin 中用代码构建一段 HTML：

HTML Builder

你可以在 Try Kotlin 上找到这段示例。

所以，我们可以用这种特性极大的精简我们的代码（第二个例子使用的是 Kotlin/anko 这个库）：

// Create Alert Dialog

// Android developer guide
val builder = AlertDialog.Builder(it)

builder.setTitle("Hi, I'm Roy")
.setMessage("Have you tried turning it off and on again?")
.setPositiveButton(R.string.fire,
DialogInterface.OnClickListener { dialog, id -> toast("Oh…")})

builder.create()

// Use Kotlin DSL
alert("Hi, I'm Roy", "Have you tried turning it off and on again?") {
 yesButton { toast("Oh…") }
}.show()

或是在代码中编写界面布局：

verticalLayout {
 val name = editText()
 button("Say Hello") {
 onClick { toast("Hello, ${name.text}!") }
 }
}

可以看到我们构建了由一个 EditText 和一个 Button 构成的界面，并且我们在描述界面的同时就完成了逻辑的编写。

操作系统原理 —— 中断

Tue, 19 Mar 2019 22:19:00 +0800

中断（英语：Interrupt）是指处理器接收到来自硬件或软件的信号，提示发生了某个事件，应该被注意，这种情况就称为中断。¹

In summary, interrupts are used throughout modern operating systems to handle asynchronous events.²

我们考虑这样一个场景：从键盘读入一个字符。从 CPU 的角度来看这种 I/O 操作的速度远慢于 CPU 频率，所以在 CPU 发出读入字符的指令后需要消耗数百上千个时钟周期来轮询是否有数据返回（这被称为忙等待 Busy waiting），在这个过程中其他操作被阻塞，直到键盘返回数据。显然这样的低效率逻辑是不可接受的。我们需要的是一种异步机制：需要时再通知 CPU 来处理，这样可以最大程度的减少 CPU 的等待时间。

Interrupt timeline

如图所示，每当 I/O 设备完成动作时都会触发中断，然后 CPU 停止正在进行的工作，去处理相应的中断

下面我们通过硬件中断（Hardware Interrupt）来详细介绍一下中断机制：

CPU 通知设备驱动程序开始一个 I/O 操作，然后去处理其他应用程序
设备控制器处理 I/O 操作并在完成时发送中断信号
CPU 检测到中断信号暂停正在处理的程序转而处理中断

Interrupt process

这就是整个硬件中断的原理，但是我们还需要讨论几个细节问题

CPU 如何检测中断信号
CPU 如何处理不同类型的中断
如何决定是否延迟执行或优先执行某个中断

为了回答上面 3 个问题，我们首先要知道什么是中断信号。每个设备的驱动程序都提供中断服务程序（interrupt service routine，ISR）用于响应中断，这些中断服务程序的地址储存在一个被称为中断向量（interrupt vector）的数组中，而中断信号给出了对应设备的中断服务程序在中断向量中的索引。

在大多数的操作系统中，中断向量并不直接储存中断服务程序的地址，而是存储着多个数组的首地址，每个数组中包含一类中断处理程序的地址。CPU 通过中断信号的索引找到对应类别的数组，然后通过遍历该数组来找到相应的处理程序。这种机制被称为 interrupt chaining，下图是 Intel 处理器的中断向量。

Intel interrupt vector

CPU 硬件有被称为中断请求线（interrupt-request line）的机制，CPU 在执行每条指令后检测到该线中是否有中断信号，如果有则以这个中断信号作为索引从中断向量中取出中断服务程序的地址，然后去执行相应的程序。

为了解决第 3 个问题，操作系统需要多级中断机制，以便操作系统可以区分高优先级和低优先级中断，并且可以对不同紧急程度的中断进行响应。大多数 CPU 有两个中断请求线。一种是不可屏蔽的中断（nonmaskable interrupt）：它被用于及时响应不可恢复的错误。第二种是可屏蔽的中断（maskable interrupt）：CPU 可以通过不同中断的优先级决定是否延迟响应或者先响应高优先级中断。

除了硬件中断外还有一种“软中断”（Software interrupt），它通常在程序抛出异常以及系统调用中触发。软中断相关内容在内核态及系统调用中介绍。

维基百科 ↩︎
《Operating System Concepts》 ↩︎

php 几种非阻塞方式分析

Sat, 02 Mar 2019 12:11:00 +0800

本文介绍了几种非阻塞执行 php 代码的方法，并分析他们的性能与适用环境

本文用如下代码来测试这几种非阻塞实现的性能：

// 1.php:
$stime = microtime(true);
$stime .= PHP_EOL;
// 执行非阻塞逻辑
file_put_contents(__DIR__ . '/debug.log', 'stime：' . $stime, FILE_APPEND);

// 2.php:
// 模拟耗时操作
sleep(2);
$etime = microtime(true);
$etime .= PHP_EOL;
file_put_contents(__DIR__ . '/debug.log', 'etime：' . $etime, FILE_APPEND);

curl

利用 php curl 函数设置一个较小的 timeout，来间接达成非阻塞。这种方法会主动断开连接，所以对于有这方面限制的 api 是不适用的

CURLOPT_TIMEOUT

较老的 curl 拓展只支持 CURLOPT_TIMEOUT 这个参数，也就是最低 timeout 为 1s

function curl() {
 $ch = curl_init();
 curl_setopt($ch, CURLOPT_URL, '127.0.0.1/aaa.php');
 curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
 curl_setopt($ch, CURLOPT_TIMEOUT, 1); // 一秒后关闭连接
 curl_setopt($ch, CURLOPT_HEADER, true);
 curl_exec($ch);
 curl_close($ch);
}

output:
3.002
3.001
2.9951

CURLOPT_TIMEOUT_MS

这个参数在 curl 7.16.2 中被加入，用于设置毫秒级的 timeout

如果 libcurl 编译时使用系统标准的名称解析器（ standard system name resolver），那部分的连接仍旧使用以秒计的超时解决方案，最小超时时间还是一秒钟

function curl() {
 $ch = curl_init();
 curl_setopt($ch, CURLOPT_URL, '127.0.0.1/aaa.php');
 curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
 curl_setopt($ch, CURLOPT_TIMEOUT_MS, 10); // 10 毫秒后关闭连接
 curl_setopt($ch, CURLOPT_HEADER, true);
 curl_exec($ch);
 curl_close($ch);
}

output:
2.0141
2.0043
2.0127

curl_multi

利用 cURL 中的 curl_multi_* 函数发送异步请求，并且可以并发请求

function curl_multi() {
 $mh = curl_multi_init();
 $ch = curl_init();
 curl_setopt($ch, CURLOPT_URL, '127.0.0.1/aaa.php');
 curl_multi_add_handle($mh, $ch);
 curl_multi_exec($mh, $active);
 curl_close($ch);
 curl_multi_remove_handle($mh, $ch);
 curl_multi_close($mh);
}

output:
2.0134
2.0226
2.0157

fsocketopen 或 stream_socket_client

用 fsocketopen() 打开一个连接，然后用 stream_set_blocking() 设置非阻塞模式

function sock() {
 $fp = fsockopen('127.0.0.1', 80, $error_code, $error_msg, 1);
 if (!$fp) {
 return array('error_code' => $error_code, 'error_msg' => $error_msg);
 }
 stream_set_blocking($fp, 0);
 $header = "GET /aaa.php HTTP/1.1\r\n";
 $header .= "Host: 127.0.0.1\r\n";
 $header .= "Connection: close\r\n\r\n";
 fwrite($fp, $header);
 fclose($fp);
 return array('error_code' => 0);
}

output:
2.0348
2.0142
2.0149

fastcgi_finish_request

这个函数可以返回缓冲区内的所有响应的数据给客户端并结束请求，但是仍继续运行当前脚本直到运行完成或者达到 timeout。所以我们可以在耗时操作前使用该函数以实现非阻塞

注意：

虽然这个函数叫 fastcgi 但是这是个实实在在的 FPM 函数，需要在 FPM 环境下调用
使用该函数后，这个脚本将占用一个 FPM 进程，所以如果对高耗时脚本滥用此函数会导致 502 bad gateway
使用这个函数会给当前 session 加锁，如不需要修改 session 推荐使用 session_write_close() 解除占用

$stime = microtime(true);
if (PHP_SAPI === 'fpm-fcgi' && function_exists('fastcgi_finish_request')) {
 fastcgi_finish_request();
}
sleep(2);
$etime = microtime(true);
$etime .= PHP_EOL;
file_put_contents(__DIR__ . '/debugtest.log', $stime - $etime, FILE_APPEND);

output:
2.00048
2.00043
2.00042

pcntl_fork

用 pcntl_fork 创建子进程的方式实现真正的异步，这个函数由 pcntl 扩展提供。
为了防止子进程变成僵尸进程，在父进程使用 pcntl_wait 等待子进程返回并回收资源
我这里采用了二次 fork 的方式，让第一次 fork 出的子进程 a 再 fork 出实际的工作进程 b，让 a 先行退出，使得 b 成为孤儿进程，被 init 进程托管。这样实现了父进程非阻塞，而且子进程不会成为僵尸进程。

class Arrow
{

 static $instance;

 public static function getInstance()
 {
 if (null === self::$instance)
 self::$instance = new self();
 return self::$instance;
 }

 public function run($rb)
 {
 cli_set_process_title('process_a');
 $pid = pcntl_fork();
 if ($pid > 0) {
 pcntl_wait($status);
 } elseif ($pid == 0) {
 $cid = pcntl_fork();
 if ($cid > 0) {
 cli_set_process_title('process_b');
 exit();
 } elseif ($cid == 0) {
 cli_set_process_title('process_c');
 $rb();
 } else {
 exit();
 }
 } else {
 exit();
 }
 }

$stime = microtime(true);
$stime .= PHP_EOL;
Arrow::getInstance()->run(function () use ($stime) {
 sleep(2);
 $etime = microtime(true);
 $etime .= PHP_EOL;
 file_put_contents(__DIR__ . '/debug.log', $stime - $etime, FILE_APPEND);
});

output:
2.023
2.004
2.010

我们用 ps ax 查看一下进程：
TTY 为 ? 的进程即为与终端无关，是守护进程（daemon）

ps ax | grep -v grep | grep -E 'process_|PID'
 PID TTY STAT TIME COMMAND
 7750 ? S 0:00 process_c

Laravel 开发准备工作

Sat, 23 Feb 2019 23:24:00 +0800

因为某些原因需要搞个 laravel 项目，于是乎翻出此前的文章补充记录下 laravel 开发准备工作。

本教程适用环境：

安装 laravel

安装 php
安装 composer
换源：composer config -g repo.packagist composer https://packagist.laravel-china.org
全局安装 laravel/installer：composer global require laravel/installer
创建 laravel 项目：laravel new blog

安装 laravel-ide-helper

Laravel 本身的依赖注入，服务提供者等特性使得 IDE 很难做到代码检查和智能提示，所以需要安装 barryvdh/laravel-ide-helper 来辅助进行代码补全和追踪。

composer require --dev barryvdh/laravel-ide-helper

然后运行下列代码命令生成代码提示文件：

php artisan ide-helper:generate
php artisan ide-helper:meta

你可以设置 composer.json 使每次自动更新后重新生成代码提示文件：

"scripts":{
 "post-update-cmd": [
 "Illuminate\\Foundation\\ComposerScripts::postUpdate",
 "php artisan ide-helper:generate",
 "php artisan ide-helper:meta"
 ]
}

可选设置项：

添加对 migration 的代码提示的支持：

发布配置文件 config/ide-helper.php

php artisan vendor:publish --provider="Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider" --tag=config

更改 include_fluent 设置

'include_fluent' => true

然后重新生成代码提示文件

php artisan ide-helper:generate

添加对 Model 的代码提示的支持：

这里使用 @mixin 注解来标注文档

PhpStorm interprets @mixin regardless of PHP version just the same way it interprets “use trait” (see WI-1730 for details)

在你的模型类或者 Illuminate\Database\Eloquent\Model 前加上 /** @mixin \Eloquent */
```
 namespace Illuminate\Database\Eloquent;

 use ...;

 /** @mixin \Eloquent */
 abstract class Model implements ArrayAccess, Arrayable, Jsonable, JsonSerializable, QueueableEntity, UrlRoutable
 { ... }
```

安装 Laravel Plugin

Laravel Plugin 是一个增强 PhpStorm 对 Laravel 支持的插件，功能截图如下：

功能截图1

功能截图2

此插件依赖于 barryvdh/laravel-ide-helper

在 Settings > Plugins 中搜索 Laravel Plugin 进行安装

本地化

生成 Application Key

php artisan key:generate

修改时区

// config/app.php
'timezone' => 'Asia/Shanghai'

安装语言包

安装 overtrue/laravel-lang :

composer require --dev overtrue/laravel-lang

将 config/app.php 中

Illuminate\Translation\TranslationServiceProvider::class

替换为

Overtrue\LaravelLang\TranslationServiceProvider::class

并修改 locale

'locale' => 'zh-CN'

Typecho 追番列表插件

Mon, 18 Feb 2019 21:31:00 +0800

项目介绍

Bangumi 追番列表插件 Typecho 版

使用短代码 [bangumi] 在任何位置插入你的 Bangumi 追番列表

插件效果见此处：https://blog.sspirits.top/about

GitHub 仓库：ShadowySpirits/BangumiList

使用方法

在 Release 中下载此插件的最新版，上传至网站的 /usr/plugins 目录下；
启用该插件，正确填写相关信息。
在你想展示的位置插入短代码 [bangumi]

Typecho 评论 SMTP、Mailgun 邮件通知插件

Mon, 18 Feb 2019 21:08:00 +0800

插件简介

Comment2Mail 是 Typecho 评论邮件通知插件，支持 SMTP、Mailgun 两种接口，其中 SMTP 接口采用非阻塞方式发送邮件

在评论审核通过、用户评论文章、用户评论被回复时发送邮件通知

详见 GitHub：ShadowySpirits/Comment2Mail

邮件模板

安装方法

至 Releases 中下载最新版本插件，上传至网站的 /usr/plugins/ 目录下
启用该插件，正确填写相关信息

鸣谢

本插件模板参考自 ylqjgm/LoveKKComment

KMS 激活 Windows 和 Office

Sun, 17 Feb 2019 19:38:00 +0800

kms 激活适用于批量授权版本，即 VL 版的 Windows 和 Office

使用方法

以管理员身份开启一个 CMD 窗口

Windows

slmgr.vbs -ipk <windows-GVLK-key>
slmgr.vbs -skms <kms-server>
slmgr.vbs -ato

各版本的 Windows GVLK Keys

Office

cd <your-office-dir>
cscript ospp.vbs /inpkey:<office-GVLK-key>
cscript ospp.vbs /sethst:<kms-server>
cscript ospp.vbs /act

各版本的 Office GVLK Keys

激活成功会看到这样的提示：

active success

过期时间可以使用 slmgr.vbs -xpr 查询

Nextcloud15 优化心得

Sun, 17 Feb 2019 12:07:16 +0800

最近抽空把 Nextcloud 从 14 升级到 15，这里记录一下升级流程和优化心得

Nextcloud15 功能更新

这里列出几个更新的功能，给观望的朋友们做个参考

全文搜索
工作流：文档自动转 PDF，自动执行 shell 命令
分享功能升级：现在一个文件可以创建多个分享链接、可以分享只读文件
协作功能加强
2-3x loading 速度提升

升级流程

因为 Nextcloud14 无法直接升级到 15，所以我采用全新安装的方式。安装完成后用备份恢复数据。详细流程可以参照文档中的 Migrating to a different server

将旧的 data 文件夹复制过去后需要用 sudo -uwww php occ files:scan –all 扫描更改

优化心得

美化 URL

这里分享一下我的 nginx 配置（去掉了 URL 中的 index.php 和 remote.php）：

server {
 listen 443 ssl;
 ssl_certificate <your certificate>;
 ssl_certificate_key <your certificate key>;
 ssl_session_timeout 5m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES;
 ssl_prefer_server_ciphers on;

 server_name <your server name>;
 root <your nextcloud path>;
 error_log /var/log/nextcloud15_error.log;
 access_log /var/log/nextcloud15_access.log;

 location = /robots.txt {
 allow all;
 log_not_found off;
 access_log off;
 }

 # Deny access to the data and config directories, .ht* files,
 # the README, and the database structure definition
 location ~ ^/(data|config|\.ht|db_structure\.xml|README) {
 deny all;
 }

 # Pretty URLs for WebDAV
 location ~* \/remote\/(?:.*)$ {
 rewrite ^ /remote.php$uri$is_args$args last;
 }

 # Pretty URLs
 location / {

 location ~* ^\/core\/(?=preview) {
 rewrite ^ /index.php$uri$is_args$args last;
 }

 location ~* ^\/core(/.*)?$ {
 break;
 }

 rewrite ^ /index.php last;
 }

 location ~ ^(.+?\.php)(/.*)?$ {
 try_files $1 = 404;
 include fastcgi_params;
 fastcgi_param SCRIPT_FILENAME $document_root$1;
 fastcgi_param PATH_INFO $2;
 fastcgi_param front_controller_active true;
 fastcgi_pass unix:/tmp/php-cgi.sock;
 }

 rewrite /.well-known/carddav /remote.php/dav permanent;
 rewrite /.well-known/caldav /remote.php/dav permanent;

 location ~ \.(?:css|js|woff|svg|gif|png|html|ttf|woff|woff2|ico|jpg|jpeg)$ {
 try_files $uri /index.php$request_uri;
 add_header Cache-Control "public, max-age=2592000";
 access_log off;
 }


}

开启 OPcache

一般的源比如 ppa:ondrej/php 都会默认安装 OPcache（可以用 php -m | grep Zend\ OPcache 来检查是否安装）但是一般默认都不会开启 OPcache，需要在 php.ini 中手动开启。官方推荐配置如下：

zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

开启内存缓存

官方文档推荐本地缓存用 APCu，分布式缓存和锁用 Redis，配置文件如下：

// <your-nextcloud-path>/config/config.php

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
 'host' => 'redis-host.example.com',
 'port' => 6379,
],

使用 APCu 和 Redis 都需要安装相应 PHP 拓展（Redis 还需要安装相应的服务端： apt install redis-server）我个人推荐自行编译安装：

下载对应源码：APCu、Redis
解压到你的服务器上
进入对应目录并编译安装：

phpize // 这个命令在 php 的安装路经下的 bin 目录里
./configure --with-php-config=<your-php-bin-dir>/php-config
make && make install

在 php.ini 中启用对应拓展：

extension = redis.so
extension = apcu.so
apc.enabled=1
apc.shm_size=32M
apc.enable_cli=1

后台任务设置为 cron

在管理员面板基本设置里将后台任务设置成 cron，然后登陆服务器配置 cron：

sudo -uwww crontab -e // -u 参数为运行 php 的用户

// 在打开的文件中添加：
*/15 * * * * php -f <your-next-cloud-path>/cron.php

Typecho 新版又拍云插件使用教程

Mon, 21 Jan 2019 00:30:00 +0800

说明

本插件 ShadowySpirits/UpyunFile 是又拍云文件上传插件，基于 codesee/UpyunFile 二次开发。

相比于原插件：

修复了启用本插件会影响其他替换内容插件生效的 Bug
修复了某些情况下图片链接替换失败的 Bug
新增：接入又拍云图片处理功能
新增：为博客静态资源加入 Token 防盗链

又拍云 SDK 仅支持 PHP >= 5.6 的环境

使用方法

在 Release 中下载此插件的最新版，上传至网站的 /usr/plugins/ 目录下。务必保持本插件文件夹名称为 UpyunFile，不能随意更改
启用该插件，正确填写相关信息，保存即可

screenshot

注意事项

启用又拍云图片处理需在又拍云控制台中创建缩略图版本并填入插件相应位置，文档：https://help.upyun.com/knowledge-base/image/#thumb；又拍云图片处理会忽略带有后缀 _nothumb 的图片（比如：example_nothumb.png）
如你创建的缩略图版本开启了转码功能，则需将输出格式填入插件相应位置
只有 JPG、JPEG、PNG、BMP 这 4 种格式的图片才会进行处理
启用 Token 防盗链需在又拍云控制台中启用 Token 防盗链并将密钥填入插件相应位置
自定义目录结构可以在 Typecho 根目录下的 config.inc.php 中添加代码 define('__TYPECHO_UPLOAD_DIR__', '/path/to/uploads'); 并设置目录结构为 Typecho结构。

Token 防盗链功能只能修改 HTML 代码中的 CDN 链接，如果需要引入字体图片等资源请内联 CSS

更新记录：

v0.9.0：

升级 SDK，修复 Bug，加入新功能

v1.0.0：

控制台的文件管理中现在可以正常查看有 Token 防盗链保护的图片
又拍云图片处理会忽略带有后缀 _nothumb 的图片（比如：example_nothumb.png）
优化代码

v1.0.2：

修复某些情况下重复添加 Token 的 bug

v1.0.3：

优化代码
增强兼容性

v1.0.4：

解决兼容性问题

如果你有使用上的问题请在提问时写清楚你的 php 和 typecho 版本以及报错信息，否则一律不予回复

网页字体优化

Thu, 03 Jan 2019 22:32:00 +0800

如果你想在网页中引入一些花式字体，比如这样：

blog_title

可以试试下面几个技巧来优化字体加载速度：

使用 CDN 加速字体资源加载

你可以把字体托管在各大 CDN 服务商的云储存中，或者使用各种公共 CDN 来分发你的字体。特别是后者，如果用户浏览过的其他网页也使用过这种字体，那么浏览器就可以从缓存中读取，而不用重新下载。

使用 WOFF2 优化字体体积

WOFF2 采用自定义预处理和压缩算法，提供的文件大小压缩率比其他格式高大约 30%。下面是一张 ttf vs woff vs woff2 的比较图：

font_type

可以看到 woff2 在体积的控制上还是非常有优势的，这里推荐一个 ttf 转 woff2 的工具，提供 CLI 和 API 两种转换方式。
[button color=“dark” icon=“fontello fontello-github” url=“https://github.com/nfroidure/ttf2woff2”]nfroidure/ttf2woff2[/button]

目前浏览器对 woff2 的兼容性已经相当不错了，可以看到浏览器的支持率达到了 84.03%。移动端 Android 5+/IOS 10+ 的 webview 支持 woff2，目前我测试的几款主流手机浏览器对 woff2 都完美支持。

woff2_support

提取部分字体

很多情况下（特别是中文字体体积在通常情况下超大），你并不需要使用完整的字体文件，比如我的签名：

sign

对于这样的静态页面，可以提取所需的字体来减小引入的字体文件体积，这里推荐两个工具：字蛛 & fontmin，并且 fontmin 提供了 Mac OS X、Windows 平台下的客户端：Github: ecomfe/fontmin-app

内联字体

在字体不大的情况下，使用 data 协议内联是个不错的选择，可以减少请求数，并且完全避免了 FOUT 和 FOIT。

@font-face {
 font-family: AomemoFont-Regular;
 src: url("data:font/woff2;base64,...") format("woff2");
 font-style: normal;
 font-weight: normal;
}

这种方式一定程度上拖慢了首屏加载时间，推荐配合提取部分字体使用。

个人网站 CDN 选用指北

Wed, 02 Jan 2019 14:05:00 +0800

全能王 Cloudflare

Cloudflare 是一家提供 DNS 和 CDN 等服务的公司，号称 Powering over 39% of managed DNS domains ，其提供的 CDN 服务在功能性（WAF、Page Rules、Argo、Load Balancing）上不知道甩掉国内同行几条街，而且基础功能和流量完全免费。但是基于国情在国内访问不是很理想，更建议体量大的静态资源使用国内 CDN 服务。

Cloudflare 的接入方式默认只支持 DNS 接入，CNAME 接入需要 py（大雾）。这里简单介绍下 Cloudflare 的几个功能。

全站 HTTPS

Cloudflare 免费提供泛域名证书，只要接入他家的 CDN 就可以体验到全站 HTTPS 的舒爽（手动狗头）。需要注意的是免费证书下载下来是自签名证书，只有在 Cloudflare 网络内受信，用它来开启个回源 HTTPS 还行，浏览器是不认的。控制台的 Crypto 标签下可以配置其他相关选项。

自动阻止恶意访问

自动检测出恶意 IP 后使用 challenge page 来进一步甄别和阻止恶意访问（下图是 javascript challenge page），可以在控制台的 Firewall 标签页下调整 Security Level 和 Challenge Passage 的等级，或者在 IP Access Rules 下根据 IP、ASN、国家等手动配置。

challenge page

Web Application Firewall

Cloudflare 提供的 WAF 可以说是相当强大的应用防火墙，免费用户拥有 5 条规则，可以根据 IP、Cookie、host、URI、威胁等级、是否是机器人等匹配规则指定阻止访问或者需要输入验证码等策略。

这里给出一个例子，禁止除我的 IP 以外的用户访问某个敏感页：

waf

Page Rules

对某些页面指定特定的 Cloudflare 设置（缓存等级、过期时间、开启 Always Online 等等），比如对某个子域名的所有 HTML 文件添加自动优化功能：

page rules

添加第三方 APP

在控制台的 Apps 标签下可以添加第三方 App，比如接入 Google Analytics、加入本站使用 Cookie 的提示等等。

其他功能

除了一般的 CDN 该有的功能以外还有自动跳转移动端页面、AMP 优化、 Rocket Loader、Always Online 等实用功能。以上介绍的都是免费功能，如果你愿意付费的话还能享受到 Argo、Load Balancing、Rate Limiting 等进阶功能。

国内 CDN 服务商

前面说过 Cloudflare 虽然功能非常强大，可惜天朝自有国情在，所以主站使用 Cloudflare CDN，静态资源托管在国内云储存这种动静分离的方式可以有更好的体验。

本站使用的是又拍云，我个人觉得又拍云性能和功能上比七牛要好一些，而且比阿里云要便宜 qwq。并且又拍云提供融合云储存，可以将增量文件同步到七牛或者阿里云，加入又拍云联盟可以获得 10GB 免费存储空间和 15GB 免费流量（HTTPS 也能用，这点要比七牛良心）

Windows 下编译 AV1 codec

Tue, 18 Dec 2018 10:52:00 +0800

什么是 AV1

AV1 全称 AOMedia Video 1 是 AOM (Alliance for Open Media) 在 2018 年推出的新一代视频编码标准，其设计目的是提供更好的质量、更小的体积，以用于在互联网上传输高质量的视频。目前 Chrome 69 和 Firefox 63 中都添加了对 AV1 的支持（需要手动开启），LAV 在 0.73 中开始支持对 AV1 的解码。

codec timeline

更详细的介绍可以参考以下两篇文章：

编译 AV1 codec

编译所需环境：

CMake version 3.5 or higher.
Git.
Perl.
For x86 targets, yasm, which is preferred, or a recent version of nasm.
Building the documentation requires doxygen.
Building the unit tests requires Python.
Emscripten builds require the portable EMSDK.

环境搭建：

cmake：cmake 3.7.1
make/gcc：MinGW-W64 （一定要选 64 位的 MinGW）
perl：strawberry-perl-5.28.1.1-64bit
yasm：yasm-1.3.0-win64

安装上述环境并添加环境变量后即可开始编译

编译流程：

clone 代码

git clone https://aomedia.googlesource.com/aom

在 aom 文件夹外新建一个文件夹 aom_build

cd aom_build
cmake ../aom
make

一切正常的话你会在 aom_build 中看到 aomenc.exe 和 aomdec.exe，这就是我们要的 codec

// aomenc --help 可以看到编码器版本
Included encoders:

 av1 - AOMedia Project AV1 Encoder 1.0.0-1047-gf4e775cf3 (default)

 Use --codec to switch to a non-default encoder.

iptables 白名单过滤

Wed, 05 Dec 2018 20:43:00 +0800

iptables 过滤参数介绍

-A (append)

向某个规则链尾部添加一条规则，如：


iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

-I (Insert) 在规则链的头部插入新的规则

一共有三条规则链：Forward、Input、Output

Forward：数据包的目的地址不是本机，也就是说，这个包将被转发
Input：数据包的目的地址是本机
Output：数据包是由本地系统进程产生的，并通过某个本地端口发送的

-m (module_name)

使用扩展模块来进行数据包的匹配，本文主要介绍 -m state


iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 2333 -j ACCEPT

在 iptables 上一共有四种状态：NEW、ESTABLISHED、INVALID、RELATED

NEW：NEW 说明这个包是我们看到的第一个包。意思就是，这是 conntrack 模块看到的某个连接的第一个包，它即将被匹配了。比如，我们看到一个 SYN 包，是我们所留意的连接的第一个包，就要匹配它。
ESTABLISHED： ESTABLISHED 已经注意到两个方向上的数据传输，而且会继续匹配这个连接的包。处于 ESTABLISHED 状态的连接是非常容易理解的。只要发送并接到应答，连接就是 ESTABLISHED 的了。一个连接要从 NEW 变为 ESTABLISHED，只需要接到应答包即可，不管这个包是发往防火墙的，还是要由防火墙转发的。ICMP 的错误和重定向等信息包也被看作是 ESTABLISHED，只要它们是我们所发出的信息的应答。
RELATED： RELATED 是个比较麻烦的状态。当一个连接和某个已处于 ESTABLISHED 状态的连接有关系时，就被认为是 RELATED 的了。换句话说，一个连接要想是 RELATED 的，首先要有一个 ESTABLISHED 的连接。这个 ESTABLISHED 连接再产生一个主连接之外的连接，这个新的连接就是 RELATED 的了，当然前提是 conntrack 模块要能理解 RELATED。ftp 是个很好的例子，FTP-data 连接就是和 FTP-control 有关联的，如果没有在 iptables 的策略中配置 RELATED 状态，FTP-data 的连接是无法正确建立的，还有其他的例子，比如，通过 IRC 的 DCC 连接。有了这个状态，ICMP 应答、FTP 传输、DCC 等才能穿过防火墙正常工作。注意，大部分还有一些 UDP 协议都依赖这个机制。这些协议是很复杂的，它们把连接信息放在数据包里，并且要求这些信息能被正确理解。
INVALID：INVALID 说明数据包不能被识别属于哪个连接或没有任何状态。有几个原因可以产生这种情况，比如，内存溢出，收到不知属于哪个连接的 ICMP 错误信息。一般地，我们 DROP 这个状态的任何东西，因为防火墙认为这是不安全的东西。

更详细的解释见此文

白名单过滤配置方法

创建白名单


iptables -N whitelist

iptables -A whitelist -s 127.0.0.1 -j ACCEPT

指定规则


iptables -A INPUT -p tcp -m tcp --dport 3306 -j whitelist

在所以规则最后加上


iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited

这条规则表示拒绝未匹配到其他规则的包

其中 –reject-with 可以有如下几种值

icmp-net-unreachable

icmp-host-unreachable

icmp-port-unreachable

icmp-proto-unreachable

icmp-net-prohibited

icmp-host-prohibited or icmp-admin-prohibited

注：

忽略网络问题的情况下 DROP 和 REJECT 分别对应 ERR_CONNECTION_TIMEOUT 和 ERR_CONNECTION_REFUSED ，iptables 帮助文档中的解释：This (mean REJECT) is used to send back an error packet in response to the matched packet: otherwise, it is equivalent to DROP
编辑规则的原则：放行的要先放在前面, 禁止的要放在最后

原生安卓 WiFi 4G 信号去叹号去叉教程

Tue, 30 Oct 2018 16:13:00 +0800

适用于 7.1.2+ :

此版本服务器地址判断逻辑相比 7.1.1 没有更改，但是检测的开关却变了。

检测开关：


删除变量：（删除以后默认启用）

adb shell settings delete global captive_portal_mode

关闭检测：

adb shell settings put global captive_portal_mode 0

查看当前状态：

adb shell settings get global captive_portal_mode

服务器地址相关（同 7.1.1）：


删除（删除默认用HTTPS）

adb shell settings delete global captive_portal_https_url

adb shell settings delete global captive_portal_http_url

分别修改两个地址

adb shell settings put global captive_portal_http_url http://captive.v2ex.co/generate_204

adb shell settings put global captive_portal_https_url https://captive.v2ex.co/generate_204

转载自原生安卓 WiFi 信号去叹号去叉教程 5.0-Android P，侵删

Laravel 中视图 view() 与重定向 redirect() 的使用

Tue, 04 Sep 2018 12:46:00 +0800

一、 view() 的使用

简单的返回视图

// 所传的参数是blade模板的路径
// 如果目录是 resources/views/static_pages/home.blade.php 则可以使用
return view('static_pages/home');
或
return view('static_pages.home');

向视图传递数据

$title = 'Hello Laravel';
$user = User::find(1);

// view() 的第二个参数接受一个数组
return view('static_pages/home', compact('user'));

return view('articles.lists')->with('title',$title);

// 所传递的变量在blade模板中用 {{ $title }} 或 {!! $title !!} 输出
// 前者作为文本输出，后者作为页面元素渲染

二、redirect() 的使用

基于 Url 的重定向

// 假设我们当前的域名为：http://localhost 则重定向到 http://localhost/home
return redirect('home');

基于路由的重定向
```
return redirect()->route('home');
```

基于控制器的重定向

return redirect()->action('UserController@index')

传递数据

return redirect('home')->with('title', 'Hello Laravel');

// 将表单值保存到 Session 中，可以用 {{ old('param') }} 来获取
return redirect('home')->withInput();

// 接收一个字符串或数组，传递的变量名为 $errors
return redirect('home')->withErrors('Error');

其他用法

// 返回登录前的页面，参数为默认跳转的页面
redirect()->intended(route('home'));

// 返回上一个页面，注意避免死循环
redirect()->back();

三、使用 view() 或 redirect() 的选择

view() 和 redirect() 的异同

使用 return view() 不会改变当前访问的 url ， return redirect() 会改变改变当前访问的 url

使用 return view() 不会使当前 Session 的 Flash 失效，但是 return redirect() 会使 Flash 失效

在 RESTful 架构中，访问 Get 方法时推荐使用 return view() ，访问其他方法推荐使用 return redirect()

MySQL 开启远程访问完全解决方案

Tue, 04 Sep 2018 11:02:00 +0800

适用环境

MySQL 5.7
Ubuntu 16.04

( 适用但不限于以上环境）

操作步骤

一、开启 MySQL 远程访问权限

将 mysql.host 字段的值改为 % 就表示能在任何客户端机器上登录到 MySQL 服务器

mysql> use mysql;
Database changed

mysql> grant all privileges on *.* to username @'%' identified by "password";
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

//或者新建一个用户并授权，只要设置 host 为 % 即可
CREATE USER 'username'@'host' IDENTIFIED BY 'password';
GRANT ALL privileges ON databasename.tablename TO 'username'@'host';
flush privileges;//如果授权未生效手动重启 mysql 服务即可

修改密码的方法：

mysql> SET PASSWORD FOR 'username'@'host' = PASSWORD('newpass');

二、检查 MySQL 配置

查看 MySQL 服务绑定的地址：

ubuntu:~$ netstat -ano | grep 3306
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN off (0.00/0/0)

如果不是如上所示（绑定在 0.0.0.0:3306），那么就需要更改 /etc/my.cnf 中的配置，修改下面一行

bind-address = 0.0.0.0

三、检查防火墙配置

在 控制面板\系统和安全\Windows Defender 防火墙 中关掉 Windows 防火墙

检查服务器上的防火墙

ubuntu:~$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:2111
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:5500:5600
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

如果 MySQL 监听的端口（默认 3306）被设置成 DROP 则需要改成 ACCEPT

ubuntu:~$ sudo vim /etc/iptables.rules
ubuntu:~$ sudo iptables-restore < /etc/iptables.rules

检查服务商提供的安全组设置，开放对应的端口

安全组

Android 7.0 之后抓包 unknown 和证书无效的解决方案

Fri, 30 Mar 2018 14:04:00 +0800

背景

使用抓包软件（以 Charles 为例）抓取 APP 的 https 请求时，Android 和 Charles 都正确安装了证书却出现抓包失败，报错：

Client SSL handshake failed: An unknown issue occurred processing the certificate (certificate_unknown)

抓包失败

原因

Android7.0 之后默认不信任用户添加到系统的 CA 证书：

To provide a more consistent and more secure experience across the Android ecosystem, beginning with Android Nougat, compatible devices trust only the standardized system CAs maintained in AOSP.（文档链接）

也就是说对基于 SDK24 及以上的 APP 来说，即使你在手机上安装了抓包工具的证书也无法抓取 https 请求

解决方案

一、官方解决方案（需修改代码）

官方文档：https://developer.android.google.cn/training/articles/security-config.html
详细演示：https://blog.csdn.net/mrxiagc/article/details/75329629

二、将抓包软件的证书安装成系统证书（需 ROOT）

系统证书目录：/system/etc/security/cacerts/

其中的每个证书的命名规则如下：
<Certificate_Hash>.<Number>
文件名是一个 Hash 值，而后缀是一个数字。

文件名可以用下面的命令计算出来：

openssl x509 -subject_hash_old -in <Certificate_File>

后缀名的数字是为了防止文件名冲突的，比如如果两个证书算出的 Hash 值是一样的话，那么一个证书的后缀名数字可以设置成 0，而另一个证书的后缀名数字可以设置成 1

操作步骤：

将抓包软件的证书用上述命令计算出 Hash 值，将其改名并复制到系统证书目录

计算 Hash 值

此时你应该可以在设置->安全->加密与凭据->信任的凭据的系统标签页看到你新加入的证书，将其启用即可顺利抓包

安装好的CA证书