Zhihang's Blog

个人快捷键记忆表

akynazh@gmail.com (zhihang) — Fri, 05 Sep 2025 01:07:44 +0800

Preface

MacOS & Windows Shortcuts.

MacOS Shortcuts

CMD » CMD + SHIFT

Key	Func	Scope	Config
`	Move Focus To Next Window	ALL
-	Zoom Out	ALL
+	Zoom In	ALL
Tab	Switch Apps	ALL
Q	Quit App	ALL
W	Close	ALL
E	Translate » Translate(OCR)	ALL	Pot
R	Replace, Refresh	ALL
T	New Tab	Browser
Y	Everything	IDE	IDE
U	Usage	IDE	IDE
I	Insert Code	IDE	IDE
O	Optimize	IDE	IDE
P	Snipaste » System Screenshot	ALL	Snipaste, Settings
[	Fold » Fold All	IDE	IDE
]	Unfold » Unfold All	IDE	IDE
\	Terminal	IDE	IDE
A	All	ALL
S	Save	ALL
D	Duplicate Tab, Split Right	Browser, IDE	Settings, IDE
F	Find	ALL
G	Globally Find	IDE	IDE
H	Hide	ALL
J	Execute	IDE	IDE
K	Debug	IDE	IDE
L	Line	IDE	IDE
;
'
Z	Undo » Redo	ALL
X	Cut	ALL
C	Copy	ALL
V	Paste » Paste As Plain Text	ALL
B	Refactor	IDE	IDE
N	New Window	ALL
M	Minimize	ALL
,
.
/	Comment	IDE
Space	Search	ALL
RK	Forward	ALL	IDE
LK	Backward	ALL	IDE
UK	Debug: Step Over	IDE	IDE
DK	Debug: Step Into	IDE	IDE

ALT

Key	Func	Scope	Config
RK	Window Right Half	ALL	Rectangle
LK	Window Left Half	ALL	Rectangle
UK	Window Maximize	ALL	Rectangle
DK	Window Almost	Maximize ALL	Rectangle
V	Pasteboard	ALL	Clipy

Windows Shortcuts

CTRL » CTRL + SHIFT

Key	Func	Scope	Config
`	Move Focus To Next Window	ALL	AutoHotkey
-	Zoom Out	ALL
+	Zoom In	ALL
Tab	Switch Apps	ALL	PowerToys
Q	Quit App	ALL	PowerToys
W	Close	ALL
E	Translate » Translate(OCR)	ALL	Pot
R	Replace, Refresh	ALL
T	New Tab	Browser
Y	Everything	IDE	IDE
U	Usage	IDE	IDE
I	Insert Code	IDE	IDE
O	Optimize	IDE	IDE
P	Snipaste » System Screenshot	ALL	Snipaste, Game Bar
[	Fold » Fold All	IDE	IDE
]	Unfold » Unfold All	IDE	IDE
\	Terminal	IDE	IDE
A	All	ALL
S	Save	ALL
D	Duplicate Tab, Split Right	Browser, IDE	AutoHotkey, IDE
F	Find	ALL
G	Globally Find	IDE	IDE
H	Hide	ALL	PowerToys
J	Execute	IDE	IDE
K	Debug	IDE	IDE
L	Line	IDE	IDE
;
'
Z	Undo » Redo	ALL
X	Cut	ALL
C	Copy	ALL
V	Paste » Paste As Plain Text	ALL
B	Refactor	IDE	IDE
N	New Window	ALL
M	Minimize	ALL	PowerToys
,
.
/	Comment	IDE
Space	Search	ALL	PowerToys
RK	Forward	ALL	IDE
LK	Backward	ALL	IDE
UK	Debug: Step Over	IDE	IDE
DK	Debug: Step Into	IDE	IDE

WIN

Key	Func
RK	Window Right Half
LK	Window Left Half
UK	Window Maximize
DK	Window Almost Maximize
V	Pasteboard
L	Lock Screen
R	Execute
X	Quick Links
G	Game Bar

FN

Key	Func
F2	Rename
F5	Refresh
F11	Full Screen

AutoHotkey

Install AutoHotkey;
Edit script;
Put script to startup folder(CMD+R >> shell:startup).

app_windows_switch

 1#Requires AutoHotkey v2.0
 2
 3^`::
 4{
 5    win_id := WinActive("A")
 6    win_class := WinGetClass("A")
 7    active_process_name := WinGetProcessName("A")
 8    ; We have to be extra careful about explorer.exe since that process is responsible for more than file explorer
 9    if (active_process_name = "explorer.exe")
10        win_list := WinGetList("ahk_exe" active_process_name " ahk_class" win_class)
11    else
12        win_list := WinGetList("ahk_exe" active_process_name)
13    
14    ; Calculate index of next window. Since activating a window puts it at the top of the list, we have to take from the bottom.
15    next_window_i := win_list.Length
16    next_window_id := win_list[next_window_i]
17    
18    ; Activate the next window and send it to the top.
19    WinMoveTop("ahk_id" next_window_id)
20    WinActivate("ahk_id" next_window_id)
21}

chrome_duplicate_tab

1#IfWinActive ahk_exe chrome.exe
2^d:: ; Ctrl + D 
3Send, ^l ; url
4Send, ^c ; copy
5Send, ^t ; new tab
6Send, ^v ; paste url
7Send, {Enter} ; open
8return
9#IfWinActive

服务器被入侵后的急救记录

akynazh@gmail.com (zhihang) — Sat, 10 May 2025 17:11:29 +0800

前言

记录一次服务器被入侵后的急救记录。第一次遇上服务器被入侵的事，觉得惊吓、紧张又有趣，一开始手足无措，依靠 AI 和社区相关博客，顺利处理完成，也得到了很重要的经验教训。

发现问题

最近发现服务器的部分服务明显卡顿，使用 top 命令观察进程：

1top -c 
2PID  USER PR  NI  VIRT RES    SHR S  %CPU  %MEM     TIME+ COMMAND
34135357 root 30 10 723224 146032 0   S   99.9 30.9  462:10.61 /root/.local/start/xmrig

这个名为 xmrig 的进程 CPU 占用经常达到 99%，查询得知 xmrig 是一个加密货币挖矿程序，通常用于挖掘 Monero (XMR)。可见服务器已经被入侵，被用来进行非法挖矿，这类攻击称为“加密劫持”（Cryptojacking）。这个入侵者以 root 身份执行了程序，因此要么是 root 密码在某些地方泄露了，要么是自己通过 root 跑的服务代码有病毒，当然也有可能单纯是密码被穷举出来了。

回忆后发现很久之前使用了通过 AppStore 下载的某些手机服务器管理软件管理这个服务器，在软件上输入了服务器账密，很大可能被某个软件的开发者泄漏了。

以后要非常小心不要在任何无法保证数据安全的地方输入密码，也尽量不要使用 root 账户登录 Linux 服务器。另外即使是 AppStore 下载的软件，可能也是不安全的，最好还是使用经过社区验证过的开源软件。

如果是密码泄露，那值得庆幸的是，入侵者并没有直接修改掉原始密码，或者很明显地破坏我的服务器。但是从另一个角度看，这确实让我在短时间内无法发现自己的服务器被入侵了，挖坑病毒在服务器上跑了快一个月了！之后最好得加一个服务器监控告警程序在服务器上面。

如果不是密码泄露的问题，那就是某些代码有病毒，这个比较难发现，只能在清理完病毒后持续观察了。

继续通过 top 命令观察进程，发现还有另外一个怪异的进程，CPU 占用也经常达到 99%：

1PID USER PR  NI  VIRT RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2518 root 20 0 10808 208 204 S 99.9 0.0 2:42.28 arpd

在正常情况下，arpd 是 Linux 上的一个合法工具，作用是缓存 ARP 表项以减少 ARP 请求，也可用于 ARP 代理，属于 iputils 套件。

个人怀疑 arqd 是否会消耗这么多资源，AI 也认为合法的 arpd 几乎不应该消耗这么多资源，可能是伪装成合法程序的恶意进程（命名为 arpd 来掩盖身份）。

重置密码

发现密码泄漏，必须马上重置密码，防止被远程自动程序继续入侵。

首先修改 root 密码：

1passwd

检查公钥列表：

1cat /root/.ssh/authorized_keys

发现确实有陌生的密钥，立马删除。

查看是否有其他陌生用户：

1cut -d: -f1 /etc/passwd

并没有发现。如果有，删除掉。

检查哪些用户有登录权限：

1grep -vE '(/false|/nologin)' /etc/passwd

没有发现陌生用户。如果有，删除掉。

如果服务器上某些文件包含了密码明文，需要及时重置，这里省略。

清除病毒

首先删除掉 xmrig 二进制执行文件，然后再 kill 掉 xmrig 进程：

1rm /root/.local/start/xmrig
2kill -9 4135357

直接 kill 会无效，因为有自启动的病毒程序在运行，所以一定要先删除 xmrig 执行文件。

接着检查 arpd 执行文件：

1dpkg -S /usr/sbin/arpd
2
3# iproute2: /usr/sbin/arpd

说明 arpd 文件确实来自于系统的官方软件包 iproute2，这在形式上是合法的。

即使它来自官方包，arpd 正常情况下几乎不会运行、也不会占用接近 100% 的 CPU。这行为极不正常，仍可能有二进制被替换或篡改的风险，攻击者可能保留了原有包元数据，但替换了实际文件内容，仅靠 dpkg -S 输出无法确认安全性。

还是直接重新安装 arpd：

1apt-get install --reinstall iproute2

这样会用官方版本覆盖掉现在的 arpd。

接着 top 持续观察，发现已经基本正常，舒服了。

检查后门

现在还不能松懈，继续检查病毒是否留有后门，比如某些自动程序可能会自动下载 xmrig 并执行。

检查相关启动文件是否有问题：

1# .*shrc
2# .*profile
3# /etc/rc.local
4
5find /root /home -type f \( -name ".bashrc" -o -name ".profile" -o -name ".zprofile" -o -name ".zshrc" \) -exec grep -i xmrig {} \;
6cat /etc/rc.local | grep xmrig

检查是否有可疑的服务：

1systemctl list-units --type=service | grep xmrig
2# grep -r xmrig /etc/systemd/system

发现有一个陌生服务 “thenorth.service”:

1ExecStart=/root/.local/start/xmrig -c /root/.local/start/config.json

可见 thenorth.service 就是攻击者伪装的 systemd 服务，执行的是 xmrig 挖矿程序。虽然 xmrig 执行文件已经删除了，但是这里还是将其删除：

1systemctl disable thenorth.service
2rm /etc/systemd/system/thenorth.service
3systemctl daemon-reload
4# 如果删除文件后，服务仍然显示存在，可以尝试清除所有 systemd 的缓存，并强制更新其配置：
5# systemctl reset-failed

检查定时任务：

1crontab -l | grep xmrig

上述步骤可能考虑不到所有地方，因此也许无法根除病毒，所以需要持续观察。

经验教训

不要在任何无法保证数据安全的地方输入密码；
尽量不要使用 root 账户登录服务器；
禁用密码登录服务器，只认公钥：PasswordAuthentication no，防止密码被穷举；
尽量使用经过社区验证的开源软件；
设置服务器监控程序，及时告警；
要非常清楚自己服务器上跑的任何一个服务，最好列个清单；
最好不要在服务器上面放置过于重要或私密的东西。

分布式系统理论知识整理

akynazh@gmail.com (zhihang) — Wed, 12 Feb 2025 23:44:09 +0800

CAP 定理

CAP 定理指出对于一个分布式计算系统来说，不可能同时满足以下三点：

一致性（Consistency）：同一时间所有节点返回的数据都是一致的
可用性（Availability）：每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
分区容错性（Partition Tolerance）：发生网络分区时（即节点之间无法通信），大部分分布式系统都不能在时限内达成数据一致性。所以在分布式系统中 P 是一定该发生的，那么 A 和 C 我们只能选择一个

一致性协议

分布式一致性具体可以分为：

强一致性：是分布式系统中的一个一致性保证，它确保了系统中的所有副本始终保持一致，无论客户端请求在哪个节点处理，系统中的所有节点都能看到相同的数据。
最终一致性：与强一致性不同，最终一致性允许系统在某些时刻存在短暂的不一致，直到系统最终达到一致性。它通常用于高可用性要求较高的系统（如某些 NoSQL 数据库）。

CAP 定理定义了分布式系统中的一致性、可用性和分区容忍性之间的权衡。在实际系统设计中，需要根据需求做出选择。2PC、3PC 和 Paxos 等协议提供了实现这些需求的具体方法。

2PC 适用于强一致性的场景，但在网络分区时可能会面临不可用的问题。
3PC 是对 2PC 的改进，力图在保证一致性的同时减少因网络分区导致的系统不可用。
Raft 是一种分布式一致性算法，旨在通过简化 Paxos 算法的理解和实现，提供一种易于理解和实现的一致性协议。
Paxos 提供了一种强一致性的分布式协议，适用于高容错性和一致性要求的系统，但在分区发生时可能会牺牲可用性。
Quorum-Based Replication 是一种用于在分布式系统中确保数据一致性和高可用性的策略。通过设置写和读操作所需的 Quorum（法定人数），系统能够容忍部分节点的失败或延迟，确保数据在最终一致的状态下达到各个副本节点。它适用于高可用性要求较高的场景，如 NoSQL 数据库、分布式存储系统和缓存系统。

2PC

2PC（Two-Phase Commit）是分布式事务中的一致性协议，保证分布式系统中事务的原子性（即事务要么全部成功，要么全部失败）。2PC 由两个阶段组成：

第一阶段（准备阶段）：协调者向所有参与者发送“准备提交”请求，参与者要么同意提交事务，要么拒绝。
第二阶段（提交阶段）：如果所有参与者都同意提交，协调者发送“提交”命令；如果有任何一个参与者拒绝，协调者发送“回滚”命令。

2PC 与 CAP 的关系：

在 2PC 中，协调者需要等待所有参与者的回应才能决定事务是否提交。如果出现网络分区或某个节点宕机，可能无法确定事务状态，导致系统不可用。因此，2PC 在分区发生时可能会牺牲可用性来保证一致性。

3PC

3PC（Three-Phase Commit）是 2PC 的改进版本，旨在解决 2PC 在面对网络分区和节点崩溃时的阻塞问题。3PC 在 2PC 的基础上增加了一个预提交阶段，以避免事务阻塞。

第一阶段（准备阶段）：协调者向参与者发送“准备提交”请求。
第二阶段（预提交阶段）：协调者向所有参与者发送“预提交”命令，参与者确认并准备提交。
第三阶段（提交阶段）：协调者向所有参与者发送“提交”命令。

为何需要预提交？在 2PC (Two-Phase Commit) 中，如果在第一阶段（准备阶段）和第二阶段（提交阶段）之间发生故障（如网络分区或某个参与者宕机），就会导致协议阻塞，无法完成事务。这是因为没有机制来确保在没有足够信息的情况下做出最终决策。3PC 通过引入一个“预提交阶段”来避免这一问题：

如果协调者在第一阶段和第二阶段之间崩溃，参与者已经在“预提交”阶段保存了事务的状态（但未完全提交），因此系统可以在恢复后继续执行，而不需要等待所有节点的反馈来决定事务的最终状态。
预提交确保了在第二阶段开始时，参与者已经做好提交准备，减少了事务最终不一致的风险。

Raft

Raft 概述

Raft 是一种分布式一致性算法，旨在通过简化 Paxos 算法的理解和实现，提供一种易于理解和实现的一致性协议。Raft 主要用于 分布式日志复制，它保证了在一个分布式系统中，所有的节点都能达成一致，尤其在一个节点故障或系统出现网络分区的情况下，仍能确保数据的一致性和系统的高可用性。

Raft 算法通过将一致性问题分为三个子问题来简化理解：

领导选举（Leader Election）
日志复制（Log Replication）
安全性（Safety）

Raft 节点角色

Raft 协议中的节点有三种角色：

Leader：负责处理所有客户端请求，并将它们记录到日志中。所有日志条目都会通过 Leader 进行复制。
Follower：被动节点，接收来自 Leader 的日志条目，并执行日志条目中的操作。大部分节点在 Raft 集群启动时都是 Follower。
Candidate：当 Follower 在一段时间内没有接收到 Leader 的心跳（即 Leader 没有按时发送心跳信号），它将变成 Candidate，发起选举来选举新的 Leader。

每个节点维护一份日志，记录了系统的状态变更。Raft 通过复制日志来确保系统的一致性。日志中的每个条目都包括一个索引和一个日志条目内容。

Raft 选举过程

在 Raft 中，当集群启动时，所有节点最初是 Follower。如果在 选举超时（即 Follower 一段时间内没有接收到 Leader 的心跳，这个时间各 Follower 随机），它会变成 Candidate，并发起选举。

Candidate 会向其他节点请求投票。如果大多数节点投票给它，它就会成为新的 Leader。
一旦 Leader 被选举出来，它开始向 Follower 节点复制日志条目。

Raft 与 Paxos 的区别

简洁性：Raft 的设计目标之一就是简化实现和理解，相比于 Paxos，Raft 的概念更直观，易于理解和实现。
Leader 优先：Raft 通过 Leader 来集中处理所有请求，这样在性能和效率上相对更优，而 Paxos 通过多轮投票机制来达成一致，可能更加复杂。
日志复制：Raft 强调日志复制，所有操作都通过 Leader 日志进行传递，确保数据一致性；Paxos 不直接处理日志复制问题，它关注的是如何在分布式系统中进行一致性的决策。

Paxos

Paxos 是一种用于保证分布式系统中一致性的算法。它通过提议和投票机制确保系统中的多个副本最终达成一致。Paxos 可以在网络分区和节点崩溃的情况下达成一致决策，适用于高可用性和一致性要求的系统。

Paxos 的选举过程并不像传统的领导选举那样明确，而是通过多个阶段（Prepare、Promise、Propose 和 Accept）达成一致。Paxos 保证，尽管会有多个提案同时存在，但最终会有一个值被选中，且达成一致的提案是唯一的。

提案者提出提案并请求投票。
接受者通过承诺和投票来决定是否接受提案。
学习者最终会了解到哪一个提案被选为一致的决策。

Paxos 是一种容错机制，能够在分布式系统中保证数据一致性，即使在部分节点失败或网络分区的情况下，最终也能达成一致的选举结果。

Quorum-Based Replication

Quorum-Based Replication 是一种用于分布式系统中实现数据一致性的策略，尤其是在高可用性和容错性要求较高的系统中，如 NoSQL 数据库（如 Cassandra 和 Riak）和分布式存储系统。它通过设置读和写的 Quorum（法定人数）来保证数据在多个副本间的最终一致性。

在分布式系统中，数据通常会被复制到多个节点上。Quorum-based replication 通过定义读（read）和写（write）操作所需的最小确认节点数来确保一致性。在每个操作中，系统会在特定数量的节点上执行并确认操作，只有当足够的节点同意时，操作才会被认为是成功的。

主要概念：

Quorum：一个操作需要的最小节点数。通常，写操作和读操作会使用不同的 Quorum 大小来确保一致性。
写 Quorum (W)：执行写操作时，需要在至少 W 个节点上完成写操作才能算作成功。
读 Quorum (R)：执行读操作时，需要从至少 R 个节点获取数据才能返回结果。
副本数 (N)：数据在系统中被复制的副本数，通常是指每个数据的副本存储在多少个节点上。

工作原理：

写操作：当进行写操作时，数据会被写入到至少 W 个节点。如果系统的副本数为 N，那么 W 必须大于 N/2，即写操作必须在超过半数的节点上成功写入才能认为是成功。
读操作：当进行读操作时，系统会从至少 R 个节点中读取数据。如果在这些节点中存在不同版本的数据，系统会通过版本号、时间戳或其他方式来解决冲突并保证数据一致。
一致性保证：为了保证一致性，通常有一个要求：W + R > N。这个条件保证了在读写操作之间，至少有一个节点是重叠的（即包含了最新的数据）。例如，如果在写操作时写入了 W 个节点，那么当执行读操作时，至少会从 R 个节点中读取到数据，这样可以避免读取到过时的数据。

分布式锁

分布式锁是一种用于保证在分布式系统中，同一时间只有一个服务或线程可以访问共享资源的机制，防止不同节点上的并发操作产生数据不一致或其他冲突。由于分布式系统中，多个服务实例通常会并发访问同一资源，因此需要一种机制来确保在某些时刻，只有一个实例能对资源进行操作。

基于数据库实现分布式锁

悲观锁：select ... for update
乐观锁：版本号递增（CAS）

基于 Redis 实现分布式锁

初始化锁的时候，使用 setnx k v，并使用 expire 命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的 value 值为一个随机生成的 UUID，通过此在释放锁的时候进行判断;
获取锁的时候设置一个获取的超时时间，若超过这个时间则放弃获取锁;
释放锁的时候，通过 UUID 判断是不是该锁，若是该锁，则执行 delete 进行锁释放。

基于 Zookeeper 实现分布式锁

创建一个目录 mylock；
线程 A 想获取锁就在 mylock 目录下创建临时顺序节点；
获取 mylock 目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
线程 B 获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
线程 A 处理完，删除自己的节点，线程 B 监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

分布式 ID

分布式 ID 是指在分布式系统中，生成的标识符（ID）具有全局唯一性，能够在多个节点或服务之间保证不重复，并且通常是高效、顺序的。分布式 ID 的生成通常需要满足以下几个要求：

全局唯一性：每个 ID 必须在整个分布式系统中唯一，不会发生重复。
高效性：生成 ID 的速度必须足够快，不会成为系统的瓶颈。
顺序性（可选）：有些场景可能需要 ID 按时间递增（有序），以便在数据库中按顺序存储。
分布式系统兼容性：在多个节点、服务实例之间，ID 的生成方式应具有良好的兼容性，避免产生冲突。

实现方案：

雪花算法
UUID
数据库自增 ID + 分布式锁

雪花算法（Snowflake Algorithm）是由 Twitter 提出的分布式唯一 ID 生成算法，旨在解决在分布式系统中生成 全局唯一且递增 的 ID 问题。它通过结合时间戳、机器标识、序列号等信息，生成一个 64 位的 ID，确保高并发环境下的唯一性和顺序性。

雪花算法生成的 ID 是一个 64 位的整数，通常分成以下几个部分：

符号位（1 bit）：始终为 0，保证生成的 ID 是正数。
时间戳（41 bits）：41 位时间戳，表示自某个纪元以来的毫秒数，支持约 69 年的时间范围。
机器 ID（10 bits）：10 位机器标识，支持最多 1024 台机器。可以根据需要分为数据中心 ID 和机器 ID。
序列号（12 bits）：在同一毫秒内，支持生成最多 4096 个唯一 ID，保证 ID 的唯一性和高并发。

雪花算法的时钟回拨问题：由于雪花算法依赖时间戳生成 ID，如果机器的系统时钟发生回拨（如 NTP 同步或系统时间调整），可能会导致 ID 冲突或顺序错误。优化：

通过记录上次生成的时间戳，在时钟回拨时暂停 ID 生成，直到时钟恢复到正确的时间。
增加时间戳回拨检测机制，例如通过记录时间戳的最大值，避免出现回拨导致的冲突。

分布式事务

基本思想

分布式系统会把一个应用系统拆分为可独立部署的多个服务，各个服务的事务会操作各自的数据库，因此需要服务与服务之间远程协作才能完成事务操作。这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务。

例如用户下一个订单，需要首先创建订单，然后删减库存，接着扣除用户的金钱，最后完成订单。这个过程中，每个操作都可以作为一个微服务，每个微服务操作对应的数据库，而各个数据库可能分布在不同机器上，那么分布式事务就产生了，我们要确保一个事务被正确地处理，必须解决好分布式事务的数据提交与回滚。

Seata

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。在 Seata 中，分布式事务的执行过程通常涉及三个主要角色：

TC (Transaction Coordinator)：事务协调者，维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager)：事务管理器，定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager)：资源管理器，管理分支事务处理的资源，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata 使用 2PC 协议来保证分布式事务的 原子性 和 一致性，确保在多个服务间的操作要么全部成功（提交），要么全部失败（回滚）。

在 Seata 中，分布式事务的执行流程：

TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态）；
TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
TC 汇总事务信息，决定分布式事务是提交还是回滚；
TC 通知所有 RM 提交/回滚资源，事务二阶段结束；

为什么不使用 Raft？在分布式事务中，Seata 更注重事务的一致性和原子性，并且其主要目标是让事务能够在分布式环境中进行有效的协调和管理。Raft 更多地关注在分布式系统中如何处理节点故障、保证一致性和日志同步，而 Seata 更侧重于事务的隔离性和原子性。Seata 的事务协调更适合使用类似 2PC 或 TCC 这种高效的协议，而 Raft 的复杂性和实现方式对于事务管理来说可能不够合适。

走进音乐的世界

akynazh@gmail.com (zhihang) — Fri, 06 Dec 2024 17:22:27 +0800

前言

这里记录一切和音乐相关的知识和信息，欢迎走进音乐的世界。

这篇博客将会持续更新下去。另外部分内容由于篇幅较长或其它原因，独立成一篇新的文章：

内容导览：

声音

我们常用音调，响度，音长和音色等来形容声音。

音调（音高，Pitch） 的高低决定于发声体振动的频率，声源1秒钟内振动的次数叫频率，它反映振动的快慢，频率高，物体振动快。频率高，音调高。

空气柱越短，音调越高，反之越低
琴弦越紧，音调越高，反之越低
琴弦越细，音调越高，反之越低

在吉他中，六弦最粗，所以音调最低，而一弦最细，所以音调最高。通过调弦，即转动吉他上方六个旋钮，可以调节琴弦的松紧程度。

响度（音强，loudness） 反映声音的大小，响度的大小与振幅有关，还与离声源距离有关，越远声音越弱。弹琴所用的力度越大，响度就越大。

音长（时值，Note value），是指声音的长短，它决定于发音体振动时间的久暂。

音色（音品，Timbre），是发声体的不同而造成的，我们可以根据音色不同，从而区别不同的声音。

吉他跟钢琴都能发出同一个音高，但它们的听感是不一样的。吉他有吉他的音色，各种乐器都有自己的音色，每个人嗓音也是一个独一无二的音色。

乐器演奏出的音符并非只有一个音高频率，而是有一组频率。基频是这组音音高最低的频率，通常把基频定义为 音符的音高。而其他的高频则遵循一个规律，它们的频率都是基频的 正整数倍，这些高频叫做泛音。基频和其他高频之间的关系决定着乐器的音色。

对于振动有规律，具有明显基频和泛音，能分辨出音高的声音叫做 乐音（Musical tone）。而对于振动没有规律无法清晰分辨基频泛音的声音则叫做 噪音（Noise）。

音符

音乐中的单词就叫做 音符（Note），而旋律就是由音符的组织出来的。

音符时值 也称为音符值或音值，在乐谱中用来表达各音符之间的相对持续时间。与音符时值持续相等时间的无声状态，则是由各种不同的 休止符 来表达。附点音符 时长则是前面音符的一半。

四分音符为一拍，全音符则为四拍，对应有休止符，表示停顿。这里要注意音符的时长是相对的。

常用音符时值如下：

常用休止符如下：

对于一首曲子，首先可以定义它每分钟有多少拍，然后才能得到一拍的时长，不同曲子一拍的时长有差异，也因此给人的感觉不一样。

音乐

音乐的三要素是 节奏（Rhythm）、和声（Harmony）、旋律（Melody）。三要素之间的结合方式叫做 织体（Texture）。

这是几种常见的音乐织体：

单调音乐：由一根旋律线单独进行的音乐织体。
复调音乐：由多个独立的旋律线并行构成的织体。
支音音乐：所有乐器声部都在演奏和模仿同一个旋律构成的织体。
主调音乐：由一条旋律线配以和声进行来构成的织体。

节奏

节奏是由有规律或无规律的脉冲、音符（或声音）和静音组成的一种模式。

音符本身的音值对节奏有影响，这体现在每种拍子的强弱规律。比如四二拍的每小节中音符的强弱规律是“强弱”，四三拍则是“强弱弱”。拍子可以组成为复拍，比如两个四二拍组成四四拍，强弱规律是“强、弱、次强、弱”。通过“>”来标记强音。

音符的排列型式对节奏有重要影响，也就是节奏型。比如切分音、连音。

切分音，指的是改变乐曲中强拍上出现重音的规律，使弱拍或强拍弱部分的音，因时值延长而成为重音。中间音的长，两边音的短，中间音是重音：

对音符进行分拍可以得到连音。对一个音符进行划分的规则如下：

比如要对一个二分音符进行五等分，就是使用二次分拍的进行四等分，也就得到八分音符，使用八分音符来书写五连音。

有些节奏型是常见的，比如前十六后八、前八后十六、三连音、无连音，可以对其迅速做出反应。

乐音体系

八度

我们可以用唱名 Do[1] Re[2] Mi[3] Fa[4] Sol[5] La[6] Ti[7] Do[8] 唱出歌曲的旋律，“[]” 中的数字就是 音级（Degree ）。

我们以 Do[1] 到 Do[1] 为一度，Do[1] 到 Re[2] 为二度，以此类推。于是从 Do[1] 到上面 Do[8] 之间音高上的距离(音程，Interval)就叫做 八度（Octave），因此说 Do[8] 比 Do[1] 高了一个八度。

音名和唱名

音名：用 C，D，E，F，G，A，B 来标记基本音级的，叫做音名，它们表示一定的音高，比如 C4 即是中央 C 音高。

唱名：与 C，D，E，F，G，A，B 对应的唱名用 do、re、mi、fa、so、la、si 来作为音级名称，但注意 do 并不能用于指代 C，只有在 C 调下可以这么认为，D 调下则 do 用 D 来唱。后文具体进行解释。

在 C 大调中，音阶的音符是没有任何升降符号的，所有音符都是自然音符。

C（主音，do）
D（大二度，re）
E（大三度，mi）
F（纯四度，fa）
G（纯五度，so）
A（大六度，la）
B（大七度，si）

在 C 小调中，音阶的音符会有不同的排列，因为小调音阶有一些特定的音程变化。

C（主音，do）
D（大二度，re）
E♭（小三度，mi）
F（纯四度，fa）
G（纯五度，so）
A♭（小六度，la）
B♭（小七度，si）

在 D 大调中，音符的关系会有所不同，因为 D 大调的音阶是基于 D 音开始的。D 大调的音阶包括：

D（主音，do）
E（大二度，re）
F#（大三度，mi）
G（纯四度，fa）
A（纯五度，so）
B（大六度，la）
C#（大七度，si）

在吉他中，从六弦到一弦（即从最粗的弦到最细的弦），音名依次为 EADGBE。标准调弦下音高为（吉他正面方向）：

1 弦: E4（约 329.63 Hz）
2 弦: B3（约 246.94 Hz）
3 弦: G3（约 196.00 Hz）
4 弦: D3（约 146.83 Hz）
5 弦: A2（约 110.00 Hz）
6 弦: E2（约 82.41 Hz）

在吉他上，音高是通过弦的振动和按压琴格的位置来决定的。每根弦和每个品格都有固定的音高。按下吉他的品格（即指板上的位置）会改变弦的振动长度，从而改变音高。每按下一个品格，音高上升一个半音。比如，按下 6 弦的 1 品，音高从 E2 变为 F2。

如果想在吉他上弹奏 C 大调，可以从 5 弦的 3 品开始弹，即从 A2 升高 3 个半音到 C3（A2 到 B2 相隔一个全音，B2 到 C3 相隔一个半音）。

半音与十二平均律

在乐音体系中，音高关系最小的计量单位叫 半音（Semitone），两个半音就是一个全音。

在 C，D，E，F，G，A，B，C 中，EF 和 BC 之间相差一个半音，其它相邻音相差一个全音。

在吉他中，相邻两个品格之间相差半音。

十二平均律（Equal temperament），或平均律, 是将八度的二倍音程等比例地划分为十二份的定律方式。它让每一个临近的音在音程上都是同样的倍数关系。这每一个音和主音 Do[1] 组成的音程的倍数关系分别是 $2^{n/12}$，n=0到12。

当 n=12，倍数正好是二倍即纯八度，它对应的音名和当 n=0 时纯一度上的音是一样的。所以去掉 12，从 0 数到 11 正好产生十二个不一样的音名。

对于 C 大调，如果是以国际标准音 A-la-440HZ 为准，通过十二平均律可以计算出各个音的频率（单位：HZ）为：

C	C#/Db	D	D#/Eb	E	F	F#/Gb	G	G#/Ab	A	A#/Bb	B
261.6	277.2	293.7	311.1	329.6	349.2	370.0	392.0	415.3	440.0	466.2	493.9

可以看出，根据十二平均律分出了 12 个音，每个音之间相差的频率大小就是一个半音的大小。

音组

不同八度的音名如果都长一样会造成误解，因此有必要用不同的标记以示区分。

音高的标记国际上通用两套体系：科学音高记号法 与 亥姆霍兹音高记号法。

科学音高记号法

我们把从 C 开始的一个八度设定为一个音组，音组中的音名用大写英文字母 CDEFGAB 和升降符号标记。每个音组都把 C 作为音组的第一个音，B 作为音组的最后一个音。

人耳的听力极限在 20Hz - 20,000Hz 左右，随年龄稍有衰减。这个频率区间跨度大约在十个八度，所以使用十一个音组就能完全将人耳听力范围涵盖在内。

于是，我们可以用数字 0-10 来标记这十一个音组。最低一个的音组对应数字 0，最高一个对应数字 10。

在标记音高时，音名的大写字母在前，数字在后。

中央 C 标记为 C4，标准音高 A440 记为 A4，这两个音都落在 4 号音组中。

最低一个 0 号音组中的 C 是 16.35Hz，标记为 C0。这个音组的最后一个音是 B0，由 B0 升高一个半音可以得到下一个音组中的第一个音 C1。

最高的一个 10 号音组中，B 的频率在 31608Hz，标记为 B10。

亥姆霍兹音高记号法

在钢琴正中央的一组音级（包括基本音级和变化音级的十二个音级–从 C 到 B）叫做“小字一组”。用小写字母 c、d、e、f、g、a、b 来表示，并在其右上方标记出阿拉伯数字 1。如：c1、d1、e1、f1、g1、a1、b1。

比小字一组高的音组由低到高分别定名为“小字二组” …… “小字六组”等等。并在其右下方用阿拉伯数字 1 或 2、3、4。如小字三组的 D 就标记为 d3。

比小字一组低的音组由高到低分别定名为“小字组”，“大字组”、“大字一组”、“大字二组”、“大字三组”、“大字四组”等等。

其中大字组的音用大写字母 C、D、E、F、G、A、B 来表示，并在其右下方用阿拉伯数字 1 或 2、3、4。如大字二组的 D 就标记为 D2。

音乐记谱法

五线谱

五线谱上的四三拍分数标记，是从下往上读的，表示以四分音符为基本拍，每小节有三拍，实际上表示每个小节的时值是三个四分音符的总时值，所以并不是只采用四分音符表示。

五线谱有五条线，最下面为一线，一线二线间为一间，一线往下为下加一间、下加一线，五线往上为上加一间、上加一线，可以一直加，每个线或间标识一个音高。

谱号是五线谱中的一个符号，用来表示乐谱中不同位置的音高。谱号通常是一个音名字母的变体，放在五线谱中的某个位置上，表示该位置上的音高。

如下图所示，从二线开始画高音谱号，那么二线即为 G4 音，一间即为 F4，一线即为 E4，下加一间即为 D4，下加一线即为中央 C4 了：

不同乐器适用不同谱号。现今的有音高乐器通常只会使用高音、中音、次中音和低音谱表四种谱表，圆号、小提琴、吉他等常使用高音谱表，长号、大提琴、低音提琴等常使用低音谱表，中提琴、大提琴等常使用中音谱表，大提琴、长号等常使用次中音谱表。

五线谱中会使用很多额外的标记来注释某段拍子应该如何演奏，比如：

标记音符的强度及其变化：用 f 表示“强”，p 表示“弱”。mf 为中强，ff 为极强，fff 为最强，sf 为突强，"<cresc." 表示渐强。

标记演奏的情感：

Cantabile：如歌的
Dolce：柔和甜美的
Leggiero：轻快的
Agitato：充满激情的
Grandioso：壮观宏伟的

标记演奏的整体速度：

Presto - 急板（168-200 bpm）
Vivace - 活泼的（~140 bpm）
Allegro assai - 颇快的
Allegro - 快板（120-168 bpm）
Allegro Moderato - 适度、中速的快板
Allegretto - 小快板（104-112 bpm）
Moderato - 中板（90-115 bpm）
Andantino - 小行板（比行板稍快）
Andante - 行板（76-108 bpm）
Adagietto - 小柔板/颇慢
Adagio - 柔板（66-76 bpm）
Largo - 广板（40-60 bpm）

若加了 Molto，则表示“非常”，用来加强速度或力度的指示。例如：

Molto Allegro: 比普通的 Allegro 更快。
Molto Adagio: 比普通的 Adagio 更轻柔。

具体的速度增加没有固定的数量，因为它依赖于演奏者的诠释和乐曲的风格。通常来说，它表示要在原有的基础上更为明显地表现出速度或力度的变化。

装饰音是一种用来装饰音符的音。装饰音可以加强音乐的旋律和节奏感。通常装饰音会附在音符上很快地演奏。

具体演奏方法可以参考：装饰音演奏大法

在学习弹奏哥德堡变奏曲中，我发现巴洛克时期的装饰音写法有所不同，如下图五线谱所示：

查找百科可以找到巴洛克时期装饰音的具体写法和演奏方法：

简谱

简谱为记谱法之一，因主要以数字作表达，亦称为数字谱。

简谱起源于十八世纪的法国，后经德国人改良，遂成今日之貌。简谱若与五线谱合并显示，则称为“简五谱”。

在简谱中，使用 1-7 代表各个音符，例如 1 表示 do，2 表示 re，以此类推。至于 1 具体代表那个音，乐谱中会有具体的表示，比如是一首 G 大调的作品，那么可能会写为 “1=G 3/4”，表示 1 为 G 音（通常为 G4），以四分音符为一拍，每小节三拍子。

对于音高，如果是高一个八度，就会在数字上方加上一点。如果是低一个八度，就会数字下方加上一点。在中间的那一个八度就什么也不用加。依此类推，如果要再高一个八度，就在上方垂直加上两点。如下所示：

对于音长，通常只有数字的是四分音符。数字下加一条横线，就可令四分音符的长度减半，即成为八分音符，依此类推。在数字后面加一条横线则变成二分音符，依此类推。此外，休止符用“0”来表示。

六线谱

六线谱是世界上通用的一种专为吉他设计的记谱方法，它的基本结构是由六根间隔相等的线组成，六根线分别代表吉他上的六根弦，最下面的一条线，代表吉他的第六根弦。

六线谱可以表示两手演奏的位置和动作（即指法），属于记录指法的乐谱。六线谱不记录音的高低，但与简谱或五线谱结合对照起来使用时非常方便，既能表示音高，又能表示指法。

四线谱

四线谱有三种，一种是精简“五线谱”，一种是尤克里里专用谱，还有就是贝斯专用谱。在音乐创作当中使用较为广泛。

十一世纪时，修道士圭多·达雷左首创四线谱。

四线谱可以精确地记录音高，以便歌手准确演唱。四线谱也是贝斯专用谱。还有一种是精简“五线谱”。

音程

音程指的是一个乐音体系中，两个音之间的高低关系。两个音可以有前后顺序，即旋律音程，也可以同时发声，即和声音程。较低的音称为根音或下方音，较高的音称为冠音或上方音。

自然音程

在采用五度相生律的自然大调中，任意两个音之间的音程可以按照度数和音程系数归为十四种。

度数指的是两个音之间包含的基本音名或唱名的数量（含自身）。例如，do－fa 的度数是四度，包含了 do、re、mi、fa 四个唱名；do－do1 的度数是八度。

“纯”音程是基于简单频率比和高度谐和性而定义的，主要包括一度、四度、五度和八度。这些音程在音乐体系中具有基础性作用。其他音程因其复杂性或功能多样性，被归类为“大”、“小”、“增”、“减”，而没有“纯”的概念。这种分类反映了音程在音乐实践和理论中的不同角色和功能。

根据对照表可以轻松计算得到音程，比如增四度，对于 sol，我们首先根据四度音程 re-mi-fa-sol，找到了 re，这相差音数为 1+0.5+1=2.5，则为纯四度，为了得增四度，将 re 降半音或者 sol 升半音即可：(b)re-sol / re-(#)sol。

变化音程

根据自然音程，变化音数，可以得到变化音程。

具体增减关系：

协和音

在音乐范畴中，协和与不协和指的是将和弦或旋律的悦耳程度进行分类与描述的一种方式。通常意义上来讲，协和的声音常与甜美、放松、愉悦、可接受等情感相联系；而不协和则常与刺耳、紧张、不愉快、不可接受和伤心等情感相联系。

在古典音乐的对位法中，协和与不协和往往按照以下的方式进行区分：

完全协和（德语：vollkommene Konsonanzen）：纯一度、纯八度、纯四度、纯五度。
不完全协和（德语：unvollkommene Konsonanzen）：大三度、小三度、大六度、小六度。
不协和：大二度、小二度、大七度、小七度，增四度或减五度。

而在爵士乐中，对于协和与不协和则有不同的定义：

一级协和（德语：primäre Konsonanzen）：大三度、小三度、大六度与小六度；
次级协和（德语：sekundäre Konsonanzen）：纯一度、纯八度、纯四度和纯五度；
轻微不协和（德语：milde Disssonanzen）：增二度、增五度、增四度、小七度和大二度；
不协和（德语：Disssonanzen）：小二度、大七度和小九度；

音程转位

在音程中，把某个音程的根音向上提高八度，或者把它的冠音降低八度，也就是将音程的根音与冠音的位置进行相互调换，这种就称为音程转位。

为方便称呼，转位之前的音程会被称为原位音程，而转位之后的音程会被称为转位音程。

和弦

现代音乐概念里面，由 多个不同的音高 同时发声就形成和声。

三个或三个音以上 的和声就叫做 和弦（Chord）。

和弦原意是指弦线。在音乐理论里，是指组合在一起的两个以上不同音高的音。在欧洲古典音乐及受其影响的音乐风格里，更多时候是指三个或以上的音高组合，而两个音高的组合则以音程来描述。

和弦的组成音，可分开演奏，亦可同时演奏。分开演奏的，称为分解和弦。

和弦类型

和弦的结构类型很多，如果按照组成音的多寡来区分，和弦可以分为三和弦（triads）、七和弦（sevenths）及九和弦（ninths）等。

三和弦是由三个音组成，从最低音到最高音依次叫根音、三音和五音。七和弦是由四个音组成，九和弦则由五个音组成。

这些和弦又可用音程结构来细分，例如三和弦可以分为大和弦（major chord）、小和弦（minor chord）、增和弦（augmented chord）、减和弦（diminished chord）四种形态。他们的构成规律如下：

和弦转位

和弦通过转位形成转位和弦。一个和弦中除根音以外的音作为最低音，则称为转位和弦。

如果和弦是 C，那么和弦音有三个：C、E、G。一般来说，低音当然是以 C 为中心来演奏的，这是基本形式，而不是围绕 E 或 G 弹奏。这就是转位。

在古典系统理论中，三音作为低音的形式被称为第一转位，低音用五音的形式被称为第二转位，没有转位的叫做基本型。

转位的形式可以用来控制歌曲的稳定性，或创造一个平滑移动的低音线。

调式体系

基本概念

音阶的类型叫做 调式(mode)。一个音阶是按泛音列或音排列，并因其规律形成循环的一系列音符。八度中选取任意一组音，它们的音高 由低到高 依次排列就能组成一条音阶。

像钢琴键盘白键这样，一个双全音群和一个三个全音的群，两个群由半音衔接在一起，这样组成的音阶就叫做 自然音阶（Diatonic scale）。

在音乐理论中，稳定音和不稳定音是指音阶中不同音级的稳定性，即它们在调性中的作用。稳定音是指音阶中相对稳定、不需要解决的音，它们是和弦的构成音，在音乐中听起来稳定、安定，通常可以停留较长时间。稳定音通常是 1、3、5 级音，这三个音构成了主和弦。不稳定音是在调性中听起来不安定，通常需要向稳定音解决的音。它们通常是音阶中的 2、4、6、7 级音。

大小调

自然音阶有七个不同的音，因此属于七声音阶。自然音阶有七种调式，各自拥有独特的气质。其中大小调是最常用的 2 种。大调音阶的音程向上以 全全半全全全半 排列，用大调写的音乐一般给人的感觉或轻松舒缓或积极阳光。小调音阶的音程向上以 全半全全半全全 排列，小调音乐带有忧郁哀伤的气质。

对于 C 大调，就是以 C 为主音，以大调作为调式。组成的音有 C、D、E、F、G、A、B 及 C。C 大调是一个没有升号和降号的调。A 小调与 C 大调是关系大小调，它们共用相同的调号，也就是没有升降号。

将 C 大调移高一个纯五度就是以 G 为主音的 G 大调。G 大调音阶为：G - A - B - C - D - E - F# - G，有了一个升号。如下图，在五线谱中，G 大调表示为在高音谱号右侧写一个升号：

键盘乐器

钢琴

传统钢琴（如立式钢琴和三角钢琴）是机械乐器，通过敲击琴键触发锤子敲打弦，产生声音。每个琴键都有一个相应的弦，弦的震动通过琴体放大，形成音响。这种声音具有自然的音色、共鸣和音质变化。传统钢琴需要定期调音和保养，尤其是对于三角钢琴，每年需要至少调音一次，以保证音色和音准的准确。

电钢琴是通过电子发声的乐器，通常没有像传统钢琴那样的弦，而是模拟或数字化音频生成声音。电钢琴的音色可以是多种多样的，包括钢琴音、电子合成音、管风琴音等。电钢琴通常不需要调音。

关于踏板：

右踏板（延音踏板）：延长所有音符的持续时间，增加音符之间的连贯性。踩下踏板后，所有音符的消音器抬起，音符持续发声。
左踏板（弱音踏板）：减弱音量并改变音色，使音符显得更加柔和。踩下踏板后，使琴槌击打弦的面积变小，音量减弱。
中踏板（延音加强踏板）：只延长特定音符的持续时间，允许在演奏时保持某些音符的持续而不影响其他音符。踩下踏板后，只延长已按下音符的持续时间，其他音符不受影响。

大键琴

大键琴（Harpsichord）是一种古老的键盘乐器，属于弦乐器家族。它在巴洛克时期尤其重要，广泛用于古典音乐中，尤其是巴赫、亨德尔、维瓦尔第等作曲家的作品中。

大键琴的外形与钢琴相似，通常有一个较大的、扁平的琴身和琴键。它通常有两组或更多的键盘，每组键盘都有一定数量的琴键。与钢琴不同，大键琴的弦是通过拨片（plectrum）来激发的，而不是通过锤子敲击弦。这种结构使得大键琴的音色与钢琴有很大的不同。

当按下大键琴的琴键时，键下的拨片会拨动对应弦的振动，产生声音。由于没有打击弦的机制，大键琴的声音相对钢琴来说更为尖锐、明亮且较为“平”。大键琴的声音不能通过力度变化来调节。即按下琴键的力度不会影响音量或音色的变化，这与钢琴的触感和声音变化机制是不同的。

大键琴的演奏不能像钢琴一样通过击打力度来变化音量，因此大键琴演奏者需要使用快速的指法技巧和精准的手指控制来达到不同的音效。大键琴通常需要演奏者在旋律中加入许多装饰音，如倚音、琶音、快速音符变化等，这些技巧使得大键琴的演奏富有表现力。

电子琴

Yamaha psr-e383 电子琴的一些使用记录：

61 键
屏幕虽然显示了 C3，但实际上的音高是 C4
视频说明书
资料下载
没有踏板

管风琴

管风琴（Organ）是一种历史悠久的键盘乐器，以其巨大的音响和丰富的音色著称，常常出现在教堂、音乐厅以及大型演奏会中。它是古典音乐、宗教音乐和某些现代音乐演奏中不可或缺的乐器。管风琴的声音通过空气流动通过管道产生，这些管道根据不同的长度、材质和形状可以产生各种音色。

弦乐器

吉他

标准定弦

标准定弦是六弦吉他最常用的定弦法。若无变格定弦的具体说明，则标准定弦是默认的。它包括以下音符:

1E2-A2-D3-G3-B3-E4

这里就采用了科学音高记号法，字母表示音名，数字表示所在八度。

弦	频率	科学记谱法音高
1 (E)	329.63 Hz	E4
2 (B)	246.94 Hz	B3
3 (G)	196.00 Hz	G3
4 (D)	146.83 Hz	D3
5 (A)	110.00 Hz	A2
6 (E)	82.41 Hz	E2

八大吉他和弦

按弦注意事项：

按的位置要尽量接近下方琴桁（Fret）。
使用指尖按弦，并且关节呈弯曲状态，而大拇指保持放松。
确保没有闷住／碰触邻弦，每条该发出声音的弦都有正常运作。
每天花点时间练习和弦之间的转换过程，进步速度会很快。

贝斯

贝斯(低音吉他)

小提琴

TODO

低音提琴

TODO

大提琴

TODO

Reference

音乐格式和分轨问题记录

akynazh@gmail.com (zhihang) — Fri, 22 Nov 2024 14:43:20 +0800

前言

实体音乐媒介有黑胶唱片、磁带、光存储介质等。光存储介质主要包括 CD(Compact Disc)、DVD(Digital Versatile Disc)，SACD(Super Audio CD)，BD(Blu-ray Disc) 等。

随着技术进步，数字化音乐出现，主要包括各种格式的音乐数字文件和各种平台所提供的流媒体服务。

作为一个音乐爱好者，我觉得了解各种音乐格式还是很有必要的。特别是作为 Apple Music 使用者，就更有意义了。Apple Music 支持导入音乐和编辑专辑，很适合做一个自己的音乐库。虽然我已经是 Apple Music 美区用户，曲库已经相当完善，但还是有一些特别想听的音乐找不到，比如最近想听 Clannad 的 OST 是没有的，古典音乐某些演奏家的演奏版本是找不到的。

因此，少部分音乐我还是得通过其他手段获取，这时候了解各种音乐格式就很有意义了，同时还需要了解一些分轨技术，以更好地享用和收藏整轨音乐包。

常见音乐格式

数字音乐有很多音乐格式，如 mp3、flac、wav、m4a 等，下面做一个记录。

MP3(MPEG Audio Layer-3)

MPEG Audio Layer-3 是音频压缩技术的全称，MPEG 是 Moving Picture Experts Group 的缩写，即动态图像专家组，它是一个国际标准化组织下的工作组，负责制定音频和视频压缩的国际标准。Layer 可以理解为同一标准中针对不同场景的压缩级别，Layer-3 相对 1 和 2 压缩效率和音质更好。

压缩方式：有损压缩（Lossy Compression）。
音质：通过移除人耳不易察觉的声音信息减小文件大小，音质受码率（bitrate）影响。
- 常见码率：128 kbps（中等）、192 kbps（良好）、320 kbps（接近无损）。
文件大小：小，适合节省存储空间。
兼容性：几乎所有设备和软件都支持。
用途：流媒体、便携式音乐设备、普通聆听。

FLAC(Free Lossless Audio Codec)

压缩方式：无损压缩（Lossless Compression）。
音质：保留录音的完整音频数据，音质与原始录音一致。
文件大小：比 WAV 小（约原文件的 50-70%），但比 MP3 大很多。
兼容性：现代播放器和设备广泛支持（如 VLC、Foobar2000、Hi-Fi 音响）。
用途：高品质音乐收藏、发烧友、高端音响设备。

优缺点：

优点：高音质，文件支持标签（如专辑封面、艺术家信息）。
缺点：文件较大，兼容性不如 MP3。

WAV(Waveform Audio File Format)

压缩方式：未压缩或无损（Uncompressed or Lossless）。
音质：最接近原始录音，极高音质。
文件大小：非常大（约 10 MB/分钟）。
兼容性：专业音频设备和软件支持良好。
用途：录音、编辑、母带制作、专业音频工程。

优缺点：

优点：音质最佳，无任何压缩损失。
缺点：文件巨大，不适合普通存储或便携设备。

M4A(MPEG-4 Audio)

压缩方式：有两种版本
- AAC（Advanced Audio Coding）：有损压缩。
- ALAC（Apple Lossless Audio Codec）：无损压缩。
音质：
- AAC 音质优于 MP3（同码率下）。
- ALAC 提供与 FLAC 类似的无损音质。
文件大小：
- AAC 比 MP3 小。
- ALAC 比 WAV 小但大于 MP3。
兼容性：苹果生态系统支持最佳（如 iTunes、iPhone），大多数现代播放器也兼容。
用途：流媒体（AAC）、高品质收藏（ALAC）。

优缺点：

优点：AAC 高效，ALAC 高音质，苹果用户友好。
缺点：ALAC 在非苹果设备上的支持较 FLAC 少。

其他常见格式

OGG（Ogg Vorbis）：
- 开源有损格式，音质优于 MP3（同码率）。
- 常用于游戏、Spotify 等流媒体。
- 缺点：兼容性较差。
AIFF（Audio Interchange File Format）：
- 苹果开发的未压缩格式，与 WAV 类似，音质无损。
- 用途：专业音频编辑，苹果生态友好。
DSD（Direct Stream Digital）：
- 超高分辨率无损格式，常用于 SACD。
- 文件巨大，仅限高端设备支持。
APE（Monkey’s Audio）：
- 高效无损格式，文件比 FLAC 小，但兼容性差。

选择建议

流媒体/普通听众：MP3、AAC（M4A）更适合，兼顾音质和文件大小。
音乐发烧友：FLAC 或 ALAC 提供高音质，适合高端设备和收藏。
音频编辑：WAV 和 AIFF 更适合，因其保留了原始录音的所有细节。
文件空间有限：MP3 或 AAC（M4A）优先，文件小且易兼容。
高分辨率音频：DSD 或 FLAC 是最佳选择。

整轨和分轨

我在处理一些 OST(Original Soundtrack，原声音乐) 包时，发现里面通常包含许多文件，cue、flac、ape 等音频文件和一些图片。这里关键在于 cue 文件。

cue 文件是一个文本文件，存储了音频文件的 分轨(Split Tracks) 信息，包括每个音轨的起始时间、曲目名称、艺术家等元数据。也就是说只要存在 cue，那么对应的音频文件(flac、ape 等)就是一个 整轨(Single Track) 音频。比如下面一个实例：

 1PERFORMER "KEY"
 2TITLE "CLANNAD ORIGINAL SOUNDTRACK"
 3FILE "KSLA-0012.ape" WAVE
 4  TRACK 01 AUDIO
 5    TITLE "汐"
 6    PERFORMER "戸越 まごめ"
 7    FLAGS DCP
 8    INDEX 01 00:00:00
 9  TRACK 02 AUDIO
10    TITLE "幻想"
11    PERFORMER "戸越 まごめ"
12    FLAGS DCP
13    INDEX 01 01:08:00
14  ...
15  TRACK 19 AUDIO
16    TITLE "月の位相"
17    PERFORMER "折戸 伸治"
18    FLAGS DCP
19    INDEX 01 64:42:00
20  TRACK 20 AUDIO
21    TITLE "無間"
22    PERFORMER "折戸 伸治"
23    FLAGS DCP
24    INDEX 01 68:34:00

这个 Clannad OST 描述了详细的音频信息，对于头部信息：

PERFORMER “KEY”：这表示专辑的表演者是 “KEY”。
TITLE “CLANNAD ORIGINAL SOUNDTRACK”：这是专辑的标题，指明这是 “CLANNAD 原声带”。
FILE “KSLA-0012.ape” WAVE：这表示音频文件的名称为 “KSLA-0012.ape”，并且文件格式为 WAV 或兼容 WAV 的格式。虽然文件扩展名是 .ape，可能是无损音频格式 APE 的文件，但在 .cue 文件中通常会使用 WAV 来表示音频格式。

从 TRACK 开始，就是每首音乐的具体信息，比如 TRACK 01:

TITLE “汐”：这是第一轨的标题，名为 “汐”。
PERFORMER “戸越まごめ”：演唱者为 “戸越まごめ”。
FLAGS DCP：标记此轨为 “Disc-at-Once” 刻录模式，意味着此轨与其他音轨之间没有间隙。
INDEX 01 00:00:00：第一轨从 00:00:00（即 0 秒）开始播放。

通过 XLD 完成分轨

在 Mac 上可以通过 xld 完成音频分轨、转换等操作，xld 支持 gui 和 cmd，下面通过 cmd 进行示范。

下载 XLD
将 “XLD.app” 安装到 “/Applications/XLD.app”
设置 xld 命令如下：

1xld() {
2    XLD_APP="/Applications/XLD.app"
3    "${XLD_APP}/Contents/MacOS/XLD" --cmdline "$@"
4}

之后即可快乐食用 xld 咯！

1mkdir "./Clannad OST 0012"
2
3# -c 指定 cue -o 指定输出目录（需要存在） -f 指定输出格式（默认 wav）最后跟上整轨音频文件
4xld -c "KSLA-0012.cue" -o "./Clannad OST 0012" -f alac "KSLA-0012.ape"

一些注意事项：

如遇乱码问题，先将 cue 文件保存为 utf8 后再操作即可。
格式则建议采用 alac，相比 wav 更小但音质无异，flac 也可但是无法导入 apple music。
输出的文件夹导入 apple music 后，专辑名称不是文件夹名而是 cue 头信息中的 TITLE

PLUS: 通过 XLD 进行音频转换：

1xld -f alac だんご大家族.flac

Reference

缓存重要知识整理

akynazh@gmail.com (zhihang) — Mon, 14 Oct 2024 01:48:44 +0800

缓存分类

缓存可分为本地缓存和分布式缓存：

本地缓存：指的是在应用中的缓存组件，其最大的优点是应用和 cache 是在同一个进程内部，请求缓存非常快速，没有过多的网络开销等，在单应用不需要集群支持或者集群情况下各节点无需互相通知的场景下使用本地缓存较合适；同时，它的缺点也是应为缓存跟应用程序耦合，多个应用程序无法直接的共享缓存，各应用或集群的各节点都需要维护自己的单独缓存，对内存是一种浪费。常见的本地缓存有：

Ehcache
Guava Cache
Caffeine

Caffeine 是基于 JAVA8 的高性能缓存库。并且在 Spring5 (Springboot 2.x) 后，Spring 官方放弃了 Guava，而使用了性能更优秀的 Caffeine 作为默认缓存组件。

分布式缓存：指的是与应用分离的缓存组件或服务，其最大的优点是自身就是一个独立的应用，与本地应用隔离，多个应用可直接的共享缓存。常见的分布式缓存有：

Redis
Memcached

Memcached 不支持灾难恢复，对分布式支持不如 Redis，已经基本被 Redis 取代，下面着重记录 Redis 相关要点。

Redis

线程模型

Redis 内部使用文件事件处理器 file event handler ，这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：

多个 socket
IO 多路复用程序
文件事件分派器
事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

单线程模型效率高的原因:

纯内存操作
核心是基于非阻塞的 IO 多路复用机制
单线程反而避免了多线程的频繁上下文切换问题，预防了多线程可能产生的竞争问题

Redis 6.0 开始引入多线程，Redis 在有些方面，单线程已经不具有优势了。因为读写网络的 Read/Write 系统调用在 Redis 执行期间占用了大部分 CPU 时间，如果把网络读写做成多线程的方式对性能会有很大提升。

Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。

通信流程

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将产生事件的 socket 放入队列中排队，事件分派器每次从队列中取出一个 socket，根据 socket 的事件类型交给对应的事件处理器进行处理。

过期删除策略

Redis 使用的过期删除策略是「惰性删除+定期删除」，删除的对象是已过期的 key。

内存淘汰策略是解决内存过大的问题，当 Redis 的运行内存超过最大运行内存时，就会触发内存淘汰策略，Redis 4.0 之后共实现了 8 种内存淘汰策略，我也对这 8 种的策略进行分类，如下：

主从架构

主从(master-slave)架构，一主多从实现高并发，主节点负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。Redis 在主从的基础上通过哨兵机制切换主从实现高可用。

主从复制流程大致是，初次连接全量复制，通过 RDB 快照 + 增量复制机制完成，如果复制过程中断线也会采用增量复制完成（可通过 heartbeat 机制确认连接情况）。

哨兵机制大致是，哨兵监控 master，如果一个哨兵觉得 master 宕机了，则是主观宕机(sdown)，超过 quorum 个认为这是客观宕机(odown)，此时选举出新 master 候选人，这个人得到 majority 个哨兵的认可就可以成为 master。

quorum 的计算公式为：quorum = (哨兵节点数/2) + 1
majority 是选举机制中的一个值，可以理解为选票，majority >= quorum 并且 majority > 哨兵数量的一半
选举机制中，候选者是判断哪个节点下线的哨兵，候选者投给自己，其他人投给收到的第一个申请的人

关于选举机制带来的“脑裂”问题，其实就是出现 2 个 master，原 master 因为网络问题脱离，而其他人开始选新 master，后来原 master 恢复，导致出现 2 个 master。原 master 未进行主从切换复制数据，清空数据并成为 slave，导致丢失数据。通过限制 master 的 slave 个数大于 0 和延迟时间不超一定时间即可避免这个问题。

集群模式

Redis cluster，主要是针对海量数据+高并发+高可用的场景。Redis cluster 支撑 N 个 Redis master node，每个 master node 都可以挂载多个 slave node。

集群模式下，各个 master 存储不同的数据，采用一致性哈希算法来计算 key 的目标 master。具体来说，Redis 集群通过一致性哈希和槽（slot）机制来管理和定位键。

Redis 集群将整个键空间分为 16384 个槽。每个键通过 CRC16 算法计算哈希值，然后对 16384 取模，决定其属于哪个槽。集群中的每个 master 负责若干个槽。

对于普通的哈希算法，一旦其中一个 master 挂了，将会影响其他大多 master 的哈希，导致大量 key 需要重新分布，采用一致性哈希，可以将影响降低到单个 master，一致性哈希还采用了虚拟节点的方法，实现 key 的均匀分布：

数据结构

String: SDS，基于 C 字符串的动态长度可变字符串。
List: QuickList(LinkedList+ZipList)
Set: HashTable/IntSet。如果一个集合只包含整数值元素，且元素数量少于 512 个时，会使用 Intset。
Hash: HashTable/ZipList。如果保存的所有键值对的键和值的字符串长度都小于 64 字节且数量小于 512 个则采用 ZipList。
Zset: ZipList/SkipList+Dict。当 Zset 保存的键值对数量少于 128 个且每个元素的长度小于 64 字节时使用 ZipList，否则使用 SkipList。

SDS 对 c 原始 char 数组的改进:

支持扩容
包含长度 len，获取长度复杂度 O(1)
空间预分配
惰性空间释放

惰性空间释放用于优化 SDS 的字符串缩短操作：当 SDS 的 API 需要缩短 SDS 保存的字符串时，程序并不立即使用内存重分配来回收缩短后多出来的字节，而是使用 free 属性将这些字节的数量记录起来，并等待将来使用。

基本操作

 1# 启动 redis
 2redis-server
 3# 连接到本地 redis:
 4redis-cli
 5# 连接到远程 redis:
 6redis-cli -h host -p port -a password
 7# 获取配置
 8config get 配置名
 9# 配置
10config set 配置名 值
11# 获取密码
12config get requirepass
13# 设置密码
14config set requirepass 12345
15# 进行密码验证
16auth 12345
17OK

ps: 如果重启服务密码会失效, 通过修改配置文件可以解决:

1# /etc/redis/redis.conf
2requirepass ${password}

以后通过下面命令启动服务，这样就可以在服务开启时同时指定密码。

1redis-server redis.conf

 1# string:
 2127.0.0.1:6379> set mkey sos
 3OK
 4127.0.0.1:6379> get mkey
 5"sos"
 6127.0.0.1:6379> del mkey
 7(integer) 1
 8127.0.0.1:6379> get mkey
 9(nil)
10# list:
11lpush clist redis
12lpush clist mysql
13lrange clist 0 100
14# hash:
15# mkeys: 接偶数个参数，一一对应。
16127.0.0.1:6379> hmset mkeys A a B b C c
17OK
18127.0.0.1:6379> hget mkeys B
19"b"
20# set:
21127.0.0.1:6379> sadd mkey 123
22(integer) 1
23127.0.0.1:6379> sadd mkey 123
24(integer) 0
25127.0.0.1:6379> smembers mkey
261) "123"
27# zset(sorted_set):
28# 根据分数和字典序进行排序，同分数下比较字典序，不同分数时，分数越低越靠前。
29# ... {分数} {键值}
30127.0.0.1:6379> zadd zs 1 ak
31(integer) 1
32127.0.0.1:6379> zadd zs 1 to
33(integer) 1
34127.0.0.1:6379> zrangebyscore zs 0 100
351) "ak"
362) "to"
37127.0.0.1:6379> zadd zs 0 pp
38(integer) 1
39127.0.0.1:6379> zrangebyscore zs 0 100
401) "pp"
412) "ak"
423) "to"
43
44# 涉及批量获取和删除操作的, 线上不建议使用。
45# 批量删除匹配到的 key
46redis-cli keys "user-*" | xargs redis-cli del
47# 如果设置了密码:
48# redis-cli -a "pwd" keys "user-*" | xargs redis-cli -a "pwd" del
49
50# 批量获取匹配到的 key 对应的 value
51redis-cli keys user-* | xargs redis-cli mget
52
53# 根据pattern获取key
54# - * 代表匹配任意字符
55# - ? 代表匹配一个字符
56# - [] 代表匹配部分字符，例如[1,3]代表匹配1和3，而[1-10]代表匹配1到10的任意数字。
57# - x 转移字符，例如要匹配星号，问号需要转义的字符
58keys {pattern}
59## e.g.
60127.0.0.1:6379> keys m*
611) "mkeys"
622) "mkey"
63
64# 获取key数量
65127.0.0.1:6379> dbsize
66
67# 删除所有数据库所有key
68127.0.0.1:6379> flushall
69# 删除当前数据库所有key
70127.0.0.1:6379> flushdb

事务

 1127.0.0.1:6379> multi # 开启事务
 2OK
 3127.0.0.1:6379> set book java
 4QUEUED
 5127.0.0.1:6379> get book
 6QUEUED
 7127.0.0.1:6379> exec # 执行事务
 81) OK
 92) "java"
10127.0.0.1:6379> get book
11"java"
12127.0.0.1:6379> multi
13OK
14127.0.0.1:6379> set name peter
15QUEUED
16127.0.0.1:6379> discard # 取消事务
17OK
18127.0.0.1:6379> exec
19(error) ERR EXEC without MULTI
20127.0.0.1:6379> get name
21(nil)

发布和订阅

1127.0.0.1:6379> subscribe news
2Reading messages... (press Ctrl-C to quit)
31) "subscribe"
42) "news"
53) (integer) 1

1# 另一个 redis 连接下
2127.0.0.1:6379> publish news "hello"
3(integer) 1
4127.0.0.1:6379> publish news "world"
5(integer) 1

在前一个 redis-cli 中可接收到订阅的消息：

 1127.0.0.1:6379> subscribe news
 2Reading messages... (press Ctrl-C to quit)
 31) "subscribe"
 42) "news"
 53) (integer) 1
 61) "message"
 72) "news"
 83) "hello"
 91) "message"
102) "news"
113) "world"

持久化机制

RDB：RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化。
AOF：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在 Redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集。

Redis 支持同时开启开启两种持久化方式，用 AOF 来保证数据不丢失，作为数据恢复的第一选择；用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。

RDB 持久化

RDB(Redis DataBase), 中文名为快照/内存快照，RDB 持久化是把当前进程数据生成快照保存到磁盘上的过程。触发 rdb 持久化的方式有 2 种，分别是手动触发和自动触发。

手动触发：save & bgsave：

save：阻塞当前 Redis 服务器，直到 RDB 过程完成为止
bgsave：Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。

自动触发：

配置：redis.conf 中配置 save m n，即在 m 秒内有 n 次修改时，自动触发 bgsave 生成 rdb 文件
主从复制时，从节点要从主节点进行全量复制时也会触发 bgsave 操作，生成当时的快照发送到从节点
执行 debug reload 命令重新加载 redis 时也会触发 bgsave 操作
默认情况下执行 shutdown 命令时，如果没有开启 aof 持久化，那么也会触发 bgsave 操作

RDB 持久化时如何保证数据一致性？

RDB 中的核心思路是 Copy-on-Write，来保证在进行快照操作的这段时间，需要压缩写入磁盘上的数据在内存中不会发生变化。在正常的快照操作中，一方面 Redis 主进程会 fork 一个新的快照进程专门来做这个事情，这样保证了 Redis 服务不会停止对客户端包括写请求在内的任何响应。另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域，待快照操作结束后才会同步到原来的内存区域。

AOF 持久化

Redis 是“写后”日志，Redis 先执行命令，把数据写入内存，然后才记录日志。日志里记录的是 Redis 收到的每一条命令，这些命令是以文本形式保存。

AOF 持久化过程：

命令追加：服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区
文件写入和同步：有三种策略如下

AOF 重写机制：

AOF 持久化会记录每个写命令到 AOF 文件，随着时间越来越长，AOF 文件会变得越来越大。如果不加以控制，会对 Redis 服务器，甚至对操作系统造成影响，而且 AOF 文件越大，数据恢复也越慢。为了解决 AOF 文件体积膨胀的问题，Redis 提供 AOF 文件重写机制来对 AOF 文件进行“瘦身”。

实例：

操作过程：

Redis 大 key 问题

定位大 key:

ps: redis-cli --bigkeys 以遍历的方式分析 Redis 实例中的所有 Key，并返回整体统计信息与每个数据类型中 Top 前几的大 Key。

删除或优化大 key:

缓存过期策略

缓存的存储空间有限制，当缓存空间被用满时，如何保证在稳定服务的同时有效提升命中率？这就由缓存清空策略来处理，设计适合自身数据特征的清空策略能有效提升命中率。常见的一般策略有：

FIFO(first in first out)：

先进先出策略，最先进入缓存的数据在缓存空间不够的情况下（超出最大元素限制）会被优先被清除掉，以腾出新的空间接受新的数据。策略算法主要比较缓存元素的创建时间。在数据实效性要求场景下可选择该类策略，优先保障最新数据可用。

LFU(less frequently used)：

最少使用策略，无论是否过期，根据元素的被使用次数判断，清除使用次数较少的元素释放空间。策略算法主要比较元素的hitCount（命中次数）。在保证高频数据有效性场景下，可选择这类策略。

LRU(least recently used)：

最近最少使用策略，无论是否过期，根据元素最后一次被使用的时间戳，清除最远使用时间戳的元素释放空间。策略算法主要比较元素最近一次被get使用时间。在热点数据场景下较适用，优先保证热点数据的有效性。

除此之外，还有一些简单策略比如：

根据过期时间判断，清理过期时间最长的元素；
根据过期时间判断，清理最近要过期的元素；
随机清理；
根据关键字（或元素内容）长短清理等。

Redis 过期策略是：定期删除+惰性删除。

定期删除，指的是 Redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。

惰性删除，就是在获取 key 的时候，如果此时 key 已经过期，就删除，不会返回任何东西。

如果定期删除漏掉了很多过期 key，然后你也没及时去查，也就没走惰性删除，此时大量过期 key 堆积在内存里，导致 Redis 内存块耗尽了，所以还需要走内存淘汰机制：

noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错；
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key；
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key。
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key。
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除。

手写 LRU，很简单，指定好最大容量，使用 python 的有序字典即可，获取 key 时重新入典，放 key 时如果存在则重新入典，如果满了就移除最空闲数据。

 1import collections
 2
 3class LRUCache:
 4
 5    def __init__(self, capacity):
 6        self.capacity = capacity
 7        self.queue = collections.OrderedDict()
 8
 9    def get(self, key):
10        if key not in self.queue:
11            return -1
12        value = self.queue.pop(key)
13        self.queue[key] = value
14        return self.queue[key]
15
16    def put(self, key, value):
17        if key in self.queue:
18            self.queue.pop(key)
19        elif len(self.queue.items()) == self.capacity:
20            self.queue.popitem(last=False)
21        self.queue[key] = value

缓存问题

缓存雪崩（宕机）

缓存系统宕机，大量请求打到数据库上。

解决方案如下：

事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。
事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

缓存穿透（绕过）

安全攻击，利用某些数据值的特点，大量请求一定不在数据库中的数据，导致缓存无法生成一直请求数据库。

数据保密，空值缓存保护，布隆过滤器拦截等方式来解决。

关于布隆过滤器：

布隆过滤器是一个很长的二进制向量和一系列随机映射函数，用于检索一个元素是否在一个集合中。其基本工作原理如下：

初始化：创建一个大小为 m 的位数组，所有位初始化为 0。并准备多个哈希函数（通常为 k 个），每个哈希函数将输入映射为位数组的一个位置。
添加元素：
- 对每个待插入的元素，使用 k 个哈希函数分别计算出该元素的 k 个位置。
- 将这些位置对应的位数组中的值设置为 1。
查询元素：
- 对于查询的元素，同样使用 k 个哈希函数计算出 k 个位置。
- 检查这些位置的位数组值：
  - 如果所有这些位置的值都是 1，则该元素可能在集合中。
  - 如果任意一个位置的值是 0，则该元素肯定不在集合中。

它的空间效率和查询时间都远远超过一般的算法，但是有一定的误判率（函数返回 true , 意味着元素可能存在，函数返回 false ，元素必定不存在），这是 k 个位置的哈希冲突导致的。

布隆过滤器的四个核心属性：

k : 哈希函数个数
m : 位数组长度
n : 插入的元素个数
p : 误判率

布隆过滤器无法删除元素，但我们可以通过计数布隆过滤器和定时重新构建布隆过滤器两种方案实现删除元素的效果。

使用场景：

缓存失效

缓存失效（击穿），就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库。

不同场景下的解决方式可如下：

若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。
若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可采用互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。
若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动地重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。

并发竞争问题

多个实例要更新同一个 key，可以采用分布式锁来解决竞争问题。

可以基于 zookeeper 实现分布式锁。每个系统通过 zookeeper 获取分布式锁，确保同一时间，只能有一个系统实例在操作某个 key，别人都不允许读和写。

缓存与数据库一致性问题

先删缓存，后更新数据库，延时再删缓存。

问题一、延迟多久？

一般建议：延迟 300ms ~ 1s 左右。

延迟时间的本质是为了：

等待数据库更新完成
尽量覆盖掉在此期间被误写回缓存的脏数据

推荐做法是根据你数据库的平均写入耗时 + 预估并发访问风险时间来确定，如果数据库写操作耗时 ≈ 150ms，建议延迟 500ms 左右。如果是高并发写系统，甚至可以用异步线程 + 延迟队列/定时任务来做第二次删除，避免主线程阻塞

问题二、是先删缓存还是先更新数据库？

一定是：先删缓存，再更新数据库！

原因：

如果你先更新数据库再删缓存，并发读请求可能读到新数据但旧缓存还在，导致数据库数据被旧缓存“污染”。
而“先删缓存”即使发生并发读，最多就是读不到数据，从数据库再读一遍，不会出错，只是慢一点。

Reference

大数据重要知识整理

akynazh@gmail.com (zhihang) — Thu, 22 Aug 2024 23:46:46 +0800

Preface

最近在负责 ShopeePay 大数据处理相关的工作，发现对大数据相关知识认识还不够，只凭大学相关课程显然差的远，在一些技术设计上存在一定问题。同时在 Shopee 对账项目中也了解到大数据领域包括 paimon 在内的流批统一相关的前沿技术，知之甚少，需要恶补一下。

这里将对大数据相关的知识做一个整理汇总，主要包括 Hadoop、Spark、Flink、Kafka 等组件的重要概念、架构、基础用法，此外还简单记录了在 Shopee DataStudio 中的 Best Practice。后面持续补充更多应用场景、踩过的坑和更多原理性的知识。

Nouns

SLA(Service-Level Agreement)：服务等级协议，指的是系统服务提供者对客户的一个服务承诺，用于衡量大型“分布式“系统是否健康的协议。
OLAP(Online Analytical Processing)：联机分析处理，主要用途是分析聚合数据。
OLTP(Online Transaction Processing)：联机事务处理，主要用途是处理数据库事务。
HTAP(Hybrid Transactional/Analytical Processing)：混合事务/分析处理。
DQC(Data Quality Control)：数据质量监控，对数据库里的数据质量进行质量管理的工具。
SPM(Shopping Page Mark)：导购页面标记，是电商业务为内外站提供的一套跟踪成交效果数据的解决方案，根据 SPM 效果指标和数据可以得到 PV、UV、CVR 等数据。SPM 编码是用来跟踪界面模块位置的编码，标准编码由 4 段组成，采用 a.b.c.d 段格式。
PV(Page View)：页面浏览量。
UV(Unique Visitors)：独立访客。
GMV(Gross Merchandise Volume)：商品交易总额。
CVR(Conversions Rates)：转化率，网站转化率=进行了相应的动作的访问量/总访问量。
KYC(Know Your Customer)：意思是充分了解你的客户，是指在服务商和客户进行业务往来之前或期间核实客户身份的过程。
ETL(Extract-Transform-Load)：用于描述将数据从来源端经过抽取、转换、加载到目的端的过程。
ODS(Operation Data Store)：数据运营层，是数据准备区。数据源中的数据经过 ETL 过程之后进入本层。
DW(Data Warehouse)：数据仓库。数据仓库从上到下可以分为三个层：DWD、DWM、DWS。
DWD(Data Warehouse Details)：数据细节层，该层是业务层和数据仓库的隔离层，对 ODS 数据层做一些数据的清洗和规范化的操作。
DWM(Data Warehouse Middle)：数据中间层，对通用的核心维度进行聚合操作，算出相应的统计指标。
DWS(Data Warehouse Service)：数据服务层，基于 DWM 上的基础数据，整合汇总成分析某一个主题域的数据服务层，一般是宽表，用于提供后续的业务查询，OLAP 分析，数据分发等。
ADS(Application Data Service)：数据应用层，出报表，该层主要是提供给数据产品和数据分析使用的数据。
FT(Fact Table)：事实表是指存储有事实记录的表，比如系统日志、销售记录等。
DIM(Dimension Table)：维度表，是与事实表相对应的一种表，它保存了维度的属性值，可以跟事实表做关联，相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。
WT(Wide Table)：指字段比较多的数据库表。通常是指业务主体相关的指标、纬度、属性关联在一起的一张数据库表。

Hadoop

Apache Hadoop 软件是一个开源框架，支持使用简单的编程模型跨计算机集群对大型数据集进行分布式存储和处理。它的核心模块分为存储和计算模块，前者被称为 HDFS，后者即 MapReduce 计算模型。

HDFS

基本概念

HDFS，即 Hadoop 分布式文件系统，它具有高容错、高吞吐量等特性，可以部署在低成本的硬件上。

HDFS 遵循主从架构，由单个 NameNode(NN) 和多个 DataNode(DN) 组成。NameNode 负责执行有关文件系统命名空间的操作，还负责集群元数据的存储，记录着文件中各个数据块的位置信息。DataNode 负责提供来自文件系统客户端的读写请求，执行块的创建，删除等操作。

HDFS 提供了数据复制机制。HDFS 将每一个文件存储为一系列块，每个块由多个副本来保证容错，块的大小和复制因子可以自行配置（默认情况下，块大小是 128M，默认复制因子是 3）。

HDFS 提供了数据完整性校验机制来保证数据的完整性，创建 HDFS 文件时会计算文件每个块的校验和并将其存储在同一 HDFS 命名空间下。HDFS 还通过心跳机制和重新复制机制来确保 DataNode 的可用性。

采用操作

HDFS 采用 Shell 操作总结：

 1# 显示当前目录结构
 2hadoop fs -ls  <path>
 3# 创建目录
 4hadoop fs -mkdir  <path> 
 5# 删除文件
 6hadoop fs -rm  <path>
 7# 递归删除目录和文件
 8hadoop fs -rm -R  <path> 
 9# 从本地加载文件到 HDFS
10hadoop fs -put  [localsrc] [dst] 
11# 从 HDFS 导出文件到本地
12hadoop fs -get  [dst] [localsrc] 
13# 查看文件内容
14hadoop fs -cat  <path>  
15# 拷贝文件
16hadoop fs -cp [src] [dst]
17# 移动文件
18hadoop fs -mv [src] [dst] 
19# 统计当前目录下各文件大小 
20# + 默认单位字节  
21# + -s : 显示所有文件大小总和，
22# + -h : 将以更友好的方式显示文件大小（例如 64.0m 而不是 67108864）
23hadoop fs -du  <path>

高可用原理

HDFS 的 HA，指的是在一个集群中存在多个 NameNode，分别运行在独立的物理节点上。在任何时间点，只有一个 NameNode 是处于 Active 状态，其它的是处于 Standby状态。 Active NameNode（简写为 Active NN）负责所有的客户端的操作，而 Standby NameNode（简写为 Standby NN）用来同步 Active NameNode 的状态信息，以提供快速的故障恢复能力。

MapReduce

MapReduce 是一个分布式计算框架，它的处理流程如下：

其中 splitting 和 shuffing 操作都是由框架实现的，需要我们自己编程实现的只有 mapping 和 reducing，这也就是 MapReduce 这个称呼的来源。

从上面流程中可以看到在 Mapping 到 Shuffling 的过程中存在大量的数据传输，可以使用 Combiner 在传输之前进行一个本地化的 Reduce 操作，降低数据传输量完成优化。注意这个优化手段需要注意是否影响最终结果，比如本地 Reduce 计算平均数将导致最终结果的错误。

还有一个重要的概念是 Partitioner，可以理解成分类器，将 map 的输出按照 key 值的不同分别分给对应的 reducer，默认的使用的是 HashPartitioner，对 key 值进行哈希散列并对 numReduceTasks 取余，可以自定义，比如按照单词分类，一个 java 示例如下：

1public class CustomPartitioner extends Partitioner<Text, IntWritable> {
2
3    public int getPartition(Text text, IntWritable intWritable, int numPartitions) {
4        return WordCountDataUtils.WORD_LIST.indexOf(text.toString());
5    }
6}

YARN

Apache YARN (Yet Another Resource Negotiator) 是 hadoop 2.0 引入的集群资源管理系统。用户可以将各种服务框架部署在 YARN 上，由 YARN 进行统一地管理和资源分配。

YARN 主要组件如下：

ResourceManager：整个集群资源的主要协调者和管理者，负责给用户提交的所有应用程序分配资源；
NodeManager：YARN 集群中的每个具体节点的管理者。主要负责该节点内所有容器的生命周期的管理，监视资源和跟踪节点健康。
ApplicationMaster：在用户提交一个应用程序时，YARN 会启动一个轻量级的进程 ApplicationMaster。它负责协调来自 ResourceManager 的资源，并通过 NodeManager 监视容器内资源的使用情况，同时还负责任务的监控与容错。
Container：Container 是 YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等。

YARN 工作原理大致如下：

Client 提交作业到 YARN 上；
Resource Manager 选择一个 Node Manager，启动一个 Container 并运行 Application Master 实例；
ApplicationMaster 根据实际需要向 Resource Manager 请求更多的 Container 资源；
ApplicationMaster 通过获取到的 Container 资源执行分布式计算。

Spark

基本概念

Spark 基于 Spark Core 扩展了四个核心组件，分别用于满足不同领域的计算需求:

Spark 最基本的数据抽象是 RDD，全称为 Resilient Distributed Datasets（弹性分布式数据集），它是只读的、分区记录的集合，支持并行操作，可以由外部数据集或其他 RDD 转换而来。一个 RDD 由一个或者多个分区（Partitions）组成。

RDD 的一个重要特性是血缘关系。RDD 会保存彼此间的依赖关系，RDD 的每次转换都会生成一个新的依赖关系，这种 RDD 之间的依赖关系就像流水线一样。在部分分区数据丢失后，可以通过这种依赖关系重新计算丢失的分区数据，而不是对 RDD 的所有分区进行重新计算。RDD 血缘关系的依赖分为窄依赖和宽依赖。窄依赖是指父 RDD 的每个分区都只被子 RDD 的一个分区所使用，宽依赖是指父 RDD 的每个分区都被多个子 RDD 的分区所依赖。

基本操作

Spark 安装：

1# INSTALL
2wget https://dlcdn.apache.org/spark/spark-3.5.2/spark-3.5.2-bin-hadoop3.tgz
3tar -zxvf https://dlcdn.apache.org/spark/spark-3.5.2/spark-3.5.2-bin-hadoop3.tgz
4export SPARK_HOME="xxx/spark-3.5.2-bin-hadoop3"
5export PATH="$SPARK_HOME/bin:$PATH"

Spark 简单示例：

 1# TEST
 2spark-shell
 3...
 4Spark context Web UI available at http://10.53.32.147:4040
 5Spark context available as 'sc' (master = local[*], app id = local-1724038257910).
 6Spark session available as 'spark'.
 7...
 8
 9# test map
10> sc.parallelize(List(1,2,3)).map(_ * 10).foreach(println)
11# test flapMap
12> sc.parallelize(List("spark flume spark", "hadoop flume hive")).flatMap(line => line.split(" ")).map(word=>(word,1)).reduceByKey(_+_).foreach(println)
13# test intersection
14> sc.parallelize(List(1, 2, 4, 5)).intersection(sc.parallelize(List(2, 4, 5, 6))).foreach(println)
15# test sortByKey
16> sc.parallelize(List((100, "hadoop"), (90, "spark"), (120, "storm"))).sortByKey(ascending = false).foreach(println)

Spark SQL 是 Spark 中的一个子模块，主要用于操作结构化数据，能够将 SQL 查询与 Spark 程序无缝混合，允许您使用 SQL 或 DataFrame API 对结构化数据进行查询。

为了支持结构化数据的处理，Spark SQL 提供了新的数据结构 DataFrame。DataFrame 是一个由具名列组成的数据集。如果你想使用函数式编程或者数据是非结构化的 (比如流媒体或者字符流)，则使用 RDDs，否则出于性能上的考虑，应优先使用 DataFrame。Dataset 也是分布式的数据集合，在 Spark 1.6 版本被引入，它集成了 RDD 和 DataFrame 的优点。

一个简单的左外连接示例：

1empDF.join(deptDF, joinExpression, "left_outer").show()
2spark.sql("SELECT * FROM emp LEFT OUTER JOIN dept ON emp.deptno = dept.deptno").show()

Spark Streaming 是 Spark 的一个子模块，用于快速构建可扩展，高吞吐量，高容错的流处理程序。具有良好的容错性，Spark Streaming 支持快速从失败中恢复丢失的操作状态，能够和 Spark 其他模块无缝集成，将流处理与批处理完美结合，Spark Streaming 可以从多种数据源读取数据，也支持自定义数据源。

一个简单的单词计数示例：

 1/*指定时间间隔为 5s*/
 2val sparkConf = new SparkConf().setAppName("NetworkWordCount").setMaster("local[2]")
 3val ssc = new StreamingContext(sparkConf, Seconds(5))
 4
 5/*创建文本输入流,并进行词频统计*/
 6val lines = ssc.socketTextStream("hadoop001", 9999)
 7lines.flatMap(_.split(" ")).map(x => (x, 1)).reduceByKey(_ + _).print()
 8
 9/*启动服务*/
10ssc.start()
11/*等待服务结束*/
12ssc.awaitTermination()

一个在 Shopee DataStudio 上执行 PySpark 用户自定义函数（UDF）任务的示例：

首先编辑 py 文件：

 1# pyspark_udf_demo.py
 2from pyspark.sql import SparkSession
 3 
 4def add_udf(x):
 5    return x + 2
 6 
 7if __name__ == '__main__':
 8    spark = SparkSession.builder.appName("add_udf").enableHiveSupport().getOrCreate()
 9    sc = spark.sparkContext
10    sc.setLogLevel("WARN")
11    # register udf
12    spark.udf.register("test_add_udf", add_udf, 'int')
13    # use udf in sql
14    spark.sql("select test_add_udf(6)").show()
15    spark.stop()

接着创建 workflow，在 Resources 上传 pyspark_udf_demo.py 文件，然后创建任务，指定 py 文件和相关版本即可。

调优原则

Flink

基本概念

Flink 是一个分布式的流处理框架，它能够对有界和无界的数据流进行高效的处理。

Flink 的核心是流处理，当然它也能支持批处理，Flink 将批处理看成是流处理的一种特殊情况，即数据流是有明确界限的，这和 Spark Streaming 的思想是刚好相反。

Flink 核心架构如下：

Flink 核心组件工作流程如下：

实践测试

Flink 快速测试使用：

1# INSTALL
2wget https://dlcdn.apache.org/flink/flink-1.20.0/flink-1.20.0-bin-scala_2.12.tgz
3tar -zxvf flink-1.20.0-bin-scala_2.12.tgz
4cd flink-1.20.0
5# TEST
6./bin/start-cluster.sh
7./bin/flink run examples/streaming/WordCount.jar
8tail tail log/flink-*-taskexecutor-*.out
9./bin/stop-cluster.sh

官方提供的两个 Flink 应用示例，可以很好地上手 Flink：

基于 DataStream API 实现欺诈检测：快速上手 State + Timer 流式处理；
基于 Table API 实现实时报表: 快速上手 Window 流式处理。

Flink 的一个重要特性就是其状态管理，Flink 为什么要参与状态管理？在 Flink 不参与管理状态的情况下，你的应用也可以使用状态，但 Flink 为其管理状态提供了一些引人注目的特性：

本地性: Flink 状态是存储在使用它的机器本地的，并且可以以内存访问速度来获取
持久性: Flink 状态是容错的，例如，它可以自动按一定的时间间隔产生 checkpoint，并且在任务失败后进行恢复
纵向可扩展性: Flink 状态可以存储在集成的 RocksDB 实例中，这种方式下可以通过增加本地磁盘来扩展空间
横向可扩展性: Flink 状态可以随着集群的扩缩容重新分布

Flink 的三个时间语义：

Event Time：是事件创建的时间。它通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink 通过时间戳分配器访问事件时间戳。
Ingestion Time：是数据进入 Flink 的时间。
Processing Time：是每一个执行基于时间操作的算子的本地系统时间，与机器相关，默认的时间属性就是 Processing Time。

Flink 在窗口的场景处理上很重要，窗口是基于 Timer 实现的。Flink 窗口操作将无界数据流分解成有界数据流聚合分析。Flink 内置窗口分配器如下：

一些常见的对应使用场景：

滚动时间窗口：每分钟页面浏览量 - TumblingEventTimeWindows.of(Time.minutes(1))
滑动时间窗口：每 10 秒钟计算前 1 分钟的页面浏览量 - SlidingEventTimeWindows.of(Time.minutes(1), Time.seconds(10))
会话窗口：每个会话的网页浏览量，其中会话之间的间隔至少为 30 分钟 - EventTimeSessionWindows.withGap(Time.minutes(30))

窗口操作的聚合类处理带来了新的问题，比如乱序/延迟。其解决方案就是 Watermark / allowLateNess / sideOutPut 这一组合拳。

Watermark 定义了什么时候不再等待更早的数据，用于处理乱序事件；
allowLateNess 是将窗口关闭时间再延迟一段时间，用于容忍迟到事件；
sideOutPut 是最后兜底操作，当指定窗口已经彻底关闭后，就会把所有过期延迟数据放到侧输出流，让用户决定如何处理。

举个例子来理解上面这几个概念。假设我们需要通过 Flink 从 Kafka 消费数据，计算每五分钟的数据。

首先列出我们知道的事情。我们知道当前实际时间所处的窗口 [window_start, window_end]，每条从 Kafka 来的数据都包含一个事件时间 event_time，我们可以设置 watermark 为 90s，从而每条数据对应的 watermark 时间就是 event_time - 90s，注意这个时间会确保 >= window_start 且左边界只会正增长。

当前窗口第一条数据出现，设事件时间为 last_event_time，计算得到当前窗口下一条数据的 event_time 范围 [last_event_time - 90s, window_end]；
然后下一条数据到来，设事件时间为 event_time：
- 如果 last_event_time - 90s <= event_time <= window_end，则落入窗口，然后根据 watermark 计算新的 event_time 范围，重复 2；
- 如果 event_time > window_end，则开启新窗口，完成旧窗口 window 聚合计算。如果 event_time - 90s <= window_end，则表明 watermark 未到，窗口保持开启，否则窗口延迟 allowLateNess 秒后关闭（不再聚合更多延迟数据）。重复 1，2；
- 如果 event_time < last_event_time - 90s，则事件发生延迟，如果旧窗口还在则落入窗口并触发旧窗口 window 聚合计算，否则放到侧输出流，重复 2。

可见，watermark 大大减少了聚合计算带来的开销，allowLateNess 在出现大量数据延迟的情况下则更有用。

最后记录一个 Task，计算每小时所有出租车司机中的最高总小费获得值，下面给出任务描述和关键代码：

The task of the exercise is to first calculate the total tips collected by each driver, hour by hour, and then from that stream, find the highest tip total in each hour.

 1public JobExecutionResult execute() throws Exception {
 2
 3    // set up streaming execution environment
 4    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
 5
 6    // start the data generator and arrange for watermarking
 7    DataStream<TaxiFare> fares =
 8            env.addSource(source)
 9                    .assignTimestampsAndWatermarks(
10                            // taxi fares are in order
11                            WatermarkStrategy.<TaxiFare>forMonotonousTimestamps()
12                                    .withTimestampAssigner(
13                                            (fare, t) -> fare.getEventTimeMillis()));
14
15    // compute tips per hour for each driver
16    DataStream<Tuple3<Long, Long, Float>> hourlyTips =
17            fares.keyBy((TaxiFare fare) -> fare.driverId)
18                    .window(TumblingEventTimeWindows.of(Time.hours(1)))
19                    .process(new AddTips());
20
21    // find the driver with the highest sum of tips for each hour
22    DataStream<Tuple3<Long, Long, Float>> hourlyMax =
23            hourlyTips.windowAll(TumblingEventTimeWindows.of(Time.hours(1))).maxBy(2);
24
25    hourlyMax.addSink(sink);
26    return env.execute("Hourly Tips");
27}

注意这里假定数据是有序的，所以采用了 WatermarkStrategy.<TaxiFare>forMonotonousTimestamps()，它将最大乱序程度设置为 0 毫秒，表示不允许有任何乱序。如果假定数据会乱序到达，则可以直接修改窗口 watermark 策略来完成。

最后可以了解一下处理函数（Process Functions）。ProcessFunction 将事件处理与 Timer，State 结合在一起，使其成为流处理应用的强大构建模块。使用 ProcessFunction 可以创建自定义的窗口操作。这里我们通过重写 KeyedProcessFunction 实现自定义窗口，使用 MapState + Timer 来处理数据，总体流程如下，具体参考flink-事件驱动应用：

设 MapState 的 key 为窗口的结束时间戳，值为该窗口的小费总和；
当窗口的第一个时间戳到达时，计算窗口结束时间戳，设置 MapState，注册回调 timer（回调时间可以设为 Watermark 到达窗口结束时间戳的实际时间）；
后续时间戳到达，如果大于 Watermark 则 update MapState，否则为延迟事件；
一个小时过去，触发 Timer，计算结果，清除当前窗口的结束时间戳 kv；
重复 2～4。

更深入地了解 Flink：

详解 Flink 容器化环境下的 OOM Killed

State

State 泛指 Flink 中有状态函数和运算符在各个元素(element)/事件(event)的处理过程中存储的数据。状态数据可以修改和查询，可以自己维护，根据自己的业务场景，保存历史数据或者中间结果到 State 中。

使用状态计算的例子：

当应用程序搜索某些事件模式时，状态将存储到目前为止遇到的事件序列。
在每分钟/小时/天聚合事件时，状态保存待处理的聚合。
当在数据点流上训练机器学习模型时，状态保持模型参数的当前版本。
当需要管理历史数据时，状态允许有效访问过去发生的事件。

无状态计算指的是数据进入 Flink 后经过算子时只需要对当前数据进行处理就能得到想要的结果；有状态计算就是需要和历史的一些状态或进行相关操作，才能计算出正确的结果。

Checkpoint 机制

Flink 是有状态的流计算处理引擎，每个算子 Operator 可能都需要记录自己的运行数据，并在接收到新流入的元素后不断更新自己的状态数据。当分布式系统引入状态计算后，为了保证计算结果的正确性（特别是对于流处理系统，不可能每次系统故障后都从头开始计算），就必然要求系统具有容错性。

Checkpoint 机制是 Flink 容错性、可靠性的基石，可以保证 Flink 集群在某个算子因为某些原因(如异常退出)出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保证应用流图状态的一致性。

Barrier 是 Flink 分布式快照的核心概念之一，称之为屏障或者数据栅栏（可以理解为快照的分界线）。Barrier 是一种特殊的内部消息，在进行 Checkpoint 的时候 Flink 会在数据流源头处周期性地注入 Barrier，这些 Barrier 会作为数据流的一部分，一起流向下游节点并且不影响正常的数据流。Barrier 的作用是将无界数据流从时间上切分成多个窗口，每个窗口对应一系列连续的快照中的一个，每个 Barrier 都带有一个快照 ID，一个 Barrier 生成之后，在这之前的数据都进入此快照，在这之后的数据则进入下一个快照。

每个需要 checkpoint 的应用在启动时，Flink 的 JobManager 为其创建一个 Checkpoint Coordinator，Checkpoint Coordinator 全权负责本应用的快照制作。如上图，Barrier-n 跟随着数据流一起流动，当算子从输入流接收到 Barrier-n 后，就会停止接收数据并对当前自身的状态做一次快照，快照完成后再将 Barrier-n 以广播的形式传给下游节点。一旦作业的 Sink 算子接收到 Barrier-n 后，会向 JobMnager 发送一个消息，确认 Barrier-n 对应的快照完成。当作业中的所有 Sink 算子都确认后，意味一次全局快照也就完成。

当一个算子有多个上游节点时，会接收到多个 Barrier，这时候需要进行 Barrier Align 对齐操作。假设一个算子有两个输入流，当算子从一个上游数据流接收到一个 Barrier-n 后，它不会立即向下游广播，而是先暂停对该数据流的处理，将到达的数据先缓存在 Input Buffer 中（因为这些数据属于下一次快照而不是当前快照，缓存数据可以不阻塞该数据流），直到从另外一个数据流中接收到 Barrier-n，才会进行快照处理并将 Barrier-n 向下游发送。

综上，Flink Checkpoint 机制的核心思想实质上是通过 Barrier 来标记触发快照的时间点和对应需要进行快照的数据集，将数据流处理和快照操作解耦开来，从而最大程度降低快照对系统性能的影响。

一致性

Flink 的一致性和 Checkpoint 机制有紧密的关系：

当不开启 Checkpoint 时，节点发生故障时可能会导致数据丢失，这就是 At-Most-Once
当开启 Checkpoint 但不进行 Barrier 对齐时，对于有多个输入流的节点如果发生故障，会导致有一部分数据可能会被处理多次，这就是 At-Least-Once
当开启 Checkpoint 并进行 Barrier 对齐时，可以保证每条数据在故障恢复时只会被重放一次，这就是 Exactly-Once

并行度

一个 Flink 程序由多个任务 task 组成（转换/算子、数据源和数据接收器）。一个 task 包括多个并行执行的实例，且每一个实例都处理 task 输入数据的一个子集。一个 task 的并行实例数被称为该 task 的并行度 (parallelism)。

Flink 提供了多种方式来设置并行度：

全局并行度: 在执行环境中设置，影响所有算子的并行度。
算子级别并行度: 为每个算子单独设置并行度。
客户端级别并行度: 在提交作业时设置并行度。

并行度和 Slot：

Slot（槽）是一个非常重要的概念，它代表了 TaskManager 上的一份固定大小的资源，一个 TaskManager 可以有多个 slot。一个 slot 可以执行一个或多个子任务，一个slot上有多个子任务时，这些子任务会共享该slot的资源。如果一个算子的并行度大于 slot 的数量，那么多个子任务会竞争 slot 资源。

反压机制

Flink 的反压策略主要分为以下几个步骤：

任务反压：当下游任务的处理速度较慢时，Flink 会检测到这种情况，并认为这是一个反压信号。此时，Flink 会将这个反压信号传递给上游任务的管理器。
调整数据生成速度：当上游任务的管理器收到反压信号后，会根据反压信号的强度来调整数据生成速度。通常情况下，反压信号越强，上游任务生成的数据量就会减少，以减轻下游任务的负担。
控制反压：Flink 还会通过一些控制机制来避免过度反压。例如，当上游任务的数据生成速度过慢时，Flink 会限制反压的强度，以避免数据积压过多。此外，Flink 还会设置一个反压阈值，当反压信号超过这个阈值时，Flink 会认为任务已经处于一个不稳定的状态，并会采取相应的措施，如调整任务并行度、暂停任务等。
恢复数据生成速度：当下游任务的处理速度恢复到正常水平时，Flink 会检测到这个变化，并逐渐增加上游任务的数据生成速度，以恢复数据流。

三种时间语义

Event Time 指的是数据流中每个元素或者每个事件自带的时间属性，一般是事件发生的时间。由于事件从发生到进入 Flink 时间算子之间有很多环节，一个较早发生的事件因为延迟可能较晚到达，因此使用 Event Time 意味着事件到达有可能是乱序的，所以使用 Watermark 通常是有必要的。

Ingestion Time 是事件到达 Flink Souce 的时间。从 Source 到下游各个算子中间可能有很多计算环节，任何一个算子的处理速度快慢可能影响到下游算子的 Processing Time。而 Ingestion Time 定义的是数据流最早进入 Flink 的时间，因此不会被算子处理速度影响。

LSM

LSM tree, short for Log-Structured-Merge Tree, is a clever algorithm design that helps us store massive amounts of data without making us wait forever to write it. It stores data in memory first, which is lightning fast. But since we can’t keep everything in memory, the LSM Tree periodically flushes data to disk.

But here’s where it gets even cooler! It organizes the data into layers of sorted structures, each with more and more compressed data. The top layer is the fastest to access but the least compressed. As the data piles up, it’s compressed and written into a new layer called an SSTable (Sorted String Table). We can decide how many layers we need and how much compression to apply, based on the type of data we’re dealing with. This trick helps us minimize disk I/O operations and make our data storage super efficient!

WRITE:

The data is first written to the in-memory layer for speedy performance.
Simultaneously, the changes are recorded in the Write-Ahead Log to ensure data integrity.
Then, at regular intervals or when the in-memory layer reaches a certain threshold, the data is flushed to disk and organized into SSTables.

READ:

Check the data at in-memory layer
Check the bloom filter that indicates whether the data might exist in a specific SSTable
Search the specified SSTable at on-disk layer

Kafka

Apache Kafka 是一个分布式的流处理平台。我所知的 Kafka 通常是作为一个消息队列的角色而存在的，在 Shopee 的大数据处理架构中，Kafka 作为 MySQL 和大数据处理框架之间的一个桥梁。 Kafka 订阅了 Binlog，产生一些列消息，让大数据处理框架进行消费。

TODO：之后会记录一些 Kafka 的原理知识和相关代码实践。

Hive

Hive 是一个构建在 Hadoop 之上的数据仓库，它可以将结构化的数据文件映射成表，并提供类 SQL 查询功能，用于查询的 SQL 语句会被转化为 MapReduce 作业，然后提交到 Hadoop 上运行。Hive 架构如下：

Hive 由内部表和外部表的概念，在导入数据到内部表，内部表数据的生命周期由 Hive 来进行管理，存在自己的数据仓库目录下。而外部表只是在元数据中存储了数据的位置。

Hive 中有分区和分桶的概念，每个表可以有一个或多个分区键，用于确定数据的存储方式。分区键的每个唯一值定义了表的一个分区。每个分区中的数据又可以基于表的某一列的散列函数的值被划分为桶。

接下来我着重记录了 HiveSQL 相关知识。

HiveSQL 在排序这一块与传统 SQL 有较大差别：

order by 是全局排序，可能性能会比较差；
sort by 进行分区内排序，往往配合 distribute by 来确定该分区都有那些数据；
distribute by 确定了数据分发的规则，满足相同条件的数据被分发到一个reducer；
cluster by 当 distribute by 和 sort by 字段相同时，可以使用 cluster by 代替 distribute by 和 sort by；
sort by limit 相当于每个 reduce 的数据 limit 之后，进行 order by 然后再 limit。

HiveSQL 支持 WITH AS 临时中间表，当我们书写一些结构相对复杂的 SQL 语句时，可能某个子查询在多个层级多个地方存在重复使用的情况，这个时候我们可以使用 WITH AS 语句将其独立出来，极大提高SQL可读性，简化 SQL。

 1-- with table_name as(子查询语句) 其他sql
 2WITH t1 AS (
 3		SELECT *
 4		FROM abc
 5	),
 6	t2 AS (
 7		SELECT *
 8		FROM efg
 9	)
10SELECT *
11FROM t1, t2;
12-- 如果定义了 with 子句，但其后没有跟 select 查询，则会报错（没有使用没关系，其后必须有 select），因此不允许单独使用。

HiveSQL 支持窗口计算。在 Hive 中，窗口函数允许你在结果集的行上进行计算，这些计算不会影响你查询的结果集的行数。

Hive 提供的窗口和分析函数可以分为聚合函数类窗口函数，分组排序类窗口函数，偏移量计算类窗口函数。语法如下：

 1-- 分析函数 
 2over(partition by 列名 order by 列名 rows between 开始位置 and 结束位置)
 3
 4-- 聚合函数类
 5count() over();
 6sum() over();
 7max() over();
 8min() over();
 9avg() over();
10
11-- 分组排序类
12row_number() over(); -- 按照排序的顺序输出窗口中的数据的行号信息
13rank() over(); -- 按照指定列进行排名，如果值相同，则排名并列，下一个排名会出现跳跃，即排名是不连续的
14dense_rank() over(); -- 相比 rank() 不会跳跃
15percent_rank() over(); -- 按百分比进行排名
16cume_dist() over(); -- 如果按升序排列，则统计：小于等于当前值的行数所占当前分区窗口总行数的比例。如果是降序排列，则统计：大于等于当前值的行数所占当前分区窗口总行数的比例
17ntile() over(); -- 用于将按指定列分组的数据按照顺序切分成 N 片，返回当前切片值
18
19-- 求偏移量类
20lead() over(); -- 用于统计窗口内往下第 n 行值
21lag() over(); -- 用于统计窗口内往上第 n 行值
22first_value() over(); -- 取分组内排序后，截止到当前行，第一个值
23last_value() over(); -- 取分组内排序后，截止到当前行，最后一个值

over() 括号内为空时，是直接进行聚合计算。
其中 partition by 列名是按指定列进行分组，进而进行聚合计算。
最后的 order by 列名是按照指定列进行排序，进而进行聚合计算。

具体用例参考这篇文章，特别详细，比如：

 1-- 按照星座分组，统计出 pv 由高到低的排名。
 2select 
 3id, client, gender,
 4row_number() over(partition by constellation order by pv desc) as rank_id
 5from temp.user_info where id <= 10;
 6
 7
 8-- 统计小于等于当前年龄的人数占总人数的比例。
 9select id, client, age,
10cume_dist() over(order by age desc) as rank_id
11from temp.user_info where id <= 10
12order by age;

HBase

HBase 是一个面向列式存储的分布式数据库，其设计思想来源于 Google 的 BigTable 论文。HBase 底层存储基于 HDFS 实现，集群的管理基于 ZooKeeper 实现。

HBase 良好的分布式架构设计为海量数据的快速存储、随机访问提供了可能，基于数据副本机制和分区机制可以轻松实现在线扩容、缩容和数据容灾，是大数据领域中 Key-Value 数据结构存储最常用的数据库方案。

HBase 的数据模型：

在 HBase 表中，一条数据拥有一个全局唯一的键(RowKey)和任意数量的列(Column)，一列或多列组成一个列族(Column Family)，同一个列族中列的数据在物理上都存储在同一个 HFile 中，这样基于列存储的数据结构有利于数据缓存和查询。

HBase 中的表是疏松地存储的，因此用户可以动态地为数据定义各种不同的列。HBase 中的数据按主键排序，同时，HBase 会将表按主键划分为多个 Region 存储在不同 Region Server 上，以完成数据的分布式存储和读取。

HBase 根据列成来存储数据，一个列族对应物理存储上的一个 HFile，列族包含多列列族在创建表的时候被指定。

通过几条操作语句了解 HBase 数据模型：

1# hbase shell
2# create '表名称', '列族名称1', '列族名称2', '列族名称N'
3create 'users', 'sex', 'info'
4# put '表名称','行名称','列族名称(：列名称)', '列值'
5put 'users', 'jack', 'sex', 'male'
6put 'users', 'jack', 'info:age', '20'

Paimon

为什么要有 Paimon？在最近开发 Shopee 订单关键指标的过程中，通过当前整个大数据计算框架，我大致明白了，具体记录如下。

首先，目前基于 Hadoop 的大数据计算体系中，如果单纯的基于 hdfs 进行 mp 计算，比如 hive，则只能实现 insert 或 insert overwrite，只能去计算 T+1 级别的数据，在计算 Shopee 订单关键指标时，就常常被用于计算一天内的订单量、成交额，这个是可以确保准确且稳定的。

还是在 Hadoop 体系内，我们希望去计算更实时的数据，比如小时、分钟级别的，可能会去采用 hudi，因为 hudi 支持 upsert。hudi upsert 支持 mor 和 cow 两种模式，而一般采用的 cow 模式 cpu 占用率较高，根据 Shopee 实际情况，hudi 常常顶不住超大数据+复杂跨国链路的压力，加上带宽相关的限制，其他团队常常反馈数据延迟过高，通过 hudi 计算小时级别的数据常常不可靠，分钟级别的就更不必说了。目前，团队将向 paimon 迁移，后文继续说明。

如果跳出 Hadoop 体系，那就是使用 flink 去计算实时数据，官方说是支持 ms 级别，但在超大数据复杂链路的情况下，一般是 s 级别，在计算 Shopee 订单关键指标时，我们采用 flink 来计算分钟级别的数据。只是在有些情况下，flink 可能不够稳定，需要加 dqc，通过离线数据去对账更新实时的数据。

为更好地计算小时级别的数据，可以说是 T+0 数据(而一般 3-5 小时到 1 天级别的数据称为 T+1 数据)，也就是更低延迟、更低成本地去计算更细粒度时间级别的数据，目前 Paimon 是一种可能的解决方案。

Apache Paimon 是一个湖格式，结合 Flink 及 Spark 构建流批处理的实时湖仓一体架构。Paimon 创新的结合湖格式与 LSM 技术，给数据湖带来了实时流更新以及完整的流处理能力。通常的实现方式是采用 Flink 实时计算相关数据写入 Paimon，这样利用了 Flink 的低延迟特性，也实现了对 hdfs 的 upsert 操作。

Paimon 是当今大数据前沿技术，这里有具体用法入门：Paimon 快速开始：基本功能

后续会在项目中对 Paimon 进行具体实践，到时将技术设计同步到此处。

Hudi

Hudi（Hadoop Upserts Deletes and Incrementals）是一个用于跟踪大规模数据集的变化的数据管理库。

Hudi 通过提供增量数据存储和查询能力，支持数据的插入、更新和删除操作。Hudi 还提供了时间旅行功能，可以让用户查询数据在不同时间点的快照。

Hudi 适用于数据湖、实时分析和流处理场景。

和 Hive 的区别：

ClickHouse

TODO

MPP

MPP（Massively Parallel Processing）架构数据库是一种分布式数据库架构，它将数据分布到多个节点上，并利用这些节点的计算资源并行处理数据。MPP 数据库通常用于处理大规模数据集，能够提供更高的性能和扩展性。MPP 常见的应用场景包括数据分析、实时报表、数据仓库等。

MPP 架构数据库通常由多个节点组成，每个节点都具有独立的计算资源和存储空间。数据被分区存储在不同的节点上，每个节点负责处理自己所存储的数据。当进行查询时，MPP 数据库可以并行处理多个节点上的数据，从而提高查询性能。

MPP 应该与 Hadoop 进行比较，mpp 相当于找一群和自己能力差不多的任一起做事，每个人做的事情是一致的。而 Hadoop 就是找一群能力差一些的人，但只需要他们每个人只做一部分工作。

StarRocks

StarRocks 采用 MPP (Massively Parallel Processing) 分布式执行框架。

在 MPP 执行框架中，一条查询请求会被拆分成多个物理计算单元，在多机并行执行。每个执行节点拥有独享的资源（CPU、内存）。MPP 执行框架能够使得单个查询请求可以充分利用所有执行节点的资源，所以单个查询的性能可以随着集群的水平扩展而不断提升。

BitMap

Bit 即比特，是目前计算机系统里数据的最小单位。BitMap 可以理解为通过一个 bit 数组来存储特定数据的一种数据结构，由于 bit 是数据的最小单位，所以这种数据结构往往是非常节省存储空间。

比如一个公司有 8 个员工，现在需要记录公司的考勤记录，可以构造一个 8bit 的数组，将这 8 个员工跟员工号分别映射到这 8 个位置，如果当天正常考勤了，则将对应的这个位置置为 1，否则置为 0，这样可以每天采用恒定的 1 个byte即可保存当天的考勤记录，大量节省了存储空间。

除了节省存储空间，BitMap 结构的另一个更重要的特点，就是很方便通过位的运算（AND,OR,XOR,NOT），高效的对多个 BitMap 数据进行处理。比如上边的考勤的例子里，如果想知道那个员工最近两天都没来，只要将昨天的 BitMap 和今天的 BitMap 做一个按位的 OR 计算，然后检查那些位置是 0，就可以得到最近两天都没来的员工的数据了。

Blogs

时间与精神的小屋
阿里 E-MapReduce
Shopee 技术团队(微信公众号)

Reference

SpringBoot Starter 开发指南

akynazh@gmail.com (zhihang) — Sun, 25 Feb 2024 21:24:58 +0800

前言

SpringBoot 不同版本开发和使用 Starter 有区别，这里记录下开发的一些前置知识、实现步骤和一些遇到的问题。

SpringBoot 不同版本自动装配的原理及细微区别

开发 Starter 很重要的一个目的就是自动装配，而不同版本的 SpringBoot 在装配细节上有着区别。

SpringBoot 通过 @EnableAutoConfiguration 开启自动装配，通过 SpringFactoriesLoader 或 ImportCandidates 加载 META-INF 下配置文件（不同版本有区别）中的自动配置类实现自动装配，自动配置类其实就是通过 @Conditional 按需加载的配置类，想要其生效必须引入 spring-boot-starter-xxx 包（官方 starter）或者 xxx-spring-boot-starter（第三方 starter）实现起步依赖。

不同版本具体自动装配的方式有所区别，可通过阅读源码中 org.springframework.boot.autoconfigure.AutoConfigurationImportSelector#getCandidateConfigurations 找到区别：

2.6 最后一个版本 2.6.15 通过 SpringFactoriesLoader 加载 META-INF/spring.factories 完成自动装配：

1// 2.6.15
2protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
3    List<String> configurations = SpringFactoriesLoader.loadFactoryNames(this.getSpringFactoriesLoaderFactoryClass(), this.getBeanClassLoader());
4    Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring.factories. If you are using a custom packaging, make sure that file is correct.");
5    return configurations;
6}

从 2.7.0 开始，额外通过 ImportCandidates 加载 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 找到添加了 @AutoConfiguration 注解的类完成装配，这时还是保证了向下兼容：

1// 2.7.0
2protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
3    List<String> configurations = new ArrayList(SpringFactoriesLoader.loadFactoryNames(this.getSpringFactoriesLoaderFactoryClass(), this.getBeanClassLoader()));
4    ImportCandidates.load(AutoConfiguration.class, this.getBeanClassLoader()).forEach(configurations::add);
5    Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring.factories nor in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. If you are using a custom packaging, make sure that file is correct.");
6    return configurations;
7}

从 3.0.0 大版本开始，不在使用 SpringFactoriesLoader，需要特别注意：

1// 3.0.0
2protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
3    List<String> configurations = ImportCandidates.load(AutoConfiguration.class, this.getBeanClassLoader()).getCandidates();
4    Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. If you are using a custom packaging, make sure that file is correct.");
5    return configurations;
6}

以下用 A 指代 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，B 指代 spring.factories，总结版本间的一些区别如下，开发和使用 Starter 时需要特别注意：

3.0.0 及以上版本自动装配类通过 A 配置，而 2.6.15 及以下版本通过 B 完成，2.7.0 以上到 3.0.0 之前 AB 均可；
A 配置文件为每行一个 class 的格式，B 为 org.springframework.boot.autoconfigure.EnableAutoConfiguration=class1, class2, ... 的格式
3.0.0 及以上版本自动装配类需要添加 @AutoConfiguration 注解，而 2.6.15 及以下版本对应是添加 @Configuration，2.7.0 以上到 3.0.0 则根据使用情况而定即可

至于为什么将自动配置类文件进行更改？可以从 Github 上的这个 issue 找到答案：Move away from spring.factories for auto-configurations，阅读后可以总结一下，就是为了避免在配置文件 spring.factories 中手动添加类，通过 @AutoConfiguration 注解自动完成配置，而具体实现是要让编译器扫描添加了 @AutoConfiguration 的类并自动生成 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件，但是这个功能还未实现，至少在 2024.2 最新版本 3.2.2 还未实现，可通过这个 issue 追踪进展。

不同版本 Starter 使用上需要注意的地方

了解前文对于原理的解释后，就可以总结出一些开发 starter 时需要注意的地方了。

如果项目使用了 SpringBoot 3.X，但是调用了一个第三方的通过 2.X 开发的 Starter，且是通过 spring.factories 加载类，那么将无法完成自动装配，需要手动配置相关 bean 完成，比如使用 rocketmq-spring-boot-starter-2.2.3 将无法自动装配 RocketMQTemplate，通过如下代码解决即可：

 1@Configuration
 2public class RocketMQConfig {
 3    @Value("${rocketmq.producer.group}")
 4    private String producerGroup;
 5    @Value("${rocketmq.name-server}")
 6    private String namesrvAddr;
 7
 8    @Bean(name = "rocketMQTemplate")
 9    public RocketMQTemplate rocketMQTemplate() {
10        RocketMQTemplate template = new RocketMQTemplate();
11        DefaultMQProducer producer = new DefaultMQProducer();
12        producer.setProducerGroup(producerGroup);
13        producer.setNamesrvAddr(namesrvAddr);
14        template.setProducer(producer);
15        return template;
16    }
17}

通过 @Bean 和 @Configuration 完成 RocketMQTemplate 的注入。

开发一个适应性更好的 Starter

为了让所有版本都能自动完成自动装配，我们可以同时适应两种自动装配方法。注意 @AutoConfiguration 也包含了 @Configuration 注解，所以可以很简单的完成适应，只是需要多准备一份配置文件。

下面使用 3.2.2 版本的 SpringBoot 开发一个模拟式的邮件服务 Starter：

新建项目 email-spring-boot

编辑 pom.xml:

 1<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 2         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 3    <modelVersion>4.0.0</modelVersion>
 4
 5    <groupId>xdu.zh</groupId>
 6    <artifactId>email-spring-boot</artifactId>
 7    <version>0.0.1</version>
 8    <packaging>pom</packaging>
 9
10    <modules>
11        <module>email-spring-boot-autoconfigure</module>
12        <module>email-spring-boot-starter</module>
13    </modules>
14</project>

新建子模块 email-spring-boot-autoconfigure

编辑 pom.xml:

 1<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 2         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 3    <modelVersion>4.0.0</modelVersion>
 4    <parent>
 5        <groupId>xdu.zh</groupId>
 6        <artifactId>email-spring-boot</artifactId>
 7        <version>0.0.1</version>
 8    </parent>
 9    <artifactId>email-spring-boot-autoconfigure</artifactId>
10    <version>0.0.1</version>
11    <packaging>jar</packaging>
12
13    <dependencyManagement>
14        <dependencies>
15            <dependency>
16                <groupId>org.springframework.boot</groupId>
17                <artifactId>spring-boot-dependencies</artifactId>
18                <version>3.2.2</version>
19                <type>pom</type>
20                <scope>import</scope>
21            </dependency>
22        </dependencies>
23    </dependencyManagement>
24
25    <dependencies>
26        <!-- Spring Boot自动配置依赖 -->
27        <dependency>
28            <groupId>org.springframework.boot</groupId>
29            <artifactId>spring-boot-autoconfigure</artifactId>
30        </dependency>
31        <!-- 元数据配置处理器 -->
32        <dependency>
33            <groupId>org.springframework.boot</groupId>
34            <artifactId>spring-boot-configuration-processor</artifactId>
35            <optional>true</optional>
36        </dependency>
37    </dependencies>
38</project>

通过 EmailProperties 定义一些自动配置项，指定配置前缀为 email.service：

 1@ConfigurationProperties("email.service")
 2public class EmailProperties {
 3    private boolean enable = true;
 4    private String host;
 5    private Integer port;
 6    private String name;
 7    private String password;
 8    
 9    // getter and setter...
10}

具体邮件服务实现：

 1public class EmailService {
 2    private final EmailProperties emailProperties;
 3
 4    public EmailService(EmailProperties emailProperties) {
 5        this.emailProperties = emailProperties;
 6    }
 7
 8    public void send(String content) {
 9        System.out.println("开始发送邮件:");
10        System.out.println(String.format("基本信息: host: %s, port: %s", emailProperties.getHost(), emailProperties.getPort()));
11        System.out.println("发送内容: " + content);
12        System.out.println("发送成功!");
13    }
14}

实现自动配置，当存在 EmailService.class 且 email.service 为 true 且容器中不存在 EmailService 这个 bean 时自动装配 EmailService：

 1/**
 2 * @author zh
 3 * @date 2024/2/24
 4 */
 5@AutoConfiguration
 6@ConditionalOnClass(EmailService.class)
 7@EnableConfigurationProperties(value = EmailProperties.class)
 8public class EmailAutoConfiguration {
 9    @Bean
10    @ConditionalOnMissingBean
11    @ConditionalOnProperty(prefix = "email.service", value = "enable", havingValue = "true")
12    public EmailService mailService(EmailProperties mailProperties) {
13        return new EmailService(mailProperties);
14    }
15}

编辑 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports:

1xdu.zh.EmailAutoConfiguration

编辑 META-INF/spring.factories:

1org.springframework.boot.autoconfigure.EnableAutoConfiguration=xdu.zh.EmailAutoConfiguration

新建子模块 email-spring-boot-starter

编辑 pom.xml:

 1<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 2         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 3    <modelVersion>4.0.0</modelVersion>
 4    <parent>
 5        <groupId>xdu.zh</groupId>
 6        <artifactId>email-spring-boot</artifactId>
 7        <version>0.0.1</version>
 8    </parent>
 9    <artifactId>email-spring-boot-starter</artifactId>
10    <packaging>jar</packaging>
11
12    <dependencies>
13        <dependency>
14            <groupId>xdu.zh</groupId>
15            <artifactId>email-spring-boot-autoconfigure</artifactId>
16            <version>0.0.1</version>
17        </dependency>
18    </dependencies>
19</project>

该模块只完成封装，包含 email-spring-boot-autoconfigure 模块，以及其它一些可能的依赖项（可选），调用 starter 时只需引入此依赖。

进行多版本功能测试

为进行更实际的测试，在此之前将 email-spring-boot 进行发布，在 IDEA 内 maven 命令行面板通过 mvn install 命令安装到本地 maven 仓库。

接着新建测试项目，编辑 pom.xml：

 1<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 2         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 3    <modelVersion>4.0.0</modelVersion>
 4
 5    <groupId>xdu.test</groupId>
 6    <artifactId>test</artifactId>
 7    <version>0.0.1</version>
 8    <packaging>jar</packaging>
 9
10    <parent>
11        <groupId>org.springframework.boot</groupId>
12        <artifactId>spring-boot-starter-parent</artifactId>
13<!--        <version>3.0.0</version>-->
14<!--        <version>2.7.0</version>-->
15        <version>2.6.15</version>
16        <relativePath/>
17    </parent>
18
19    <dependencies>
20        <dependency>
21            <groupId>xdu.zh</groupId>
22            <artifactId>email-spring-boot-starter</artifactId>
23            <version>0.0.1</version>
24        </dependency>
25    </dependencies>
26</project>

进行一些必要配置：

1# resources/application.properties
2email.service.enable=true
3email.service.host=mail.qq.com
4email.service.port=965
5email.service.name=admin
6email.service.password=admin

新建 Spring 应用，注入 EmailService，执行 send 方法进行功能测试：

 1@SpringBootApplication
 2public class EmailStarterTestApplication implements CommandLineRunner {
 3    @Autowired
 4    private EmailService emailService;
 5
 6    public static void main(String[] args) {
 7        SpringApplication.run(EmailStarterTestApplication.class, args);
 8    }
 9
10    @Override
11    public void run(String... args) throws Exception {
12        emailService.send("test");
13    }
14}

测试结果：

1...
2开始发送邮件:
3基本信息: host: mail.qq.com, port: 965
4发送内容: test
5发送成功!

再分别将 SpringBoot 版本改为 2.7.0、3.0.0，测试均通过。

参考来源

搭建私人代理服务简易教程

akynazh@gmail.com (zhihang) — Mon, 12 Feb 2024 21:52:12 +0800

一、购买国外可用服务器

从 ISP 服务商购买 VPS，下单前先测试服务器附带的公网 IP 是否被封(本地不要挂代理)：

1ping $ip
2# 或者使用 traceroute，更加详细:（mac: traceroute $ip）
3# tracert $ip

另外也推荐使用 https://ping.pe 测试，可进行多地区测试，更为全面。访问 https://ping.pe/$ip 以测试 IP，访问 https://tcp.ping.pe/$ip:$port 以测试具体端口。

完成购买后，即可开始搭建代理服务，下面记录了两种代理方式，SSH 隧道道理和加密协议代理。

二、配置 SSH 隧道代理

通过 ssh 动态转发的能力，可以在本地建立一个 socks 协议的代理，它可通过 ssh 隧道转发请求到代理服务器。这应该是较古老而简便的代理方式，只需在本地进行操作，便捷但稳定性一般。通过以下一条简单的命令即可建立代理：

1ssh -D 1080 -qCN $user@$ip
2
3# -D：本机SOCKS 服务端口
4# -q : quiet 模式，没有输出
5# -C : 数据压缩，可以节约一些带宽
6# -N : 不运行远程命令，只做端口转发

为了让代理服务在后台长久运行，可通过 autossh 完成，通过 brew, apt 等源都可安装 autossh。

1# brew install autossh
2autossh -f -M 1088 -D 1080 -qCN $user@$ip
3# -f 后台运行
4# -M 监控服务端口

完成后即可进行测试，如下是一些简单的用法：

1# 使用代理登录其他服务器
2ssh -o ProxyCommand='/usr/bin/nc -X 5 -x 127.0.0.1:1080 %h %p' $user1@$ip1 -v
3
4# 使用代理访问 web
5export ALL_PROXY=socks5h://127.0.0.1:1080
6curl https://google.com -v

注意这里 ALL_PROXY 变量使用了 socks5h，本机实测通过 socks5 无法顺利请求 google。

socks5 通过本地 dns 解析目标主机域名
socks5h 通过代理服务器 dns 解析目标主机域名

另外可以通过一些软件实现全局代理或者规则分流，比如 QuantumultX, V2rayN 等支持 socks 协议的客户端。以下是 QuantumultX 配置：

1[server_local]
2socks5=127.0.0.1:1080, fast-open=false, udp-relay=false, tag=socks5-ssh

三、配置加密协议代理

现在用的多的协议应该是 Vmess、Shadowsocks、Trojan 和 Vless，个人建议使用 Vmess 即可，不推荐 Shadowsocks。VMess 协议是由 V2Ray 开发者原创并使用于 V2Ray 的加密传输协议。V2Ray 是一个代理软件，支持多种协议，它存在于客户端和服务端中，每个端均存在一个入口点和出口点，用于流量转发。安装代理服务，首先需要安装服务端，客户端进行简单对接即可。如下是一个基本的数据包流向：

1{本地请求目标网站} <--(socks)--> {V2Ray 客户端 inbound <-> V2Ray 客户端 outbound} <--(VMess)-->  {V2Ray 服务器 inbound <-> V2Ray 服务器 outbound} <--(Freedom)--> {目标网站}

下文以 Vmess 为例进行安装，将直接使用 V2Ray 脚本安装服务端 V2Ray 并进行自动化配置，该脚本还支持其它多种协议且易于装卸更新，如需深入了解原理或者手动安装，可阅读 V2Ray 新白话文指南。

首先登上服务器，然后运行如下命令进行安装：

1bash <(wget -qO- -o- https://git.io/v2ray.sh)

完成后即可通过 v2ray 命令交互式的添加各种协议的代理。默认安装了 Vmess 协议代理，控制台将打印出配置信息。具体配置和可执行文件位于 /etc/v2ray 目录下。如不放心，可参考 Vmess 配置指南进行操作。

配置信息中最重要的就是用户 id，是一串用于认证流量的 uuid，据此和其它一些配置信息可以开始配置客户端 V2Ray。不过更方便的方式是使用配置信息中脚本为我们生成的 base64 加密 url，该 url 通过解析可以取得用户 id，协议信息，地址信息等服务器代理信息。将该 url 导入本地支持解析加密 url 的 V2Ray 客户端即可一键完成配置。

完成到这里就差不多了，但是有域名的话推荐外加 TLS，比如配置 Vmess + WebSocket + TLS 代理：

购买一个域名，并添加(子)域名解析到服务器 ip
服务器运行 v2ray add ws $domain, 将会自动通过 Caddy 配置证书且安装代理服务

该脚本使用了 Caddy 作为服务管理工具（类似于 Nginx）。如果服务器本身使用了 Nginx，可以通过 v2ray no-auto-tls 手动配置 Nginx 而不是通过 Caddy，运行后控制台将打印代理路径和端口，用于配置 Nginx 反向代理。如下是一个参考配置：

 1server {
 2    listen 443 ssl http2;
 3    listen [::]:443 ssl http2;
 4    server_name $domain;
 5
 6    ssl_certificate /etc/letsencrypt/live/$domain/fullchain.pem;
 7    ssl_certificate_key /etc/letsencrypt/live/$domain/privkey.pem;
 8    ssl_protocols TLSv1.2 TLSv1.3;
 9    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
10    
11    location /$path {
12        if ($http_upgrade != "websocket") {
13            return 404;
14        }
15        proxy_pass http://127.0.0.1:$port;
16        proxy_redirect off;
17        proxy_http_version 1.1;
18        proxy_set_header Upgrade $http_upgrade;
19        proxy_set_header Connection "upgrade";
20        proxy_set_header Host $host;
21        proxy_set_header X-Real-IP $remote_addr;
22        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
23        proxy_read_timeout 5d;
24    }
25}

将 $domain, $path, $port 分别替换为域名、代理路径、代理端口即可。

四、客户端代理配置

完成代理服务的搭建后，即可在客户端中配置代理服务器。

对于 V2Ray 客户端选择，只要支持对应加密协议即可，比如 Windows 上的 V2rayN，MacOS 上的 QuantumultX，它们本质上都是内置了 V2Ray 的图形化界面软件，支持一键导入且可以方便完成其它配置（一些推荐的客户端）。

如果选择手动配置 V2Ray，则需要手动编辑配置文件，比较麻烦但可以进行更多定制化操作。在 Windows 和 macOS 中，配置文件通常是 V2Ray 同目录下的 config.json 文件，而在 Linux 中，配置文件通常位于 /usr/local/etc/v2ray/config.json 文件，这里给出我的配置（更多信息具体可参考 Vmess 配置指南）：

 1// /usr/local/etc/v2ray/config.json                                
 2{
 3  "log": {
 4    "loglevel": "info",
 5    "error": "",
 6    "access": ""
 7  },
 8  "inbounds": [
 9    {
10      "settings": {
11        "udp": false,
12        "auth": "noauth"
13      },
14      "protocol": "socks",
15      "listen": "127.0.0.1",
16      "port": "7891"
17    },
18    {
19      "settings": {
20        "timeout": 360
21      },
22      "protocol": "http",
23      "port": "7890",
24      "listen": "127.0.0.1"
25    }
26  ],
27  "outbounds": [
28    {
29      "streamSettings": {
30        "wsSettings": {
31          "headers": {
32            "host": "zhihang.org"
33          },
34          "path": "/{proxy_uuid}"
35        },
36        "tlsSettings": {
37          "serverName": "zhihang.org",
38          "allowInsecure": true
39        },
40        "security": "tls",
41        "network": "ws"
42      },
43      "mux": {
44        "concurrency": 8,
45        "enabled": false
46      },
47      "settings": {
48        "vnext": [
49          {
50            "users": [
51              {
52                "id": "{proxy_uuid}",
53                "level": 0,
54                "alterId": 0,
55                "security": "auto"
56              }
57            ],
58            "address": "zhihang.org",
59            "port": 443
60          }
61        ]
62      },
63      "tag": "proxy",
64      "protocol": "vmess"
65    },
66    {
67      "protocol": "freedom",
68      "tag": "direct",
69      "settings": {
70        "userLevel": 0,
71        "domainStrategy": "UseIP"
72      }
73    },
74    {
75      "settings": {
76        "response": {
77          "type": "none"
78        }
79      },
80      "protocol": "blackhole",
81      "tag": "block"
82    }
83  ],
84  "dns": {},
85  "routing": {
86    "rules": [
87      {
88        "type": "field",
89        "ip": [
90          "geoip:private",
91          "geoip:cn"
92        ],
93        "outboundTag": "direct"
94      }
95    ]
96  },
97  "transport": {}
98}

将 {proxy_uuid} 替换为自己代理认证的 uuid，代理服务将跑在 http(7890) 和 socks(7891) 端口。

最后附上 Linux 上的 V2ray 客户端安装和启动方法：

 1# 如果服务器能直连 Github:
 2# bash <(curl -L https://raw.githubusercontent.com/v2fly/fhs-install-v2ray/master/install-release.sh)
 3
 4# 如果服务器不能直连 Github 则在其它能连的机器手动下载后上传安装
 5# https://github.com/v2fly/fhs-install-v2ray
 6wget https://github.com/v2fly/v2ray-core/releases/download/v5.29.3/v2ray-linux-64.zip
 7mkdir -p /usr/local/etc/v2ray
 8unzip v2ray-linux-64.zip -d /usr/local/etc/v2ray
 9echo "export PATH=$PATH:/usr/local/etc/v2ray" >> ~/.zprofile && source ~/.zprofile
10# v2ray run
11nohup v2ray run >/dev/null 2>&1 &

五、服务器被封的可能解决方法

1、更换 IP 或端口

ip 被封：需要前往 vps 服务商更换服务器 ip 并重新生成配置
端口被封：通过修改配置更换端口即可

如何判断 ip 还是端口被封了：

ping $ip or tracert $ip or https://ping.pe/$ip -> 不通 -> ip 被封
telnet $ip $port or https://tcp.ping.pe/$ip:$port -> 不通 -> 端口被封

2、通过 CDN 中转流量

该方法适用于本身已经外加 WebSocket 的代理服务，如果不支持需要先进行安装，另外本方法还需要有一个域名指向服务器 ip。

WebSocket 是一种新的通讯协议，支持在单个 TCP 连接上进行双向数据传输。如果代理服务不含 WebSocket 则无法配合 CDN 使用，同时 CDN 本身也需要支持 WebSocket(CloudFlare CDN 支持，建议使用)。

CDN 一般情况下将任意选择靠近你的可用节点来中转你的流量到达被封服务器，使用它来中转流量通常可行，但可能导致速度下降。通过 cloudflare 可以很简单地完成配置：

将原域名服务商的 dns 服务器地址改为 cloudflare 提供的地址(如原服务商为 cloudflare 则忽略此步)
在 SSL/TLS 处将加密模式选为"完全"
在 cloudflare 添加(子)域名解析到被封 ip，代理状态选为已代理，即走让请求 cdn

六、测试网速

Op1. 服务器测试：

在服务器执行以下多地网速测试脚本：

1curl -Lso- https://raw.githubusercontent.com/wn789/Superspeed/master/superbench.sh | bash

Op2. 本地挂全局代理测试：

访问 speedtest，点击 GO 开始测试。

七、解锁更多地区

上述代理可以满足我 99% 的需求，但只限于一个地区。如果要解锁更多地区，通常我们可以购买按量付费的机场节点来实现。不过如果为了省钱，也可以通过一些国外的云服务商实现，比如 BrightData。可以利用 BrightData 强大的 ISP Proxies 来构建 HTTP 代理，效果不错，以下是大致的步骤：

首先开一个 BrightData 的 ISP Proxies，在配置中选择按 ip 付费，选择需要的 region，有几个 region 就至少配几个 ip。复制得到的 host、username 和 password，然后即可配置 http 代理，以 quantumultx 为例：

1[server_local]
2http=brd.superproxy.io:22225, username=$username, password=$password, fast-open=false, udp-relay=false, tag=HTTP-JP

这样就完成了，是不是很简单？注意这里有个坑，因为 BrightData 的 ISP Proxies 不能代理 Google(可以用 BrightData 的 SERP 来弥补)，而代理软件使用 Google 作为延迟测试，所以导致我以为配置有问题，其实直接更改延迟测试的 url 即可：

1[general]
2server_check_url =http://www.apple.com/library/test/success.html

再以 Python Requests 请求为例，使用 HTTP 代理只需提供代理地址即可：

1requests.get(url="xxx", proxies={
2    "http": "http://$username:$password@brd.superproxy.io:22225",
3    "https": "http://$username:$password@brd.superproxy.io:22225"
4})

区别之前的代理搭建方式，这样优点是不用买服务器，更方便和灵活，但缺点是可能不够稳定。不过，和之前的代理方式结合起来用，在稳定的基础上，实现了更灵活的代理，解锁了更多网站和功能，也更便于开发者集成到自己的应用中，两者结合，真的实现了我理想中的个人代理服务！

参考文章：

消息队列重要知识整理

akynazh@gmail.com (zhihang) — Mon, 12 Feb 2024 01:49:02 +0800

使用消息队列的目的

解耦：降低模块之间耦合度，提高业务灵活度。
异步：异步地执行一系列互不影响的操作，降低执行所需时间。
削峰：防止高并发场景下大量数据操作直接访问数据库，导致系统不可用。

消息队列的高可用性

保证高可用需要分消息队列选型来确定，相关重要文章如下：

RabbitMQ - 镜像集群模式

跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论是元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。

Kafka - 主从集群模式

Kafka 由多个 broker 组成，每个 broker 是一个节点。创建一个 topic，这个 topic 根据 key(也可以是随机) 可划分为多个 partition，每个 broker 都存有所有的 partition。对于每个 key 对应的多个 partition，其中一个 broker 下的 partition 会被选为 leader，其他 partition 作为 follower。

任何一个 partition 都可用于读，写则只作用于 leader。在正常情况下，任何一个 broker 都可以得到利用，因为每个主题的某个 key 对应的 leader partition 可能存在于任一 broker 中。而由于每个 broker 都存了所有 partition 数据，当出现故障则进行选举，调整 leader-follower 关系即可。

RocketMQ - 主从集群模式

Master（主节点）可以进行读和写操作，Slave（从节点）只可以读，不进行写操作。RocketMQ 提供两种数据同步模式：

异步模式：每个 Master 配置一个 Slave，有多组 Master-Slave，HA 采用异步复制方式，主备有短暂消息延迟（毫秒级）。
同步模式：每个 Master 配置一个 Slave，有多组 Master-Slave，HA 采用同步双写方式，即只有主备都写成功，才向应用返回成功。

消费如何做到幂等性

从源头角度解决，就要确保不重复消费某条消息，从结果角度解决，就要确保重复消费后对实际业务没有任何影响。

针对这两个角度，有两种解决方案：

状态判断法：消费者消费数据后把消费数据记录在 redis 中，比如设定一个可唯一确定该条消息的全局 ID，下次消费时先到 redis 中查看是否存在该消息，存在则表示消息已经消费过，直接丢弃消息。
业务判断法：通常数据消费后都需要插入到数据库中，使用数据库的唯一性约束防止重复消费。每次消费直接尝试插入数据，如果提示唯一性字段重复，则直接丢失消息。

消息的可靠性传输

开启确认模式

消息传输过程中，在生产者、消息队列存储端、消费者端三个点都可能发生丢失。且对于不同的消息队列，需要进行不同的考虑。具体可以参考文章：

Kafka 通过如下手段确保消息不丢失：

数据持久化：日志写入磁盘（log.dirs）。
多副本存储：ISR 机制（同步副本）。
生产者 acks=all 确保消息持久化。
消费者手动提交 Offset。

总结地讲，我们可以从消息可能丢失的三个地方入手，一般而言对于生产者和消费者端，都要开启确认模式，以 ACK 的方式来确认消息是否被成功生产或消费，注意是要进行手动的 ACK 而不是自动 ACK。对于消息队列存储端，需要关注磁盘，要开启消息的持久化，同时可以采用同步刷盘的方式确保消息被顺利存入。

消息消费的顺序性

参考文章：如何保证消息的顺序性？

总结如下，对于 RabbitMQ 和 RocketMQ，将同一事务的消息顺序存入同一队列，且该队列绑定给一个消费者进行消费即可。对于 Kafka，由于一个 topic 下同一个 partition 中的消息是有序的，将同一事务的消息顺序存入一个 partition，由一个消费者进行消费即可。

最后对于消费者端可能存在的多线程消费方式，只需要一个事务中的消息被一个线程处理即可，可以在线程处理前增加个内存队列，每个线程只负责处理其中一个内存队列的消息，同一个事务中的消息发送到同一个内存队列中即可。

消息积压问题的处理

水平扩展消费者：消费者数量增多，则可以并行提升消息消费的速度，从而避免消息积压的问题。
优化消费者处理速度：提升消费者的消费速度也可以避免消息积压的问题，它的解决方案有：
- 优化消费者处理消息的逻辑，减少不必要的计算和 I/O 操作。
- 对于可以并行处理的任务，使用多线程或异步处理来提高吞吐量。
限流生产者和使用背压机制：
- 在生产者端实施限流策略，确保消息产生的速度不会超过系统的处理能力。
- 使用背压机制，即当消息队列达到某个阈值时，通知生产者降低发送速率或暂停发送。
使用死信队列：在消费者处理消息出现失败或超时的情况下，加入消息重试机制或将异常消息放入死信队列，避免异常消息一直占用队列资源。
监控和告警：设置合理的告警阈值，当消息积压达到一定程度时及时发出告警，以便快速响应和处理。

RocketMQ 消费状态

PushConsumer 有如下五种消费状态：

Ready：已就绪状态。消息在 Apache RocketMQ 服务端已就绪，可以被消费者消费。
Inflight：处理中状态。消息被消费者客户端获取，处于消费中还未返回消费结果的状态。
WaitingRetry：待重试状态，PushConsumer 独有的状态。当消费者消息处理失败或消费超时，会触发消费重试逻辑判断。如果当前重试次数未达到最大次数，则该消息变为待重试状态，经过重试间隔后，消息将重新变为已就绪状态可被重新消费。多次重试之间，可通过重试间隔进行延长，防止无效高频的失败。
Commit：提交状态。消费成功的状态，消费者返回成功响应即可结束消息的状态机。
DLQ：死信状态。消费逻辑的最终兜底机制，若消息一直处理失败并不断进行重试，直到超过最大重试次数还未成功，此时消息不会再重试，会被投递至死信队列。可以通过消费死信队列的消息进行业务恢复。

和 PushConsumer 消费重试策略不同的是，SimpleConsumer 消费者的重试间隔是预分配的，每次获取消息时，消费者会在调用 API 时设置一个不可见时间参数 InvisibleDuration，即消息的最大处理时长。若消息消费失败则触发重试，不需要设置下一次重试的时间间隔，直接复用不可见时间参数的取值。

Kafka 消费策略

latest 和 earliest 区别

earliest 当各分区下有已提交的 offset 时，从提交的 offset 开始消费；无提交的 offset 时，从头开始消费
latest 当各分区下有已提交的 offset 时，从提交的 offset 开始消费；无提交的 offset 时，消费新产生的该分区下的数据

Reference

RSSHub 开发者食用指南

akynazh@gmail.com (zhihang) — Thu, 21 Dec 2023 10:47:06 +0800

注：由于 RSSHub 已经对整个项目进行了重构，本篇文档所介绍的开发流程不再适用于最新版本的 RSSHub。重构后的 RSSHub 完全使用 TS 进行开发，步骤更加清晰简洁，且官方提供的开发文档很详细，具体可参考官方开发文档。如果你还使用着未重构的老版本 RSSHub，则可以考虑参考本文。—— 2024.4.22 更新

前言

最近写了几个 RSSHub 的路由，由于官方的开发步骤较为杂乱，这里提供一个简易的开发步骤，最后还记录了手动配置部署的过程。

下面以开发今日热榜的榜单路由为例进行介绍。

下载安装 RSSHub

1git clone git@github.com:DIYgod/RSSHub.git && cd RSSHub
2pnpm i # npm install -g pnpm
3pnpm run dev # localhost:1200

本文中基本都是用 pnpm 进行操作（pnpm 是新一代包管理器，它解决了 npm 幻影依赖和分身问题并较好地解决了依赖包复用问题，实现了依赖包高效快速的安装），其他操作方式详见官方文档。打开浏览器访问 localhost:1200 即可看到 RSSHub index 页面。

接着在 lib/v2 下开始开发路由，一个文件夹对应一个域，这里创建文件夹 “tophub” 即可。

定义路由规则

首先要分析网站结构，今日热榜一个榜单对应一个唯一的 id，那么可以将这个 id 作为匹配对象：

1// router.js
2module.exports = (router) => {
3    router.get('/list/:id', require('./list'));
4};

这里生成了一个路由规则，用户可通过 /tophub/list/xxxxx 这样的路由来生成 rss，通过同一目录下的 list.js 完成具体抓取和生成逻辑。

定义抓取和生成逻辑

首先引用下依赖包如下：

1// list.js
2const got = require('@/utils/got');
3const cheerio = require('cheerio');
4const config = require('@/config').value;
5const path = require('path');
6const { art } = require('@/utils/render');

got：用于发起 http 请求
cheerio：一个为服务器 jQuery 实现，可方便地解析页面
config：用于读取配置文件，经过分析发现爬取需使用 cookie，所以需要用户手动配置 cookie
path：路径生成工具
art：一个模板引擎（art-template），由于生成榜单需要定制 html 界面，所以需要使用它（仓库维护者的要求）

下面是具体逻辑：

 1// list.js
 2module.exports = async (ctx) => {
 3    const id = ctx.params.id;
 4    const link = `https://tophub.today/n/${id}`;
 5    const response = await got.get(link, {
 6        headers: {
 7            Referer: 'https://tophub.today',
 8            Cookie: config.tophub.cookie,
 9        },
10    });
11    const $ = cheerio.load(response.data);
12    // 解析榜单标题
13    const title = $('div.Xc-ec-L.b-L').text().trim();
14    // 解析榜单元素
15    const items = $('div.Zd-p-Sc > div:nth-child(1) tr')
16        .toArray()
17        .map((e) => ({
18            title: $(e).find('td.al a').text().trim(),
19            link: $(e).find('td.al a').attr('href'),
20            heatRate: $(e).find('td:nth-child(3)').text().trim(),
21        }));
22    // 将所有条目标题合一用于生成 GUID
23    const combinedTitles = items.map((item) => item.title).join('');
24    // 渲染榜单
25    const renderRank = art(path.join(__dirname, 'templates/rank.art'), { items });
26
27    ctx.state.data = {
28        title,
29        link,
30        item: [
31            {
32                title,
33                link,
34                description: renderRank,
35                guid: combinedTitles,
36            },
37        ],
38    };
39};

这里通过 jquery 语法读取元素: $('div.Xc-ec-L.b-L')，具体可以参考 cheerio 官方文档。

由于当榜单中任一个条目顺序或内容发生变化都可认为是更新了，同时 guid 可以唯一标识一个 rss 条目，所以将所有条目标题合一用于生成 guid 即可，下面是关于 guid 的介绍：

guid: A string that uniquely identifies the item.

引自：rss 标准

最后，ctx.state.data 生成了一个 rss，title 用于标识 rss 标题，link 为原网址（tophub.today），item 为一个数组，保存了最新的条目，具体可参考 rss 标准。

编写渲染模版

编辑 template/rank.art:

 1<table>
 2  <thead>
 3    <tr>
 4      <th>排名</th>
 5      <th>标题</th>
 6      <th>热度</th>
 7    </tr>
 8  </thead>
 9  <tbody>
10    {{each items}}
11      <tr>
12        <td>{{ $index + 1 }}</td>
13        <td>
14          <a href="{{ $value.link }}">
15            {{ $value.title }}
16          </a>
17        </td>
18        <td>{{ $value.heatRate }}</td>
19      </tr>
20    {{/each}}
21  </tbody>
22</table>

这里用 each 操作遍历传入的 items，$index 为下标，$value 为对应值，具体语法可以参考官方文档。

另外注意传入 items 的方式：

1art(path.join(__dirname, 'templates/rank.art'), { items });

传入的是一个 object，需要用 {} 扩住 items。

定义路由维护者

1// maintainer.js
2module.exports = {
3    '/list/:id': ['akynazh'],
4};

/list/:id 这个路由对应 github.com/akynazh 这个开发者。

注意同一路由可有多个维护者，feat 和 fix 提交都可以加入该路由的维护者名单。

编写路由文档

在 website/docs/routes 下编写路由对应的文档，方便用户使用，首先确定路由类型，这里可以认为是新媒体，所以编辑 new-media.mdx 即可：

1## 今日热榜 {#jin-ri-re-bang}
2
3:::warning
4由于需要登录后的 Cookie 值才能获取原始链接，所以需要自建，需要在环境变量中配置 `TOPHUB_COOKIE`，详情见部署页面的配置模块。
5:::
6
7### 榜单列表 {#jin-ri-re-bang-bang-dan-lie-biao}
8
9<Route author="akynazh" example="/tophub/list/Om4ejxvxEN" path="/tophub/list/:id" paramsDesc={['榜单id，可在 URL 中找到']} />

{#jin-ri-re-bang} 定义了中文名对应的拼写名，用于快速定位。

:::warning::: 定义了一个重要注意事项模块，其他模块可参考官方文档。

Route 标签定义了一条路由。

支持 Radar 插件

 1module.exports = {
 2    'tophub.today': {
 3        _name: '今日热榜',
 4        '.': [
 5            {
 6                title: '榜单列表',
 7                docs: 'https://docs.rsshub.app/routes/new-media#jin-ri-re-bang-bang-dan-lie-biao',
 8                source: ['/n/:id'],
 9                target: '/tophub/list/:id',
10            },
11        ],
12    },
13};

docs 为文档地址。source 为原路由，target 为目标路由，通过 :id 映射了 id 值，另外 target 还支持更复杂的操作（比如正则），具体可参考官方文档。

配置环境变量

前面我们通过 config.tophub.cookie 读取 cookie，对应为全大写+下划线分隔生成的 KEY，在 RSSHub 根目录下编辑 .env 即可：

1TOPHUB_COOKIE=""

测试

接着，即可在本地进行调试了，通过 curl 或者浏览器访问对应路由，注意观察逻辑是否正确和渲染效果即可。

另外最好也把文档进行测试：

1cd website
2pnpm i
3pnpm run start:zh

部署

测试确保没问题后可以向 RSSHub 提交合并请求，需要格外注意格式，比如新增路由为 feat(route): xxx。

如果嫌官方处理合并请求太慢，建议自己部署使用（另外需要配置变量的基本都得自己部署）：

1git clone git@github.com:DIYgod/RSSHub.git && cd RSSHub
2pnpm i # npm install -g pnpm
3pm2 start lib/index.js --name rsshub # npm install pm2 -g

这里是用 pm2 让 RSSHub 运行在后台，可通过 pnpm start 之类的操作运行在前台。

之后每次更新，拉取完代码后重启即可 pm2 restart rsshub，但如果有新的依赖，需要先运行 pnpm i 以更新依赖。

可能出现的问题

这里记录下遇到的问题，持续更新。

commit 失败

报错提示说缺少某个依赖(pinyin-pro)，是文档相关的。

如果修改了文档，那么需要到 website 下运行 pnpm i 安装相关依赖，以便于 commit 检查。

参考

InfluxDb 重要知识整理

akynazh@gmail.com (zhihang) — Mon, 04 Dec 2023 11:40:20 +0800

前言

InfluxDB 是一个用于存储和分析时间序列数据的开源数据库，对与时间相关联的数据进行分析、处理和存储时有较大的优势，比如针对某一个智能设备连续不断收集的数据，可以将其进行合理地存储和整理，从时间角度对数据进行分析以得到相关的统计数据，通过内置的 CQ 与 RP 操作，可以对大量的数据进行采样和保留。

本文介绍的 InfluxDb 版本为 v2。

安装与启动

这里暂时只记录了 MacOS 的操作步骤。

1# install influxdb and its cli tool
2brew install influxdb influxdb-cli
3# start influxdb | listen 8086
4influxd

启动成功后，访问 localhost:8086 根据提示完成用户初始化，并得到一个认证 token 用于 API 调用。influxdb 默认将数据保存在 ~/.influxdbv2 目录下面。

重要概念

数据组织形式

bucket: 存储时序数据的地方，一个 bucket 可以包含多个 measurement，相当于 database
measurement: 用于描述时序数据，包含 timestamp, tags 和 fields，相当于 table
timestamp: 记录时序数据的时间
tag: 键值对，用于标识一个时序数据的特点
field: 键值对，用于记录时序数据的具体值

第一次接触 bucket 的概念，可能会有所疑惑，下面是官方的解释：

A bucket is a named location where data is stored that has a retention policy. It’s similar to an InfluxDB v1. x “database,” but is a combination of both a database and a retention policy.

也就是说它类似于 v1 版本中的 “database”，但是多了一个数据保存策略。

时序数据通常是海量的，对其进行合适的数据清理和保存是十分重要的，每个数据库对应着一个数据保存策略以适应于实际场景的使用。

在一个 bucket 中，插入每条数据需要遵循以下格式（行协议）：

重要定义

Point 和 Series 是官方列出的两个重要定义。

Point: Single data record identified by its measurement, tag keys, tag values, field key, and timestamp.

Point 其实就相当于数据库表中的一条记录。

Series: A group of points with the same measurement, tag keys, and tag values.

Series 可以理解为同一 measurement 中具有相同 tag 的数据组成的数据集。

存储引擎

TSM 采用了类似于 LSM 的存储思路，LSM 是许多 NOSQL 采用的存储引擎，大致的过程如下图(来源网络)：

LSM 树核心思想的核心就是放弃部分读能力，换取写入的最大化能力。

LSM 假定不需要每次有数据更新就必须同时将数据写入到磁盘中，而可以先将最新的数据驻留在内存中，等到积累到足够多之后再使用归并排序的方式将内存内的数据合并追加到磁盘队尾(因为所有待排序的树都是有序的，可以通过合并排序的方式快速合并到一起)。

这也就是 LSM 在某些情况比 B+ 树更合适的原因，如果你的场景一直需要大量的写入，而不需要很多读取和修改操作，推荐使用 LSM，比如时序数据的存储，一般不会进行任何修改操作而会有海量的写入操作。

TSM 存储流程大同小异，如下所述：

Batches of points are sent to InfluxDB, compressed, and written to a WAL for immediate durability. Points are also written to an in-memory cache and become immediately queryable. The in-memory cache is periodically written to disk in the form of TSM files. As TSM files accumulate, the storage engine combines and compacts accumulated them into higher level TSM files.

批量的 points 将会被写或更新到 cache 中并将操作写入 wal 中以确保在宕机之类的情况发生时数据的可恢复性。cache 中的数据按 series key 有序地被组织好，且会周期性地写入到磁盘中，以 TSM 文件的格式存储着。

对于 TSM 文件，TSM 全称 Time-Structured Merge Tree，即时间结构化归并树，从名字可以大概推知其组织数据的形式，下面是官方解释：

To efficiently compact and store data, the storage engine groups field values by series key, and then orders those field values by time.

根据 series key 分组数据，并且将他们根据时间排序好。

其中 series key 由 measurement, tag key & value, field key 进行定义。

那么 TSM 如何一步步地合并与分组数据的呢？它大致是基于分级压缩的策略来进行的，当多个一级数据达到一定大小后会合并压缩为二级数据，直到达到四级数据，然后将会为这些数据分出一个新的 TSM 文件，所有具有相同 series key 的数据将为位于同一 TSM 文件中，这样确保了索引数据的效率，因为数据是连续的。

数据操作

创建数据库

1influx bucket create \
2--org="$org" \
3--token="$token" \
4--name="$bucket" \
5--retention "3d" \
6--shard-group-duration "1h"

该语句创建了一个 bucket，其中数据保留 3 天，分片时间跨度为 1 小时。

分片是时间序列数据的横向分区，每个分片包含其指定时间范围内的时间序列数据子集。在这个例子中，由于数据最多保留 3 天，分片时间跨度为 1 小时，那么将产生 3 * 24 个分片。

分片持续期的选择影响查询性能、数据压缩和存储效率，需要仔细考虑后进行使用。

数据写入

influxdb 在插入数据时自动创建 measurement，插入数据的格式需要符合行协议。

 1influx write \
 2--org="$org" \
 3--token="$token" \
 4--bucket $bucket \
 5--precision s "
 6health_data_t1,cardId='20181214062',type=1 heartrate=80,bloodOxygen=97,microcirculation=80 1706002825
 7health_data_t1,cardId='20181215062',type=1 heartrate=81,bloodOxygen=87,microcirculation=81 1706002825
 8health_data_t1,cardId='20181214072',type=1 heartrate=82,bloodOxygen=98,microcirculation=80 1706002825
 9health_data_t1,cardId='20181214052',type=1 heartrate=80,bloodOxygen=97,microcirculation=84 1706002825
10health_data_t1,cardId='20181212062',type=1 heartrate=86,bloodOxygen=99,microcirculation=80 1706002825
11health_data_t1,cardId='20181214162',type=1 heartrate=80,bloodOxygen=97,microcirculation=82 1706002825
12"

以上操作将创建一个名为 health_data_t1 的 measurement，有 cardId，type 这两个 tag，有 heartrate，bloodOxygen，microcirculation 这三个 field，最后跟着的是时间戳，通过 --precision 指定其单位为 s（如果不是纳秒级都需要自己指定单位）。

数据查询

influx 支持通过 flux 和 influxql(sql) 进行查询，flux 更为灵活而强大，下面只介绍 flux。

如下是一个查询示例：

1influx query \
2--org="$org" \
3--token="$token" '
4from(bucket: "equipments")
5    |> range(start: 2024-01-23T16:00:00Z, stop: 2024-01-23T19:00:01Z)
6    |> filter(fn: (r) => r._measurement == "health_data_t1")
7    |> filter(fn: (r) => r._field == "heartrate")
8'

需要注意数据中时间的时区以 UTC 作为标准，如果需要使用当地时间，比如中国，则修改时间范围为如下：

1range(start: 2024-01-23T16:00:00+08:00, stop: 2024-01-23T19:00:01+08:00)

更多用法记录：

 1# 映射操作
 2|> map(fn: (r) => ({r with _value: r._value / 100.0}))
 3
 4# 求平均值
 5|> mean()
 6
 7# 定时任务
 8option task = {name: "downsample_5m_precision", every: 1h, offset: 0m}
 9from(bucket: "equipments")
10    |> range(start: -task.every)
11    |> filter(fn: (r) => r._measurement == "mem" and r.host == "myHost")
12    |> aggregateWindow(every: 5m, fn: mean)
13    |> to(bucket: "equipments-downsample")

其中，定时任务每一小时执行一次，时间偏移为 0，时间窗口设为五分钟，对五分钟内的数据取平均值得到新的数据，然后存入新的 bucket 中，一般新的 bucket 会采用时间更长的保存策略。

第三方接口使用

这里记录下 Java 的接入方式。

1<dependency>
2  <groupId>com.influxdb</groupId>
3  <artifactId>influxdb-client-java</artifactId>
4  <version>6.6.0</version>
5</dependency>

官方提供了三种写入方式：

Use InfluxDB Line Protocol to write data（行协议的方式）
Use a Data Point to write data（Point 方式）
Use POJO and corresponding class to write data（POJO 映射方式）

这里采用第二种作为示例：

 1String url = "http://localhost:8086";
 2String token = "your_token";
 3String bucket = "test";
 4String org = "xdu";
 5
 6try(InfluxDBClient client = InfluxDBClientFactory.create(url,
 7        token.toCharArray(), org, bucket)) {
 8    Point p = Point.measurement("cpu")
 9            .addTag("host", "serverB")
10            .addTag("region", "cn")
11            .addField("value", 0.2318)
12            .addField("value1", 0.8238)
13            .addField("value2", "s1")
14            .time(Instant.now(), WritePrecision.NS);
15    client.getWriteApiBlocking().writePoint(p);
16} catch (Exception e) {
17    System.out.println(e.getMessage());
18}

查询操作可以直接通过 flux 脚本完成。找出过去 12h 内 measurement 为 “cpu”，host 为 “serverB”，且展现 field 为 “value1”：

1String query = "from(bucket:\"test\")\n" +
2        "  |> range(start: -12h)\n" +
3        "  |> filter(fn: (r) =>\n" +
4        "    r._measurement == \"cpu\" and\n" +
5        "    r._field == \"value1\" and\n" +
6        "    r.host == \"serverB\"\n" +
7        "  )";

接着调用该脚本：

1List<FluxTable> tables = client.getQueryApi().query(query, org);
2
3for (FluxTable table : tables) {
4    for (FluxRecord record : table.getRecords()) {
5        System.out.println(record.getValues());
6    }
7}

参考文档

QuantumultX 重要使用记录

akynazh@gmail.com (zhihang) — Sat, 11 Nov 2023 23:51:44 +0800

前言

本文记录了通过 QuantumultX 配置代理，书写分流规则，抓包分析并重写规则，启用定时任务等简易操作流程，另外还记录了其他一些相关操作。

配置代理

可以导入自己搭建的节点，也可以通过引用导入 QuantumultX 格式的订阅链接，步骤比较简单略过，记录一个点，如果相关机场不支持 QuantumultX 格式的订阅，可以通过解析器完成转换，在配置中引用转换脚本即可：

1[general]
2resource_parser_url=https://raw.githubusercontent.com/KOP-XIAO/QuantumultX/master/Scripts/resource-parser.js

resource-parser.js 是 github 上的一个资源解析转换脚本，主要功能是将其它格式的订阅解析成 QuantumultX 格式的订阅，以及可以对引用的重写/分流规则进行转换和筛选。

书写分流规则

分流规则可以简单理解，就是对某一类地址进行分流，通过一定的分流策略来处理这些地址的相关请求，这里以一个例子引入：

我需要在访问 *.dmm.co.jp 这类日本网址时使用日本节点，那么可以首先创建一个分流策略，名为 Japan，类型可以选择 avaiable(可用性) 或者 static(静态指定)，也可以视情况选择如负载均衡之类的其他策略，匹配的节点标签可以根据自己的日本节点名称来填写，比如“日本”。

接着可以书写分流规则，host 需要填写一个正则式，这里就填 *.dmm.co.jp，类型即是 HOST-WILDCARD(通配符类型)，策略即指定为 Japan。

以上操作同样都可通过直接编辑配置文件完成：

1[filter_local]
2host-wildcard, *.dmm.co.jp, Japan
3
4[policy]
5available=Japan, server-tag-regex=日本, img-url=🇯🇵

抓包分析并重写规则

由于很多请求是 https 的，为了抓包和重写 https 请求，需要安装并信任证书。

首先在设置界面开启重写和 MitM(中间人攻击)，然后点击生成、配置证书。

接着，对于 IOS，需要在设置界面信任证书。对于 MacOS，点击生成证书会在 Safari 完成生成，然后双击证书在 Keychain Access 应用进行信任操作，如提示不可安装，则手动从 finder 将证书拖到 Keychain Access 的 login 列表中。

完成以上步骤后，即可开启 Http 抓取功能进行抓包和重写规则了，注意对于每个 https 请求，需要在 mitm 处添加对应的域名才能进行抓包和重写，而 http 请求则不用。

下面以屏蔽知乎的开屏广告为例子来进行一次规则重写。

开启抓包，如果是通过 http 加载的广告则很方便，直接开始抓包，但一些广告的加载可能是通过 https 加载，所以可以先通过 Activity 观察一下一些可能的 https 广告网址，然后在 mitm 处配置域名。

打开知乎加载开屏广告，抓包发现加载开屏广告图片的请求为:

1http://images.pinduoduo.com/marketing_api/2023-11-09/ce00e978-7d7f-11ee-81f3-0a580a4a3166.png?filtered=pread&filtered=pread

这是一个 http 请求，我们就可以通过一个正则式来 reject 这类请求，添加重写规则，类型可以指定为 reject，匹配的 url 为以下正则式：

1^https?:\/\/images\.pinduoduo\.com

考虑到同网址可能有 https 相关的广告，可以在 mitm 处再添加 images.pinduoduo.com。

接着重新打开知乎，发现开屏广告已经不出现了。注意这只是一个简陋的例子，很多广告是通过 https 加载的，广告地址可能动态变化且繁多，需要更多更复杂的匹配，建议直接引用社区维护的规则：AdvertisingLite，但是不保证一直可用，关键还需自己抓包分析。

同样以上操作对应到配置文件如下：

1[rewrite_local]
2^https?:\/\/images\.pinduoduo\.com url reject
3
4[mitm]
5hostname = images.pinduoduo.com

设置定时任务

QuantumultX 支持以 crontab 格式设置定时任务，任务脚本为 js 脚本，可以实现定时签到等操作，具体可以自行抓包分析并书写自动化脚本。

下面以书写一个简单的定时汇率播报脚本为例：

 1// currency.js
 2const from_cur = "USD"
 3const to_cur = "CNY"
 4const amount = 1
 5const token = "your_exchangerate-api_token"
 6const url = `https://v6.exchangerate-api.com/v6/${token}/pair/${from_cur}/${to_cur}/${amount}`;
 7const method = "GET";
 8const headers = {};
 9const data = {};
10
11const myRequest = {
12    url: url,
13    method: method,
14    headers: headers,
15    body: JSON.stringify(data)
16};
17
18$task.fetch(myRequest).then(response => {
19    let m = JSON.parse(response.body).conversion_result;
20    $notify("今日汇率 -- 美元兑人民币", "", `${m}`); // 中间那个是副标题
21    $done();
22}, reason => {
23    $notify("今日汇率 -- 美元兑人民币", "", reason.error); // Error!
24    $done();
25});

其中注意这几个 QuantumultX 提供的 API:

$task.fetch 可以触发定时任务发送 http 请求
$notify 可以方便地调用系统通知
$done 标志一个任务的完成

接着把脚本放到 Quantumult X/Scripts/ 这个文件夹下，然后编写配置，在早上 10 点定时播报汇率情况：

1[task_local]
20 10 * * * currency.js, tag=今日汇率, enabled=true

另外，QuantumultX 还支持引用社区的脚本，但是感觉不太安全，建议阅读完代码确认没问题再引用。

配置 GeoIP 数据库源

目前市面上绝大多数的代理工具都依赖于 GeoIP2 数据库判断地址所属地，QuantumultX 也不例外。GeoIP2 数据库是来自于 MaxMind 的 GeoLite2 免费数据库，据官方说法，这个数据库目前存在一下几个问题：获取不便，数据量大，准确度低。

GeoIP2-CN 是一个小巧精悍、准确、实用 GeoIP2 数据库，而支持 QuantumultX，在设置页的 GeoLite2 项设置来源为如下链接，即可引用 GeoIP2-CN：

1https://github.com/Hackl0us/GeoIP2-CN/raw/release/Country.mmdb

IOS 与 MacOS 配置双向同步

首先在每个端的设置-资源开启 icloud，然后在一个端的关联配置下点击 icloud 新增 profile，然后其他端都 link profile，之后即可实现双向同步，默认有更新延迟，可以点击立即更新强制更新。

Git 重要用法整理

akynazh@gmail.com (zhihang) — Fri, 15 Sep 2023 19:42:58 +0800

前言

这里记录一些重要的 Git 操作和知识, 随着学习和工作中遇到的 git 相关问题而持续更新。

初始化配置

 1# 配置用户
 2git config --global user.name "akynazh"
 3git config --global user.email "akynazh@gmail.com"
 4
 5# 禁用换行符自动转换
 6git config --global core.autocrlf false
 7
 8# 配置 http 代理
 9git config --global http.proxy "http://127.0.0.1:7890"
10git config --global https.proxy "http://127.0.0.1:7890"
11
12# 设置 commit 编辑工具为 vim
13git config --global core.editor "vim"
14
15# 配置 SSH 代理
16# 编辑 ~/.ssh/config 如下:
17
18#########################################################
19Host github.com
20    User git
21    Port 22
22    Hostname github.com
23    IdentityFile ~/.ssh/id_rsa
24    # Winodws
25    # ProxyCommand connect -S 127.0.0.1:7890 -a none %h %p
26    # Mac
27    ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p
28Host ssh.github.com
29    User git
30    Port 443
31    Hostname ssh.github.com
32    IdentityFile ~/.ssh/id_rsa
33    # Winodws
34    # ProxyCommand connect -S 127.0.0.1:7890 -a none %h %p
35    # Mac
36    ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p
37
38# connect 命令是在 Windows 中位于 git 安装目录下的一个操作命令, 位置大致在：C:\Program Files\Git\mingw64\bin\connect.exe
39# nc 为 netcat 可通过 brew, apt 安装
40#########################################################
41
42# 如果使用 HTTP 进行 Git 拉取或推送，需要使用 ACCESS_TOKEN
43# Username for 'https://github.com': akynazh
44# Password for 'https://akynazh@github.com': (输入 ACCESS_TOKEN)
45# 为了避免重复输入，对 TOKEN 进行持久化：
46git config --global credential.helper store

初始化仓库

首先从代码托管网站建立一个仓库，获取仓库地址 url (如果是 ssh 类型的 url, 需要上传本机公钥)，然后进入项目所在文件夹，运行以下代码：

1url="your_repo_url"
2git init # 初始化仓库，生成.git文件
3git add . # 将项目文件的修改信息添加到 .git 内的一个暂存区（index）
4git commit -m “init” # 将暂存区的修改信息提交到分支
5git remote add origin $url # 添加远程仓库
6git push origin master # 将本地分支推送到远程仓库

这里执行完 git commit -m "init" 后，我们查看一下本地分支信息：

1> git branch
2* master

可见 git 自动为我们本地创建了一个 master 分支。

执行完 git push origin master 后，我们查看一下本地分支与远程分支的映射关系：

1> git branch -a
2* master
3  remotes/origin/master
4
5> git branch -vv
6* master 3a31f4c init

可见并没有产生映射。所以如果直接使用 git push 提交代码会报错，因为 git 不知道你要提交到哪个远程分支。为了方便提交, 我们可以建立映射关系:

1git branch -u origin/dev_r 将当前分支与远程分支 dev_r 建立映射关系

如果建立了映射关系，那么以后在当前分支 git push 时默认 push 到与当前分支建立关系的那个远程分支。

实际操作如下：

1> git branch -u origin/master
2Branch 'master' set up to track remote branch 'master' from 'origin'.
3> git branch -vv
4* master 3a31f4c [origin/master] init # 可看见产生了映射关系：master <> origin/master

HEAD 相关知识

HEAD 代表当前分支的最新提交名称，它可以由一些修饰符进行修饰进而产生不同的含义。

关于 HEAD~{n}

~ 是用来在当前提交路径上回溯的修饰符。

HEAD~{n} 表示当前所在的提交路径上的前 n 个提交（n >= 0）：

HEAD = HEAD~0 （即当前最新的一次commit）
HEAD~ = HEAD~1
HEAD~~ = HEAD~2

关于 HEAD^{n}

^ 是用来切换父级提交路径的修饰符。

当我们始终在一个分支比如 dev 开发/提交代码时，每个 commit 都只会有一个父级提交，就是上一次提交。此时 HEAD~1 等价于 HEAD^。

当并行多个分支开发，feat1, feat2, feat3，完成后 merge feat1 feat2 feat3 回 dev 分支后，此次的 merge commit 就会有多个父级提交。

HEAD^ = HEAD^1 第一个父级提交
HEAD^2~1 第二个父级提交的上一次提交

代码的提交与修改

修改上次提交

这里以对提交的信息和作者进行修改为例，注意邮箱两侧由 <> 包括住

1git commit --amend --message="modify" --author="your_name <your_email>"
2git push -f

修改多次提交

首先列出近 n 次提交：

1# 列出最近3次提交
2git rebase -i HEAD~3

注: 进行 git rebase 之前，先将本地修改提交完毕。

得到大致如下内容：

 1pick 8ae7972 update
 2pick 1a22dfd update
 3pick 00433e4 update
 4
 5# Rebase 368e5c8..00433e4 onto 368e5c8 (3 commands)
 6#
 7# Commands:
 8# p, pick <commit> = use commit
 9# r, reword <commit> = use commit, but edit the commit message
10# e, edit <commit> = use commit, but stop for amending
11# s, squash <commit> = use commit, but meld into previous commit
12# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
13
14......

可见确实列出了前面 3 次的修改记录。

将需要修改的 commit-id 前面对应 “pick” 改为 “edit”，即可在后续操作中对该分支进行修改。

之后，x 次修改就进行 x 次下面两条命令：

1git commit --amend --message="modify" --author="your_name <your_email>"
2git rebase --continue

经过 x 次以上命令，不出什么问题的话，将会有大致如下的提示出现：

1Successfully rebased and updated refs/heads/master.

现在，强制推送即可：

1git push -f

取消或删除提交

当你在某一次提交中不小心忘记了把一些敏感信息进行 ignore，那么你很可能需要删除那一次提交。

可以使用 git reset 删除提交，记录将被真正删除，是将 HEAD 指向某个 commit-id，该操作需要谨慎使用。比如, 删除上一次提交，也就是把 HEAD 指向 HEAD^, 追加 --hard 使得工作区和暂存区里面的文件也回到以前的状态，下面是 reset 三种操作选项：

–soft: 重置 HEAD 到指定的提交，但保持工作目录和暂存区的更改。
–mixed（默认）：重置 HEAD 到指定的提交，并重置暂存区，但保持工作目录的更改。
–hard：重置 HEAD 到指定的提交，并重置暂存区和工作目录的所有更改。这意味着所有未提交的更改将丢失。

如果使用 git revert 则只是取消修改，提交记录还在，并且多生成了一次 “revert” 提交记录，而对 “revert” 提交进行 “revert” 则会恢复对应修改，并生成一次 “reapply” 提交记录。注意 revert 对于敏感信息的处理是无效的。

在进行 revert 之前需要提交或贮藏(stash)本地修改，而 reset 可以无视当前工作区状态。下面是一些具体操作：

 1git revert [倒数第一个提交] [倒数第二个提交]
 2# e.g. git revert HEAD HEAD~1
 3
 4# 取消上次提交
 5git revert HEAD
 6# 接上，恢复上次提交
 7git revert HEAD
 8
 9# 取消上次提交(删除提交记录, 保留工作区修改)
10git reset HEAD^
11# 取消上次提交(删除提交记录, 保留工作区和暂存区修改)
12git reset --soft HEAD^
13
14# 删除本地所有最新提交, 直接使用远程分支覆盖本地分支
15git reset --hard origin/master
16# 删除上一次提交
17git reset --hard HEAD^
18# 删除某次提交
19git reset --hard commit_id

取消或移动未提交的更改

将本地未提交的更改合并到另一个分支:

通过 stash 操作存储我们在当前分支上所做的更改, 然后我们可以切换到正确的分支并将它们应用到它上面:

1git stash
2git checkout <right-branch>
3git stash pop

取消本地未提交的更改:

1git stash
2# git stash show
3git stash drop

合并某几个提交

有些公司要求每个 PR 对应一个 Commit，这时就需要将多个 Commit 合并到一个 Commit 中，可以使用 git rebase 命令完成，具体操作如下：

1git rebase -i HEAD~2

这条命令会打开你默认的文本编辑器，列出最近的两个 commit，类似这样：

1pick abc1234 第一个 commit 信息
2pick def5678 第二个 commit 信息
3
4# 命令：
5# p, pick = 使用这个 commit
6# r, reword = 使用这个 commit，但修改提交信息
7# s, squash = 使用这个 commit，但合并到前一个 commit 中
8# f, fixup = 类似 squash，但丢弃提交信息

修改第二个 commit 的操作为 squash 或 s 即可：

1pick abc1234 第一个 commit 信息
2s def5678 第二个 commit 信息

保存并关闭编辑器。接着 Git 会再次打开编辑器，让你编辑合并后的新 commit 信息。你可以保留、修改或删除部分内容。

保存后，两个 commit 就成功合并为一个了。最后强制提交即可。

集成某几个提交

如果需要另一个分支的所有代码变动，那么就采用 merge。而如果只需要部分代码变动（某几个提交），这时可以采用 cherry-pick（意为挑选最有利的一个）。

1# 将提交 A 和提交 B 集成到当前分支
2git cherry-pick <HashA> <HashB>
3# 如果有冲突则解决后继续执行 --continue, 如果回到操作前的样子则 --abort, 如果不想则 --quit
4git cherry-pick --continue

合并上游分支

1# git remote add upstream https://github.com/whoever/whatever.git
2git fetch upstream
3git checkout master
4git merge upstream/master
5git push origin master

审查同事提交

1git remote add zhihang https://gitlab.com/zhihang/smps.git
2git fetch zhihang
3git checkout zhihang/release-26.05.01.tesla

这样很方便，但如果是要修改或者在 IDE 内比对分支，则需要使用 switch：

1git remote add zhihang https://gitlab.com/zhihang/smps.git
2git fetch zhihang
3git switch -c test/release-26.05.01.tesla zhihang/release-26.05.01.tesla

代码恢复抢救

有时候脑子瓦特了做出一些离谱的操作, 导致辛苦写的代码白白消失不见, 这时候就需要抢救了……

恢复丢弃的 stash 数据

这是一次真实经历过的事件, 有个 stash 的记录忘记 pop 了, 后来操作失误直接 drop 了, 发现之后直接头脑一片空白! 记录下抢救措施！

1git fsck --lost-found

会看到一条条记录类似:

1dangling commit 6cb2480fa3a59c140b58a07ac734838a2d958d44
2dangling commit e9b4c85c437aacf628e724903df21648538963d4
3dangling blob 983515c6f78d232f1c8878e98598218c142aa9b9
4dangling commit 4ab67a050c5a8288da28154f79ea89106918ea36
5dangling commit c2363d6a03dad8f2bc986f8d21ab0fa38c74477b
6dangling blob 4338d18c5224397a03b40548b7e0f1ea9ca3ffff

复制 dangling commit 的 id (其他的 dangling blob 不用关心), 通过 show 操作查看具体的修改：

1git show 6cb2480fa3a59c140b58a07ac734838a2d958d44

其中日期是 stash 的日期, 摘要会记录你是在哪一条 commit 上进行 stash 操作。

再找到想要的记录后执行 merge 即可：

1git merge 6cb2480fa3a59c140b58a07ac734838a2d958d44

查看或恢复被覆盖掉的提交历史

之前我使用 git commit --amend 修改以前的提交，这样使得 git log 见不到上次提交的信息, 但事实上 git 并没有真的删除上次提交，而是重新创建了一批新的提交，并将当前分支顶端指向了新提交。

可以使用 git reflog 找到并且重新指向原来的提交来恢复它们，注意 reflog 保存的提交是有期限的，需要及时进行操作。

1git reflog
2
3# 可以查看到 amend 前的一条提交 99d2720 如下
43805bba (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: commit (amend): update
599d2720 HEAD@{1}: commit: update
6...

拿到 commit id 99d2720 之后就好办了, 使用 git reset --hard 99d2720 即可恢复。

开源仓库前清除历史提交

1git checkout --orphan x
2git add -A
3git commit -am "oss"
4git branch -D master
5git branch -m master
6git push -f origin master

子模块相关操作

子模块初始化及更新方法

 1# add >> .gitmodules
 2git submodule add https://github.com/chaconinc/DbConnector
 3# clone
 4git clone --recurse-submodules https://github.com/chaconinc/MainProject
 5# or
 6git clone https://github.com/chaconinc/MainProject && git submodule update --init --recursive
 7# renew
 8cd your/submodule/path && git checkout master && git pull && cd your/proj/root && git commit -am "update submodule" && git push
 9# checkout master on all submodules in a single line (submodules are pinned to a specific sha)
10git submodule foreach --recursive git checkout master
11# publish
12cd your/submodule/path && git commit -am "update" && git push && cd your/proj/root && git commit -am "update submodule" && git push

完全移除子模块的方法

手动删除子模块目录；
手动删除 .git/modules 下子模块暂存区目录；
更新 .gitmodules 文件，移除子模块信息块；
更新 .git/config 文件，移除子模块信息块；

构建自己的 Git 存储库

这里介绍最简单便捷的方法，需要有自己的一台服务器，假设用户是 root，然后先通过配置密钥实现免密登陆服务器，接着进行下面操作即可。

 1# to remote server: s1(alias)
 2ssh root@your_server_ip # ssh s1
 3
 4# init git 
 5mkdir /git && cd /git
 6git init --bare site.git
 7
 8# remote: clone repo
 9git clone /git/site.git
10# local: clone repo
11git clone ssh://root@your_server_ip/git/site.git # git clone s1:/git/site.git

这样就基本可以了，如果是已经使用了 github 之类的托管网站的仓库，添加 remote 即可：

1# remote: add remote
2git remote add local /git/site.git
3# local: add remote
4git remote add server_git ssh://root@your_server_ip/git/site.git # git remote add server_git s1:/git/site.git

License 配置

这里讲的比较宽泛，而实际上也不建议去记忆这些，在用到时去找到适合自己项目的 License 即可。如果是使用别人的代码，则再具体去了解对应 License 的条款即可，在 github 中点击 License，也可以很清楚的看到 Permissions、Limitations 以及 Conditions，比如常见的 GPLv3:

Permissions
- Commercial use: 允许用于商业目的。
- Modification: 允许修改源代码。
- Distribution: 允许分发原始或修改后的代码。
- Patent use: 提供专利使用权。
- Private use: 允许私下使用。
Limitations
- Liability: 不提供责任担保。
- Warranty: 不提供任何保证。
Conditions
- License and copyright notice: 必须保留版权声明和许可证信息。
- State changes: 必须声明对源代码所做的更改。
- Disclose source: 分发时必须提供完整的源代码。
- Same license: 衍生作品必须在相同的许可证下发布。

Commit 规范

良好的，遵循一定规则的提交信息不仅有助于编码历史的回顾，也有助于 CHANGELOG 等文件的生成。

格式 Format

每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。其中，Header 是必需的，Body 和 Footer 可以省略。

1<type>(<scope>): <subject>
2<空行>
3<body>
4<空行>
5<footer>

不管是哪一个部分，任何一行都不得超过 72 个字符（或 100 个字符）。Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）。Footer 部分如果提交存在一个与之关联的 Issue 则要关联。

示例：

1fix(release): need to depend on latest rxjs and zone.js
2
3The version in our package.json gets copied to the one we publish, 
4and users need the latest of these.

主题 Subject

subject 是本次 commit 目的的简短描述，一般不要超过 50 个字符：

使用祈使句和现在时：例如使用 “change” 而不是 “changed” 或 “changes”。
规范大小写和相应书写规则。
无需加句号符标识结尾。

类型 Type

Commit Type	Title	Description
`feat`	Features	A new feature
`fix`	Bug Fixes	A bug Fix
`docs`	Documentation	Documentation only changes
`style`	Styles	Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
`refactor`	Code Refactoring	A code change that neither fixes a bug nor adds a feature
`perf`	Performance Improvements	A code change that improves performance
`test`	Tests	Adding missing tests or correcting existing tests
`build`	Builds	Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
`ci`	Continuous Integrations	Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
`chore`	Chores	Other changes that don’t modify src or test files
`revert`	Reverts	Reverts a previous commit

作用域 Scope

scope 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同，同样属于枚举类型。

常见的有：

$cmpt
$container
$view
$api

主体 Body

Body是对本地提交的一个详细描述，需要注意的是，描述每行字符不应超过 72 个字符，这利于各种环境下良好的阅读体验。

Footer 部分只用于两种情况：

Breaking Changes: 如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。
Closes Issue: 如果当前 commit 针对某个 issue，那么可以在 Footer 部分关闭或关联这个 issue，或多个 issue:

1Closes #234
2Closes #123, #245, #992
3Ref #234

回退 Revert

还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，格式规定如下

header 以 revert: 开头，后面跟着被撤销 commit 的 header
body 以 This reverts commit <hash> 的格式，其中的 hash 是被撤销 commit 的 SHA 标识符。

1revert: feat(pencil): add 'graphiteWidth' option
2
3This reverts commit 667ecc1654a317a13331b17617d973392f415f

如果当前 commit 与被撤销的 commit，在同一个发布（release）里面，那么它们都不会出现在 Change log 里面。如果两者在不同的发布，那么当前 commit，会出现在 Change log 的 Reverts 小标题下面。

Git Alias

Git 别名（alias）允许你为常用的 Git 命令创建简短的、易于记忆的替代名称。

 1# 单命令别名
 2git config --global alias.co checkout
 3# git co main
 4
 5# 多命令别名
 6git config --global alias.commitall '!git add -A && git commit -am'
 7# git commitall "Initial commit"
 8
 9# 运行外部脚本
10git config --global alias.deploy '!sh ~/scripts/deploy.sh'
11# git deploy
12
13#查看别名配置
14git config --global --get-regexp alias
15
16# 删除别名
17git config --global --unset alias.co

也可以直接编辑 Git 配置文件来添加别名。全局配置文件通常位于 ~/.gitconfig，本地配置文件通常位于仓库根目录下的 .git/config。

 1[alias]
 2    co = checkout
 3    ci = commit
 4    br = branch
 5    st = status
 6    commitall = !git add -A && git commit -am
 7    bra = !git branch -a
 8    pf = !git push -f
 9    tags = !git tag
10    stashes = !git stash list

建议用法

使用 rebase 来集成其他分支修改

rebase 通常用于重写提交历史。下面的使用场景在大多数 Git 工作流中是十分常见的：

我们从 master 分支拉取了一条 feature 分支在本地进行功能开发
远程的 master 分支在之后又合并了一些新的提交
我们想在 feature 分支集成 master 的最新更改

基本操作流程如下：

 1# [feature]
 2git checkout feature
 3# feature 集成 master 修改
 4git rebase master
 5# 手动解决冲突
 6# ...
 7git rebase --continue
 8git push origin feature -f
 9
10# 或者通过 git pull 完成:
11git pull origin feature --rebase
12# git config pull.rebase true # 也可以进行默认配置
13# 手动解决冲突
14git push origin feature
15---------------------------------
16
17# [master]
18git checkout master
19git merge origin feature
20git push origin master

这样, 提交的历史将是很干净的, 即使在 master 进行了 merge 但是提交历史仍然不会出现 “merge …” 之类的提交, 因为 merge 的目标分支 feature 经过了 rebase, 现在合并后 feature 上的提交就如同在 master 上进行提交一般，效果如下：

使用 fast-forward 来集成其他分支修改

如果当前分支没有新提交，则可以通过 fast-forward 集成其他基于当前分支开发最新提交的其他分支带来的变更，可以少一条 merge 信息，也让提交历史更为干净。不过其实这是执行 git merge 时的默认策略。

而如果当前分支有新提交，则执行 git merge 时，如果有冲突，则需要手动处理冲突，如果没有冲突，则会生成一条 merge 信息，而且也无法进行 fast-forward 操作。

所以其实大部份情况下还是得通过 rebase 来完成提交历史的简洁化。

Reference

AngularJS Git Commit Message Conventions

Docker 重要使用记录

akynazh@gmail.com (zhihang) — Wed, 14 Jun 2023 23:03:41 +0800

Install

 1# op1. apt
 2apt update && apt install docker.io -y && apt install docker-compose -y
 3
 4# op2. yum
 5# yum install -y yum-utils device-mapper-persistent-data lvm2
 6yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
 7yum install docker-ce
 8curl -L "https://github.com/docker/compose/releases/download/v2.2.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
 9chmod +x /usr/local/bin/docker-compose
10ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
11
12# op3. script
13curl -fsSL https://get.docker.com -o get-docker.sh
14sudo sh get-docker.sh
15curl -SL https://github.com/docker/compose/releases/download/v2.32.4/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
16chmod +x /usr/local/bin/docker-compose
17# sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
18
19# op4. 阿里云服务器版
20# 参考 https://help.aliyun.com/zh/ecs/use-cases/install-and-use-docker

1systemctl start docker && systemctl enable docker

Mirror

EDIT: /etc/docker/daemon.json

1{
2  "registry-mirrors": [
3          "https://docker.mirrors.ustc.edu.cn",
4          "http://hub-mirror.c.163.com",
5          "https://registry.docker-cn.com"
6  ]
7}

1systemctl restart docker

Proxy

 1sudo mkdir -p /etc/systemd/system/docker.service.d
 2
 3
 4sudo vim /etc/systemd/system/docker.service.d/http-proxy.conf
 5[Service]
 6Environment="HTTP_PROXY=http://127.0.0.1:7890"
 7Environment="HTTPS_PROXY=http://127.0.0.1:7890"
 8
 9sudo systemctl daemon-reload
10sudo systemctl restart docker

Manual Pull Image

1# local desktop
2docker save node:20 | gzip -c -9 > node20.tar.gz
3# remote server
4docker load < node20.tar.gz

Webdav

 1version: "3"
 2services:
 3  webdav:
 4    image: bytemark/webdav
 5    restart: unless-stopped
 6    ports:
 7      - "8099:80"
 8    environment:
 9      AUTH_TYPE: Basic
10      USERNAME: ${WEBDAV_USERNAME}
11      PASSWORD: ${WEBDAV_PASSWORD}
12    volumes:
13      - ./data/:/var/lib/dav

Alist

 1version: "3"
 2services:
 3    alist:
 4        image: 'xhofe/alist:latest'
 5        container_name: alist
 6        volumes:
 7            - './data:/opt/alist/data'
 8        ports:
 9            - '${ALIST_PORT}:5244'
10        environment:
11            - PUID=0
12            - PGID=0
13            - UMASK=022
14        restart: always

IT-Tools

1docker run -d --name it-tools --restart unless-stopped -p ${IT_TOOLS_PORT}:80 corentinth/it-tools:latest

Kafka-Zookeeper

 1version: "3"
 2services:
 3  zoo1:
 4    image: zookeeper:3.4.9
 5    hostname: zoo1
 6    ports:
 7      - "${ZOOKEEPER_PORT}:2181"
 8    environment:
 9      ZOO_MY_ID: 1
10      ZOO_PORT: 2181
11      ZOO_SERVERS: server.1=zoo1:2888:3888
12    volumes:
13      - ./zk-single-kafka-single/zoo1/data:/data
14      - ./zk-single-kafka-single/zoo1/datalog:/datalog
15
16  kafka1:
17    image: confluentinc/cp-kafka:5.3.1
18    hostname: kafka1
19    ports:
20      - "${KAFKA_PORT}:9092"
21    environment:
22      KAFKA_ADVERTISED_LISTENERS: LISTENER_DOCKER_INTERNAL://kafka1:19092,LISTENER_DOCKER_EXTERNAL://${DOCKER_HOST_IP:-127.0.0.1}:9092
23      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_DOCKER_INTERNAL:PLAINTEXT,LISTENER_DOCKER_EXTERNAL:PLAINTEXT
24      KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_DOCKER_INTERNAL
25      KAFKA_ZOOKEEPER_CONNECT: "zoo1:2181"
26      KAFKA_BROKER_ID: 1
27      KAFKA_LOG4J_LOGGERS: "kafka.controller=INFO,kafka.producer.async.DefaultEventHandler=INFO,state.change.logger=INFO"
28      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
29
30    volumes:
31      - ./zk-single-kafka-single/kafka1/data:/var/lib/kafka/data
32    depends_on:
33      - zoo1

 1version: "3"
 2services:
 3  kafka1:
 4    image: bitnami/kafka:3.5.2
 5    container_name: kafka1
 6    restart: always
 7    ports:
 8      - 19092:9092
 9      - 19093:9093
10    privileged: true
11    networks:
12      - kafka-net
13    environment:
14      #是否使用KRaft模式
15      KAFKA_ENABLE_KRAFT: "yes"
16      KAFKA_CFG_PROCESS_ROLES: broker,controller
17      KAFKA_CFG_CONTROLLER_LISTENER_NAMES: CONTROLLER
18      KAFKA_CFG_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
19      KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
20      KAFKA_KRAFT_CLUSTER_ID: VaW86rUCTMmoxIcDiER_lA
21      KAFKA_CFG_CONTROLLER_QUORUM_VOTERS: 1@kafka1:9093,2@kafka2:9093,3@kafka3:9093
22      ALLOW_PLAINTEXT_LISTENER: "yes"
23      KAFKA_HEAP_OPTS: -Xmx512M -Xms256M
24      KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE: "true"
25      #broker单独配置
26      KAFKA_CFG_NODE_ID: 1
27      KAFKA_CFG_ADVERTISED_LISTENERS: PLAINTEXT://172.20.103.104:19092
28
29  kafka2:
30    image: bitnami/kafka:3.5.2
31    container_name: kafka2
32    restart: always
33    ports:
34      - 29092:9092
35      - 29093:9093
36    privileged: true
37    networks:
38      - kafka-net
39    environment:
40      KAFKA_ENABLE_KRAFT: "yes"
41      KAFKA_CFG_PROCESS_ROLES: broker,controller
42      KAFKA_CFG_CONTROLLER_LISTENER_NAMES: CONTROLLER
43      KAFKA_CFG_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
44      KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
45      KAFKA_KRAFT_CLUSTER_ID: VaW86rUCTMmoxIcDiER_lA
46      KAFKA_CFG_CONTROLLER_QUORUM_VOTERS: 1@kafka1:9093,2@kafka2:9093,3@kafka3:9093
47      ALLOW_PLAINTEXT_LISTENER: "yes"
48      KAFKA_HEAP_OPTS: -Xmx512M -Xms256M
49      KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE: "true"
50      #broker单独配置
51      KAFKA_CFG_NODE_ID: 2
52      KAFKA_CFG_ADVERTISED_LISTENERS: PLAINTEXT://172.20.103.104:29092
53
54  kafka3:
55    image: bitnami/kafka:3.5.2
56    container_name: kafka3
57    restart: always
58    ports:
59      - 39092:9092
60      - 39093:9093
61    privileged: true
62    networks:
63      - kafka-net
64    environment:
65      KAFKA_ENABLE_KRAFT: "yes"
66      KAFKA_CFG_PROCESS_ROLES: broker,controller
67      KAFKA_CFG_CONTROLLER_LISTENER_NAMES: CONTROLLER
68      KAFKA_CFG_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
69      KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
70      KAFKA_KRAFT_CLUSTER_ID: VaW86rUCTMmoxIcDiER_lA
71      KAFKA_CFG_CONTROLLER_QUORUM_VOTERS: 1@kafka1:9093,2@kafka2:9093,3@kafka3:9093
72      ALLOW_PLAINTEXT_LISTENER: "yes"
73      KAFKA_HEAP_OPTS: -Xmx512M -Xms256M
74      KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE: "true"
75      #broker单独配置
76      KAFKA_CFG_NODE_ID: 3
77      KAFKA_CFG_ADVERTISED_LISTENERS: PLAINTEXT://172.20.103.104:39092
78
79networks:
80  kafka-net:
81    driver: bridge

FreshRSS

 1version: "3"
 2services:
 3  freshrss:
 4    image: freshrss/freshrss:latest
 5    container_name: freshrss
 6    restart: unless-stopped
 7    logging:
 8      options:
 9        max-size: 10m
10    volumes:
11      - ./data:/var/www/FreshRSS/data
12      - ./extensions:/var/www/FreshRSS/extensions
13    ports:
14      - "${FRESHRSS_PORT}:80"
15    environment:
16      TZ: "Asia/Shanghai"
17      CRON_MIN: "3,33"

MySQL

 1version: "3"
 2services:
 3  mysql:
 4    image: mysql:8
 5    container_name: mysql
 6    restart: unless-stopped
 7    ports:
 8      - ${DB_PORT}:3306
 9    environment:
10      - MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
11      - MYSQL_DATABASE=${DB_DATABASE}
12      - MYSQL_USER=${DB_USERNAME}
13      - MYSQL_PASSWORD=${DB_PASSWORD}
14    volumes:
15      - ./data:/var/lib/mysql
16      - ./conf:/etc/mysql/conf.d

PostgreSQL

 1version: "3"
 2services:
 3  postgres:
 4    image: postgres:15
 5    ports:
 6      - ${PORT}:5432
 7    volumes:
 8      - ./data:/var/lib/postgresql/data
 9    environment:
10      - POSTGRES_USER=${POSTGRES_USER}
11      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
12      - POSTGRES_DB=${POSTGRES_DB}

RSSHub

1wget https://raw.githubusercontent.com/DIYgod/RSSHub/master/docker-compose.yml

Redis

 1version: "3"
 2services:
 3  redis:
 4    image: redis:alpine
 5    container_name: redis
 6    ports:
 7      - "${REDIS_PORT}:6379"
 8    restart: always
 9    command: "redis-server --requirepass ${REDIS_PASSWORD}"
10    # command: "redis-server"
11    volumes:
12      - ./data:/data

FakaShop

 1version: "3"
 2services:
 3  faka:
 4    image: ghcr.io/apocalypsor/dujiaoka:latest
 5    container_name: faka
 6    environment:
 7      - INSTALL=${INSTALL}
 8    volumes:
 9      - ./.env:/dujiaoka/.env
10      - ./uploads:/dujiaoka/public/uploads
11      - ./storage:/dujiaoka/storage
12    ports:
13      - ${PORT}:80
14    restart: always
15    depends_on:
16      - db
17      - redis
18  db:
19    image: mariadb:focal
20    container_name: faka-data
21    restart: always
22    environment:
23      - MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
24      - MYSQL_DATABASE=${DB_DATABASE}
25      - MYSQL_USER=${DB_USERNAME}
26      - MYSQL_PASSWORD=${DB_PASSWORD}
27    volumes:
28      - ./data:/var/lib/mysql
29  redis:
30    image: redis:alpine
31    container_name: faka-redis
32    ports:
33      - "${REDIS_PORT}:6379"
34    restart: always
35    command: "redis-server --requirepass ${REDIS_PASSWORD}"
36    volumes:
37      - ./redis:/data

 1# .env
 2INSTALL=false # first time -> true
 3PORT=80
 4APP_NAME=APP_NAME
 5APP_ENV=local
 6APP_KEY=APP_KEY
 7APP_DEBUG=false
 8APP_URL=APP_URL
 9ADMIN_HTTPS=false
10ADMIN_ROUTE_PREFIX=/admin
11
12DB_CONNECTION=mysql
13DB_HOST=db
14DB_PORT=3306
15DB_ROOT_PASSWORD=DB_ROOT_PASSWORD
16DB_DATABASE=dujiaoka
17DB_USERNAME=dujiaoka
18DB_PASSWORD=DB_PASSWORD
19
20REDIS_HOST=redis
21REDIS_PASSWORD=REDIS_PASSWORD
22REDIS_PORT=6379
23CACHE_DRIVER=redis
24QUEUE_CONNECTION=redis
25
26LOG_CHANNEL=stack
27BROADCAST_DRIVER=log
28SESSION_DRIVER=file
29SESSION_LIFETIME=120
30
31# zh_CN zh_TW en
32DUJIAO_ADMIN_LANGUAGE=zh_CN
33

技术问题追踪与处理记录

akynazh@gmail.com (zhihang) — Wed, 10 May 2023 18:13:33 +0800

Header Field Too Long

Bad Request - Header Field Too Long HTTP Error 400. A request header field is too long.

F12 清除 cookie

Tomcat DBCP JMX 问题

1Tomcat 9.x DBCP basicdatasource methods returning java.time.* cannot be mapped to JMX OpenType.

https://stackoverflow.com/questions/70803376/tomcat-9-x-dbcp-basicdatasource-methods-returning-java-time-cannot-be-mapped-t

We also struggled with this issue. Stumbled upon another question that was similar and someone mentioned a PR that lead us down the path of looking at commits in the tomcat project and the changelogs. If you look at the changelog for Tomcat 9.x you can find that for a dev/nightly release (at the time of this writing) of 9.0.59:

Revert the cherry-pick of JavaDoc fix from DBCP applied in 9.0.57 that broke the DataSourceMXBean by using a type that isn’t supported by MXBeans. (markt)

If you are still struggling with this you could either try the latest dev/nightly build (not yet published in maven central) or use version 9.0.56, which is what we used, and it should resolve this issue.

Tomcat 运行项目出现 Mysql 连接器问题

java.sql.SQLException: Cannot load JDBC driver class ‘com.mysql.cj.jdbc.Driver’ Caused by: java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver

这意味着 Tomcat 在运行时无法加载 MySQL 的 JDBC 驱动类 com.mysql.cj.jdbc.Driver，通常是因为 MySQL JDBC 驱动（即 mysql-connector-java）没有正确部署到应用或 Tomcat 环境中。

下载 mysql-connector-java-8.0.33.jar 或更高版本
复制到 /usr/share/tomcat9-56/lib/
检查 context.xml 中的 driverClassName 是否为 com.mysql.cj.jdbc.Driver

WSL Gradle JVM 问题

使用 Windows-IDEA 打开项目，执行 Main 函数时无法找到 JVM，执行 Spring Application，Test 等都没问题。

使用 Windows-IDEA-WSL 打开项目，执行 Main 函数时成功。

大概率就是 Gradle 插件的问题，如果需要执行 Main 函数，就到别的地方执行，或者使用 Windows-IDEA-WSL 打开项目吧。

跨域问题

SpringBoot 跨域配置

这是一段跨域配置的代码，有一些问题需要注意。

 1@Configuration
 2public class CorsConfig implements WebMvcConfigurer {
 3    @Override
 4    public void addCorsMappings(CorsRegistry registry) {
 5        registry.addMapping("/**")
 6                .allowedOriginPatterns("http://127.0.0.1:*", "https://127.0.0.1:*", "http://localhost:*", "https://localhost:*")
 7                .allowedMethods("GET", "HEAD", "POST", "PUT", "DELETE", "OPTIONS")
 8                .allowCredentials(true)
 9                .allowedHeaders("*")
10                .maxAge(3600);
11    }
12}

第一，127.0.0.1 和 localhost 需要同时指定！通过测试，如果只指定其中一个，无法进行另一个的请求。

第二，当项目里使用的 springboot 的版本是 2.1.2.RELEASE 时，使用 allowedOrigins("*") 没有问题，但是当版本改为 2.4.4 后会提示报错。

当 allowCredentials 为 true 时，allowedOrigins 不能包含特殊值 “*"，因为它不能在 “Access-Control-Allow-Origin” 响应头中设置。

要允许一组起源的凭证，明确地列出它们，或者考虑使用 allowedOriginPatterns 代替。

Options 请求跨域问题

在浏览器内请求跨域时，浏览器会先进行一次 preflight request（预检请求），以确认目标域是否允许跨域，如果允许，再进行实际操作中的请求。

在接口请求中我们总会自定义请求头做 token，但是浏览器预检请求中的 OPTIONS 只会携带自定义的 token 字段但不会带相应的值，导致跨域以及报错。

所以要处理跨域以及在 SpringSecurity 的认证过滤器链中需要过滤掉 OPTIONS。

如果使用的是 Interceptor，则可以在定义的拦截器中将 OPTIONS 方法的请求放行即可。

 1@Component
 2public class EnterInterceptor implements HandlerInterceptor {
 3    @Override
 4    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
 5        if (request.getMethod().equals("OPTIONS")) {
 6            return true;
 7        }
 8        if (AuthUtil.checkToken(request)) {
 9            return true;
10        } else {
11            response.sendRedirect("/api/error/401/" + URLEncoder.encode("token 验证失败", "UTF-8"));
12            return false;
13        }
14    }
15}

除此之外，为节省资源，可以通过配置缓存时间以防止浏览器频繁进行预检请求。

在 CORS 中，当浏览器发送跨域请求时，服务器可以返回一个 Access-Control-Max-Age 响应头，它指定了在这个响应被缓存多久。这意味着，在接下来的一段时间内，浏览器不需要向服务器再发送预检请求，而可以直接发送实际请求。

还是如下这段跨域配置代码：

1@Override
2public void addCorsMappings(CorsRegistry registry) {
3    registry.addMapping("/**")
4            .allowedOriginPatterns("http://127.0.0.1:*", "https://127.0.0.1:*", "http://localhost:*", "https://localhost:*")
5            .allowedMethods("GET", "HEAD", "POST", "PUT", "DELETE", "OPTIONS")
6            .allowCredentials(true)
7            .allowedHeaders("*")
8            .maxAge(3600);
9}

在上面的代码片段中，maxAge(3600) 指定了响应在缓存中的最长时间为 3600 秒（1 小时），在这段时间内，浏览器将不再发送预检请求，从而提高了跨域请求的性能和效率。然而，需要注意的是，设置 maxAge 过长可能会导致安全风险，因为在这段时间内，任何网站都可以使用这个响应进行访问。因此，应该根据实际需求设置一个适当的值。

fastjson 反序列化对象修饰符问题

1Caused by: java.lang.IllegalAccessException: class com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer cannot access a member of class com.jzh.test.json.SubmitTime with modifiers "public"

fastjson 通过有参构造函数反序列化可能会出现此问题，原因是 SubmitTime 这个类没有被 public 修饰，而其构造函数使用 public 修饰，所以导致反序列化失败。而如果通过无参构造加 setter 进行反序列化则无此问题。

本地多线程测试天坑: 测试方法开的线程没跑完

如果测试方法中包含异步操作，那么直接运行测试方法，异步方法未执行完成时，主线程已经退出，导致异步方法无法正常执行完！！

解决方法是在 @Test 测试方法中打个断点，不要让 @Test 的方法直接完成退出！

IDEA maven reload : out of memory error

Maven | Importing | VM options for importer: -Xmx6144m

sqlite-jdbc No native library is found

1Caused by: java.lang.Exception: No native library is found for os.name=Mac and os.arch=aarch64. path=/org/sqlite/native/Mac/aarch64

If you are using Apple M1 chip

One of the release notes they have mentioned by jetpack (Version 2.4.0-alpha03 )

Fixed an issue with Room’s SQLite native library to support Apple’s M1 chips. Change Version to 2.4.0-alpha03 or above

For those who are facing this problem, you can simply add this line before the room-compiler as a workaround now:

kapt “org.xerial:sqlite-jdbc:3.34.0”

hibernate + sqlite 问题

 1Description:
 2
 3An attempt was made to call a method that does not exist. The attempt was made from the following location:
 4
 5    org.sqlite.hibernate.dialect.SQLiteDialect.<init>(SQLiteDialect.java:57)
 6
 7The following method did not exist:
 8
 9    'void org.sqlite.hibernate.dialect.SQLiteDialect.registerColumnType(int, java.lang.String)'
10
11The calling method's class, org.sqlite.hibernate.dialect.SQLiteDialect, was loaded from the following location:
12
13    jar:file:/Users/zh/.m2/repository/com/github/gwenn/sqlite-dialect/0.1.2/sqlite-dialect-0.1.2.jar!/org/sqlite/hibernate/dialect/SQLiteDialect.class
14
15The called method's class, org.sqlite.hibernate.dialect.SQLiteDialect, is available from the following locations:
16
17    jar:file:/Users/zh/.m2/repository/com/github/gwenn/sqlite-dialect/0.1.2/sqlite-dialect-0.1.2.jar!/org/sqlite/hibernate/dialect/SQLiteDialect.class
18
19The called method's class hierarchy was loaded from the following locations:
20
21    org.sqlite.hibernate.dialect.SQLiteDialect: file:/Users/zh/.m2/repository/com/github/gwenn/sqlite-dialect/0.1.2/sqlite-dialect-0.1.2.jar
22    org.hibernate.dialect.Dialect: file:/Users/zh/.m2/repository/org/hibernate/orm/hibernate-core/6.4.1.Final/hibernate-core-6.4.1.Final.jar
23
24
25Action:
26
27Correct the classpath of your application so that it contains a single, compatible version of org.sqlite.hibernate.dialect.SQLiteDialect

fix:

From Hibernate 6, SQLite dialect is supported. We have to import in our pom.xml:

1<dependency>
2    <groupId>org.hibernate.orm</groupId>
3    <artifactId>hibernate-community-dialects</artifactId>
4</dependency>

Copy And in our application properties:

1spring.jpa.database-platform=org.hibernate.community.dialect.SQLiteDialect

 1        <!--jpa-->
 2        <dependency>
 3            <groupId>org.springframework.boot</groupId>
 4            <artifactId>spring-boot-starter-data-jpa</artifactId>
 5        </dependency>
 6        <!-- sqlite -->
 7        <dependency>
 8            <groupId>org.xerial</groupId>
 9            <artifactId>sqlite-jdbc</artifactId>
10            <version>3.34.0</version>
11        </dependency>
12<!--        <dependency>-->
13<!--            <groupId>com.github.gwenn</groupId>-->
14<!--            <artifactId>sqlite-dialect</artifactId>-->
15<!--            <version>0.1.4</version>-->
16<!--        </dependency>-->
17        <dependency>
18            <groupId>org.hibernate.orm</groupId>
19            <artifactId>hibernate-community-dialects</artifactId>
20        </dependency>

具体就是要删去 sqlite-dialect 并引入 hibernate-community-dialects，然后添加 jpa 配置。

JAR 包项目文件上传问题

获取类路径：

如果单纯运行一个 java 项目：${project}/target/classes

如果是运行 jar 包，且是在 Linux 系统上：${jar包名}!/BOOT-INF/classes!

所以如果是 jar 包启动并上传文件，则无法正确放到类路径下，需指定新的上传路径。

可以在 jar 包同一路径下新建并编辑 application.yaml 文件如下：

1spring:
2    resources:
3        static-locations:
4            - classpath:static/
5            - file:/app/static/

然后在文件上传是指定上传路径即可。

类文件具有错误的版本 55.0, 应为 52.0

上面报错中的 55.0 是 JDK11 使用的类文件格式 (class file format) 的版本号，提示的意思是当面项目使用的类文件格式版本比某个依赖包使用的类文件格式版本低。

实际就是指当前项目使用的 JDK 版本比某个依赖包使用的 JDK 版本低。

Mockito 5.8 使用了 JDK 11，而项目使用 JDK 8，那么会报错。

The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]

Remove “TLSv1, TLSv1.1” from “jdk.tls.disabledAlgorithms” property in file ${soapui_home}/jre/conf/securityjava.security.

RocketMQ: It may be caused by one of the following reasons: the broker’s disk is full

1cd conf/2m-2s-sync
2
3vim broker-a.properties
4diskMaxUsedSpaceRatio=99

SpringBoot 3.X 使用 SpringBoot 2.X 的 Starter 无法完成自动装配

SpringBoot 3.X 自动装配类通过 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 配置，而 2.X 通过 META-INF/spring.factories 完成，所以无法完成自动装配。解决方式是自己通过 @Bean 和 @Configuration 装配 Bean。

list.remove() 正确的使用重载

调用 set.remove(i) 选择重载 remove(E) 方法，其中 E 是 set (Integer) 的元素类型，将基本类型 i 由 int 自动装箱为 Integer 中。这是你所期望的行为，因此程序最终会从集合中删除指定大小的值。

调用 list.remove(i) 的调用选择重载 remove(int i) 方法，它将删除列表中指定位置的元素。若要删除指定大小的元素，对于 List<E> 接口对方法有的两个重载: remove(E) 和 remove(int)，需要强制转换的参数为类型，迫使其选择正确的重载。

后端返回的 json 数据格式出错

首先注意，json 采用驼峰命名法。

一般对于前后端分离的项目，后端都是返回 json 格式数据，比如使用 @RestController 进行自动的转换。

对于一个采用驼峰命名法命名的变量，比如 userId，转换后返回前端的 json 属性名是 userId，没有问题。

但是当变量名为 uId时，转换后则变为 uid，这就产生了问题。我还测试了其它一些变量，如下：

1# userId
2{"code":200,"msg":"ok","obj":{"userId":"hello"}}
3# uId
4{"code":200,"msg":"ok","obj":{"uid":"hello"}}
5# Id
6{"code":200,"msg":"ok","obj":{"id":"hello"}}
7# uuId
8{"code":200,"msg":"ok","obj":{"uuId":"hello"}}

可见当为 uId 和 Id 时，都会出现问题。

一般可以考虑在后端变量命名时，不让第二个字符大写，或者采用 @JsonProperty("uId") 进行解决。

IDEA 中在 maven 配置文件中配置 JVM 启动参数

有些是 .maven/maven.config，有些是 .mvn/jvm.config，必须在设置 > maven 中查看。

BigDecimal 构造函数的结果可能不可预测

1BigDecimal amount1 = new BigDecimal(0.02);
2BigDecimal amount2 = new BigDecimal(0.03);
3System.out.println(amount2.subtract(amount1));
4// 0.0099999999999999984734433411404097569175064563751220703125

正确方法：

1BigDecimal amount1 = BigDecimal.valueOf(0.02);
2BigDecimal amount2 = BigDecimal.valueOf(0.03);

反序列化 boolean 字段失败的问题

直接以一个例子说明这个问题：

 1public class FastJsonTest {
 2    @Test
 3    public void test1() {
 4        Vote vote = new Vote();
 5        vote.setTitle("test");
 6        vote.setIsOverdue(true);
 7        vote.setDeleted(false);
 8        vote.setImportant(true);
 9        String voteJson = JSON.toJSONString(vote);
10        System.out.println(voteJson);
11        // {"deleted":false,"important":true,"isOverdue":true,"title":"test"}
12
13        // ok
14        Vote voteFromJson = JSON.parseObject(voteJson, Vote.class);
15        System.out.println(voteFromJson);
16
17        // {"deleted":false,"isImportant":true,"isOverdue":true,"title":"test"}
18        String anotherVoteJson = "{\"deleted\":false,\"isImportant\":true,\"isOverdue\":true,\"title\":\"test\"}";
19        Vote anotherVote = JSON.parseObject(anotherVoteJson, Vote.class);
20        System.out.println(anotherVote);
21        // 反序列化失败：
22        // Vote(isOverdue=true, deleted=false, isImportant=false, title=test)
23    }
24}
25
26@NoArgsConstructor
27@Data
28class Vote {
29    // ok
30    private Boolean isOverdue;
31    // ok
32    private Boolean deleted;
33    // fail
34    private boolean isImportant;
35
36    private String title;
37}

使用 fastjson 反序列化时，由于 Vote 对象存在空参构造, 所以将根据 set 方法反序列化，如果字段是 Boolean 类型，那么反序列化成功，如果是 boolean 类型，且字段命名以 is 开头，那么反序列化失败。

所以，建议布尔类型都不要加 is 作为前缀，否则部分框架解析可能会有问题。(来自阿里巴巴 Java 开发手册)

maven 的 http 问题

Maven 升级到 3.8.1 之后，执行 mvn clean package 命令后会报错如下：

1maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories

maven 在 3.8.1 的默认配置文件中增加了一组标签，如果仓库镜像是 http 而不是 https 就会被拦截禁止访问

新增节点：

1<mirror>
2    <id>maven-default-http-blocker</id>
3    <mirrorOf>dummy</mirrorOf>
4    <name>Dummy mirror to override default blocking mirror that blocks http</name>
5    <url>http://0.0.0.0/</url>
6</mirror>

或回退版本

Failed to determine a suitable driver class

 12023-05-31T16:52:18.233+08:00  WARN 28432 --- [           main] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSource' defined in class path resource [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]: Failed to instantiate [com.zaxxer.hikari.HikariDataSource]: Factory method 'dataSource' threw exception with message: Failed to determine a suitable driver class
 22023-05-31T16:52:18.235+08:00  INFO 28432 --- [           main] o.apache.catalina.core.StandardService   : Stopping service [Tomcat]
 32023-05-31T16:52:18.250+08:00  INFO 28432 --- [           main] .s.b.a.l.ConditionEvaluationReportLogger : 
 4
 5......
 6
 7Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured.
 8
 9Reason: Failed to determine a suitable driver class
10
11
12Action:
13
14Consider the following:
15  If you want an embedded database (H2, HSQL or Derby), please put it on the classpath.
16  If you have database settings to be loaded from a particular profile you may need to activate it (no profiles are currently active).

关键在于：

1Error creating bean with name 'dataSource' defined in class path resource [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]: Failed to instantiate [com.zaxxer.hikari.HikariDataSource]: Factory method 'dataSource' threw exception with message: Failed to determine a suitable driver class

可以发现是 springboot 自动配置的锅，找不到一个合适的 driver 进行数据源的连接。

解决方法：

1@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})

隐藏的依赖版本冲突问题

当我从 SpringBoot 2.7 迁移到 SpringBoot 3.0 时，发现项目启动报错，原来的项目能正常启动，证明可能是依赖错误的问题了。

而 pom.xml 中有着很多依赖，由于是和 SpringBoot 有关，所以估计是一些第三方的 starter 有问题，最终发现是 MybatisPlus 的 3.4.3.4 版本不能正常在 SpringBoot 3.0 中使用，升级到 3.5.3.1 就没这个问题了。

BufferedWriter 无法正确写出问题

这是一段客户端代码，向服务器端发送消息，然后接收服务器端的回复：

 1try (
 2        BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
 3        BufferedWriter out = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()))
 4) {
 5    String message;
 6    while((message = stdIn.readLine()) != null) {
 7        out.write(message);
 8        out.flush();
 9        System.out.println("Receive from server: " + in.readLine());
10    }
11} catch (Exception e) {
12    System.out.println(e.getMessage());
13}

这是服务端代码的一部分，接收客户端消息，并向客户端回复：

 1try (
 2        BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
 3        BufferedWriter out = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()))
 4) {
 5    String message;
 6    while((message = in.readLine()) != null) {
 7        System.out.println(Thread.currentThread().getName() + ": receive from port " + socket.getPort() + ": " + message);
 8        out.write(message);
 9        out.flush();
10    }
11} catch (Exception e) {
12    System.out.println(e.getMessage());
13}

这里两端都使用了 BufferedReader 和 BufferedWriter 作为消息的传输工具。

经过测试发现，消息传输是失败的。

问题出现在 out.write(message); 和 message = in.readLine() 这两个地方，因为 in.readLine() 读取的是一行数据，即数据必须要存在换行符，如果不存在的话将无法读完，一直处于阻塞状态。

所以，解决方法就是将写出的数据通过 newLine 操作加上换行符：

1out.write(message); // 如果使用BufferedWriter，则需要添加换行符
2out.newLine();

另一种更好的方法是使用 PrintWriter，使用它的写出操作 println 进行消息的输出。

pnpm build error: Rollup

构建失败的原因是 Rollup 在处理代码时遇到了一个错误：Cannot read properties of null (reading ‘render’)。这种错误通常与代码中的某些语法或依赖问题有关。

某些第三方库可能与 Rollup 不兼容，尤其是使用了动态导入或复杂语法的库。检查 node_modules 中是否有库的版本更新或损坏。

1# 清理缓存
2pnpm store prune
3# 删除 node_modules 和 lock 文件
4rm -rf node_modules pnpm-lock.yaml
5# 重新安装依赖
6pnpm install

Spark: Cannot safely cast

Spark-sql 执行 sql 语句报：Cannot safely cast xxx string to int.

原因是 spark-sql 执行 sql 有三中模式：ANSI, LEGACY, STRICT。

ANSI 模式是标准 sql，不允许不合理的类型转换，与 PostgreSQL 相同；
LEGACY 模式允许类型强制转换，只要它是有效的 Cast，这也是 Spark 2.x 中的唯一行为，它与 Hive 兼容；
STRICT 模式下 Spark 不允许任何可能的精度损失或数据截断。

解决方法是添加如下配置即可：

1spark.sql.storeAssignmentPolicy=LEGACY

Node: Error message “error:0308010C:digital envelope routines::unsupported”

1export NODE_OPTIONS=--openssl-legacy-provider

Apple Watch 无法更新，一直显示已暂停

在 Apple Watch 中的储存空间下删除之前的更新文件即可。

Apple Map icloud 关闭同步后指南丢失

卸载重装 Apple Map 即可

go build stuck

1go build -v -o bepusdt ./main
2github.com/goccy/go-json/internal/encoder/vm
3
4# stuck here

Try cleaning the build cache to ensure that no corrupted files are causing the problem.

1go clean -cache -modcache -i -r

iterm2 scp 下载每次都要询问 key

1ssh-add -K ~/.ssh/id_rsa

latex 中文编码问题

1\usepackage{CJKutf8}
2
3\begin{document}
4\begin{CJK}{UTF8}{gbsn}
5...
6\end{CJK}
7\end{document}

certbot renew 报错 urlib3 依赖问题

try:

1pip install --upgrade --force-reinstall 'requests==2.6.0' urllib3

I’ve had the same problem https://niuhp.com/other/https-certbot.html

mybatis 判断和语法错误

1<if test="employeeIds != null and employeeIds.size > 0">
2    AND A.EmployeeId in
3    <foreach collection="employeeIds" index="index" item="item" open="(" separator="," close=")">
4        #{item}
5    </foreach>
6</if>
7
8ORDER BY A.FeedId DESC

and employeeIds.size > 0 不可少否则报错：

1org.springframework.jdbc.BadSqlGrammarException

curl 请求路径正确但报 404 或参数反序列化异常

去掉 content-length 限制 -H 'Content-Length: 19'

sqlserver TLSv1 was negotiated. Please update server and client to use TLSv1.2 at minimum.

由于公司的 sqlserver 只支持 tls1 所以需要安装旧版本 driver 并配置 VM option：

1"-Djdk.tls.disabledAlgorithms=SSLv3, TLSv1.1, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL"

driver 使用 8 及以下版本即可。

Unittest test discovery error for workspace

12024-02-05 15:27:34.532 [error]     from typing_extensions import Literal, NotRequired, TypedDict
2  File "/Users/zh/.vscode/extensions/ms-python.python-2024.0.0/pythonFiles/lib/python/typing_extensions.py", line 916
3    def TypedDict(typename, fields=_marker, /, *, total=True, **kwargs):
4                                            ^
5SyntaxError: invalid syntax
6
72024-02-05 15:27:34.544 [error] Subprocess exited unsuccessfully with exit code 1 and signal null on workspace /Users/zh/Codes/jvav. Creating and sending error discovery payload 
8
92024-02-05 15:27:34.544 [error] Unittest test discovery error for workspace:  /Users/zh/Codes/jvav

Fixed by #21757:

Thank you for your issue report. We are looking into this now! In the meantime, you are likely on the new testing rewrite and this is why you saw a change in behavior. You can opt out of the rewrite as I get this fix in by setting this in your user settings: “python.experiments.optOutFrom”: [“pythonTestAdapter”],. If this doesn’t work let me know as this will mean it is a different issue. Thank you and I will send updates in this thread as I get a fix in.

1// settings.json
2"python.experiments.optOutFrom": ["pythonTestAdapter"]

Gitignore 失效

1git rm -rf --cached .
2git add .

Nginx Error PID

1nginx: [error] invalid PID number "" in "/run/nginx.pid"

1pkill nginx
2nginx
3nginx -s reload

Nginx 相对地址资源引用不走反向代理

1location /pay/usdt/ {
2  sub_filter 'src="/img/'  'src="/pay/usdt/img/';
3  sub_filter 'src="/js/' 'src="/pay/usdt/js/' ;
4  sub_filter 'src="/css/' 'src="/pay/usdt/css/' ;
5  sub_filter_once off;
6  
7  proxy_pass http://127.0.0.1:8080/;
8}

Nginx 无法加载 css

1http {
2    include /etc/nginx/mime.types;
3}

dujiaoka 重启后前台需要重新安装

1# enter dujiaoka container
2echo "ok" > /dujiaoka/install.lock

manpath: can’t set the locale; make sure $LC_* and $LANG are correct

Add these lines to /etc/environment:

1LANG=en_US.utf-8
2LC_ALL=en_US.utf-8

RSSHub commit 不通过

报错提示说缺少某个依赖(pinyin-pro)，是文档相关的。

如果修改了文档，那么需要到 website 下运行 pnpm i 安装相关依赖，以便于 commit 检查。

InfluxDb 引号问题

插入数据时，tag 不带引号，field 字符串类型带双引号

查询数据时，字符串类型带单引号

docker-compose 容器内无法连接服务的问题

这是一个 docker-compose 配置文件:

 1version: "3"
 2
 3services:
 4  cache:
 5    image: redis
 6    command: bash -c "mkdir -p ${PATH_REDIS} && touch ${PATH_REDIS}/redis.conf && redis-server ${PATH_REDIS}/redis.conf"
 7    ports:
 8      - "6379:6379"
 9    volumes:
10      - ${HOST_PATH_ROOT}/redis:${PATH_REDIS}
11      - ${HOST_PATH_ROOT}/redis/data:/data
12  web:
13    build: .
14    volumes:
15      - ${HOST_PATH_ROOT}:${PATH_ROOT}
16    depends_on:
17      - cache
18    # network_mode: "host"

我组织了两个容器服务，redis 和 web，在 web 中需要连接到 redis，如果指定的 redis 地址为 127.0.0.1 则无法连接到，报错如下：

1ERROR: 无法连接到 redis 服务: 127.0.0.1:6379 : Error 111 connecting to 127.0.0.1:6379. Connection refused.

这是因为通过 docker-compose 组织的容器，主机名被设置为 cache 和 web，将 127.0.0.1 改为 cache 即可。

XX 不允许发送按键

执行发送按键的 applescript 时可能会失败：

1execution error: “System Events”遇到一个错误：“osascript”不允许发送按键。 (1002)

在隐私与安全性 -> 辅助功能 -> + -> 添加 /usr/bin/osascript 即可

.gitignore 反选的正确用法

排除 /.xxx 下除了 jvm.cfg 的所有文件:

1/.xxx/*
2!/.xxx/jvm.cfg

如果 /.xxx/* 写为 /.xxx/ 或 /.xxx 都将失效，因为这样忽略的是 ./xxx 这个文件夹，而不是整个文件夹下的文件，导致反选无效。

brew 安装报错 curl: (56) Failure when receiving data from the peer

1git config --global http.sslVerify "false"
2git config --global https.sslVerify "false"

oh-my-zsh agnoster 主题乱码问题

从这个链接下载字体文件： https://github.com/lxbrtsch/Menlo-for-Powerline

1mv "Menlo for Powerline.ttf" ~/Library/Fonts

VSCode -> Terminal Font Family 设置字体为 Menlo for Powerline

Terminal -> 设置 -> 字体 -> 更改

docker-compose volume 指定对象为文件时产生的问题

如果指定为文件（命名为 a），且事先没有创建该文件，那么当启动后，docker 将会自动创建一个名为 a 的目录。

这样就读取不到该文件了。

所以，如果指定的对象为文件，建议先创建。

Sqlite3 执行 sql 出错

1sqlite> select * from t_record where comment != "";
2Parse error: no such column:
3  select * from t_record where comment != "";
4                            error here ---^

应该将双引号改为单引号。

根据 SQL 标准，通常在标识符（例如表名或列名）周围使用双引号，而在字符串字面量周围使用单引号。

在 3.41 版本往后 cli 默认禁用了双引号表示字符串，使用单引号就不报错了：https://www.sqlite.org/quirks.html#double_quoted_string_literals_are_accepted

iterm2 无法使用 scp

1# server side
2vim .zprofile
3export iterm2_hostname=your_server_global_ip
4# then relogin

Python 版本冲突问题

certbot 依赖系统 python3 的 requests 包，但它和某个项目依赖的 requests 包版本不一样，如果项目不使用 venv，将会导致 certbot 不可用。

建议在资源允许的情况下所有项目都使用 venv 来隔离 python 环境。

Python requests_cache 在多线程环境下发生错误 “database is locked”

代码包含了使用了 requests_cache 的引用包，而引用包中存在的 requests_cache.install_cache 将影响所有范围的 requests，代码中有着多线程操作，其中某个线程长时间占用 sqlite，锁长时间无法释放，从而导致其它线程无法访问数据库（sqlite3 本身是线程安全的）、CPU 占用率飙升。引用包建议单独使用 requests_cache.CachedSession 完成操作。

FYI, a better option for using requests-cache is using CachedSession directly, instead of patching with install_cache(). It makes it more explicit what you are and aren’t caching, and doesn’t affect downstream requests calls. It’s mostly thread-safe, except for cache_disabled(), as you noted; instead, when you want to make a non-cached request, you can just use a regular requests.Session.

[Errno 24] Too many open files

1ulimit -n 50000

Django 手动删除 migrations 目录后 migrate 无效

1python3 manage.py migrate --fake <app-name> zero
2python3 manage.py makemigrations <app-name>
3python3 manage.py migrate

mac m1 python3.7.9 ModuleNotFoundError: No module named ‘_ctypes’

Use python3.7.12 instead.

Windows 下安装 lxml 报错

1Error while installing lxml through pip: Microsoft Visual C++ 14.0 is required

Run pip install wheel
Download lxml from http://www.lfd.uci.edu/~gohlke/pythonlibs/#lxml, if your python version is 3.5, download lxml-3.6.4-cp35-cp35m-win32.whl (补充一句: 经测试 3.12 版本的安装无法 3.11 版本的)
Run pip install lxml-3.6.4-cp35-cp35m-win32.whl

UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xff in position 0: invalid start byte

byte 0xff in position 0 could also mean the file is encoded in UTF-16, then you can do with open(path, encoding=‘utf-16’) as f: instead

包冲突

1ModuleNotFoundError: No module named 'utils.util_bus'; 'utils' is not a package

项目下的 utils 文件夹 <-> pip 某个依赖包中的 utils.py 文件名 “utils” 冲突！

默认先扫描当前目录下包，但是识别不到 utils 包，因为 utils 文件夹下缺失了 __init__.py 文件！

SSLError(SSLCertVerificationError)

使用 requests 库时出现 bug:

1(Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:997)')))

解决方法：python-requests-throwing-sslerror

From requests documentation on SSL verification:

Requests can verify SSL certificates for HTTPS requests, just like a web browser. To check a host’s SSL certificate, you can use the verify argument:

1requests.get('https://kennethreitz.com', verify=True)

pipenv 无法正常 install

1PS C:\Users\akyna\Codes\test\test_py> pipenv install
2Usage: pipenv install [OPTIONS] [PACKAGES]...
3
4ERROR:: --system is intended to be used for pre-existing Pipfile installation, not installation of specific packages. Aborting.

解决方法：

因为pipenv检测到之前在该目录下创建过了环境，需要先删除之前的环境才可以：

1PS C:\Users\akyna\Codes\test\test_py> pipenv --rm
2Removing virtualenv (C:\Users\akyna\.virtualenvs\test_py-_qApXuy4)...

Python requests 库 headers 字段编码错误

1UnicodeEncodeError: 'latin-1' codec can't encode characters in position 30-34: ordinal not in range(256)

解决方法：

加上.encode(‘utf-8’)：

1return {
2    'User-Agent':
3    'Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36',
4    'Host': HOST,
5    'Connection': 'close',
6    'X-Requested-With': 'XMLHttpRequest',
7    'Referer': url.encode('utf-8'), ## fix bug
8}

python + crontab 环境变量

crontab运行python时，如果python中使用了环境变量，将无法正常获取。

解决方法：

在crontab中配置好 python 中用到的环境变量：

1## backup
20 1 * * * env code=/root/Codes /bin/bash /root/Codes/scripts/unix/bbak
3## tg send
40 8 * * * env code=/root/Codes /bin/python3 ~/Codes/scripts/py/submit_tg_send.py

Python 关于爬虫所设置的 Headers 中的 UserAgent

这是一个很难以发现的点，但不能说是bug吧。

Headers 中的 UserAgent 可以配置不同的设备端，如果设置了类似于 Android 这样的手机端，那从 requests.get() 返回得到的页面是手机端的界面！如果这个网站手机端的界面和电脑端的界面不是一样的，那么这个问题是很值得注意的。

Clannad, 一曲治愈而忧伤的诗

akynazh@gmail.com (zhihang) — Thu, 27 Apr 2023 16:11:45 +0800

Clannad 是京都动画根据 Key 社同名游戏改编的电视动画作品，总体上，Clannad 给人的感觉还是温馨，治愈的，搞笑欢乐的情节也不少，但同时带有淡淡的忧伤。它富有情感的剧情和优雅的音乐，让它成为一曲动人的诗。

我想记录一下 Clannad 中让我印象深刻的一些故事，音乐，人物等，写写我的感受。

忧伤，温柔的轻音乐

《東風-piano-》by 折户伸治
《町, 時の流れ人》(小镇时光的流逝人) by 折户伸治
《潮鳴り》(潮鸣) by 折户伸治
《白詰草》(白诘草) by 折户伸治
《日々の遑》(日常生活) by 折户伸治
《空に光る》(天空中闪烁着光) by 戸越まごめ
《渚～坂の下の別れ》(渚~坡下的离别) by 麻枝准
《汐》by 戸越まごめ

Clannad 可谓是动画 BGM 的教科书，完美诠释了音乐在故事构建中的重要性。

每当《潮鳴り》响起，感情就会不由自主地被带动。就如《未闻花名》中《secret base》一曲一样。

Clannad 中很多音乐都带有一种淡淡的忧伤感，就比如《渚～坂の下の別れ》，但其实也都是温柔而治愈的。

《白詰草》给人就是一种温柔的感觉，每当听到这一曲，就会觉得很舒服，优雅婉转的笛声，久久难忘。

即使如此，你还会喜欢上这里吗

无法忘记渚在那条樱花坡道上说了的这么一段话：

你喜欢这所学校吗

我非常非常喜欢

但所有的这一切，都在不断变化着

无论是多么愉快的事，还是多么开心的事，一切

都在不断改变着

即使如此，你还会喜欢上这里吗

时间带走了许多东西，我们曾经一起度过的岁月一去不返。那片老树林已经不见了，取而代之的是一座高楼。学校的旧教室将要翻新，旧时安静的街道现在已经车水马龙，忙忙碌碌。

我们人的一生总在经历着变化，永无止境的变化，然而尽管如此，你还会喜欢上那些变化后的事物吗？

我接受着变化，但是我无法忘记从前，无法忘记那些旧事物的模样。记忆是一种美好的东西，但又是一种残忍的东西。人的一生是漫长的，但又是稍纵即逝的。珍惜当下吧，因为很快当下这一切又将成为回忆！

伊吹风子的故事

风子是一个相当可爱的角色，她作为一个思念体而存在着。

她的姐姐伊吹公子每天都会去医院看望她，尽管医生说风子可能已经不会再醒过来。伊吹公子有着婚约，但是一直不愿意无法放下妹妹，让自己去幸福，她内心怀着坚定的信念，相信妹妹风子有一天会醒过来。但风子希望姐姐放下自己，去追寻自己的幸福，她不希望姐姐因为自己而无法获得属于自己的幸福。

寄托着风子愿望的亲情，让风子化作思念体，来到学校，整天在旧校舍空教室里默默雕刻，并把雕刻得像星型的木雕分送给人，当做姐姐公子婚礼上的请帖。

最后，风子终于完成了自己的愿望。姐姐似乎感受到了风子的心意，勇敢地放下负担，去追求自己的幸福。在婚礼的最后，风子将最后一个海星送给了姐姐，说完”一直，一直要幸福哦“，便化作一阵风，伴随着《Ana》这一首动人的歌曲，永远地消失在了空中：

The place changes and goes

Like a wind like clouds

Like the traces of the heart

No halt at the places

风子是我最喜欢的角色之一，特别喜欢她俏皮可爱而又天然呆的样子ヾ(≧▽≦*)o 风子赛高！

你的梦想就是我们的梦想

当渚意外翻到爸妈的青春回忆录，内心几乎快要奔溃。她终于知道了爸妈一直对自己隐瞒的事。

渚小的时候，有一次生病了。他们在安顿好了渚之后，由于都有着不能请假的理由，无法继续陪伴生病的渚，各自离开去处理自己的事情。而当他们回来后，看到的是因等待，寻找爸妈不得，害怕孤单，心力交瘁后晕倒在雪地中的女儿。

他们因为自己的失职而后悔不已，发誓要将自己的后半生的时间花在陪伴家人，照顾女儿上面。于是，他们放弃了自己的梦想，开了自己的面包店。而面包店的生活是十分幸福快乐的，他们并未感到后悔。

渚知道了爸爸曾经在高中时代也是演剧部的一员，上演了高水平的戏剧，成为一名优秀的演员是他的梦想。而自己现在也将要踏上舞台，去实现自己的梦想。她自责地认为是因为自己的原因让爸爸不能再去追求梦想，并对站上舞台产生了恐惧，丧失了自信。

当渚在舞台上抑制不住自己的感情而落泪，没有勇气和自信继续自己的戏剧时，爸爸古田秋生冲后面从了进来，大声地喊：“渚！你是笨蛋吗？孩子的梦想就是父母的梦想，由你去实现就行！我们梦想着你能实现自己的梦想，我们并没有放弃自己的梦想！只是把自己的梦想寄托在了你的梦想身上！所谓父母就是这样的，所谓家族就是这样的！所以，从那天开始就一直……一直过着烤面包的生活，一直……我们一直都在渴望着这一刻！如果你在这里气馁了，我们会很失落的！”……

最后，渚终于顺利完成了戏剧，大家的努力没有白费，渚也不再感到自责。

亲情是如此的伟大。看到这里，多少能理解一些为人父母的感觉。

无法再次抬起发力的右臂

冈崎的母亲因为事故过世，父亲绝望地失去了生活的希望，整日酗酒赌博，对儿子毫不关心。

冈崎在一次和父亲大打出手中，右臂受重伤，导致自己无法再次抬起右臂发力，进而让自己无法再碰篮球。

这让他在以体育生的身份进入的高中迷失了自我。

所幸，他遇到了和他一样迷失自我的春原，遇到了渚，还有其它一些朋友。

在一起为演剧部的建立而进行的篮球赛中，冈崎拼尽全力，终究投进了球。

尽管知道自己做不到，但还是去尝试，万一发生奇迹了呢？

在重建演剧部的过程中，冈崎邂逅了各式各样的人，为他们做出了自己力所能及的事，也渐渐接收过去遇到的种种挫折，认真地对待起了自己。到最后步入社会，拿到自己的第一份工作，右臂刚好会对这份工作造成影响。但他不是简单地逃避，也没有自怨自艾，而是努力克服自己的弱点，顺利完成了工作。

人生，要往前看，要善待他人，更要善待自己。

不要忘记，那些不应被忘记的事

冈崎在遇到奶奶，和她进行了一次长谈之后，渐渐回忆起了儿时的回忆，是关于他父亲的回忆，是一段他不该忘记的回忆。

他的父亲早年也丧失了自己的妻子，绝望的经历让他痛苦万分。尽管他仍无法摆脱绝望的心情，但是仍旧尽心尽力养育儿子，用少的可怜的积蓄给儿子买零食和玩具，供儿子上学。

儿时的记忆，往往会是我们一生中非常重要，但是又非常易于忘记的记忆。我们的父母在那段时间里，需要费很大的精力来养育我们，他们青春年华的色彩很可能就在那几年慢慢地褪去……

很多事情我们可能都只能等到自己为人父母时，才能慢慢地体会吧。

在那片美丽的花田，夕阳覆盖了父女两人，冈崎终于知道放下过去的伤痛，去珍惜和保护汐。

看不到终点的时间

在 Clannad 中不乏有非常令人绝望的剧情。在失去自己生命中最重要，最不可或缺的东西之后，冈崎陷入了绝望。在这段时间里，看不到希望，看不到生命的意义，这痛苦的每分每秒似乎将永远持续下去，没有终点。生与死的间隔，是永远，是彻底的天各一方。

我们人生中，无可避免的要经历生死离别。这是没有办法的事，我们只有真正珍惜过了，才能尽量地避免更多的悲伤和后悔。怎么说呢，人是一种有感情的生物，正是因为我们拥有感情，我们的生命才更加地有意义。所以，如果知道有一天自己在经历那些时刻时会感到悲伤，那就努力去珍视他们吧。

一生的朋友

昔日的好友重聚，人生中，能有几个能联系一辈子的朋友，真的很幸运。尽管各自有了自己新的，不一样的生活，但在重要的日子时，还是会抽时间聚在一起聊天，聊过去，聊现在。

在 Clannad 中，展现了很多人生的真实场景：离别，变化，重聚，我们一生都在面对着这样的事情。

每次返回家乡，我下意识地就会观察一下家乡的建筑，街道，哪家的店不见了呀，哪条街道又翻新了呀，会观察家里的家具的变化，会观察亲人的变化。我们无法阻止那些变化，但我们可以让不变的东西永远存在——感情。

很可惜的是，我没有从高中到现在，都能一直保持联系的朋友。在高中，初中，甚至更久以前，和我要好的那些朋友们，你们都还好吗？

其它一些值得记录的事情

远漂重洋的行李箱，装着的不是论文手稿，而是女儿想要的小熊。

因为受到父亲牵连的冈崎，在近乎奔溃的时候，渚给了他安慰，终于让他平静下来。或许，也只有渚才可以做到了吧。

冈崎或许正是在这时意识到了自己人生中不能没有渚，所以顺势地求婚了：

因为身体原因，无法和大家一起毕业的渚，终于在第五年顺利毕业了。可惜在毕业典礼当天，又因为身体原因无法参加。冈崎准备为渚准备一次毕业典礼。昔日的好友，虽然已经各自步向自己新的生活，但还是接受了邀请，来为自己的旧朋友送上祝福。

冈崎和怀孕后的渚坐在海边，一起为肚子里的孩子取名，取名为汐。冈崎希望渚和他一起许愿，来年，和汐一起，再来这里看海。

被芽衣妹妹教坏的渚同学：（其实就是想让平时总是不太自信的渚能表现得自信一点，结果闹笑话了，不过目的是达到了，和冈崎关系更进一步！）

在 After Story 中，可爱的风子醒过来了！仍旧是那个熟悉的味道，那个可爱俏皮的风子！

在最后的最后，我们看到了我们想看到的一幕，一家三口散步的场景。

后记

个人觉得总体来说，Clannad 真的值得一看吧，不管是音乐，剧情，还是对于人生的一些启示，都很不错。但由于它本身是游戏改编，所以有一些 IF 线剧集，个人不是很喜欢。另外前期有一定的后宫色彩，不是很好（但总体上是纯爱）。另外，个人也不是很能接受最后做梦的剧情，稍有点狗血（虽然也是为了推进剧情服务）。不管怎么说，瑕不掩瑜，Clannad 绝对称得上日漫中的经典之作，在亲情这类番剧中会是难以超越的作品。

Hugo 实现搜索功能

akynazh@gmail.com (zhihang) — Fri, 07 Apr 2023 21:48:58 +0800

前言

这里记录了两种实现方式，一种通过 Fuse 进行，一种通过 Algolia 进行。通过 fuse 实现是纯静态的方式，更为简单便捷，且很稳定，而通过 algolia 实现需要依赖于 algolia 服务，搜索功能更强大但可能不够稳定（特别是墙内用户）。

Fuse

生成搜索数据

在 layouts/_default/ 下新建 index.json 文件，编辑如下：

1{{- $.Scratch.Add "index" slice -}}
2{{- range .Site.RegularPages -}}
3    {{- $.Scratch.Add "index" (dict "title" .Title "tags" .Params.tags "categories" .Params.categories "contents" .Plain "permalink" .Permalink) -}}
4{{- end -}}
5{{- $.Scratch.Get "index" | jsonify -}}

在配置文件(这里以 config.yaml 为例)中进行输出文件的配置：

1outputs:
2  home: [HTML, JSON, RSS]

注意，HTML, JSON, RSS 分别生成 index.html, index.json, index.xml。

这样，运行 hugo 生成命令即可生成搜索数据文件 index.json。

下载引用 fuse

About fuse: Lightweight fuzzy-search, in JavaScript.

可以从 github 下载到 fuse。

将 fuse 脚本（fuse.min.js）放置到根路径下（比如 static/js）。

调用 fuse 实现搜索功能

该脚本参考了 github 上的代码，然后在一些地方进行了小改动。

  1var fuse; // holds our search engine
  2var fuseIndex;
  3var searchVisible = false;
  4var firstRun = true; // allow us to delay loading json data unless search activated
  5var list = document.getElementById("searchResults"); // targets the <ul>
  6var first = list.firstChild; // first child of search list
  7var last = list.lastChild; // last child of search list
  8var maininput = document.getElementById("searchInput"); // input box for search
  9var resultsAvailable = false; // Did we get any search results?
 10
 11// ==========================================
 12// The main keyboard event listener running the show
 13//
 14document.addEventListener("keydown", function (event) {
 15  // CMD-/ to show / hide Search
 16  if (event.altKey && event.which === 191) {
 17    // Load json search index if first time invoking search
 18    // Means we don't load json unless searches are going to happen; keep user payload small unless needed
 19    doSearch(event);
 20  }
 21
 22  // Allow ESC (27) to close search box
 23  if (event.keyCode == 27) {
 24    if (searchVisible) {
 25      document.getElementById("fastSearch").style.visibility = "hidden";
 26      document.activeElement.blur();
 27      searchVisible = false;
 28    }
 29  }
 30
 31  // DOWN (40) arrow
 32  if (event.keyCode == 40) {
 33    if (searchVisible && resultsAvailable) {
 34      console.log("down");
 35      event.preventDefault(); // stop window from scrolling
 36      if (document.activeElement == maininput) {
 37        first.focus();
 38      } // if the currently focused element is the main input --> focus the first <li>
 39      else if (document.activeElement == last) {
 40        last.focus();
 41      } // if we're at the bottom, stay there
 42      else {
 43        document.activeElement.parentElement.nextSibling.firstElementChild.focus();
 44      } // otherwise select the next search result
 45    }
 46  }
 47
 48  // UP (38) arrow
 49  if (event.keyCode == 38) {
 50    if (searchVisible && resultsAvailable) {
 51      event.preventDefault(); // stop window from scrolling
 52      if (document.activeElement == maininput) {
 53        maininput.focus();
 54      } // If we're in the input box, do nothing
 55      else if (document.activeElement == first) {
 56        maininput.focus();
 57      } // If we're at the first item, go to input box
 58      else {
 59        document.activeElement.parentElement.previousSibling.firstElementChild.focus();
 60      } // Otherwise, select the search result above the current active one
 61    }
 62  }
 63});
 64
 65// ==========================================
 66// execute search as each character is typed
 67//
 68document.getElementById("searchInput").onkeyup = function (e) {
 69  executeSearch(this.value);
 70};
 71
 72document.querySelector("html").onclick = function (e) {
 73  if (e.target.id !== "searchInput") {
 74    hideSearch();
 75    $("#menu").css("visibility", "visible");
 76  }
 77};
 78
 79searchBtn = document.getElementById("searchBtn");
 80if (searchBtn) {
 81  searchBtn.onclick = function (e) {
 82    $("#menu").css("visibility", "hidden");
 83    doSearch(e);
 84  };
 85}
 86
 87function doSearch(e) {
 88  e.stopPropagation();
 89  if (firstRun) {
 90    loadSearch(); // loads our json data and builds fuse.js search index
 91    firstRun = false; // let's never do this again
 92  }
 93  // Toggle visibility of search box
 94  if (!searchVisible) {
 95    showSearch(); // search visible
 96  } else {
 97    hideSearch();
 98  }
 99}
100
101function hideSearch() {
102  document.getElementById("searchInput").value = "";
103  document.getElementById("fastSearch").style.visibility = "hidden"; // hide search box
104  document.getElementById("searchResults").innerHTML = ""; // remmove results
105  document.activeElement.blur(); // remove focus from search box
106  searchVisible = false;
107}
108
109function showSearch() {
110  document.getElementById("fastSearch").style.visibility = "visible"; // show search box
111  document.getElementById("searchInput").focus(); // put focus in input box so you can just start typing
112  searchVisible = true;
113}
114
115// ==========================================
116// fetch some json without jquery
117//
118function fetchJSONFile(path, callback) {
119  var httpRequest = new XMLHttpRequest();
120  httpRequest.onreadystatechange = function () {
121    if (httpRequest.readyState === 4) {
122      if (httpRequest.status === 200) {
123        var data = JSON.parse(httpRequest.responseText);
124        if (callback) callback(data);
125      }
126    }
127  };
128  httpRequest.open("GET", path);
129  httpRequest.send();
130}
131
132// ==========================================
133// load our search index, only executed once
134// on first call of search box (CMD-/)
135//
136function loadSearch() {
137  console.log("loadSearch()");
138  fetchJSONFile("/index.json", function (data) {
139    var options = {
140      // fuse.js options; check fuse.js website for details
141      shouldSort: true,
142      location: 0,
143      distance: 100,
144      threshold: 0.4,
145      minMatchCharLength: 2,
146      keys: ["permalink", "title", "tags", "contents"],
147    };
148    // Create the Fuse index
149    fuseIndex = Fuse.createIndex(options.keys, data);
150    fuse = new Fuse(data, options, fuseIndex); // build the index from the json file
151  });
152}
153
154// ==========================================
155// using the index we loaded on CMD-/, run
156// a search query (for "term") every time a letter is typed
157// in the search box
158//
159function executeSearch(term) {
160  let results = fuse.search(term); // the actual query being run using fuse.js
161  let searchitems = ""; // our results bucket
162
163  if (results.length === 0) {
164    // no results based on what was typed into the input box
165    resultsAvailable = false;
166    searchitems = "";
167  } else {
168    // build our html
169    // console.log(results)
170    permalinks = [];
171    numLimit = 15;
172    for (let item in results) {
173      if (item > numLimit) {
174        break;
175      }
176      if (permalinks.includes(results[item].item.permalink)) {
177        continue;
178      }
179      //   console.log('item: %d, title: %s', item, results[item].item.title)
180      searchitems =
181        searchitems +
182        '<li><a href="' +
183        results[item].item.permalink +
184        '" tabindex="0">' +
185        "<span>" +
186        results[item].item.title +
187        "</span></a></li>";
188      permalinks.push(results[item].item.permalink);
189    }
190    resultsAvailable = true;
191  }
192
193  document.getElementById("searchResults").innerHTML = searchitems;
194  if (results.length > 0) {
195    first = list.firstChild.firstElementChild; // first result container — used for checking against keyboard up/down location
196    last = list.lastChild.firstElementChild; // last result container — used for checking against keyboard up/down location
197  }
198}

将该脚本放置到根路径下（比如 static/js）。

接着，在需要用到搜索功能的界面中同时引用 fuse 脚本和该脚本。

创建搜索块

在 partials 下创建 search.html，编写内容如下：

1<div id="fastSearch">
2  <input id="searchInput" tabindex="0" />
3  <ul id="searchResults"></ul>
4</div>

在需要调用搜索功能的地方放置 {{ partial "search.html" . }} 即可（同一界面需要引用了以上两个脚本）。

参考 css：

 1#fastSearch {
 2  visibility: hidden;
 3  font-size: 15px;
 4  z-index: 99999;
 5}
 6
 7#searchInput {
 8  color: $color-search-text;
 9  background-color: $color-search-bg;
10  position: fixed;
11  display: inline;
12  top: 30px;
13  right: 8px;
14  height: 30px;
15  width: 300px;
16  padding: 4px;
17  outline: none;
18}
19
20#searchResults {
21  visibility: inherit;
22  display: inline;
23  position: fixed;
24  top: 64px;
25  right: 8px;
26  width: 340px;
27  li {
28    padding: 4px;
29    list-style: none;
30    background-color: $color-search-bg;
31    border-bottom: 1px dotted $color-search-border;
32  }
33}
34
35@media (max-width: 683px) {
36  #searchInput {
37    top: 20px;
38    left: 15px;
39    right: auto;
40  }
41
42  #searchResults {
43    top: 50px;
44    left: -25px;
45    right: auto;
46  }
47}

创建搜索图标

上面的搜索块通过参考 css 作用，在未被触发的情况下是隐藏的。

通过点击搜索图标可以弹出搜索块，可以通过 font-awesome 快速实现：

1<a class="icon" href="#" id="searchBtn"><i class="fas fa-search"></i></a>

在需要用到的地方放置该代码块即可（同个界面还需要包含搜索块和之前的两个脚本）。

Algolia

注册账号并创建 Index

官网链接：Algolia，注册完成后保存好 ApiID 和 ApiKey。

接着，创建一个 Index，保存好 Index 的名称。

搜索数据生成及上传

这里可以通过 github action 方便地实现，另外也通过 hugo-algolia 插件的方式进行，但是个人认为不够方便，这里不介绍了。

配置 algolia 输出文件

 1outputs:
 2home:
 3    - HTML
 4    - RSS
 5    - Algolia
 6outputFormats:
 7    Algolia:
 8        mediaType: application/json
 9        baseName: algolia
10        isPlainText: true

生成 algolia.json

编辑 {site}/themes/layouts/_default/list.algolia.json 如下：

 1[
 2    {{- range $index, $entry := .Site.RegularPages }}
 3    {{- if $index }}, {{ end }}
 4        {
 5        "objectID": "{{ .File.TranslationBaseName }}",
 6        "url": {{ .Permalink | jsonify }},
 7        "title": {{ .Title | jsonify }},
 8        "date": {{ .PublishDate | jsonify }},
 9        "tags": {{ .Params.tags | jsonify }},
10        "categories": {{.Params.categories | jsonify}},
11        "summary": {{ .Summary | jsonify }},
12        "content": {{ .Plain | jsonify }}
13        }
14    {{- end }}
15]

这里可以自行查阅文档定制化查询数据。

接着，通过 hugo 相关命令即可在 public 下生成 algolia.json 文件，这样就得到了搜索数据。

在 GithubAction 新建工作流

 1name: Algolia Upload Records
 2on:
 3[push] # 推送时执行
 4jobs:
 5algolia:
 6    runs-on: ubuntu-latest
 7    steps:
 8    - name: Checkout
 9        # 获取代码 Checkout
10        uses: actions/checkout@v2
11    - name: Upload Records
12        # 使用 Action
13        uses: iChochy/Algolia-Upload-Records@main
14        # 设置环境变量
15        env:
16        APPLICATION_ID: ${{secrets.ALGOLIA_APPID}} # appID
17        ADMIN_API_KEY: ${{secrets.ALGOLIA_KEY}} # key
18        INDEX_NAME: ${{secrets.ALGOLIA_INDEX}} # index
19        FILE_PATH: algolia.json

注意添加好对应环境变量。

之后，每次 push 都会自动将 algolia.json 推送到 algolia 数据库啦。

关于搜索类型及优先级的设置

前往 algolia 的 indices 进行搜索类型的设置，可以选择按 tag，category，content 等内容进行搜索，并指定优先级。

这里也就是 algolia 更加强大的一个点了。

定制搜索框

在 {site}/themes/{theme}/layouts/partials 下创建 search.html：

 1<div id="modalSearch" class="modal fade" role="dialog">
 2    <div class="modal-dialog">
 3        <div class="modal-content">
 4            <div class="modal-body">
 5                <div class="aa-input-container" id="aa-input-container">
 6                    <input type="search" id="aa-search-input" class="aa-input-search" placeholder="write here..." name="search" autocomplete="off" />
 7                </div>
 8            </div>
 9        </div>
10    </div>
11</div>
12
13<script src="{{ "https://res.cloudinary.com/jimmysong/raw/upload/rootsongjc-hugo/algoliasearch.min.js" | absURL }}"></script>
14<script src="{{ "https://res.cloudinary.com/jimmysong/raw/upload/rootsongjc-hugo/autocomplete.min.js" | absURL }}"></script>
15<script>
16var client = algoliasearch("{appID}", "{key}");
17var index = client.initIndex('{indexName}');
18autocomplete('#aa-search-input',
19{ hint: false}, {
20    source: autocomplete.sources.hits(index, {hitsPerPage: 8}),
21    displayKey: 'name',
22    templates: {
23        suggestion: function(suggestion) {
24            var des_url = suggestion.uri;
25            var reg = /[《》（）]/g; // 转化一些中文字符，可以自己指定需要的
26            des_url = des_url.toLowerCase().replace(reg, ""); // 转为小写
27            return '<span>' + '<a href="' + des_url + '"">' +
28            suggestion._highlightResult.title.value + '</a></span>';
29        }
30    }
31});
32</script>

其中注意代码片段：

1var client = algoliasearch("{appID}", "{key}");
2var index = client.initIndex('{indexName}');

自己填入自己的 appID，key，index 名称即可。

最后在自己需要的地方放置搜索框即可：

1<!--搜索文章-->
2{{ partial "search.html" . }}

软件设计模式

akynazh@gmail.com (zhihang) — Fri, 31 Mar 2023 23:35:52 +0800

观察者模式

理解

对于观察者模式，既然有观察者，那么就首先有被观察者。

观察者可以通过订阅，监听等方式实现“观察”，被观察者需要通过通知，发消息之类的方式通知观察者接收信息。

假设有一个气象观测站，天气数据对象作为被观察者，各个气象观测站作为观察者订阅天气数据，而天气数据记录各个订阅了自己的观测站，以便于通知。

再比如 rss 订阅工具，它作为观察者，而各个用户订阅的 rss 地址作为被观察者，rss 订阅工具定时抓取 rss 内容，并将有更新的内容发送给用户。

实现

下面以气象站为例进行模拟实现。

首先定义两个接口：

被观察者：

1public interface Subject {
2	public void registerObserver(Observer o);
3	public void removeObserver(Observer o);
4	public void notifyObservers();
5}

观察者：

1public interface Observer {
2	public void update(float temp，float humidity，float pressure);
3}

接着，定义对象，实现接口：

天气数据对象：

 1public class WeatherData implements Subject {
 2	private List<Observer> observers;
 3	private float temperature;
 4	private float humidity;
 5	private float pressure;
 6	
 7	public WeatherData() {
 8		observers = new ArrayList<Observer>();
 9	}
10	
11	public void registerObserver(Observer o) {
12		observers.add(o);
13	}
14	
15	public void removeObserver(Observer o) {
16		observers.remove(o);
17	}
18	
19	public void notifyObservers() {
20		for (Observer observer : observers) {
21			observer.update(temperature，humidity，pressure);
22		}
23	}
24	
25	public void measurementsChanged() {
26		notifyObservers();
27	}
28	
29	public void setMeasurements(float temperature，float humidity，float pressure) {
30		this.temperature = temperature;
31		this.humidity = humidity;
32		this.pressure = pressure;
33		measurementsChanged();
34	}
35
36	public float getTemperature() {
37		return temperature;
38	}
39	
40	public float getHumidity() {
41		return humidity;
42	}
43	
44	public float getPressure() {
45		return pressure;
46	}
47
48}

气象观测站对象：

省略了 StatisticsDisplay 和 ForecastDisplay。

 1public class CurrentConditionsDisplay implements Observer {
 2	private float temperature;
 3	private float humidity;
 4	private WeatherData weatherData;
 5	
 6	public CurrentConditionsDisplay(WeatherData weatherData) {
 7		this.weatherData = weatherData;
 8		weatherData.registerObserver(this);
 9	}
10	
11	public void update(float temperature，float humidity，float pressure) {
12		this.temperature = temperature;
13		this.humidity = humidity;
14		display();
15	}
16	
17	public void display() {
18        ...
19	}
20}

最后，编写测试代码：

 1public class WeatherStation {
 2
 3	public static void main(String[] args) {
 4		WeatherData weatherData = new WeatherData();
 5	
 6		CurrentConditionsDisplay currentDisplay = 
 7			new CurrentConditionsDisplay(weatherData);
 8		StatisticsDisplay statisticsDisplay = new StatisticsDisplay(weatherData);
 9		ForecastDisplay forecastDisplay = new ForecastDisplay(weatherData);
10
11		weatherData.setMeasurements(80，65，30.4f);
12		weatherData.setMeasurements(82，70，29.2f);
13		weatherData.setMeasurements(78，90，29.2f);
14		
15		weatherData.removeObserver(forecastDisplay);
16		weatherData.setMeasurements(62，90，28.1f);
17	}
18}

装饰者模式

理解

装饰，如其名，就是对一个对象进行加工，包装，修饰。

假设一杯“普通的咖啡，价格 10”，我们可以选择添加自己喜欢的配料。

首先我们添加牛奶，那么就变成了一杯“含牛奶配料的咖啡，价格 2 +（价格 12）”；

我想再加点巧克力，那么再往上包装变成“含巧克力的含牛奶配料的咖啡，价格 3 +【价格 2+（价格 12）】”。

这么一层层封装上去就是装饰模式。

我们要在每一个配料中定义一个可包装的对象，在包装后返回这个对象。具体代码如下文。

实现

以饮料店作为例子编写代码。

首先定义一些抽象类：

饮料抽象类：

1public abstract class Beverage {
2	String description = "Unknown Beverage";
3  
4	public String getDescription() {
5		return description;
6	}
7 
8	public abstract double cost();
9}

配料抽象类：

注意这里配料也继承了饮料类，这样Beverage在通过包装之后还是返回一个Beverage，具体见测试代码。

1public abstract class CondimentDecorator extends Beverage {
2	Beverage beverage;
3	public abstract String getDescription();
4}

接着，定义一些实际的饮料和配料：

牛奶配料：（其他配料省略）

 1public class Milk extends CondimentDecorator {
 2	public Milk(Beverage beverage) {
 3		this.beverage = beverage;
 4	}
 5
 6	public String getDescription() {
 7		return beverage.getDescription() + "，Milk";
 8	}
 9
10	public double cost() {
11		return .10 + beverage.cost();
12	}
13}

浓缩咖啡类：（其他饮料略）

1public class Espresso extends Beverage {
2	public Espresso() {
3		description = "Espresso";
4	}
5  
6	public double cost() {
7		return 1.99;
8	}
9}

最后，编写测试代码：

 1public class StarbuzzCoffee {
 2 
 3	public static void main(String args[]) {
 4		Beverage beverage = new Espresso();
 5		System.out.println(beverage.getDescription() 
 6				+ " $" + beverage.cost());
 7 
 8		Beverage beverage2 = new DarkRoast();
 9		beverage2 = new Mocha(beverage2);
10		beverage2 = new Mocha(beverage2);
11		beverage2 = new Whip(beverage2);
12		System.out.println(beverage2.getDescription() 
13				+ " $" + beverage2.cost());
14 
15		Beverage beverage3 = new HouseBlend();
16		beverage3 = new Soy(beverage3);
17		beverage3 = new Mocha(beverage3);
18		beverage3 = new Whip(beverage3);
19		System.out.println(beverage3.getDescription() 
20				+ " $" + beverage3.cost());
21	}
22}

工厂模式

理解

工厂模式，包括工厂方法模式和抽象工厂模式。

对于工厂方法模式，工厂是一个抽象类，提供了一些默认实现方法和一些抽象方法，具体工厂继承于它，实现对应抽象方法。

假设有多家比萨店，他们提供不同口味的比萨，而都有相同的订购比萨的方法，那么可以定义一个抽象类，提供订购比萨的具体方法和创建比萨的抽象方法。

对于抽象工厂模式，工厂是一个接口，提供了一些具体工厂会用到的方法，同时还需要定义这些方法可能用到的接口。具体工厂需要首先实现抽象工厂定义的方法可能用到的接口，然后实现抽象工厂的所有方法。

假设有多家生产比萨配料的工厂，他们都有自己的独特的配料（实现所有配料接口），那么可以定义一个抽象工厂（一个接口），提供所有配料创建方法，具体工厂各自实现所有创建方法即可。

总之，他们的具体区别如下：

工厂方法模式使用继承，把对象的创建委托给子类，子类实现工厂方法来创建对象。
抽象工厂模式使用对象组合，对象的创建被实现在工厂接口所暴露出来的方法中。

工厂方法模式实现

下面通过披萨店的例子来进行模拟。

从抽象开始，定义一个比萨店抽象类：

 1public abstract class PizzaStore {
 2 
 3	abstract Pizza createPizza(String item);
 4 
 5	public Pizza orderPizza(String type) {
 6		Pizza pizza = createPizza(type);
 7		System.out.println("--- Making a " + pizza.getName() + " ---");
 8		pizza.prepare();
 9		pizza.bake();
10		pizza.cut();
11		pizza.box();
12		return pizza;
13	}
14}

定义一些具体的比萨店，比如一个芝加哥的比萨店：

 1public class ChicagoPizzaStore extends PizzaStore {
 2
 3	Pizza createPizza(String item) {
 4        	if (item.equals("cheese")) {
 5            		return new ChicagoStyleCheesePizza();
 6        	} else if (item.equals("veggie")) {
 7        	    	return new ChicagoStyleVeggiePizza();
 8        	} else if (item.equals("clam")) {
 9        	    	return new ChicagoStyleClamPizza();
10        	} else if (item.equals("pepperoni")) {
11            		return new ChicagoStylePepperoniPizza();
12        	} else return null;
13	}
14}

关于其它比萨店和比萨的实现省略了。

最后进行代码的测试：

根据自然的思路：首先应有比萨店，顾客选择比萨店，选择具体口味的比萨，完成订单。

 1PizzaStore nyStore = new NYPizzaStore();
 2PizzaStore chicagoStore = new ChicagoPizzaStore();
 3
 4Pizza pizza = nyStore.orderPizza("cheese");
 5System.out.println("Ethan ordered a " + pizza.getName() + "\n");
 6
 7pizza = chicagoStore.orderPizza("cheese");
 8System.out.println("Joel ordered a " + pizza.getName() + "\n");
 9
10pizza = nyStore.orderPizza("clam");
11System.out.println("Ethan ordered a " + pizza.getName() + "\n");

抽象工厂模式实现

还是从抽象开始，定义一个配料工厂接口：

 1public interface PizzaIngredientFactory {
 2 
 3	public Dough createDough();
 4	public Sauce createSauce();
 5	public Cheese createCheese();
 6	public Veggies[] createVeggies();
 7	public Pepperoni createPepperoni();
 8	public Clams createClam();
 9 
10}

接着提供各种配料接口：

1public interface Cheese {
2	public String toString();
3}

其它的省略了。

然后实现配料接口：

1public class MozzarellaCheese implements Cheese {
2	public String toString() {
3		return "Shredded Mozzarella";
4	}
5}

其它的省略了。

接着再实现配料工厂接口，也就是定义具体的配料工厂，提供自己实现的配料。

 1public class ChicagoPizzaIngredientFactory
 2        implements PizzaIngredientFactory {
 3
 4    public Dough createDough() {
 5        return new ThickCrustDough();
 6    }
 7
 8    public Sauce createSauce() {
 9        return new PlumTomatoSauce();
10    }
11	// ...
12}

其它配料工厂省略了。

接着，再从抽象开始。抽象的比萨应该含有所有工厂可能用到的配料，同时应该提供一个准备配料的抽象方法，在具体的比萨中实现这个方法，指定需要的配料，不要的则为null。抽象的比萨店如工厂方法模式一样。这里代码省略了。测试代码亦如工厂方法模式一样，这里省略了。

如何决定使用哪个工厂模式

工厂方法模式和抽象工厂模式都是创建对象的设计模式，但它们的使用场景略有不同。

当需求只需要单个对象的实例时，可以使用工厂方法模式。在这种模式下，一个工厂类负责实例化唯一的具体产品类。

而当需要创建多个相关的对象（产品族）时，可以使用抽象工厂模式。在这种模式下，一个抽象工厂类定义了一组方法，每个方法都用于实例化一个相关的具体产品类。使用抽象工厂模式的好处是，它能够确保创建的产品族是相互兼容的，因为所有产品都是由同一个工厂创建的。

在实践中，需要仔细考虑需求，以确定是否需要使用工厂方法模式或抽象工厂模式。

当需要创建一个简单图形的绘画程序时，可以使用工厂方法模式。

例如，一个工厂类可以根据用户选择创建圆形、矩形或三角形的实例。这些形状对象可以继承自一个通用的 Shape 类，该类定义了绘制图形所需的公共接口。

当需要创建一个跨不同操作系统的 UI 组件时，可以使用抽象工厂模式。

例如，一个抽象工厂类（一个应用程序）可以定义一组方法，每个方法都用于实例化一个操作系统特定的 UI 组件，如窗口、按钮和文本框。不同操作系统的具体工厂类（应用程序在某个操作系统上的表现）可以实现这些方法以创建适用于特定操作系统的 UI 组件（实现各个组件对应的接口并在实现工厂方法时使用对应的组件）。在这种情况下，每个具体工厂类实现的产品族都包含不同操作系统的 UI 组件，但它们共同满足了通用的接口。

策略模式

解释

策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

比如对于鸭子而言，不同鸭子的叫声方式可能不一样也可能一样，我们可以定义一个叫声行为接口，然后通过创建不同的叫声行为实现这个接口，在实例化鸭子时设定叫声行为即可。

这样相比于直接继承抽象鸭子后重写叫声行为方法，好处是减少了重复代码，而坏处是增加了类的数量。

实现

首先定义一个叫声接口：

1public interface QuackBehavior {
2	public void quack();
3}

其它接口省略。

实现叫声接口：

1public class MuteQuack implements QuackBehavior {
2	public void quack() {
3		System.out.println("<< Silence >>");
4	}
5}

其它实现省略。

创建抽象鸭子：

 1public abstract class Duck {
 2	FlyBehavior flyBehavior;
 3	QuackBehavior quackBehavior;
 4
 5	public Duck() {
 6	}
 7
 8	public void setFlyBehavior(FlyBehavior fb) {
 9		flyBehavior = fb;
10	}
11
12	public void setQuackBehavior(QuackBehavior qb) {
13		quackBehavior = qb;
14	}
15
16	abstract void display();
17
18	public void performFly() {
19		flyBehavior.fly();
20	}
21
22	public void performQuack() {
23		quackBehavior.quack();
24	}
25
26	public void swim() {
27		System.out.println("All ducks float, even decoys!");
28	}
29}

最后，即可创建具体鸭子，继承于抽象鸭子，实例化时指定具体行为：

 1public class MallardDuck extends Duck {
 2
 3	public MallardDuck() {
 4		quackBehavior = new Quack();
 5		flyBehavior = new FlyWithWings();
 6	}
 7
 8	public void display() {
 9		System.out.println("I'm a real Mallard duck");
10	}
11}

同样可以轻松地创建其它鸭子。

和工厂模式的区别

工厂模式是创建型模式，适应对象的变化；策略模式是行为性模式，适应行为的变化。

形象点的例子：

工厂模式：

有一天你决定去吃培根披萨，首先得选择店铺，A 店和 B 店都有培根披萨；你点了 A 店的培根披萨，过了二十分钟，你的披萨就来了就可以吃到了。但这个披萨是怎么做的，到底面粉放了多少，培根放了多少，佐料放了多少，有多少道工序，你是不需要管的，你需要的是一个美味培根披萨。

策略模式：

在披萨店，你要一个培根披萨，老板说有标准的 pizza，也可以自己去做。原料有培根、面粉、佐料。工序有 1、2、3 工序，你自己去做吧。然后你就需要自己去做，到底放多少培根，放多少面粉，放多少佐料，这都你自己来决定，工序 1、2、3，你是怎么实现的，都你自己决定。最后你得到了披萨。

单例模式

理解

单例模式，容易知道需要某个对象是独一无二的，那么它首先应该是静态的，不能在程序动态运行期间被再次创建。

当在多个线程中用到它时，在创建时需要考虑线程安全问题，可通过加锁等方式解决。

单例模式的实现方式有多种，下面从最简单的方式开始实现，接着使用线程安全的方式实现，最后对多线程性能进行改善。

懒汉式

如其名，不是“急切”地进行对象的创建，而是在第一次主动获取对象时才加锁进行对象的初始化，实现对象的懒加载。

定义一个私有实例化的对象，把单例对象作为一个私有的静态成员变量，通过静态方法 Singleton.getInstance() 获取，若获取为 null 则创建对象。

 1public class Singleton {
 2	private static Singleton uniqueInstance;
 3 
 4	private Singleton() {}
 5 
 6	public static Singleton getInstance() {
 7		if (uniqueInstance == null) {
 8			uniqueInstance = new Singleton();
 9		}
10		return uniqueInstance;
11	}
12}

懒汉式（线程安全）

上面的懒汉式是线程不安全的，只适用于单线程环境。在多线程环境下，同时初始化该对象时将导致重复初始化对象的问题。解决方法如下：

 1public class Singleton {
 2	private static Singleton uniqueInstance;
 3 
 4	private Singleton() {}
 5 
 6	public static synchronized Singleton getInstance() {
 7		if (uniqueInstance == null) {
 8			uniqueInstance = new Singleton();
 9		}
10		return uniqueInstance;
11	}
12}

如上线程安全的代码，getInstance() 在多次调用的情况下性能太低，需要进行改善。

懒汉式（双重检查锁）

这里需要通过双重检查并加锁的方式实现，在进入 getInstance() 方法后检查对象是否为空，以及在获得锁之后，再次检查对象是否为空。

 1public class Singleton {
 2	private volatile static Singleton uniqueInstance;
 3 
 4	private Singleton() {}
 5 
 6	public static Singleton getInstance() {
 7		if (uniqueInstance == null) {
 8			synchronized (Singleton.class) {
 9				if (uniqueInstance == null) {
10					uniqueInstance = new Singleton();
11				}
12			}
13		}
14		return uniqueInstance;
15	}
16}

volatile 用于告诉编译器该变量可能会被其它线程或外部程序修改，一次每次访问该变量时都需要从内存重新读取其值，而不是使用缓存。这样可以确保当 uniqueInstance 被初始化时，多个线程正确处理 uniqueInstance 变量，保证并发的正确性。

另外 volatile 还可以防止编译器对代码进行重排序优化。比如在多线程环境下，几个线程对某个对象进行读操作，其它几个进行写操作，在写操作中，如果在进行对象的初始化，并且构造函数中操作比较多时，为了提升效率，JVM 会在构造函数里面的属性未全部完成实例化时，就返回对象。这样可能导致其它进行读操作的线程读取到未初始化完全的对象，而加上 volatile 关键字就没有这个问题了。

为什么之前的线程安全方式不需要添加 volatile 呢？因为之前的 synchronized 是作用在方法上的，也就是说在进入该方法之前不会访问到 uniqueInstance 变量，也就不会有缓存，不需要重新读取值。同时，也不会被重排序优化影响，因为读操作或写操作都是在进入方法内部之后进行的。

而这里是进入 getInstance 方法后首先访问 uniqueInstance 变量，之后再尝试获取锁，所以编译器可能会对 uniqueInstance 进行优化，将其缓存到寄存器中，同时，写操作和读操作都是进入方法之后进行的，可能被重排序优化影响。

双重检查锁模式是一种比较好的单例实现模式，能够保证在多线程的情况下线程安全也不会有性能问题。

饿汉式

如其名，就是“急切”地创建实例，也就是在 JVM 加载该类时马上创建实例，也可以保证线程安全。

1public class Singleton {
2	private static final Singleton uniqueInstance = new Singleton();
3 
4	private Singleton() {}
5 
6	public static Singleton getInstance() {
7		return uniqueInstance;
8	}
9}

该方式不能实现懒加载，造成空间浪费，如果一个类比较大，我们在初始化的时就加载了这个类，但是我们长时间没有使用这个类，这就导致了内存空间的浪费。当然如果类比较小可以考虑使用。

饿汉式（静态内部类）

静态内部类单例模式也称单例持有者模式，实例由内部类创建，由于 JVM 在加载外部类的过程中，是不会加载静态内部类的，只有内部类的属性/方法被调用时才会被加载，并初始化其静态属性。静态属性由static修饰，保证只被实例化一次，并且严格保证实例化顺序。

 1public class Singleton {
 2    private Singleton() {}
 3
 4    private static class InstanceHolder {
 5        private final static Singleton instance = new Singleton();
 6    }
 7    
 8    public static Singleton getInstance() {
 9        return InstanceHolder.instance;
10    }
11}

静态内部类单例模式是一种优秀的单例模式，是开源项目中比较常用的一种单例模式。在没有加任何锁的情况下，保证了多线程下的安全，并且没有任何性能影响和空间的浪费。

饿汉式（枚举）

为什么可以通过枚举实现单例？这是因为我们定义的一个枚举，只有在第一次被真正用到的时候，才会被虚拟机加载并初始化。基于这个特性，可以知道通过枚举实现的单例是天生线程安全的。

枚举类实现单例模式是 effective java 作者极力推荐的单例实现模式，因为枚举类型是线程安全的，并且只会装载一次，设计者充分的利用了枚举的这个特性来实现单例模式，枚举的写法非常简单，而且枚举类型是所用单例实现中唯一一种不会被破坏的单例实现模式。

 1public class Singleton {
 2    private Singleton() {}
 3
 4    private enum SingletonEnum {
 5        INSTANCE;
 6
 7        private final Singleton instance;
 8
 9        SingletonEnum() {
10            instance = new Singleton();
11        }
12
13        private Singleton getInstance() {
14            return instance;
15        }
16    }
17
18    public static Singleton getInstance() {
19        return SingletonEnum.INSTANCE.getInstance();
20    }
21}

破坏单例模式的方法及解决办法

1、除枚举方式外，其他方法都会通过反射的方式破坏单例，反射是通过调用构造方法生成新的对象，所以如果我们想要阻止单例破坏，可以在构造方法中进行判断，若已有实例，则阻止生成新的实例，解决办法如下:

1private Singleton() {
2    if (instance != null){
3        throw new RuntimeException("实例已经存在，请通过 getInstance()方法获取");
4    }
5}

2、如果单例类实现了序列化接口 Serializable，就可以通过反序列化破坏单例，所以我们可以不实现序列化接口，如果非得实现序列化接口，可以重写反序列化方法 readResolve()，反序列化时直接返回相关单例对象。

1public Object readResolve() throws ObjectStreamException {
2	return instance;
3}

命令模式

理解

命令模式将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。

比如对于遥控器而已，我们会将操作封装为一个按钮（命令）对象，通过按下按钮执行操作。

实现

下面以遥控器作为例子进行代码模拟。

首先从接口开始，定义一个命令接口：

1public interface Command {
2	public void execute();
3}

接着，定义操作对象风扇：（其它对象省略了）

 1public class Light {
 2	String location = "";
 3
 4	public Light(String location) {
 5		this.location = location;
 6	}
 7
 8	public void on() {
 9		System.out.println(location + " light is on");
10	}
11
12	public void off() {
13		System.out.println(location + " light is off");
14	}
15}

然后编写操作风扇的命令：

 1// 开风扇，其它操作省略了
 2public class LightOnCommand implements Command {
 3	Light light;
 4
 5	public LightOnCommand(Light light) {
 6		this.light = light;
 7	}
 8
 9	public void execute() {
10		light.on();
11	}
12}

还需要定义空命令，用于初始化遥控器命令：

1public class NoCommand implements Command {
2	public void execute() {}
3}

最后，定义遥控器，包含两个数组，分别用于开命令和关命令：

 1public class RemoteControl {
 2	Command[] onCommands;
 3	Command[] offCommands;
 4 
 5	public RemoteControl() {
 6		onCommands = new Command[7];
 7		offCommands = new Command[7];
 8 
 9		Command noCommand = new NoCommand();
10		for (int i = 0; i < 7; i++) {
11			onCommands[i] = noCommand;
12			offCommands[i] = noCommand;
13		}
14	}
15  
16	public void setCommand(int slot, Command onCommand, Command offCommand) {
17		onCommands[slot] = onCommand;
18		offCommands[slot] = offCommand;
19	}
20 
21	public void onButtonWasPushed(int slot) {
22		onCommands[slot].execute();
23	}
24 
25	public void offButtonWasPushed(int slot) {
26		offCommands[slot].execute();
27	}
28  
29	public String toString() {
30        // ...
31	}
32}

对代码进行简单测试：

 1// 定义遥控
 2RemoteControl remoteControl = new RemoteControl();
 3// 定义一些遥控对象
 4Light livingRoomLight = new Light("Living Room");
 5// ...
 6// 定义作用在某个遥控对象上的一些命令
 7LightOnCommand livingRoomLightOn = 
 8		new LightOnCommand(livingRoomLight);
 9LightOffCommand livingRoomLightOff = 
10		new LightOffCommand(livingRoomLight);
11LightOnCommand kitchenLightOn = 
12		new LightOnCommand(kitchenLight);
13LightOffCommand kitchenLightOff = 
14		new LightOffCommand(kitchenLight);
15// ...
16// 配置遥控器命令
17remoteControl.setCommand(0, livingRoomLightOn, livingRoomLightOff);
18// ...
19// 操作遥控
20remoteControl.onButtonWasPushed(0);
21remoteControl.offButtonWasPushed(0);
22// ...

适配器模式

解释

适配器模式将一个类的接口，转换成客户期望的另一个接口，适配器让原本接口不兼容的类可以合作无间。

实现

鸭子和火鸡叫声不一样，通过编写适配器让火鸡适配鸭的方法。

首先，从接口开始，定义鸭子和火鸡接口：

1public interface Duck {
2	public void quack();
3	public void fly();
4}
5
6public interface Turkey {
7	public void gobble();
8	public void fly();
9}

接着编写适配器，让火鸡适配鸭子，也就是让火鸡适配器实现鸭子接口：

 1public class TurkeyAdapter implements Duck {
 2	Turkey turkey;
 3 
 4	public TurkeyAdapter(Turkey turkey) {
 5		this.turkey = turkey;
 6	}
 7    
 8	public void quack() {
 9		turkey.gobble();
10	}
11  
12	public void fly() {
13		for(int i=0; i < 5; i++) {
14			turkey.fly();
15		}
16	}
17}

接着就可以编写一些具体类了：

1// 绿头鸭
2public class MallardDuck implements Duck {
3	// ...
4}
5// 野火鸡：
6public class WildTurkey implements Turkey {
7	// ...
8}

最后对代码进行测试：

 1public class DuckTestDrive {
 2    static void testDuck(Duck duck) {
 3		duck.quack();
 4		duck.fly();
 5	}
 6	public static void main(String[] args) {
 7		Duck duck = new MallardDuck();
 8
 9		Turkey turkey = new WildTurkey();
10		Duck turkeyAdapter = new TurkeyAdapter(turkey);
11
12		turkey.gobble();
13		turkey.fly();
14		testDuck(duck);
15		testDuck(turkeyAdapter);
16	}
17}

外观模式

解释

外观模式提供了一个统一的接口，用来访问子系统中的一群接口，外观定义了一个高层接口，让子系统更容易使用。

最少知识原则：减少对象之间的交互，只和“密友”谈话，也就是减少一个类所交互的类的数量。

实现

执行一些复杂操作需要一步步执行许多小操作，那么可以将复杂操作封装为一个高层类中的方法，将所有复杂操作需要用到的类作为高层类的成员，在复杂操作的方法中可以方便的调用各个类执行各自的功能。

下面是一个家庭影院的例子：

 1public class HomeTheaterFacade {
 2	Amplifier amp;
 3	Tuner tuner;
 4	StreamingPlayer player;
 5	CdPlayer cd;
 6	Projector projector;
 7	TheaterLights lights;
 8	Screen screen;
 9	PopcornPopper popper;
10 
11	public HomeTheaterFacade(Amplifier amp, 
12				 Tuner tuner, 
13				 StreamingPlayer player, 
14				 Projector projector, 
15				 Screen screen,
16				 TheaterLights lights,
17				 PopcornPopper popper) {
18					// ...
19	}
20 
21	public void watchMovie(String movie) {
22		System.out.println("Get ready to watch a movie...");
23		popper.on();
24		popper.pop();
25		lights.dim(10);
26		screen.down();
27		projector.on();
28		projector.wideScreenMode();
29		amp.on();
30		amp.setStreamingPlayer(player);
31		amp.setSurroundSound();
32		amp.setVolume(5);
33		player.on();
34		player.play(movie);
35	}
36 
37 
38	public void endMovie() {
39		System.out.println("Shutting movie theater down...");
40		// ...
41	}
42
43	public void listenToRadio(double frequency) {
44		System.out.println("Tuning in the airwaves...");
45		// ...
46	}
47
48	public void endRadio() {
49		System.out.println("Shutting down the tuner...");
50		// ...
51	}
52}

各个功能器件的代码和测试代码省略了。

模板方法模式

解释

模板方法模式在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

关于好莱坞原则：别调用我们，我们会调用你。

其实就是防止“依赖腐败”，也就是要避免高层组件和低层组件相互依赖。一般由高层组件依赖低层组件。

实现

泡茶和泡咖啡有着几乎相同的步骤，但在某些子步骤中有差别。通过模板方法可以很好地解决问题。

可以定义一个泡饮料的模板方法，其中子步骤 brew() 和 addCondiments() 为抽象方法，由子类进行具体实现。

 1public abstract class CaffeineBeverage {
 2  
 3	final void prepareRecipe() {
 4		boilWater();
 5		brew();
 6		pourInCup();
 7		addCondiments();
 8	}
 9 
10	abstract void brew();
11  
12	abstract void addCondiments();
13 
14	void boilWater() {
15		System.out.println("Boiling water");
16	}
17  
18	void pourInCup() {
19		System.out.println("Pouring into cup");
20	}
21}

其它代码就省略了。

迭代器模式

解释

迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。

通过一个 Iterator，可以方便地遍历各种类型，如 HashMap，LinkedList 等。特别对于 LinkedList，使用迭代器进行迭代比使用下标进行迭代会快很多，因为是它基于链表的结构。

实现

下面通过菜单的例子进行说明。

分别用简单数组 String[] 和 ArrayList<String> 类创建菜单内容。

首先创建菜单接口：

1public interface Menu {
2	public Iterator<String> createIterator();
3}

每个菜单都可以返回一个迭代器。

接着创建 Diner 的菜单，用String[]创建内容，需要编写自己的迭代器。

 1public class DinerMenu implements Menu {
 2	static final int MAX_ITEMS = 6;
 3	int numberOfItems = 0;
 4	String[] menuItems;
 5  
 6	public DinerMenu() {
 7		menuItems = new String[MAX_ITEMS];
 8 
 9		addItem("Vegetarian BLT");
10		// ...
11	}
12  
13	public void addItem(String name) 
14	{
15		if (numberOfItems >= MAX_ITEMS) {
16			System.err.println("Sorry, menu is full!  Can't add item to menu");
17		} else {
18			menuItems[numberOfItems] = name;
19			numberOfItems = numberOfItems + 1;
20		}
21	}
22 
23	public String[] getMenuItems() {
24		return menuItems;
25	}
26  
27	public Iterator<String> createIterator() {
28		return new DinerMenuIterator(menuItems); // 后面需要进行实现
29	}
30 
31	public String toString() {
32		return "Diner Menu";
33	}
34	// other menu methods here
35}

接着，创建菜单迭代器，需要实现 Iterater<String> 接口，实现 next()，hasNext() 和 remove() 方法。

 1public class DinerMenuIterator implements Iterator<String> {
 2	String[] list;
 3	int position = 0;
 4 
 5	public DinerMenuIterator(String[] list) {
 6		this.list = list;
 7	}
 8 
 9	public String next() {
10		String menuItem = list[position];
11		position = position + 1;
12		return menuItem;
13	}
14 
15	public boolean hasNext() {
16		if (position >= list.length || list[position] == null) {
17			return false;
18		} else {
19			return true;
20		}
21	}
22  
23	public void remove() {
24		if (position <= 0) {
25			throw new IllegalStateException
26				("You can't remove an item until you've done at least one next()");
27		}
28		if (list[position-1] != null) {
29			for (int i = position-1; i < (list.length-1); i++) {
30				list[i] = list[i+1];
31			}
32			list[list.length-1] = null;
33		}
34	}
35}

以后，访问菜单就很方便了，只需要获得菜单的迭代器即可。

其它代码省略了。

组合模式

解释

允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。

对于菜单内容而言，假如只有简单的菜品项，那么通过迭代器可以轻松地遍历，但是如果菜单内容中含有子菜单，那么就需要组合模式了。

实现

下面就以菜单为例子展示组合模式，每个菜单既可能由菜单项，也可能有子菜单，所以可以把菜单项和子菜单这两者都理解为菜单组件，作为一个抽象的对象，具体操作时根据需要进行实现即可。

首先创建菜单组件：

 1public abstract class MenuComponent {
 2   
 3	public void add(MenuComponent menuComponent) {
 4		throw new UnsupportedOperationException();
 5	}
 6	public void remove(MenuComponent menuComponent) {
 7		throw new UnsupportedOperationException();
 8	}
 9	public MenuComponent getChild(int i) {
10		throw new UnsupportedOperationException();
11	}
12	public String getName() {
13		throw new UnsupportedOperationException();
14	}
15	public String getDescription() {
16		throw new UnsupportedOperationException();
17	}
18	public double getPrice() {
19		throw new UnsupportedOperationException();
20	}
21	public boolean isVegetarian() {
22		throw new UnsupportedOperationException();
23	}
24	public void print() {
25		throw new UnsupportedOperationException();
26	}
27}

接着创建具体的菜单，继承菜单组件，实现父类方法中关于操作子菜单：

 1public class Menu extends MenuComponent {
 2	ArrayList<MenuComponent> menuComponents = new ArrayList<MenuComponent>();
 3	String name;
 4	String description;
 5  
 6	public Menu(String name, String description) {
 7		this.name = name;
 8		this.description = description;
 9	}
10	public void add(MenuComponent menuComponent) {
11		menuComponents.add(menuComponent);
12	}
13	public void remove(MenuComponent menuComponent) {
14		menuComponents.remove(menuComponent);
15	}
16	public MenuComponent getChild(int i) {
17		return (MenuComponent)menuComponents.get(i);
18	}
19	public String getName() {
20		return name;
21	}
22	public String getDescription() {
23		return description;
24	}
25	// getPrice 和 isVegetarian 就不需要了，因为是菜单
26	public void print() {
27		System.out.print("\n" + getName());
28		System.out.println(", " + getDescription());
29		System.out.println("---------------------");
30		for (MenuComponent menuComponent : menuComponents) {
31			menuComponent.print();
32		}
33	}
34}

接着创建菜单项，它也是一个菜单组件，但是它不需要重写部分关于子菜单的方法：

 1public class MenuItem extends MenuComponent {
 2	String name;
 3	String description;
 4	boolean vegetarian;
 5	double price;
 6    
 7	public MenuItem(String name, 
 8	                String description, 
 9	                boolean vegetarian, 
10	                double price) 
11	{ 
12		//...
13	}
14  
15	public String getName() {
16		return name;
17	}
18  
19	public String getDescription() {
20		return description;
21	}
22  
23	public double getPrice() {
24		return price;
25	}
26  
27	public boolean isVegetarian() {
28		return vegetarian;
29	}
30  
31	public void print() {
32		// ...
33	}
34}

最后进行测试：

 1public class MenuTestDrive {
 2	public static void main(String args[]) {
 3		// 主菜单
 4		MenuComponent allMenus = new Menu("ALL MENUS", "All menus combined");
 5		// 一些子菜单
 6		MenuComponent pancakeHouseMenu = 
 7			new Menu("PANCAKE HOUSE MENU", "Breakfast");
 8		// 其它子菜单省略了
 9		// ...
10		// 添加子菜单
11		allMenus.add(pancakeHouseMenu);
12		allMenus.add(dinerMenu);
13		allMenus.add(cafeMenu);
14		// 在子菜单中添加菜单项
15		pancakeHouseMenu.add(new MenuItem(
16			"K&B's Pancake Breakfast", 
17			"Pancakes with scrambled eggs and toast", 
18			true,
19			2.99));
20        // 省略其它菜品项
21		// ...
22		// 子菜单添加子菜单
23		dinerMenu.add(dessertMenu);
24	}
25}

状态模式

解释

状态模式允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。

比如某个机器有各种复杂的状态，每个状态都着共同的参数，而这些参数值有区别。用户通过某些操作会改变机器的状态，机器转变状态后，以当前状态的方法给用户反馈。

实现

以机器的例子说明。每次对机器进行操作，机器的状态都可能发生改变，但是下一个状态是什么需要由当前状态决定。所以每个具体的状态定义好了从当前状态经过当前操作会跳转到哪个状态。

首先编写一个状态接口，其中包括该机器可能的所有状态：

1public interface State {
2	public void insertQuarter();
3	public void ejectQuarter();
4	public void turnCrank();
5	public void dispense();
6	public void refill();
7}

接着创建机器类：

 1public class GumballMachine {
 2    // 各种机器状态，后续需要进行具体实现
 3	State soldOutState;
 4	State noQuarterState;
 5	State hasQuarterState;
 6	State soldState;
 7    // 当前状态
 8	State state;
 9	int count = 0;
10	
11	// 初始化该机器的各个状态
12	public GumballMachine(int numberGumballs) {
13		soldOutState = new SoldOutState(this); // 这些状态依赖于该机器
14		noQuarterState = new NoQuarterState(this);
15		hasQuarterState = new HasQuarterState(this);
16		soldState = new SoldState(this);
17		this.count = numberGumballs;
18 		if (numberGumballs > 0) {
19			state = noQuarterState;
20		} else {
21			state = soldOutState;
22		}
23	}
24	// 定义一些操作，经过某个操作后，机器状态发生改变
25	public void turnCrank() {
26		state.turnCrank();
27		state.dispense();
28	}
29	// 其它操作省略了
30	// ...
31	// constructor getter setter
32}

接着，定义各种机器状态，以其中一个状态为例子：

 1public class HasQuarterState implements State {
 2	GumballMachine gumballMachine;
 3	// 依赖某个具体的机器
 4	public HasQuarterState(GumballMachine gumballMachine) {
 5		this.gumballMachine = gumballMachine;
 6	}
 7	// 经过该操作，该机器从 HasQuarterState 转移到下一个状态
 8	public void ejectQuarter() {
 9		System.out.println("Quarter returned");
10		gumballMachine.setState(gumballMachine.getNoQuarterState()); // 转移到该机器的其它状态
11	}
12	// 重写的其它方法省略了
13	// ...
14}

测试部分代码省略了。

代理模式

解释

代理模式提供了对目标对象另外的访问方式，即通过代理对象访问目标对象。这样做的好处是可以在目标对象实现的基础上，增强额外的功能操作，即扩展目标对象的功能。

这里使用到编程中的一个思想：不要随意去修改别人已经写好的代码或者方法，如果需改修改，可以通过代理的方式来扩展该方法。

实现静态代理

静态代理在使用时，需要定义接口或者父类，被代理对象与代理对象一起实现相同的接口或者是继承相同父类。

下面举个案例来解释。

模拟保存动作，定义一个保存操作的接口 IUserDao，然后目标对象实现这个接口的方法 UserDao，此时如果使用静态代理方式，就需要在代理对象 UserDaoProxy 中也实现 IUserDao 接口，调用的时候通过调用代理对象的方法来调用目标对象。

需要注意的是，代理对象与目标对象要实现相同的接口，然后通过调用相同的方法来调用目标对象的方法。

首先定义接口 IUserDao：

1public interface IUserDao {
2    void save();
3}

接着定义目标对象 UserDao：

1public class UserDao implements IUserDao {
2    public void save() {
3        System.out.println("saved.");
4    }
5}

然后代理对象 UserDaoProxy：

 1public class UserDaoProxy implements IUserDao{
 2    // 接收保存目标对象
 3    private IUserDao target;
 4
 5    public UserDaoProxy(IUserDao target){
 6        this.target=target;
 7    }
 8
 9    public void save() {
10        System.out.println("before..."); // 增强的方法
11        target.save(); // 执行目标对象的方法
12        System.out.println("after..."); // 增强的方法
13    }
14}

静态代理在编译器就完成了，可以做到在不修改目标对象的功能前提下，对目标功能扩展。但因为代理对象需要与目标对象实现一样的接口，所以会有很多代理类。同时，一旦接口增加方法，目标对象与代理对象都要维护。

实现动态代理

在动态代理中，代理对象不需要实现接口。代理对象的生成利用了 JDK 的 API，动态的在内存中构建代理对象(需要我们指定创建代理对象/目标对象实现的接口的类型)。

JDK 实现代理只需要使用 newProxyInstance 方法，该方法需要接收三个参数，完整的写法是：

1static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h)

ClassLoader loader: 指定当前目标对象使用类加载器，获取加载器的方法是固定的
Class<?>[] interfaces: 目标对象实现的接口的类型，使用泛型方式确认类型
InvocationHandler h: 事件处理，执行目标对象的方法时，会触发事件处理器的方法，会把当前执行目标对象的方法作为参数传入

接口类IUserDao.java以及接口实现类,目标对象UserDao是一样的,没有做修改.在这个基础上,增加一个代理工厂类(ProxyFactory.java),将代理类写在这个地方,然后在测试类(需要使用到代理的代码)中先建立目标对象和代理对象的联系,然后代用代理对象的中同名方法

定义一个代理工厂类 ProxyFactory，用于方便地生成代理对象：

 1public class ProxyFactory{
 2    //维护一个目标对象
 3    private Object target;
 4    public ProxyFactory(Object target) {
 5        this.target=target;
 6    }
 7
 8   //给目标对象生成代理对象
 9    public Object getProxyInstance() {
10        return Proxy.newProxyInstance(
11                target.getClass().getClassLoader(),
12                target.getClass().getInterfaces(),
13                new InvocationHandler() {
14                    @Override
15                    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
16                        System.out.println("before...");
17                        Object returnValue = method.invoke(target, args);
18                        System.out.println("after...");
19                        return returnValue;
20                    }
21                }
22        );
23    }
24}

代理对象不需要实现接口，但是目标对象一定要实现接口，否则不能用动态代理。

Cglib 代理

上面的静态代理和动态代理模式都是要求目标对象是实现一个接口的目标对象，但是有时候目标对象只是一个单独的对象，并没有实现任何的接口，这个时候就可以使用以目标对象子类的方式类实现代理，这种方法就叫做 Cglib 代理。

Cglib 代理，也叫作子类代理，它是在内存中构建一个子类对象从而实现对目标对象功能的扩展。

Cglib 是一个强大的高性能的代码生成包，它可以在运行期扩展类与实现接口，广泛的被许多 AOP 的框架使用，例如 Spring。Cglib 包的底层是通过使用一个小而快的字节码处理框架 ASM 来转换字节码并生成新的类。

Cglib 子类代理实现方法:

需要引入 cglib 的 jar 文件，但是 Spring 的核心包中已经包括了 Cglib 功能，所以直接引入 spring-core-3.2.5.jar 也可以；
代理的类不能为 final；
目标对象的方法如果为 final/static，那么就不会被拦截，即不会执行目标对象额外的业务方法；

创建一个 Cglib 代理工厂 ProxyFactory：

 1public class ProxyFactory implements MethodInterceptor{
 2    // 维护目标对象
 3    private Object target;
 4
 5    public ProxyFactory(Object target) {
 6        this.target = target;
 7    }
 8
 9    // 给目标对象创建一个代理对象
10    public Object getProxyInstance(){
11        // 1.工具类
12        Enhancer en = new Enhancer();
13        // 2.设置父类
14        en.setSuperclass(target.getClass());
15        // 3.设置回调函数
16        en.setCallback(this);
17        // 4.创建子类(代理对象)
18        return en.create();
19    }
20
21    @Override
22    public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
23        System.out.println("before...");
24        Object returnValue = method.invoke(target, args);
25        System.out.println("after...");
26        return returnValue;
27    }
28}

在 Spring 的 AOP 编程中:

如果加入容器的目标对象有实现接口，用 JDK 代理
如果目标对象没有实现接口，用 Cglib 代理

结合策略模式实现动态 Bean

假设在某个业务类中存在一个注入 bean 如下：

1@Autowired
2private TestService testService;

其中 TestService 是一个接口，假设我们有该接口有多种实现：TestServiceImpl1 和 TestServiceImpl2，在不同环境下按需调用接口对应的实现（比如可能需要能根据请求参数进行选择），这时如何实现呢？

可以通过反射的机制并配合 Spring 注解实现，以下是具体的实现过程分析。

首先我们可以设计一个 TestApiSwitcher:

1@Bean(name = "testService")
2@Primary
3public TestService getTestService() {
4    return Reflection.newProxy(TestService.class, switcherInvocationHandler);
5}

其中，@Bean 是 Spring 中的注解之一，通常用于在配置类中声明一个方法，并将其返回值作为一个 Bean 注册到 Spring 容器中。而 @Primary 注解配合于 @Bean 注解，用于指定一个 Bean 作为默认首选的候选项。

当有多个同类型的 Bean 需要注入时，Spring 容器会根据类型匹配进行自动装配。但如果存在多个匹配的 Bean 时，会产生歧义性，导致无法确定要注入哪个 Bean。使用 @Primary 注解，可以将一个 Bean 标记为首选的候选项。当需要注入该类型的 Bean 时，如果代码中没有通过 @Resource 之类的注解进行指定, Spring 容器会优先选择被 @Primary 注解标记的 Bean 作为注入对象。

观察方法内部，我们通过 guava 库的反射操作 Reflection.newProxy 为 TestService 设置代理对象 switcherInvocationHandler，那么继续设计我们的 switcherInvocationHandler。

首先，我们需要判断被调用的方法是否是 Object 类中的方法（即通用的方法，如equals()、hashCode()、toString()等）。

如果是通用方法，则直接在代理对象上调用该方法并返回结果。
如果被调用的方法不是通用方法，则根据请求参数 args 进行路由，选择合适的实现类，进行对应方法的调用即可。

大致实现思路如下：

 1private class SwitcherInvocationHandler implements InvocationHandler {
 2    private final Set<String> METHODS_ON_OBJECT_CLASS = (Set) Arrays.stream(Object.class.getMethods()).map(Method::getName).collect(Collectors.toSet());
 3
 4    @Override
 5    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
 6        if (METHODS_ON_OBJECT_CLASS.contains(method.getName())) {
 7            return method.invoke(this, args);
 8        } else {
 9            try {
10                // 根据 args 进行路由
11                if (getArgInfo(args) == 1) return method.invoke(TestServiceImpl1, args);
12                if (getArgInfo(args) == 2) return method.invoke(TestServiceImpl2, args);
13                if (getArgInfo(args) == 3) return method.invoke(TestServiceImpl1, args);
14            } catch (InvocationTargetException e) {
15                throw e.getCause();
16            }
17        }
18    }
19}

其中， METHODS_ON_OBJECT_CLASS 是一个记录了 Object 类基本方法的集合。

SwitcherInvocationHandler 为一个代理类，实现了 InvocationHandler 接口，通过 JDK 动态代理进行实现。在每个方法调用前将会先进行 invoke 方法的调用。

参考

《Head First 设计模式》

微服务重要知识整理

akynazh@gmail.com (zhihang) — Sun, 12 Mar 2023 01:49:47 +0800

Preface

本篇 Blog 对接触到的微服务相关知识做一个整理汇总，仅供查阅学习。如有错误，请批评指正；如发现有文段引用自别处但未在文末加来源，请联系我。

微服务

基本思想

微服务（Microservices） 是一种软件架构风格，它将一个复杂的应用拆分成一组小型、独立运行的服务。每个微服务都是围绕某个特定的业务功能构建的，并且能够通过轻量级的通信协议（如 HTTP 或消息队列）相互协作。

这种架构以解耦、灵活性和扩展性为核心目标，是对传统单体架构（Monolithic Architecture）的改进。

核心特点

单一职责：每个微服务只专注于完成一个业务功能，例如用户管理、订单处理、支付服务等。
独立部署：每个微服务可以单独构建、测试、部署和升级，而无需影响其他服务。
技术多样性：不同微服务可以使用不同的编程语言、数据库或技术栈，根据具体需求选择最佳实现方式。
轻量级通信：微服务通过轻量化的协议（如 HTTP REST API、gRPC 或消息队列）进行通信，避免复杂的交互。
自治性：每个微服务独立运行，拥有自己的逻辑、数据存储和业务边界。
去中心化管理：微服务架构倾向于分布式治理，各服务独立开发、独立运维。
高扩展性：可以根据流量或业务需求，对特定服务进行横向扩展，而不是整体扩展整个系统。

关键组件

为了实现微服务架构，通常需要以下组件的支持：

服务注册与发现：实现服务之间动态查找，例如通过 Eureka、Consul 或 Zookeeper。
API 网关：统一入口，管理微服务之间的请求路由、安全认证和限流等功能，例如 Kong、Spring Cloud Gateway。
分布式配置：集中管理配置，支持动态更新，例如 Spring Cloud Config、Consul KV Store。
服务通信：HTTP、gRPC、MQ 等。
负载均衡：在服务实例之间分发请求，例如使用 Ribbon 或 Spring Cloud LoadBalancer。
监控和日志：监控和追踪服务运行状态，例如 Prometheus、Grafana 或分布式追踪工具 Zipkin。
容错机制：实现熔断、限流和自动重试功能，例如通过 Hystrix 或 Resilience4j。

设计原因

微服务架构解决了单体架构在开发、扩展和运维中的诸多痛点，特别适合现代复杂应用。它的核心价值在于：

灵活性：独立部署与技术栈多样性。每个服务是独立模块，可以单独开发、测试和部署，而无需影响其他服务；不同的微服务可以根据需求选择最合适的技术栈或编程语言。
可扩展性：按需扩展，优化资源利用。微服务允许针对不同服务进行独立扩展，而不是整体扩展整个系统；由于服务的独立性，可以在必要时为高负载服务分配更多资源。
容错性：故障隔离和快速恢复。一个服务的故障不会直接导致整个系统宕机；微服务部署简单，受影响的服务可以快速替换或恢复。

重要框架

微服务框架是一种为开发和管理微服务架构提供支持的工具集或技术栈。它们帮助开发者构建、部署和维护微服务，并简化了许多微服务架构中常见的挑战，如上文提到的大多微服务关键组件。

现在主要存在两种微服务框架，SpringCloud 和 Dubbo，它们都是分布式系统中广泛使用的微服务框架。对比如下

特性	Dubbo	Spring Cloud
语言支持	主要支持 Java（虽然有一些其他语言支持，但偏向 Java）	支持多语言，尤其是与 REST 和 HTTP 接口交互
服务治理	内置完善的服务治理，如负载均衡、容错、动态路由等，也可以集成 Sentinel	通过集成其他工具实现服务治理（如 Ribbon、Hystrix、Eureka 等）
服务注册与发现	支持多种注册中心（如 Zookeeper、Nacos、Redis）	提供内置支持，如 Eureka、Consul、Zookeeper
通信协议	支持多种协议（Dubbo、HTTP、gRPC 等）	主要基于 HTTP 和 REST
开发方式	通过 Java 接口定义远程调用接口，并通过框架自动实现	使用 Spring Boot，通过注解和配置文件配置服务
扩展性	高度可定制，适合高性能服务间通信需求	灵活但依赖更多外部组件（如 Hystrix、Ribbon）

Dubbo 大致框架：

SpringCloud 大致框架：

服务注册与发现

Eureka

Eureka 微服务架构

服务接口采用集群模式，8001 和 8002 端口都实现支付接口服务。
用户接口在运行在 80 端口，调用 8001 和 8002 的服务。
注册中心内部也采用集群模式，7001 和 7002 端口都实现注册服务。

Eureka 依赖

 1<!-- client端 -->
 2<dependency>
 3    <groupId>org.springframework.cloud</groupId>
 4    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
 5</dependency>
 6
 7<!-- server端 -->
 8<dependency>
 9    <groupId>org.springframework.cloud</groupId>
10    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
11</dependency>

7001 和 7002 端口关键配置内容

在启动类开启注解 @EnableEurekaServer:

1@SpringBootApplication
2@EnableEurekaServer
3public class EurekaMain7001 {
4    public static void main(String[] args) {
5        SpringApplication.run(EurekaMain7001.class, args);
6    }
7}

接着进行基础配置如下：

对于 7001 端口服务：（7002 端口类似）

 1eureka:
 2    instance:
 3    hostname: eureka7001.com
 4    client:
 5    # false 表示不向注册中心注册自己
 6    register-with-eureka: false
 7    # false 表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
 8    fetch-registry: false
 9    service-url:
10    # 设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址
11        defaultZone: http://eureka7002.com:7002/eureka/

注意 defaultZone 配置指向其他注册服务端口，需满足“相互注册”。

另外，eureka7001.com 和 eureka7002.com 其实配置指向 localhost，这里只是为了模拟多台机器。

8001 和 8002 端口关键配置内容

注：(2023-03-20 更新)

Eureka version 4.0.0 onwards, which is being used in Spring Cloud 2022.0.0, you do not need to explicitly register using the annotation @EnableEurekaClient, It automatically gets registered as client if spring-cloud-starter-netflix-eureka-client is on the class path.

By having spring-cloud-starter-netflix-eureka-client on the classpath, your application automatically registers with the Eureka Server. Configuration is required to locate the Eureka server.

否则需要开启 @EnableEurekaClient 注解:

1@SpringBootApplication
2@EnableEurekaClient
3public class PaymentMain8001 {
4    public static void main(String[] args) {
5        SpringApplication.run(PaymentMain8001.class, args);
6    }
7}

接着进行基础配置如下：

 1# eureka 配置部分
 2eureka:
 3    client:
 4    register-with-eureka: true # 配置是否进行注册
 5    fetch-registry: true # 配置是否从eureka注册中心拉取注册信息
 6    service-url: # 配置注册地址
 7        defaultZone: http://eureka7001.com:7001/eureka, http://eureka7002.com:7002/eureka
 8    instance:
 9    instance-id: payment8001
10    prefer-ip-address: true # 鼠标到instance上会显示ip
11
12# 配置服务名称
13spring:
14    application:
15    name: cloud-payment-service

这个服务名很重要，用于配置后面用户接口的服务地址。

80 端口关键配置内容

开启 @EnableEurekaClient 注解:

1@SpringBootApplication
2@EnableEurekaClient
3public class OrderMain80 {
4    public static void main(String[] args) {
5        SpringApplication.run(OrderMain80.class, args);
6    }
7}

配置 RestTemplate，开启负载均衡:

1@Configuration
2public class ApplicationContextConfig {
3    @Bean
4    @LoadBalanced // 赋予负载均衡能力
5    public RestTemplate getRestTemplate() {
6        return new RestTemplate();
7    }
8}

Controller 指定负载均衡访问服务地址:

 1@RestController
 2@Slf4j
 3public class OrderController {
 4    public static final String PAYMENT_URL = "http://CLOUD-PAYMENT-SERVICE";
 5
 6    @Resource
 7    private RestTemplate restTemplate;
 8
 9    @GetMapping("/consumer/payment/create")
10    public CommonResult<Integer> create(@RequestParam(value = "serial") String serial) {
11        Payment payment = new Payment(0L, serial);
12        log.info("serial: " + serial);
13        return restTemplate.postForObject(PAYMENT_URL + "/payment/create", payment, CommonResult.class);
14    }
15
16    @GetMapping("/consumer/payment/get/{id}")
17    public  CommonResult<Payment> getPayment(@PathVariable("id") Long id) {
18        return restTemplate.getForObject(PAYMENT_URL + "/payment/get/" + id, CommonResult.class);
19    }
20}

注意：

Controller 必须是 GetMapping，然后通过 restTemplate.getForObject()或 restTemplate.postForObject()发送 get 或 post 请求。
配置的服务地址前缀为 http:// 加上服务接口对应的 application-name 的全大写形式。

效果展示

访问 http://localhost:7001 或者 http://eureka7001.com:7001

可见所有服务已经成功注册。

访问 http://localhost/consumer/payment/get/3

成功返回结果，服务端口动态变换：

1{
2    "code":200,
3    "message":"查询成功，访问端口：8001",
4    "data":{"id":3,"serial":"ajefskldfa"}
5}

1{
2    "code":200,
3    "message":"查询成功，访问端口：8002",
4    "data":{"id":3,"serial":"ajefskldfa"}
5}

Nacos

Nacos 是阿里巴巴开源的一款动态服务发现、配置管理和服务管理平台，主要用于微服务架构中。Nacos 的名字来源于 Dynamic Naming and Configuration Service，它致力于帮助开发者实现服务的高可用性和动态管理。

主要功能

服务注册与发现：微服务实例启动时会将自己的地址和元数据注册到 Nacos，注册后，Nacos 会维护服务实例的健康状态；其他服务可以通过 Nacos 查询可用的服务实例列表，支持 DNS 和 HTTP REST 两种服务发现机制。
配置管理：应用的所有配置可以集中存储在 Nacos 中，简化配置管理，配置可以动态刷新，服务无需重启即可更新配置，支持多环境和多租户。
动态服务配置：Nacos 可以根据流量动态调整服务的路由策略，结合服务网格实现流量分配与治理。

基本架构

核心组件：

服务端：提供服务注册、发现、配置管理和健康检查等功能。
客户端：微服务通过 Nacos SDK 与服务端交互，实现注册、发现和配置读取。

工作流程：

服务实例启动时，向 Nacos 注册自己的元数据。
其他服务通过 Nacos 获取服务列表，并根据路由策略调用目标服务。
配置更新后，Nacos 将变更通知到相关的服务实例。

实践测试

总体架构

在一台 CentOS 主机上部署，版本为 7.9，IP 为 192.168.1.127。

通过 docker 创建三台 nacos 环境的机器，端口均运行在 8848，分别映射到主机的 8848，8858，8868 端口上，名称（hostname）分别为 nacos-server1，nacos-server2，nacos-server3。

主机通过 nginx 监听 8080 端口，通过负载均衡将请求转发到三台 nacos 机器上。

主机作为数据库源，使用 mysql 作为数据库，端口为 3306，三台机器都安装 mysql 环境，端口运行在 3306，映射到主机 3307 端口。

服务说明

创建一个简单的服务，注册到上述 nacos 环境中，通过在 bootstrap.yaml 中读取 nacos 配置来验证环境是否配置成功。

搭建 nacos 环境

在 nacos 官网下载 nacos-docker 到主机上，编辑 docker-compose.yaml 文件。

根据官网说明，在 nacos2 中需要额外暴露两个端口，分别偏移 8848 这个端口 1000 和 1001。

 1version: "3"
 2services:
 3  nacos1:
 4    hostname: nacos-server-1
 5    container_name: nacos1
 6    image: nacos/nacos-server:${NACOS_VERSION}
 7    volumes:
 8      - ./cluster-logs/nacos1:/home/nacos/logs
 9      - ./init.d/custom.properties:/home/nacos/init.d/custom.properties
10    ports:
11      - "8848:8848"
12      - "9848:9848" # 偏移 1000
13      - "9849:9849" # 偏移 1001
14      - "9555:9555"
15    env_file:
16      - ../env/nacos-hostname.env
17    restart: always
18    depends_on:
19      - mysql
20
21  nacos2:
22    hostname: nacos-server-2
23    image: nacos/nacos-server:${NACOS_VERSION}
24    container_name: nacos2
25    volumes:
26      - ./cluster-logs/nacos2:/home/nacos/logs
27      - ./init.d/custom.properties:/home/nacos/init.d/custom.properties
28    ports:
29      - "8858:8848"
30      - "9858:9848"
31      - "9859:9849"
32    env_file:
33      - ../env/nacos-hostname.env
34    restart: always
35    depends_on:
36      - mysql
37
38  nacos3:
39    hostname: nacos-server-3
40    image: nacos/nacos-server:${NACOS_VERSION}
41    container_name: nacos3
42    volumes:
43      - ./cluster-logs/nacos3:/home/nacos/logs
44      - ./init.d/custom.properties:/home/nacos/init.d/custom.properties
45    ports:
46      - "8868:8848"
47      - "9868:9848"
48      - "9869:9849"
49    env_file:
50      - ../env/nacos-hostname.env
51    restart: always
52    depends_on:
53      - mysql
54      
55  mysql:
56    container_name: mysql
57    image: nacos/nacos-mysql:5.7
58    env_file:
59      - ../env/mysql.env
60    volumes:
61      - ./mysql:/var/lib/mysql
62    ports:
63      - "3307:3306"

配置数据库信息

通过官网提供的 sql 脚本在主机建好数据库。

接着指定 mysql 数据库源信息，编辑 env/nacos-hostname.env 文件如下：

1PREFER_HOST_MODE=hostname # hostname 模式
2NACOS_SERVERS=nacos-server-1 nacos-server-2 nacos-server-3
3MYSQL_SERVICE_HOST=192.168.1.127
4MYSQL_SERVICE_DB_NAME=nacos_config
5MYSQL_SERVICE_PORT=3306
6MYSQL_SERVICE_USER=****
7MYSQL_SERVICE_PASSWORD=******

注意填写好主机的 mysql 账号密码。

最后指定 docker 中 mysql 信息，编辑 env/mysql.env 文件即可：

1MYSQL_ROOT_PASSWORD=******
2MYSQL_DATABASE=nacos_config
3MYSQL_USER=****
4MYSQL_PASSWORD=******

运行 docker

 1docker-compose up
 2
 3nacos2  | 2022-08-07 07:05:41,147 INFO Nacos started successfully in cluster mode. use external storage
 4nacos2  |
 5nacos1  | 2022-08-07 07:05:41,194 INFO Nacos is starting...
 6nacos1  |
 7nacos1  | 2022-08-07 07:05:41,240 INFO Nacos started successfully in cluster mode. use external storage
 8nacos1  |
 9nacos3  | 2022-08-07 07:05:42,097 INFO Nacos is starting...
10nacos3  |
11nacos3  | 2022-08-07 07:05:42,135 INFO Nacos started successfully in cluster mode. use external storage

搭建 nginx 环境

首先安装 nginx，接着编辑 /etc/nginx/nginx.conf 文件如下：

 1...
 2
 3http {
 4    ...
 5    upstream nacos-servers {
 6            server 192.168.1.127:8848;
 7            server 192.168.1.127:8858;
 8            server 192.168.1.127:8868;
 9    }
10    server {
11            location / {
12                    proxy_pass http://nacos-servers;
13            }
14            listen 8080;
15    }
16}

监听 8080 端口，通过 upstream 转发到三台机器上。

接着运行 nginx 即可：

1nginx -c /etc/nginx/nginx.conf

创建微服务

依赖导入：

1<dependency>
2    <groupId>com.alibaba.cloud</groupId>
3    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
4</dependency>
5<dependency>
6    <groupId>com.alibaba.cloud</groupId>
7    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
8</dependency>

基本配置。编辑 bootstarp.yaml 如下：（nacos 的地址即 nginx 配置好的地址 192.168.1.127:8080）

 1spring:
 2  cloud:
 3    nacos:
 4      discovery:
 5        server-addr: 192.168.1.127:8080
 6      config:
 7        server-addr: 192.168.1.127:8080
 8        file-extension: yaml
 9  profiles:
10    active: prod
11  application:
12    name: nacos-config-client
13server:
14  port: 9669

编写服务

启动类开启 @EnableDiscoveryClient 注解，然后编写接口：

 1@RefreshScope
 2@RestController
 3@Slf4j
 4public class ConfigController {
 5    @Value("${config.version}")
 6    private String version;
 7
 8    @GetMapping("/v")
 9    public String getVersion() {
10        return version;
11    }
12}

完成测试

访问 192.168.1.127:8080，成功访问并登录；
查看集群管理的节点列表，三个前缀名为 nacos-server 的节点都处在 UP 状态；
编写 nacos-config-client-prod.yaml 文件，为微服务名+环境的格式，新增变量 config.version 为 1.0；
开启微服务，再查看服务列表，名为 nacos-config-client 的服务已经成功注册，访问接口 /v，返回 1.0；
修改配置，version 改为 2.0，再次访问 /v 接口，返回 2.0。

API 网关

网关的作用

如图所示，网关介于外部请求和具体微服务之间，在不暴露内部微服务端口的情况下，通过一个或者多个指定的网关端口统一地处理外部各种请求。

SpringCloud Gateway 实践

依赖引入

除了基本依赖以外，引入下列依赖：

1<dependency>
2    <groupId>org.springframework.cloud</groupId>
3    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
4</dependency>
5<dependency>
6    <groupId>org.springframework.cloud</groupId>
7    <artifactId>spring-cloud-starter-gateway</artifactId>
8</dependency>

注意不能引入 web 相关依赖，因为 Gateway 是基于 WebFlux 的。

文件配置

列出部分重要配置：

 1server:
 2port: 9669
 3cloud:
 4    gateway:
 5    discovery:
 6        locator:
 7        enabled: true # 开启从注册中心动态创建路由的功能，利用微服务名进行路由
 8    routes:
 9        - id: path_route
10        uri: lb://CLOUD-PAYMENT-SERVICE # lb：负载均衡
11        predicates:
12            - Path=/payment/**
13            - After=2022-07-26T17:33:52.449+08:00[Asia/Shanghai] # ZonedDateTime.now()
14            - Cookie=username,jzh

注意点如下：

9669 端口作为网关端口；
uri 中 http 改为了 lb，用于负载均衡；
predicates，即断言，上述断言为：
- 匹配路径：/payment/**；
- 开始允许访问时间：ZonedDateTime.now()（Java函数获取该格式时间）
- 携带cookie：key=username, value=jzh

过滤器配置

实现 GlobalFilter，Ordered，重写方法即可：

 1@Component
 2@Slf4j
 3public class MyGlobalFilter implements GlobalFilter, Ordered {
 4    @Override
 5    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
 6        String username = exchange.getRequest().getQueryParams().getFirst("username");
 7        if (username == null) {
 8            log.info("username lost");
 9            exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);
10            return exchange.getResponse().setComplete();
11        }
12        return chain.filter(exchange);
13    }
14
15    @Override
16    public int getOrder() {
17        return 0;
18    }
19}

定义了 url 中携带必须携带一个 key 为 username 的参数。

测试

注意先开启指定的微服务，访问http://localhost:9669/payment/get/11?username=aaa（同时配好cookie），成功返回结果：

1{
2    "code": 200,
3    "data": {
4        "serial": "8asd8sa2j",
5        "id": 11
6    },
7    "message": "查询成功，访问端口：8001"
8}

再刷新，发现端口动态变化为8002，负载均衡功能也测试成功。

分布式配置

基本概念

分布式配置是一种在分布式系统或微服务架构中，用于集中管理和分发应用配置的机制。它解决了多服务、多节点环境下配置管理的复杂性，确保各服务实例能够动态获取和更新所需的配置数据。

常用分布式配置工具有 Spring Cloud Config、Consul、以及之前提到的 Nacos。

Spring Cloud Config

这里结合 Bus 来实现分布式配置。当全局配置修改时，需要通知各个微服务，一个一个地通知是非常耗时的，如果可以通过广播的方式快速将消息传递出去就轻松多了，而通过 Bus 即可实现这一点。

操作方法

在 6996 端口通过 git 拉取全局配置，相当于一个 ConfigServer；
6886 和 6776 端口作为 ConfigClient；
Bus 结合 RabbitMQ 实现，修改配置时，只通知 ConfigServer，达到消息广播的效果。

依赖引入

 1<!-- ConfigServer 端 -->
 2<dependency>
 3    <groupId>org.springframework.cloud</groupId>
 4    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
 5</dependency>
 6<dependency>
 7    <groupId>org.springframework.cloud</groupId>
 8    <artifactId>spring-cloud-config-server</artifactId>
 9</dependency>
10
11<!-- ConfigClient 端 -->
12<dependency>
13    <groupId>org.springframework.cloud</groupId>
14    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
15</dependency>
16<dependency>
17    <groupId>org.springframework.cloud</groupId>
18    <artifactId>spring-cloud-starter-config</artifactId>
19</dependency>

基础配置

 1# ConfigServer 端
 2# application.yaml
 3spring:
 4  cloud:
 5    config:
 6      server:
 7        git:
 8          # github 项目地址
 9          uri: https://github.com/akynazh/SpringCloud-Demo.git
10          # 指定搜索项目下 config 文件夹中的内容
11          search-paths:
12            - config
13          # 指定分支
14          default-label: master
15  rabbitmq:
16    host: localhost
17    port: 5672
18    username: guest
19    password: guest
20management:
21  endpoints:
22    web:
23      exposure:
24        # 通过 /actuator/bus-refresh 可进行事件通知
25        include: "bus-refresh"

以后，运维人员修改 config 时，即可通过 http://localhost:6996/actuator/bus-refresh 发送 POST 请求进行消息通知。

 1# ConfigClient 端
 2# bootstrap.yml | 可以加载全局配置
 3spring:
 4  application:
 5    name: cloud-config-client
 6  cloud:
 7    config:
 8      label: master # 分支
 9      name: config # 文件名
10      profile: dev # 环境
11      uri: http://localhost:6996 # 全局配置加载地址
12  rabbitmq:
13    host: localhost
14    port: 5672
15    username: guest
16    password: guest

值得注意的地方：

第一，config 文件名编写需要遵循一定规则，我选择的是 {name}-{profile}.yml 的格式，然后如上配置文件应该填写对应内容。

第二，application-name 可以用于后续选择性通知，如只想通知 6776，可通过 POST 请求访问如下地址：http://localhost:6996/actuator/bus-refresh/cloud-config-client:6776。

编写相关接口

在 ConfigServer 添加 @EnableConfigServer 注解，在 ConfigClient 端编写接口：

 1@RestController
 2@Slf4j
 3public class MyController {
 4
 5    @Resource
 6    private Environment env;
 7
 8    @Value("${server.port}")
 9    String port;
10
11    @GetMapping("/v")
12    public String getVersion() {
13        return "port: " + port + "\t " + env.getProperty("config.version");
14    }
15}

测试

启动 RabbitMQ:

1.sbin\rabbitmq-service.bat start

默认启动在 5672 端口。（图形界面在 15672 端口）

加载配置测试。访问：http://localhost:6996/master/config-dev.yml，会从 github 加载得到：

1config:
2  label: master
3  profile: dev
4  version: 3.0

访问：http://localhost:6776/v，得到：

1port: 6776 3.0

6886 得到相同结果，证明成功加载全局配置。

修改配置测试。修改配置 version 为 3.6，提交，发送请求如下：

1curl -X POST "http://localhost:6996/actuator/bus-refresh"

发现三个端口 version 均改为 3.6，测试通过。

修改配置 version 为 3.9，提交，发送请求如下：

1curl -X POST "http://localhost:6996/actuator/bus-refresh/cloud-config-client:6776"

发现 6996 和 6776 的 version 为 3.9，而 6886 的 version 仍为 3.6，测试通过。

服务通信

采用协议

HTTP
RPC
gRPC
Dubbo

gRPC 协议介绍

gRPC 是 Google 基于 HTTP/2 以及 protobuf 的开发的协议：

gRPC 是高性能的，由于是基于 HTTP/2，支持多路复用、头部压缩、低延迟和二进制传输，大幅提高了数据传输效率。
Protobuf 采用高效的二进制序列化，比 JSON 或 XML 更快且数据更小，Protobuf 一方面选用了 VarInts 对数字进行编码，解决了效率问题；另一方面给每个字段指定一个整数编号，传输的时候只传字段编号，解决了冗余问题。
使用 Protobuf 定义服务接口，提供强类型约束，减少通信中的解析错误并简化代码生成。
gRPC 支持全双工通信，支持客户端流式、服务端流式和双向流式通信，适用于需要实时或高频数据传输的场景。

Dubbo 协议介绍

Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。dubbo RPC 是 dubbo 体系中最核心的一种高性能、高吞吐量的远程调用方式。

负载均衡

基本思想

负载均衡（LB），即是对于用户的某个请求，将有多个相同功能的服务点服务该请求，某个服务点挂了，其他服务点还是可以进行服务，这样就实现了系统的高可用。

关于集中式 LB 和进程内 LB

集中式 LB

在服务的消费方和提供方之间使用独立的 LB 设施，（软硬件均可，软件如 Nginx，硬件如 F5），由该设施负责把访问请求通过某种策略（可自行指定）转发至服务的提供方。

进程内 LB

将 LB 逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务点进行服务。

Ribbon 属于进程内 LB，它只是一个类库，集成于消费方进程，消费方通过它获取服务提供方的地址。

Dubbo

Dubbo 内置了 client-based 负载均衡机制，如下是当前支持的负载均衡算法，结合上文提到的自动服务发现机制，消费端会自动使用 Weighted Random LoadBalance 加权随机负载均衡策略选址调用。

如果要调整负载均衡算法，以下是 Dubbo 框架内置的负载均衡策略：

加权随机：默认算法，默认权重相同
加权轮询：借鉴于 Nginx 的平滑加权轮询算法，默认权重相同
最少活跃优先 + 加权随机：背后是能者多劳的思想
最短响应优先 + 加权随机：更加关注响应速度
一致性哈希：确定的入参，确定的提供者，适用于有状态请求
Power of Two Choice：随机选择两个节点后，继续选择“连接数”较小的那个节点
自适应负载均衡：在 P2C 算法基础上，选择二者中 load 最小的那个节点

Dubbo 框架的默认策略是 random 加权随机负载均衡。如果要调整策略，只需要设置 loadbalance 相应取值即可。为所有服务调用指定全局配置：

1dubbo:
2  consumer:
3    loadbalance: roundrobin

Ribbon

Ribbon 是一个用于微服务架构的 客户端负载均衡工具。它的核心功能是通过客户端侧的负载均衡，帮助微服务在调用其他服务时动态选择最优的实例。

具体功能

客户端负载均衡：
- Ribbon 会维护目标服务实例列表，并根据配置的负载均衡策略（如轮询、随机等）在这些实例间分发请求。
- 例如，当一个服务需要访问其他服务的多个实例时，Ribbon 会动态决定使用哪一个实例。
服务发现集成：
- Ribbon 可以与服务注册中心（如 Eureka）集成，动态获取服务实例列表，无需手动更新配置。
自定义负载均衡策略：
- 提供多种内置策略（如轮询、随机、加权轮询等）。
- 允许开发者实现自定义策略以满足特定业务需求。
故障检测与重试：
- Ribbon 支持健康检查，可在目标服务实例不可用时自动排除。
- 提供自动重试功能，增加请求成功的可能性。

基本架构

Ribbon 是一个完全在客户端运行的负载均衡器。其基本工作流程如下：

客户端通过 Ribbon 请求目标服务。
Ribbon 查询服务实例列表（可能来自配置文件，也可能通过 Eureka 动态获取）。
根据负载均衡策略选择一个实例。
将请求发送到选定的实例。

实践测试

Ribbon 通常与 Spring Cloud 一起使用，在微服务环境中，服务消费者通过 Ribbon 调用服务提供者。

如果与 Eureka 集成，则导入依赖如下：

1<dependency>
2    <groupId>org.springframework.cloud</groupId>
3    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> <!-- 已经包含了ribbon -->
4</dependency>

然后开启注解：

1@Configuration
2public class ApplicationContextConfig {
3    @Bean
4    @LoadBalanced // 赋予负载均衡能力
5    public RestTemplate getRestTemplate() {
6        return new RestTemplate();
7    }
8}

访问相同服务名地址即可。下面来指定 Ribbon 负载均衡规则，所有规则均实现了 IRule 接口，通过查看接口实现类即可知道规则的种类。

默认是 RoundRobinRule（轮询）这一规则。下面修改为 RandomRule（随机）这一规则，在启动类扫描不到的包下创建规则：

1@Configuration
2public class MyRibbonRule {
3    @Bean
4    public IRule myRule() {
5        return new RandomRule();
6    }
7}

最后在启动类指定规则：

1@SpringBootApplication
2@EnableEurekaClient
3@RibbonClient(name="CLOUD-PAYMENT-SERVICE", configuration = MyRibbonRule.class)
4public class OrderMain80 {
5    public static void main(String[] args) {
6        SpringApplication.run(OrderMain80.class, args);
7    }
8}

自己实现负载均衡

编写 LB 接口即实现类

要实现负载均衡，首先应获取得到所有的服务实例 ServiceInstance。

1public interface LoadBalancer {
2    ServiceInstance getServiceInstance(List<ServiceInstance> instances);
3}

通过自旋锁获取新值，取余 ServiceInstance 个数，得到目标 ServiceInstance 下标。

 1@Component
 2public class MyLoadBalancer implements LoadBalancer {
 3    private AtomicInteger aint = new AtomicInteger(0);
 4    public final int myCAS() {
 5        int expect, next;
 6        for (;;) {
 7            expect = aint.get();
 8            next = (expect + 1) % Integer.MAX_VALUE;
 9            if (aint.compareAndSet(expect, next)) return next;
10        }
11    }
12    @Override
13    public ServiceInstance getServiceInstance(List<ServiceInstance> instances) {
14        if (instances == null || instances.size() <= 0) return null;
15        return instances.get(myCAS() % instances.size());
16    }
17}

编写 Controller

注意需要通过获取得到的 ServiceInstance 的 uri 作为访问前缀。

 1@Resource
 2private RestTemplate restTemplate;
 3
 4@Resource
 5private EurekaDiscoveryClient discoveryClient;
 6
 7@Resource
 8private LoadBalancer loadBalancer;
 9
10@GetMapping("/consumer/payment/lb")
11public String lbTest() {
12    List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");
13    ServiceInstance instance = loadBalancer.getServiceInstance(instances);
14    log.info("lbtest: " + instance.getUri().toString());
15
16    return restTemplate.getForObject(instance.getUri() + "/payment/lb", String.class);
17}

接着访问 /consumer/payment/lb 接口即可完成负载均衡的测试。

容错机制：服务熔断

基本思想

应对微服务雪崩效应的一种链路保护机制，类似保险丝。

关于雪崩效应：

微服务之间的数据交互是通过远程调用来完成的。服务 A 调用服务，服务 B 调用服务 C，某一时间链路上对服务 C 的调用响应时间过长或者服务 C 不可用，随着时间的增长，对服务 C 的调用也越来越多，然后服务 C 崩溃了，但是链路调用还在，对服务 B 的调用也在持续增多，然后服务 B 崩溃，随之 A 也崩溃，导致雪崩效应。

实现机制

当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

通过 Hystrix 实现服务熔断，Hystrix 会监控微服务间调用的状况，当失败的调用到一定阈值，就会启动熔断机制，断路器打开。而在一段时间之后，断路器会变为半开状态，此时允许部分微服务调用，如果都成功了，即不超过设定好的阈值，那么断路器将恢复为关闭状态。

如下图所示：（来自Martin Fowler大神的博客）

Hystrix 实践

这里实现一下服务监控和熔断。

依赖导入

 1<!-- 服务熔断 -->
 2<dependency>
 3    <groupId>org.springframework.cloud</groupId>
 4    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
 5</dependency>
 6<dependency>
 7    <groupId>org.springframework.cloud</groupId>
 8    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
 9</dependency>
10
11<!-- 服务监控 -->
12<dependency>
13    <groupId>org.springframework.cloud</groupId>
14    <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
15</dependency>

基本配置

启动类添加 @EnableHystrix 注解，表示使用熔断器，添加 @EnableHystrixDashboard 注解，表示使用监控面板。

在要监控的服务的配置文件中添加：

1# hystrix 9001 监控配置
2management:
3endpoints:
4    web:
5    exposure:
6        include: hystrix.stream, info, health

方法实现

1// PaymentService.java
2public interface PaymentService {
3    ...
4    String circuitBreaker(Integer id);
5}

在实现类设置服务熔断的核心配置：

 1// （1）启用断路器: 
 2@HystrixProperty(name = "circuitBreaker.enabled", value = "true")
 3
 4// （2）设置请求次数: 
 5@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10")
 6
 7// （3）设置时间窗口期: 
 8@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000")
 9
10// （4）设置失败率: 
11@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60")

如上设置的值，如果在 10 秒内，失败率达到请求次数（10）的百分之 60，也就是 6 次，就会打开断路器，否则断路器依然关闭。

断路器打开后，在一定时间之后，断路器变为半开状态，允许部分请求访问，如果这些请求满足要求，不超阈值，则断路器恢复为关闭状态。

 1@Service
 2public class PaymentServiceImpl implements PaymentService {
 3    ...
 4    @Override
 5    @HystrixCommand(fallbackMethod = "circuitBreaker_fallback",
 6            commandProperties = {
 7                    @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),
 8                    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),
 9                    @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"),
10                    @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60")
11            })
12    public String circuitBreaker(Integer id) {
13        if (id < 0) throw new RuntimeException("id 不能小于0");
14        String uuid = IdUtil.simpleUUID();
15        return Thread.currentThread().getName() + "\t" + "uuid:" + uuid;
16    }
17    public String circuitBreaker_fallback(@PathVariable("id") Integer id) {
18        return "id 不能小于0, 请重试~ id: " + id;
19    }
20}

接着编写接口：

 1// PaymentController.java
 2@RestController
 3@Slf4j
 4public class PaymentController {
 5    @Resource
 6    private PaymentService paymentService;
 7
 8    @GetMapping("/payment/cir/{id}")
 9    public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
10        return paymentService.circuitBreaker(id);
11    }
12    ...

测试

打开：http://{ip}:{port}/hystrix；
监控：http://{ip}:{port}/actuator/hystrix.stream；
访问 http://localhost:8001/payment/cir/1，可以正常访问；
多次访问http://localhost:8001/payment/cir/-1, 返回系统繁忙信息，发现断路器开启了：
此时，再访问http://localhost:8001/payment/cir/1，发现返回了系统繁忙信息；
多次访问http://localhost:8001/payment/cir/1，发现断路器关闭，恢复正常访问。

容错机制：服务降级

基本思想

服务降级是指在服务器压力剧增的时候，根据实际业务使用情况以及流量，对一些服务和页面有策略的不处理或者用一种简单的方式进行处理，从而释放服务器资源的资源以保证核心业务的正常高效运行。

多用于微服务架构中，一般当整个微服务架构整体的负载超出了预设的上限阈值（和服务器的配置性能有关系），或者即将到来的流量预计会超过预设的阈值时。

实现机制

为了预防某些功能出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的 fallback（退路）错误处理信息。

这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

Hystrix 实践

本实践配合了 Feign 实现，利用 Feign 通过接口的方式解耦服务这一特点，通过在实现服务接口的类来编写方法对应的 fallback 方法。

依赖导入

在消费方实现服务降级，除了基本包导入外，导入以下：

 1<dependency>
 2    <groupId>org.springframework.cloud</groupId>
 3    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
 4</dependency>
 5<dependency>
 6    <groupId>org.springframework.cloud</groupId>
 7    <artifactId>spring-cloud-starter-openfeign</artifactId>
 8</dependency>
 9<dependency>
10    <groupId>org.springframework.cloud</groupId>
11    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
12</dependency>

基本配置

 1# 设置feign超时时间（默认为1秒）
 2feign:
 3hystrix:
 4    enabled: true
 5client:
 6    config:
 7    default:
 8        ConnectTimeOut: 5000
 9        ReadTimeOut: 5000
10# 设置hystrix超时时间（默认为1秒）
11hystrix:
12command:
13    default:
14    execution:
15        isolation:
16        thread:
17            timeoutInMilliseconds: 2000

其他关于 Feign 的环境配置省略了。

方法实现

在使用了 Feign 的基础上使用 Hystrix 功能，指定 fallback 对应的实现类。

 1// PaymentService.java
 2@Service
 3@FeignClient(value = "CLOUD-HYSTRIX-PAYMENT-SERVICE", fallback = PaymentHystrixService.class)
 4public interface PaymentService {
 5   //  ...
 6    @GetMapping("/payment/tt")
 7    CommonResult<Object> timeoutTest();
 8}
 9
10// PaymentServiceImpl.java
11@Service
12public class PaymentHystrixService implements PaymentService {
13   //  ...
14    @Override
15    public CommonResult<Object> timeoutTest() {
16        return new CommonResult<>(500, "error");
17    }
18}

接着编写接口：

 1// PaymentController.java
 2@RestController
 3@Slf4j
 4public class PaymentController {
 5    @Resource
 6    private PaymentService paymentService;
 7    ...
 8    /**
 9    * @description: 访问一个耗时超过3秒的服务
10    * @author Jiang Zhihang
11    * @date 2022/7/26 11:16
12    */
13    @GetMapping("/consumer/payment/tt")
14    public CommonResult<Object> timeoutTest() {
15        return paymentService.timeoutTest();
16    }
17}

测试

一、访问 http://localhost:8001/payment/tt，由于 hystrix 配置最小超时时间为 2 秒，而访问时间超 3 秒，所以得到如下结果：

1{
2    "code": 500,
3    "message": "error",
4    "data": null
5}

可以发现调用了 fallback 方法。

二、修改 hystrix 超时时间为 4 秒，再次访问得到：

1{
2    "code": 200,
3    "message": "timeout test",
4    "data": null
5}

得到成功返回的数据。

容错机制：服务限流

实现目标

当系统的处理能力不能应对外部请求的突增流量时，为了不让系统奔溃，必须采取限流的措施。限流目标：

防止被突发流量冲垮
防止恶意请求和攻击
保证集群服务中心的健康稳定运行（流量整形）
API 经济的细粒度资源量（请求量）控制

限流算法

计数限流算法
固定窗口限流算法（采样时间窗）
滑动窗口限流（记录每个请求到达的时间点）
漏桶算法（定速流出）：宽进严出，按照固定速率处理
令牌桶算法（定速流入）：每个请求分配一个令牌，只有拿到了令牌才能进入服务器处理

容错机制：Sentinel

通过 Sentinel 同时完成实现服务熔断、降级和限流。

基本概念

Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。

架构说明

两个生产者服务运行在 9001 和 9002 端口，一个消费者服务运行在 80 端口，均注册到 nacos，消费者调用两个生产者的服务。

将消费者服务注册到 sentinel 中，通过修改一些规则进行测试：

controller 下的方法指定好处理服务限流，降级或熔断等的方法 blockHandler，以及处理未知异常的 fallback 方法，通过指定 class 的方法避免代码膨胀。
service 下的方法指定好关于生产者的服务限流，降级或熔断等的处理方法。

代码实现（生产者端）

基本配置

关于 nacos 的配置省略，只记录 sentinel 的配置：

1spring:
2  application:
3    name: nacos-payment-provider
4  cloud:
5    sentinel:
6      transport:
7        dashboard: localhost:8080
8        port: 8179

方法实现

返回对应端口，方便测试负载均衡：

 1@RestController
 2@Slf4j
 3public class PaymentController {
 4    @Value("${server.port}")
 5    private String port;
 6
 7    @GetMapping("/payment/nacos/info")
 8    public String paymentInfo() {
 9        return "port: " + port;
10    }
11}

代码实现（消费者端）

依赖导入

1<dependency>
2    <groupId>com.alibaba.cloud</groupId>
3    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
4</dependency>

基本配置

注意要开启 feign 的 sentinel 支持：

 1spring:
 2  application:
 3    name: nacos-order-consumer
 4    sentinel:
 5      transport:
 6        dashboard: localhost:8080
 7        port: 8179
 8feign:
 9  sentinel:
10    enabled: true

方法实现

1@FeignClient(value = "nacos-payment-provider", fallback = PaymentFallbackService.class)
2@Service
3public interface PaymentService {
4    @GetMapping("/payment/nacos/info")
5    String paymentInfo();
6}

对应实现类：

1@Service
2public class PaymentFallbackService implements PaymentService{
3    @Override
4    public String paymentInfo() {
5        return "feign::fallback";
6    }
7}

这里处理关于生产者的服务限流，降级或熔断问题。

两个服务问题 Hanlder 的编写。根据官方文档，这里的方法都需指明为 static，否者无法识别：

1@Component
2public class GlobalBlockHandler {
3    public static String block1(BlockException e) {return "block1";}
4    public static String block2(BlockException e) {return "block2";}
5}

这个用于消费者端处理服务限流，降级或熔断等问题。

1@Component
2public class GlobalFallbackHandler {
3    public static String fallback1()  {return "fallback1";}
4    public static String fallback2()  {return "fallback2";}
5}

这个用于消费者端处理未知异常。

最后编写 controller，指定处理方式：

 1@RestController
 2@Slf4j
 3public class OrderController {
 4    @Resource
 5    PaymentService paymentService;
 6
 7    @GetMapping("/consumer/payment/nacos/info")
 8    @SentinelResource(
 9            value = "paymentInfo",
10            fallbackClass = GlobalFallbackHandler.class, fallback = "fallback1",
11            blockHandlerClass = GlobalBlockHandler.class, blockHandler = "block1"
12    )
13    public String paymentInfo()  {
14        int a = 1 / 0;
15        return paymentService.paymentInfo();
16    }
17}

指定好 class 的同时，需用 fallback 和 blockHandler 分别指定好具体的方法名。

测试

测试除 0 错误是否正确进入 fallback1：直接访问接口，返回 “fallback1”，正确；
测试消费者端服务限流：sentinel 指定流控规则，QPS 设置阈值为 1，连续访问接口，返回 “block1”，正确；
测试生产者端除 0 错误是否正确进入 fallback：给生产者 controller 添加除 0 错误，访问接口，返回 “feign::fallback”，正确；
测试其他服务规则：指定熔断规则，熔断策略选为慢调用比例，最大 RT（Round Trip Time，也叫响应时间）设置为 200ms，比例阈值设置为 0.5，最小请求数设置为 5。为模拟慢调用，手动增大发出接口请求到收到结果的延迟，在 controller 中添加 Thread.sleep(1000)，延迟 1 秒：连续访问接口，首先返回了“9001”，即访问正常时得到的结果，然而发现在 5 次以上的请求以后，返回了 “block1”，成功熔断。

Reference

数据库重要知识整理

akynazh@gmail.com (zhihang) — Wed, 22 Feb 2023 22:35:25 +0800

关系数据库理论

关系数据库理论为关系数据库的设计和实现提供了理论基础和指导原则。

关系语言的种类

关系代数
关系演算（元组演算和域演算）
SQL

关系的定义

候选码 (Candidate Key)：能唯一标识元组的属性(组)。
主码 (Primary Key)：多个候选码中选定一个作主码。
主属性 (Prime Attribute)：候选码中的诸属性。
非主属性 (Non-Key Attribute)：不出现在任何候选码中的属性。

关系运算

5 种基本关系代数运算：

并 ($\cup$)
差 ($-$)
投影 ($\pi$): 从某个关系中选择出若干属性列组成新的关系
选择 ($\sigma$): 在某个关系中选择满足给定条件的诸元组
笛卡尔积 ($\times$)

其它运算：

连接 ($\bowtie$): 从两个关系的笛卡尔积中选取属性间满足一定条件的元组
除 ($\div$): 设关系 R 除以关系 S 的结果为关系 T，则 T 包含所有在 R 但不在 S 中的属性及其值，且 T 的元组与 S 的元组的所有组合都在 R 中
重命名 ($\rho$): 将某个关系重命名为其它关系名

关系演算

关系演算就是用谓词来描述关系的构成(查询的结果)。按照谓词变元的不同分为元组关系演算和域关系演算，分别简称为元组演算和域演算。

元组演算例子

给出关系模式：

S (Sno, Sname, Ssex, Sage, Sdep)
C (Cno, Cname, Ccredit, Cpno)
SC (Sno, Cno, Grade)

查询选修学号为“95002”的学生所选全部课程的学生学号。

$\{ t|\exists u(SC(u) \land \forall v(SC(v) \land v['Sno']='95002' \rightarrow \exists w(SC(w) \land w['Sno']=u['Sno'] \land w['Cno']=v['Cno'])) \land t['Sno']=u['Sno']) \}$

域演算例子

同上关系模式，查询选修了 C2 课程的学生学号和成绩。

$\{t_1, t_2 | \exists u_1 \exists u_2 \exists u_3 (SC(u_1, u_2, u_3) \land u_2='c2' \land t_1=u_1 \land t_2=u_3)\}$

$\{t_1, t_2 | SC(t_1, 'C2', t_2)\}$

范式

数据库范式是用于规范化数据库表结构的规则，旨在减少冗余和提高数据完整性。下面具体介绍这几个范式。

BCNF: 关系模式 $R \in 3NF$，且对于 R 的每个函数依赖 $X \rightarrow Y (Y \nsubseteq X)$，X 必包含码

第一范式（1NF）

定义：关系模式 R 的所有属性都是不可分的基本数据项。即表中的每个字段都必须是原子的，即每个字段只能包含单一值，不能有重复的行。
目的：消除重复组，确保数据的原子性。
示例：如果一个表中有一个字段存储多个电话号码，需要将其拆分成多个独立的记录。

第二范式（2NF）

定义：关系模式 $R \in 1NF$，且每一个非主属性都完全函数依赖于 R 的码（而不是部分依赖）。即在满足 1NF 的基础上，表中的每个非主属性必须完全依赖于候选键的整个组成部分，而不是部分依赖。
目的：消除部分依赖，确保所有非主属性完全依赖于主键。
示例：如果一个表的主键由两个字段组成，而一个非主属性只依赖于其中一个字段，就需要将其分拆成两个表。

第三范式（3NF）

定义：关系模式 $R \in 2NF$，且不存在非主属性对码的传递依赖。即在满足 2NF 的基础上，表中的每个非主属性必须直接依赖于候选键，而不是通过其他非主属性间接依赖（即消除传递依赖）。
目的：消除传递依赖，确保非主属性仅依赖于主键。
示例：如果一个表主键为 AB，AB → C，但存在 A → B 和 B → C 的依赖关系，需要将其分拆成两个表，以消除 B → C 的传递依赖。

巴斯-科德范式（BCNF）

定义：在满足 3NF 的基础上，表中的每个决定因素都必须是候选键。
目的：进一步消除依赖异常，确保所有决定因素都是候选键。
示例：如果一个表中存在非主属性对主属性的依赖关系，需要将其分拆，以确保每个决定因素都是候选键。

通过遵循这些范式，可以设计出结构良好的数据库，提高数据的完整性和一致性。

数据库授权

将数据库中的某些对象的某些操作权限赋予某些用户

1GRANT <权限>[,<权限>]... 
2    [ON <对象类型> <对象名>]
3    TO <用户>[,<用户>]...
4    [WITH GRANT OPTION];

指定了 WITH GRANT OPTION 子句, 获得某种权限的用户还可以把这种权限再授予别的用户。

一些例子：

 1GRANT  ALL  PRIVILIGES /* 所有权限 */
 2ON  TABLE  Student, Course 
 3TO  U2, U3
 4WITH  GRANT  OPTION;
 5
 6GRANT  SELECT 
 7ON  TABLE  SC 
 8TO  PUBLIC; /* 所有用户 */
 9
10GRANT  UPDATE (Sno),  SELECT 
11ON  TABLE  Student 
12TO  U4;

从指定用户那里收回对指定对象的指定权限：

1REVOKE  <权限>[,<权限>]... 
2[ON  <对象类型> <对象名>]
3FROM  <用户>[,<用户>]...;

存储过程及触发器

存储过程

存储过程（Stored Procedure）是一组为了完成特定功能的 SQL 语句集，经编译后存储在服务器端数据库中，用户通过指定存储过程的名字并给定参数（如果该存储过程带有参数）来执行它。

 1CREATE [ OR ALTER ] { PROC | PROCEDURE }
 2    [schema_name.] procedure_name [ ; number ]
 3    [ { @parameter_name [ type_schema_name. ] data_type }
 4        [ VARYING ] [ NULL ] [ = default ] [ OUT | OUTPUT] | [READONLY]
 5    ] [ ,...n ]
 6[ WITH <procedure_option> [ ,...n ] ]
 7[ FOR REPLICATION ]
 8AS { [ BEGIN ] sql_statement [;] [ ...n ] [ END ] }
 9[;]
10
11<procedure_option> ::=
12    [ ENCRYPTION ]
13    [ RECOMPILE ]
14    [ EXECUTE AS Clause ]

一个例子：

 1USE pubs
 2GO
 3if exists (SELECT name  FROM sysobjects
 4	WHERE name = 'titles_sum' AND type = 'p ')
 5      DROP  PROCEDURE titles_sum
 6
 7GO
 8CREATE PROCEDURE titles_sum @stor_id char(4), @sum smallint 
 9OUTPUT AS
10	SELECT  ord_num, ord_date, payterms, title_id, qty
11	FROM sales
12	WHERE  stor_id = @stor_id
13	SELECT  @sum = sum (qty)
14	FROM sales
15	WHERE  stor_id = @stor_id
16	Return (0)
17GO

触发器

触发器是一种特殊类型的存储过程。它与存储过程的区别：触发器主要是通过事件进行触发而被执行的，而存储过程可以通过存储过程名字被直接调用执行。

当对某一表进行诸如 UPDATE、 INSERT、DELETE 这些操作时，SQL Server 就会自动执行触发器所定义的 SQL 语句。

 1CREATE [ OR ALTER ] TRIGGER [ schema_name . ]trigger_name   
 2ON { table | view }   
 3[ WITH <dml_trigger_option> [ ,...n ] ]  
 4{ FOR | AFTER | INSTEAD OF }   
 5{ [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] }   
 6[ WITH APPEND ]  
 7[ NOT FOR REPLICATION ]   
 8AS { sql_statement  [ ; ] [ ,...n ] | EXTERNAL NAME <method specifier [ ; ] > }  
 9  
10<dml_trigger_option> ::=  
11    [ ENCRYPTION ]  
12    [ EXECUTE AS Clause ]  
13  
14<method_specifier> ::=  
15    assembly_name.class_name.method_name

一个例子：

 1CREATE  TRIGGER  utitle1 ON titles
 2FOR  UPDATE
 3AS
 4declare @rows int
 5SELECT  @rows=@@rowcount
 6if @rows=0
 7     RETURN
 8if UPDATE (title_id)
 9BEGIN
10    if @rows > 1
11    BEGIN
12            raiserror( 'update to primary keys of multiple row is not permitted' , \\
13		16,10)
14            ROLLBACK  TRANSACTION
15            RETURN
16     END
17     UPDATE  t SET t.title_id=i.title_id
18     FROM  titleauthor  t,  inserted  i, deleted  d
19     WHERE   t.title_id=d.title_id
20END
21RETURN

原理解析：

在触发器的执行过程中，系统会自动建立和管理两个逻辑表：插入表（inserted）和删除表（deleted）。

这两个表与触发器所对应的基本表有着完全相同的结构，但为只读表，驻留于内存之中，直到触发器执行完毕，系统会自动删除。

这两个表是事务回滚的重要依据。

数据库事务

事务 (Transaction) 是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。

ACID 特性

原子性（Atomicity）：事务中包括的诸操作要么都做，要么都不做。
一致性（Consistency）：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
隔离性（Isolation）：一个事务的执行不能被其他事务干扰，而影响它对数据的正确使用和修改。
持久性（Durability）：一个事务一旦提交，它对数据库中数据的改变就应该是永久性的，接下来的其他操作或故障不应该对其执行结果有任何影响。

并发导致的问题

丢失修改：当两个事务并发执行但没有锁的控制，可能导致其中一个事务的处理结果被覆盖
脏读：某一事务发生回滚，另一事务读到的数据和数据库中的不一致
不可重复读：某一事务修改了数据，可能导致另一事务中前后读取到的数据不一致
幻读：某一事务插入或删除了部分记录，另一事务前后读取数据发现记录多或少了

四个隔离级别

读未提交：允许读到未提交的事务，解决了丢失修改问题。

一个事务读的时候允许其他事务操作，写的时候其他事务只能读不能写。

读已提交：只允许读已提交的事务，再解决了脏读问题。（PostgreSQL 默认隔离级别）

一个事务读的时候允许其他事务操作，写事务的时候禁止其他任何事务。

可重复读：再解决了不可重复读问题。（MySQL 默认隔离级别）

一个事务读取的时候其他事务不可修改（允许读），写事务的时候禁止其他任何事务。

串行化：再解决了幻读问题。

事务串行化执行，使用表级锁。

MVCC 多版本并发控制

MVCC, Multiversion Concurrency Control, 多版本并发控制，解决读写并发问题。

没有写的情况下发读-读并发是不会出现问题的，而写-写并发这种情况比较常用的就是通过加锁的方式实现。那么，读-写并发则可以通过 MVCC 的机制解决，它可通过无锁的方案来实现并发控制。

首先我们需要理解快照读和当前读，普通的 select 语句在加锁的情况下（for update）就是当前读，反之即快照读，而快照即是 UndoLog 中所记录的更新前的数据。当存在多个快照时，要读哪个呢，这时我们需要知道快照的存储方式。

数据库中的每行记录都存在着隐式字段：隐藏主键，对这条记录做了最新一次修改的事务 ID，以及回滚指针，它指向这条记录的上一个版本，即 UndoLog 中的上一个版本的快照的地址。当发生数据更新时，将会将当前行记录存为一个快照，当有多个快照时，多个快照将会通过回滚指针连成一个链表。

有了快照链表的概念，我们还需理解 ReadView，数据库通过它来决定快照链表中哪条记录是可见的，即会被某个 select 查出。不同隔离级别下，ReadView 的产生有差异。在读已提交隔离级别下，每一条 SELECT 都重新构建一个 ReadView，可以看到其他已经提交的事务对数据的修改，只要事务产生了，其结果都可见，与事务开始的先后顺序无关，也因此无法解决不可重复读的问题。而在可重复读隔离级别下，由第一条 SELECT 生成 ReadView，以后的 SELECT 将复用该 ReadView，这时只有已完成事务的修改可见，即在事务内部不会出现不一致的问题。

那么回到 MVCC，InnoDB 中的 MVCC 就是通过 ReadView + Undolog 来实现的。举个例子，当某个时刻只存在两个事务，一个写操作，一个读操作，这时读写均无需加锁，读操作直接根据 Read View 拿到合适的快照，而写操作直接写并且记录快照即可。

总的来讲，MVCC 是一种作用于读写并发时的无锁并发控制方案，通过 ReadView + Undolog 来实现，读写并发时读操作读 ReadView，写操作写 UndoLog 形成快照链表，此外，MVCC 在 Innodb 中是默认开启的。

注意，快照读的存在，使得读取数据不需要加锁，提高了读操作的性能，但这也意味着数据有可能是历史版本的，是弱一致的，如果同一事务中后续存在 Update 操作，并且基于本次读出来的数据，那么 Update 写入的数据实际上是错误的。

对于这类场景，可以通过在业务上使用乐观锁，在每条记录增加一个版本号字段，每次更新前比对，也可以手动加锁（悲观锁），将快照读升级为当前读：

1SELECT * FROM table WHERE id = 1 lock in share mode	-- 加读锁
2SELECT * FROM table WHERE id = 1 for update	-- 加写锁

对于 for update, 它会锁定行或者表，上的是排他锁，不同情况锁的行会有差异：

当 for update 的字段为索引或者主键的时候，锁住索引或者主键对应的行
当没有匹配的行，则无锁
除此之外，则上表锁

如果出现无锁，innodb 将通过间隙锁解决 Insert + Update 并发问题。

2PL 两阶段锁

2PL 是数据库事务处理时的并发控制方法，以保证可串行化，解决写写并发问题。

操作数据必须读取当前版本数据的，叫做当前读，包括显式加锁的 SELECT 和隐式加写锁的 INSERT、UPDATE、DELETE。

在 2PL 的加锁阶段，只允许加锁操作，已有读锁可以加读锁但不能再加写锁，已有写锁则不能再加任何锁，无法获取锁的事务只能阻塞等待，直到持锁事务在解锁阶段（事务提交）释放锁后才能继续竞争锁并执行。

间隙锁

事务 A 加行锁 update 某个范围的数据后，事务 B 在这个范围内插入一条记录，这时事务 A 发现多了一条数据，而且没有被自己 update。

MySQL 的实现中，利用了间隙锁在一定索引区间内加锁，锁住甚至不需要的数据，防止其他事务往其中插入数据，这样行锁+间隙锁组成的 Next-Key 锁 就同时防止别的事务修改、删除和插入，解决了幻读的问题。

死锁

产生原因：
- 两个事务持有相反的锁顺序。
解决方案：
- innodb_lock_wait_timeout 设置超时回滚。
- 避免大事务，减少锁范围。

数据库设计

数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。

需求分析

需求分析就是通过详细调查现实世界要处理的对象（现实业务），充分了解原系统（手工系统或计算机系统），明确用户的各种需求，并在此基础上确定新系统的功能。需求分析包括两个步骤：需求信息的收集和分析。

需求信息的收集又称为系统调查，即了解用户的组织机构设置、主要业务活动和职能，以及对新系统的要求。

需求信息的分析就是对收集到的需求信息进行加工整理，以数据流图和数据字典的形式进行描述，作为需求分析阶段的成果，这也是下一步设计的基础。

概念模型设计

概念结构设计就是将现实事物以不依赖于任何数据模型的方式加以描述，目的在于以符号化的形式正确地反映现实事物及事物与事物之间的联系。

概念结构设计的内容就是建立概念模型。

这是一个通过 E-R 图构建概念模型的例子：

E-R 图三要素：实体，属性，联系。

逻辑结构设计

逻辑结构设计是对数据在计算机中的组织形式的设计，即依照 DBMS 支持的数据模型，设计用户数据的组织形式(模式设计)。同样，逻辑结构设计也是建立在概念结构设计的基础上，为下一步数据的存储设计(物理设计)作准备。

数据库恢复技术

恢复操作的基本原理是冗余，即利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据。

故障种类

事务故障：某个事务在运行过程中，由于种种原因未运行至正常，终止点就夭折了
系统故障：整个系统的正常运行突然被破坏，所有正在运行的事务都非正常终止，内存中数据库缓冲区的信息全部丢失，外部存储设备上的数据未受影响
介质（硬件）故障：存储数据库的设备（如硬盘）发生故障，使存储在其上的数据部分丢失或全部丢失

数据转储（backup）

转储是指 DBA 将整个数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据文本称为后备副本或后援副本。

转储操作的分类：

静态转储：在系统中无运行事务时进行转储，转储开始时数据库处于一致性状态，转储期间不允许对数据库的任何存取、修改活动。
动态转储：转储操作与用户事务并发进行，转储期间允许对数据库进行存取或修改。
海量转储：每次转储全部数据库。
增量转储: 只转储上次转储后更新过的数据。

登记日志文件（logging）

日志文件（log）是用来记录事务对数据库的更新操作的文件。

日志文件的格式及内容：

以记录为单位的日志文件
- 各个事务的开始标记(BEGIN TRANSACTION)
- 各个事务的结束标记(COMMIT或ROLLBACK)
- 各个事务的所有更新操作
- 与事务有关的内部更新操作
以数据块为单位的日志文件
- 事务标识
- 操作类型（插入、删除或修改）
- 操作对象（记录ID、Block NO.）
- 更新前数据的旧值（对插入操作而言，此项为空值）
- 更新后数据的新值（对删除操作而言, 此项为空值）

恢复策略

数据恢复就是在发生故障、数据被破坏时，根据后被副本和事务日志文件，将数据库恢复到故障前的正确状态（一致性状态）。

根据故障各类的不同，有不同的恢复方法：

事务故障：由恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改。
系统故障：Undo 故障发生时未完成的事务，Redo 已完成的事务。
介质故障：重装数据库，使数据库恢复到一致性状态，重做已完成的事务。

数据库 SQL 操作

表连接

1SELECT  [ ALL | DISTINCT ] <目标列表达式1> [, <目标列表达式2>] …
2FROM  <table_source1> 
3-- 不指定则默认使用内连接
4INNER|{LEFT | RIGHT | FULL [OUTER]} JOIN <table_source2> 
5ON <search_condition >
6[ WHERE  <条件表达式> ]

[INNER] JOIN 内连接：普通连接操作只输出满足连接条件的元组
LEFT [OUTER] JOIN 左外连接（⟕）：左表为主体，连接条件右边出现空行
RIGHT [OUTER] JOIN 右外连接（⟖）：右表为主体，连接条件左边出现空行
FULL [OUTER] JOIN 左右外连接（全外连接，⟗）：在连接条件的左右两边出现空行

外连接与内连接的区别：普通连接操作只输出满足连接条件的元组，外连接操作以指定表为连接主体，将主体表中不满足连接条件的元组一并输出。

“左”外连接，即以“左”表为主表。

查询操作

MySQL 执行一条 SELECT 语句的流程大致如下：

数据库日志

以 MySQL 为例，日志分类如下：

错误日志：记录 MySQL 启动、运行和停止时的错误信息
查询日志：记录所有的 SQL 查询，包括连接和断开连接的信息
慢查询日志：记录执行时间超过指定阈值的查询，用于性能调优
事务日志（RedoLog、UndoLog）
二进制日志（BinLog）

RedoLog

RedoLog，即重做日志，是物理日志, 记录内容是“在某个数据页上做了什么修改”, 记录的是物理数据页面修改的信息, 其 RedoLog 是顺序写入 RedoLogFile 物理文件中去的。

RedoLog 是 InnoDB 存储引擎独有的，它让 MySQL 拥有了崩溃恢复能力：

当 innodb_flush_log_at_trx_commit == 1 时, 会进行主动进行刷盘；当为 0 时不会主动进行刷盘, 如果 MySQL 挂了或宕机可能会有 1 秒数据的丢失；当为 2 时, 只要事务提交成功，RedoLogBuffer 中的内容只写入文件系统缓存, 如果仅仅只是 MySQL 挂了不会有任何数据丢失，但是宕机可能会有 1 秒数据的丢失。

UndoLog

UndoLog，即回滚日志，记录数据修改之前的原始值（即“前镜像”），所有事务进行的修改都会先记录到这个回滚日志中，然后再执行相关的操作。

我们知道如果想要保证事务的原子性，就需要在异常发生时，对已经执行的操作进行回滚，在 MySQL 中，恢复机制是通过回滚日志实现的。

如果执行过程中遇到异常的话，我们直接利用回滚日志中的信息将数据回滚到修改之前的样子。并且，回滚日志会先于数据持久化到磁盘上。这样就保证了即使遇到数据库突然宕机等情况，当用户再次启动数据库的时候，数据库还能够通过查询回滚日志来回滚将之前未完成的事务。

BinLog

BinLog 是逻辑日志, 记录内容是语句的原始逻辑, 类似于 “给 ID=2 这一行的 c 字段加 1”, 属于 MySQL Server 层。不管用什么存储引擎, 只要发生了表数据更新, 都会产生 BinLog 日志。MySQL 数据库的数据备份、主备、主主、主从模式 都离不开 BinLog，需要依靠 BinLog 来同步数据，保证数据一致性。

BinLog 的写入时机也非常简单，事务执行过程中，先把日志写到 BinLog Cache，事务提交的时候，再把 BinLog Cache 写到 BinLog 文件中。因为一个事务的 BinLog 不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为 BinLog Cache。

我们可以通过 BinLog_cache_size 参数控制单个线程 BinLog cache 大小，如果存储内容超过了这个参数，就要暂存到磁盘（Swap）。

上图的 write，是指把日志写入到文件系统的 page cache，并没有把数据持久化到磁盘，所以速度比较快。上图的 fsync 才是将数据持久化到磁盘的操作。 write 和 fsync 的时机可以由参数 sync_binLog 控制，默认是 1。sync_binLog 为 0 的时候，表示每次提交事务都只 write，由系统自行判断什么时候执行 fsync。虽然性能得到提升，但是机器宕机，page cache 里面的 BinLog 会丢失。为了安全起见，可以设置为 1，表示每次提交事务都会执行 fsync，就如同 RedoLog 日志刷盘流程一样。

最后还有一种折中方式，可以设置为N(N>1)，表示每次提交事务都 write，但累积 N 个事务后才 fsync。

BinLog 和 RedoLog 的一致性

RedoLog 两阶段提交原理？

首先需要了解 RedoLog 两阶段提交原理，其实就是把 RedoLog 的写入拆分成了两个步骤：prepare 和 commit。

SQL 更新语句执行顺序如下：

首先，存储引擎将执行更新好的新数据存到内存中，同时将这个更新操作记录到 RedoLog 里面，此时 RedoLog 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
然后执行器生成这个操作的 BinLog，并把 BinLog 写入磁盘。
最后执行器调用存储引擎的提交事务接口，存储引擎把刚刚写入的 RedoLog 状态改成 commit 状态，更新完成。

崩溃发生点及其相应造成的结果：

p1: 如果数据库在写入 RedoLog(prepare) 阶段之后、写入 BinLog 之前，发生了崩溃：

此时 RedoLog 里面的事务处于 prepare 状态，BinLog 还没写，之后从库进行同步的时候，无法执行这个操作，但是实际上主库已经完成了这个操作，所以为了主备一致，MySQL 崩溃时会在主库上回滚这个事务。

p2: 如果数据库在写入 BinLog 之后，RedoLog 状态修改为 commit 前发生崩溃：

此时 RedoLog 里面的事务仍然是 prepare 状态，BinLog 存在并完整，这样之后就会被从库同步过去，但是实际上主库并没有完成这个操作，所以为了主备一致，即使在这个时刻数据库崩溃了，主库上事务仍然会被正常提交。

MySQL 集群方案

一主多从架构

在 MySQL 的一主多从架构中，类似于 Redis 的主从架构，一个主节点负责处理所有的写操作，而多个从节点负责读取操作，从而提高数据库的读取性能和可用性。一主多从架构有多种复制模式。

异步复制

应用发起更新请求，即进行增加、删除、修改数据的操作时，主实例完成操作后会立即响应应用，同时主实例向备实例异步复制数据。因此，在异步数据复制方式下，备实例不可用时不会影响主实例上的操作，而主实例不可用时可能会导致主备实例数据不一致。

半同步复制

为解决异步同步 Binlog 复制数据会产生主从数据不一致的情况，MySQL 在 5.6 版本中推出半同步复制，在同步数据协议中添加了一个 ACK 同步操作，这样意味主节点在 commit 操作，需要确认最少一个从节点确认接收到并且返回 ACK，只有这样主节点才能正确提交数据。

应用发起的更新在主实例执行完成后，会将日志同步传输到备实例，备实例收到日志，事务就算完成了提交，不需要等待备实例执行日志内容。当备实例不可用或者主备实例间出现网络异常时，半同步会退化为异步。

组复制(MGR)

组复制基于分布式一致性协议（Paxos），事务在主节点提交之前，会将事务的数据发送到各个备节点上(而不是先写入 Binlog)，确保超过半数备节点收到事务的数据后，事务才能在主节点提交。

组复制支持单主和多主两种部署模式。

MMM 架构(双主多从)

两主多从架构，还是基于主从复制，增加了 master 备用机制。

MHA 架构(多主多从)

MHA 基于标准的主从复制提供了故障转换功能。MHA 节点分为管理节点和数据节点。管理节点会定时探测集群中的 master 节点，当 master 节点出现故障时，它可以自动将拥有最新数据的 slave 节点提升为新的 master 节点。

数据库索引

索引的分类

聚集索引：又称主键索引，主键索引的叶子节点存的是整行数据，根据主键查询可以直接查询出记录；
非聚集索引：又称普通索引，叶子节点内容是索引字段值和对应主键的值，如果需要查询的字段全部命中则无需回表（即覆盖索引），否则需要根据主键进行回表获取目标字段；
唯一索引：相比于普通索引增加了唯一性约束，更新操作会先判断是否违反唯一性约束，查找操作取到第一个满足条件的值就会停止；
联合索引：相比于普通索引，区别是联合索引由多个字段组成。

索引下推

以联合索引（name, age）为例。如果现在有一个需求：检索出表中“名字第一个字是张，而且年龄是 10 岁的所有男孩”。那么，SQL 语句是这么写的：

1mysql> select * from tuser where name like '张%' and age=10 and ismale=1;

根据前缀索引规则，所以这个语句在搜索索引树的时候，只能用 “张%"，age 索引失效，只能找到符合 “张%” 的列，在 MySQL5.6 之前，会逐个根据主键回表，找到符合 age=10 and ismale=1 的数据。

而 MySQL 5.6 引入的索引下推优化 (index condition pushdown)，可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数，如下图所示：

索引结构

B 树

B 树的出现是为了弥合不同的存储级别之间的访问速度上的巨大差异，实现高效的 I/O。

平衡二叉树的查找效率是非常高的，并可以通过降低树的深度来提高查找的效率。但是当数据量非常大，树的存储的元素数量是有限的，这样会导致二叉查找树结构由于树的深度过大而造成磁盘 I/O 读写过于频繁，进而导致查询效率低下。另外数据量过大会导致内存空间不够容纳平衡二叉树所有结点的情况。B 树是解决这个问题的很好的结构。

B 树是一种自平衡树数据结构，B 即 Balance。B 树是二叉搜索树的一般化，因为节点可以有两个以上的子节点。B 树非常适合读取和写入相对较大的数据块（如光盘）的存储系统，通常用于数据库和文件系统。

B 树的每个节点的元素可以视为一次 I/O 读取，树的高度表示最多的 I/O 次数，在相同数量的总元素个数下，每个节点的元素个数越多，高度越低，查询所需的 I/O 次数越少。这也是 B 树相比于 B+ 树的一个缺点，因为 B 树不管叶子节点还是非叶子节点，都会保存数据，这样导致在非叶子节点中能保存的指针数量变少（有些资料也称为扇出），指针少的情况下要保存大量数据，只能增加树的高度，导致 IO 操作变多，查询性能变低。

B+ 树

B+ 树是应文件系统所需而产生的 B 树的变形树。B+ 树相比于 B树的差异及优缺点：

B+ 树的磁盘读写代价更低，内部节点只存索引，更小，但单点查询不如 B 树
B+ 树查询效率稳定，树高即是路径长度
B+ 树便于范围查询，叶子通过双向循环链表连成，在链表上遍历即可
B+ 树便于插入和删除，冗余节点的存在使得不会出现复杂的树结构变化

MySQL 的不同数据存储引擎所构造的索引 B+ 树有所不同：

对于 InnoDB 引擎，每一个表会存在一棵叶子节点存储所有数据的索引树，这个树一般是主键索引构造的，但如果没有主键，那么会选择一个唯一键作为主键，如果没有唯一键，那么会生成一个 6 位的 row_id 来作为隐式主键。除了这棵树，其他索引字段所构建的索引树，叶子节点只存储主键索引和索引列的值，如果是覆盖索引则无需回表，否则需要通过主键索引再搜一遍主索引树，拿到目标数据。

对于 MyISAM 引擎，任何索引树的叶子节点都是存的数据的地址，需要根据这个地址去数据文件拿到数据，也就是都是二级索引。注意 InnoDB 的数据文件本身就是索引文件，而 MyISAM 索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。

对于树高和记录数：

在 MySQL 中 InnoDB 存储引擎的最小存储单元是页（大小默认是 16k，可通过参数设置）。页可用于存放 B+ 树叶节点数据，也可用于存放 B+ 树非叶节点的 “键+指针”。在查找数据时一次页的查找代表一次 IO，一般 B+ 树高大约为 1-3 层，所以通过主键索引查询通常只需要 1-3 次 IO 操作即可查找到数据。

索引组织表通过非叶节点的二分查找法以及指针确定数据在下一层的哪个页中，进而再去叶节点的数据页中查找到所需数据。一个非叶节点可容纳约 1170 个指针。假设一行记录数据大小为 1k，那么底层叶节点一页 16k 就能存 16 条记录。所以：

在 2 层 B+ 树中，叶节点数 * 一个叶节点能存放的记录数 = 1170 * 16 = 18720 条记录数。

在 3 层 B+ 树中，叶节点数 * 叶节点数 * 一个叶节点能存放的记录数 = 1170 * 1170 * 16 = 21902400，2190w 条记录数。

跳表

跳表时间复杂度和 B+ 树差不多，为什么一般采用 B+ 树不采用跳表？

B+ 树是多叉平衡搜索树，扇出高，只需要 3 层左右就能存放 2kw 左右的数据，同样情况下跳表则需要 24 层左右，假设层高对应磁盘 IO，那么 B+ 树的读性能会比跳表要好。

而对于 Redis，它读写全在内存里进行操作，不涉及磁盘 IO，同时跳表实现简单，相比 B+ 树、AVL 树、少了旋转树结构的开销，因此 redis 使用跳表来实现 ZSET，而不是树结构。

索引命中与否

例如有表 t(a,b,c), 建立了联合索引 (a,b)，有 sql 语句如下:

1select * from t where b = 2;

这时候是用不了联合索引 (a,b) 的，因为 (a,b) 规定 b 有序的前提是 a 有序，如果 a 不能确定，那 b 在 b+ 树里肯定是无序的，所以无法使用索引 (a,b)。

如果 sql 为：

1select * from t where a = 1 and b = 2 and c = 3;

如何建立索引?

此题正确答法是，建立联合索引 (a,b,c) 或 (c,b,a) 或者 (b,a,c) 都可以，重点要的是将区分度高的字段孜在前面，区分度低的字段放后面。

例如假设区分度由大到小为 b,a,c。那么我们就对 (b,a,c) 建立索引。在执行 sql 的时候，优化器会帮我们调整 where 后 a,b,c 的顺序，让我们用上索引。

索引失效的场景

数据库索引可能会失效（即查询无法利用索引，而是进行全表扫描 FULL TABLE SCAN），常见的失效场景包括：

使用 LIKE 模糊匹配且模式以通配符 % 开头

1SELECT * FROM users WHERE name LIKE '%abc';

% 开头会导致索引失效，因为数据库无法使用 B+ 树索引进行范围查找。
解决方案：避免 % 开头，可以使用 FULLTEXT 索引（如 MySQL 的 FULLTEXT 索引）。

计算、函数或类型转换导致索引列失效

1SELECT * FROM orders WHERE YEAR(order_date) = 2023;

YEAR(order_date) 使索引列 order_date 需要逐行计算，导致索引无法被利用。
解决方案：转换查询逻辑，避免对索引列进行计算：

1SELECT * FROM orders WHERE order_date >= '2023-01-01' AND order_date < '2024-01-01';

OR 连接多个条件，且没有合适的索引

1SELECT * FROM products WHERE category = 'A' OR price > 100;

OR 连接的字段 category 和 price 没有都建立索引，可能会导致索引失效。
解决方案：为 category 和 price 都建立索引，或使用 UNION ALL 替代 OR：

1SELECT * FROM products WHERE category = 'A'
2UNION ALL
3SELECT * FROM products WHERE price > 100;

!=、<>、NOT IN 可能导致索引失效

1SELECT * FROM employees WHERE department_id != 10;

!= 或 <> 使索引无法高效过滤数据，数据库通常会进行全表扫描。
解决方案：使用 BETWEEN 或 IN 进行改写：

1SELECT * FROM employees WHERE department_id > 10 OR department_id < 10;

IS NULL 或 IS NOT NULL

1SELECT * FROM users WHERE last_login IS NULL;

B+ 树索引通常不会索引 NULL 值，导致索引失效。
解决方案：
- 在 last_login 列上创建索引时，指定 NOT NULL。
- 使用默认值（如 1970-01-01）代替 NULL 并查询时改写：

1SELECT * FROM users WHERE last_login = '1970-01-01';

ORDER BY 与索引顺序不匹配

1SELECT * FROM orders ORDER BY user_id DESC;

如果索引 user_id 是升序（ASC），但查询要求降序（DESC），可能导致索引失效。
解决方案：如果 ORDER BY 频繁使用 DESC，可以创建降序索引：

CREATE INDEX idx_user_id_desc ON orders(user_id DESC);

过度使用索引导致优化器选择全表扫描

索引在低基数（重复值多）字段上，如 status 只有 0 和 1 两种值：

1SELECT * FROM users WHERE status = 1;

由于 status 只有两个值，索引效果不明显，优化器可能选择全表扫描。
解决方案：索引适用于高基数字段，低基数字段可以通过联合索引优化。

分库分表

拆分方法：

水平拆分：把一个表的数据给分到多个库的多个表里去，但是每个库的表结构都一样
垂直拆分：把一个有很多字段的表给拆分成多个表，或者是多个库上去

迁移为分库分表方法：

双写迁移：增删改操作同时作用在新库老库上
停机迁移

Reference

Shell 重要用法整理

akynazh@gmail.com (zhihang) — Fri, 03 Feb 2023 22:44:10 +0800

shell 参数

$# 参数个数
$@ / $* 取出所有参数
$0 取出命令中第一个字符串
$1 取出第一个参数

1if [ "$1" == "-u" ]
2then
3    echo update
4fi
5echo $0

ans:

1[root => ~]$ ./test.sh
2./test.sh
3[root => ~]$ ./test.sh -u
4update
5./test.sh

$@ 与 $* 的区别：（from stackoverflow）

$@ behaves like $* except that when quoted the arguments are broken up properly if there are spaces in them.

Take this script for example (taken from the linked answer):

1for var in "$@"
2do
3    echo "$var"
4done

Gives this:

1$ sh test.sh 1 2 '3 4'
21
32
43 4

Now change $@ to $*, And you get this:

1$ sh test.sh 1 2 '3 4'
21
32
43
54

个人觉得使用 $@ 更为妥当。

关于数组

取值

根据下标取值，下标从 0 开始：

1${arr[0]}
2${arr[1]}
3${arr[2]}

获取所有值：

1${arr[@]}
2
3# 常用于：
4/bin/bash test.sh ${arr[@]}

获取长度：

1${#args[@]}
2
3if [ ${#args[@]} -eq 0 ]; then
4	echo "length=0"
5fi

切片

数组切片：

1# 从 $start 开始到 $end
2arr=( $(arr[@]:$start:$end) )
3
4# 从 $start 开始到最后，两侧必须加括号
5arr=( $(arr[@]:$start) )

一个简单的测试：

 1root@Server-Debian-Jzh:~# arr=(1, 2, 3, 4, 5)
 2root@Server-Debian-Jzh:~# echo ${arr[@]}
 31, 2, 3, 4, 5
 4root@Server-Debian-Jzh:~# echo ${arr[@]:1}
 52, 3, 4, 5
 6root@Server-Debian-Jzh:~# s=1;e=2
 7root@Server-Debian-Jzh:~# echo ${arr[@]:$s:$e}
 82, 3,
 9
10# 切片后不加括号的后果：
11root@Server-Debian-Jzh:~# tarr=${arr[@]:$s:$e}
12root@Server-Debian-Jzh:~# echo ${tarr[0]}
132, 3,

$@ 和数组

$@ 不是真正的数组，如需使用上述取值和切片特性，需将其转换为数组：

1args=( $@ ) # convert to array

$@ 可以直接嵌入命令中而数组不可以：

1/bin/bash t.sh $val1 $@

关于 $@ 的数据结构，这是一段 chatgpt 的回答，挺不错的：

……

Q: but what i want to know is the data structure of $@

A: As I mentioned earlier, $@ is a special shell parameter in Bash that holds the positional parameters passed to the script or function. It is not technically an array in Bash, although it behaves like one in many ways.

Under the hood, $@ is actually a space-separated list of strings, with each string representing an individual positional parameter. When the shell expands $@, it splits this list into separate words, treating each space as a delimiter.

So you can think of the data structure of $@ as a simple list or sequence of strings, where each string represents an argument passed to the script or function. While it doesn’t have all the advanced functionality of a true array, such as indexed access and manipulation, it is still a very useful and versatile tool in Bash scripting.

算术运算

1[root@VM-0-11-centos ~]# a=1
2[root@VM-0-11-centos ~]# b=$((a*12))
3[root@VM-0-11-centos ~]# echo $b
412

比较运算

指令：-eq -ne -lt -gt -ge -le

注：字符串比较直接用 “==” 而不是上述指令。

1[root@VM-0-11-centos ~]# a=10
2[root@VM-0-11-centos ~]# [ $a -eq 10 ] && echo yes
3yes
4[root@VM-0-11-centos ~]# [ $a -ge 11 ] && echo yes || echo no
5no

指令：-a -o

1[root@VM-0-11-centos ~]# a=10;b=12;
2[root@VM-0-11-centos ~]# [ $a -lt 11 -a $b -lt 13 ] && echo yes || echo no
3yes
4[root@VM-0-11-centos ~]# [ $a -lt 11 -a $b -lt 11 ] && echo yes || echo no
5no

字符串运算

-z（即 zero）检测字符串长度是否为 0，为 0 返回 true。
str 检测字符串是否为空，不为空返回 true。

1[root@VM-0-11-centos ~]# [ -z "jzh" ] && echo yes || echo no
2no
3[root@VM-0-11-centos ~]# [ "jzh" == "zh" ] && echo yes || echo no
4no

字符串的引号使用

双引号与单引号效果不一样，如下：

1root@ubuntu2004:~# echo "$PATH"
2/usr/local/java/jdk1.8.0_311/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:...
3root@ubuntu2004:~# echo '$PATH'
4$PATH

获取时间

1# 输出格式化时间
2[root@VM-0-11-centos ~]# date '+%Y-%m-%d %H:%M:%S'
32022-04-10 13:22:04
4# 输出当前时间戳
5[root@VM-0-11-centos ~]# date +%s
61649568128

条件判断

注：中括号两端要有空白符。

1[root@VM-0-11-centos tmp]# [ "a" == "b" ] && echo hello || echo bye
2bye
3[root@VM-0-11-centos tmp]# [ "a" == "a" ] && echo hello || echo bye
4hello

文件运算

-r 即 read
-w 即 write
-x 即 exec
-s 即文件不为空
-e 即 exist

1[root@VM-0-11-centos ~]# touch t.sh
2[root@VM-0-11-centos ~]# [ -s ./t.sh ] && echo yes || echo no
3no
4[root@VM-0-11-centos ~]# [ -e ./t.sh ] && echo yes || echo no
5yes

读取输入

read -p “prompt words” var_name

1[root@VM-0-11-centos ~]# read -p "age:" age
2age:12
3[root@VM-0-11-centos ~]# echo $age
412

read -a variable_name （读取数组）

1[root@VM-0-11-centos tmp]# read -a arr
21 2 3 4 5
3[root@VM-0-11-centos tmp]# echo ${arr[4]}
45

条件判断语句

if else

1if [  ] || [  ]; then
2	do_something
3elif [  ] && [  ]; then
4	do_something
5else
6	do_something
7fi

case

 1case ${var} in
 2"condition1")
 3do_something
 4;;
 5"condition2")
 6do_something
 7;;
 8*) #anything
 9do_something
10;;
11esac

循环语句

while

1while [ condition ]
2do
3	do_something
4done

when meet the condition, start the loop.

until

1until [ condition ]
2do
3	do_something
4done

when meet the condition, end the loop.

for

遍历数组：

1for $var in ${array}
2do
3	do_something
4done

遍历指定数字序列：

1for $var in {1..100}
2do
3	do_something
4done

条件遍历：

1for ( (i=1; i<=${var}; i++) )
2do
3	do_something
4done

sh 命令

-n 不执行，只检查语法 not execute but check
-v 执行前输出脚本内容 view the script
-x 将使用到脚本内容输出

Hugo 实现深浅主题的切换

akynazh@gmail.com (zhihang) — Thu, 02 Feb 2023 18:49:54 +0800

前言

实现深浅主题切换的方法不只一种，这里记录我所使用的一种。

生成深浅主题对应的 css 文件

配置入口文件

我的博客通过 sass 构建样式，可以将写好的 scss 文件组合生成一个 css 文件。

而组合成为 css 文件需要一个入口文件，在入口文件里指定主题。

比如我在 assets/scss/colors 中指定了两种色调 dark.scss 和 light.scss, 那么可以在对应的入口文件中 import:

1// assets/scss/styles_dark.scss
2@import "colors/dark";
3
4@import "variables";
5@import "util";
6@import "mixins";
7// ...

1// assets/scss/styles_light.scss
2@import "colors/light";
3
4@import "variables";
5@import "util";
6@import "mixins";
7// ...

这样，就有了 styles_dark.scss 和 styles_light.scss 这两个入口文件。

通过 hugo 生成目标文件

接着，在 <head></head> 中指定入口文件进行操作：

1<!-- head.html -->
2{{ $opts := (dict "targetPath" "css/styles_dark.css" "outputStyle" "compressed") }}
3{{ $styles_dark := resources.Get "scss/styles_dark.scss" | resources.ExecuteAsTemplate "scss/styles_dark.scss" . | resources.ToCSS $opts }}
4
5{{ $opts := (dict "targetPath" "css/styles_light.css" "outputStyle" "compressed") }}
6{{ $styles_light := resources.Get "scss/styles_light.scss" | resources.ExecuteAsTemplate "scss/styles_light.scss" . | resources.ToCSS $opts }}

这里通过 hugo 操作之后，即可生成深浅主题对应的两个 css 文件，位置在 css 目录下。

接着，将地址赋值到 $dark 和 $light 中：

1<!-- head.html -->
2{{ $dark := $styles_dark.Permalink }}
3{{ $light := $styles_light.Permalink }}

保存地址变量到隐藏域

接着，通过隐藏域保存这两个地址以便后续使用：

1<!-- head.html -->
2<input value="{{ $dark }}" id="styles-dark" style="display: none;" />
3<input value="{{ $light }}" id="styles-light" style="display: none;" />

设定初始主题

一开始的主题应由网站发布者指定，读取 config 文件中的变量即可：

1<!-- head.html -->
2{{ if eq .Site.Params.colortheme "dark" }}
3<input value="dark" id="theme-current" style="display: none;" />
4<link id="theme-css" rel="stylesheet" href="{{ $dark }}" />
5{{ else if eq .Site.Params.colortheme "light" }}
6<input value="light" id="theme-current" style="display: none;" />
7<link id="theme-css" rel="stylesheet" href="{{ $light }}" />
8{{ end }}

这里又配置了一个隐藏域，用于后续确认和修改主题。

通过 js 动态设置主题

加载主题

加载步骤如下：

读取用户 localStorage 中保存的主题变量；
读取当前主题隐藏域值；
读取 css 文件地址隐藏域值；
修改主题 css 标签中的地址以加载主题。

其中，用户 localStorage 中保存的主题变量是在用户首次切换主题之后生成的，在下一步中进行介绍。

 1// theme.js
 2function setTheme(theme) {
 3  let stylesDark = document.getElementById("styles-dark").value;
 4  let stylesLight = document.getElementById("styles-light").value;
 5  let themeCss = document.getElementById("theme-css");
 6  let setThemeStyle = theme === "dark" ? stylesDark : stylesLight;
 7  themeCss.setAttribute("href", setThemeStyle);
 8}
 9
10function getCurrentTheme() {
11  // user theme
12  let userTheme = localStorage.getItem("userTheme");
13  let userThemeExpire = localStorage.getItem("userThemeExpire");
14  if (
15    userTheme !== null &&
16    userTheme != "" &&
17    userThemeExpire !== null &&
18    userThemeExpire > new Date().getTime()
19  ) {
20    document.getElementById("theme-current").setAttribute("value", userTheme);
21  }
22  return document.getElementById("theme-current").value;
23}
24
25setTheme(getCurrentTheme());

修改主题

每次修改主题都需要修改当前主题隐藏域中的值，并且在用户 localStorage 中存储或修改用户选择的主题，而设置超时时间则是一个可选项：

1// theme.js
2function changeTheme(theme) {
3  setTheme(theme);
4  document.getElementById("theme-current").setAttribute("value", theme);
5  localStorage.setItem("userTheme", theme);
6  // 设置超时时间： 24 小时
7  let expire = new Date().getTime() + 1000 * 3600 * 24;
8  localStorage.setItem("userThemeExpire", expire);
9}

将脚本放在合适的位置

theme.js 脚本需要在脚本所用到的元素加载完毕后，才能正确执行，否则将导致主题修改失败。

由于浏览器加载页面是从上到下按顺序执行的，所以只要不将脚本放在任一依赖项的上方即可让脚本顺利执行。

绑定事件到按钮

脚本编写完毕后，则将其绑定到某个按钮上即可，示例如下：

定义一个按钮：

1<a class="icon" id="theme-change"><i class="fas fa-adjust"></i></a>

绑定事件：

 1// main.js
 2// button: change theme
 3$("#theme-change").click(function () {
 4  let newTheme;
 5  if (getCurrentTheme() === "light") {
 6    newTheme = "dark";
 7  } else {
 8    newTheme = "light";
 9  }
10  changeTheme(newTheme);
11});

抚摸主页上的猫猫，美妙的事情会发生哦~

Apple 产品和服务使用记录

akynazh@gmail.com (zhihang) — Sun, 08 Jan 2023 18:51:27 +0800

前言

Welcome to the world of Apple. If you’re also a fan of Apple, we might just become friends.

Apple 服务

Apple 帐号问题

Apple 分为两个帐号，iCloud 帐号和 AppStore 帐号，一般建议 iCloud 帐号使用国区，AppStore 帐号使用美区帐号，搭配使用 Apple One 服务。美区 Apple Music 曲库最全，AppStore 软件最全，Apple Fitness 很有用，Apple Arcade 的游戏也挺丰富的。

对于帐号具体功能，iCloud 帐号用于同步相簿、联系人、备忘录、日历等存放在 iCloud 的信息。AppStore 帐号和软件购买、Apple Music、Apple TV、Apple Books 相关。

这里注意，所有自己上传的文件，都属于 iCloud 内容，比如 Apple Music 自己上传的音乐，但是 Apple Music 收藏的音乐则属于 AppStore 帐号，同步随 AppStore 帐号。注意切换 AppStore 帐号会导致下载的 Apple Music 下载的音乐被删除，但是播放列表、播放历史不回被删除，而是正常的云同步状态。

Apple 服务与代理分流问题

有些代理软件的分流操作会错误将 Apple 服务加入代理。下面从一个论坛上的关于 Apple Map 的例子引入：

解决 China IP List 分流导致 iPad 和 Mac 的 Maps App 提供商为 TomTom 的问题

如果你和我一样在使用透明代理和 China IP List 的组合，iPad 和 Mac 上的 Maps App 会使用 TomTom 作为地图提供商，而在不使用代理的设备上应该是高德地图。

由于 Mac 和 iPad 是根据 IP 地址判断地区的，而判断的域名只有国外的解析，所以如果单纯使用 China IP List 会导致判断为国外用户。

如果你是 Surge 用户，请将 *.ls.apple.com 加上 DIRECT 的规则。
如果是透明代理和 China IP List 的组合，无法对域名进行单独处理，可以添加一段 host，将请求转发到国内的 SNI Proxy 处理。具体的域名是 gsp[0-64]-ssl.ls.apple.com 和 gspe[0-64]-ssl.ls.apple.com。

所以，从这个 Apple Map 的例子可以知道 *.ls.apple.com 应该直连。下面是一个 Qx 的配置：

1[filter_local]
2host-wildcard, *.ls.apple.com, direct

另外，测试发现其实 iPhone 并不需要这个配置，这里判断 iPhone 应该是根据 SIM 卡判断地区。

Apple Map 没有同步指南等信息

Mac 上设置 - icloud，关闭 Apple Map 同步，退出后重新打开 Apple Map，然后打开 Apple Map 同步。

Apple Music 自动取消收藏专辑

目前的解决方法是首先收藏专辑中喜欢的歌曲，然后收藏专辑，之后不再变更专辑中的歌曲收藏情况。

Apple Music 专辑重复问题

当不同设备使用不同语言时，专辑呈现的语言不同导致的，所有设备使用同一语言可以解决。

Apple 官方节假日日历地址

Apple 日历可以订阅 ics 日历：

 1# 大陆节日
 2webcal://p10-calendars.icloud.com/holiday/CN_zh.ics
 3# 台湾节日
 4webcal://p10-calendars.icloud.com/holiday/TW_zh.ics
 5# 香港节日
 6webcal://p10-calendars.icloud.com/holiday/HK_zh.ics
 7# 美国节假
 8webcal://p10-calendars.icloud.com/holiday/US_en.ics
 9# 日本节假
10webcal://p10-calendars.icloud.com/holiday/JP_ja.ics
11# 澳大利亚
12webcal://p10-calendars.icloud.com/holiday/AU_en.ics
13# 法国节假
14webcal://p10-calendars.icloud.com/holiday/FR_fr.ics
15# 德国节假
16webcal://p10-calendars.icloud.com/holiday/DE_de.ics
17# 英国节假
18webcal://p10-calendars.icloud.com/holiday/GB_en.ics

Apple Fitness 手动更新活动圆环

在 Apple Health > Workouts > Add Data 处手动添加 Workout 即可。实测支持更新当天和过去的圆环，如果有时候忘记戴 Apple Watch 或者忘记记录，可以通过此方式 Close Ring。

Airpods 相关

不充电问题

可参考：关于AirPods的一些问题，你们有遇到过放在耳机盒子里面，一个耳机没有充上电的状态么？

我是 Airpods 的左耳机充不上电了，用牙线棒轻戳了一下左耳机仓的金属片，就成功解决了。

功能特性

AirPods Max 2 (2024) 相比于 2020 年的第一代差异只在于换了一个 TypeC 口，没有任何音质、ANC 主动降噪功能上的升级，仍搭载 H1 芯片。

AirPods3 并不支持主动降噪，AirPods4 普通版也不支持，AirPods4 ANC 版支持。

Apple Watch 相关

蜂窝网络

如果需要脱离 iPhone 使用，只需要在 Apple Watch 应用内开通蜂窝网络（注意 Watch 需要时蜂窝版），移动是每月多交 10 元，和话费一起交，流量也是一起算的。

蜂窝网络的意义在于：

救急，iPhone 没电了，无法坐地铁，看地图
运动时无需携带 iPhone，无需担心错过电话和消息

公交地铁卡相关

同一张 NFC 卡无法同时绑定在 iPhone 和 Watch。我的操作是 iPhone 一个城市的卡，Watch 另一个城市的卡，国内各个城市的卡其实都是通用的。

iPhone 相关

Wallet

香港八达通

Wallet 开通的八达通和实体卡八达通完全一样，测试在香港可以坐地铁、购物。

日本 Suica

Wallet 开通的 Suica 和实体卡 Suica 完全一样，测试在东京可以坐地铁、购物。

门禁卡

目前 iPhone 无法复制任何形式的门禁卡，受限于 Apple 自身的安全政策。而支持 NFC 的安卓机型可以复制门禁卡，但部分加密门卡可能无法成功刷卡。

机型重大变化

15 开始支持 TypeC
14p 开始支持灵动岛
13，14 刘海较 12 窄一截
16 多了一个快捷拍照按钮
16 标准版仍为 60HZ
16p 是钛合金
13p 开始有 120HZ
15p 静音键更新
17 改回铝合金
17 也有快捷拍照按钮了
17p 采用横向长方形相机模组

iPad 相关

我的 iPad 只用来看书和论文，基本没有遇到什么问题。

Mac 系统遇到的问题

desktop 文件夹里有东西，但是桌面不显示，而且无法拖动任何文件到桌面

原因是一些破解软件修改了系统配置造成的。

1defaults write com.apple.finder CreateDesktop -bool true; killall Finder

阻止 Anydesk 开机自启

删除该文件:

1/Library/LaunchAgents/com.philandro.anydesk.Frontend.plist

Mac 系统重要操作和配置记录

阻止睡眠

1caffeinate

终端运行，ctrl-c 即取消，仅开盖锁屏时可用。

回退系统

从 Ventura 升级到 Sonoma 后发现有些问题，部分重要功能有小 bug，所以决定回退到 Ventura，记录下流程和恢复后遇到的问题，方便后续参考。

制作启动盘

首先在 store 搜索 MacOS Ventura，点击下载即可。

接着插入外接盘，我用的是一个容量为 32 G 的小 U 盘，其实大概 15 G 即可。

接着打开磁盘工具, 选择该 U 盘，抹掉它(选择目标文件系统为 MacOS 扩展), 命名为 T(也可以是其他，下面用得到)。

接着打开控制台，执行命令如下：

1sudo /Applications/Install\ macOS\ Ventura.app/Contents/Resources/createinstallmedia --volume /Volumes/T

其中 “/Applications/Install\ macOS\ Ventura.app” 即为从 store 下载好的 Ventura，通过 createinstallmedia 命令即可制作启动盘，通过 –volume 参数指定启动盘位置为 /Volumes 下的 “T”。

然后等待启动盘制作完成即可。

备份系统数据

这里我使用了时间机器备份数据，比较方便且安全。

备份数据也需要一个数据盘，大小的话，据官方文档建议的话是要略大于当前 mac 系统大小。

我使用的是西数的 1T SSD，由于我系统大小 256G，因此划分了一个大概 300 G 的分区给它，接着，将其抹掉，格式化为 APFS 文件系统。

然后在时间机器界面点击选择备份盘，然后就可以开始备份了，确认备份完成了，继续执行下面的操作。

从启动盘安装 Ventura

关机，长按开机键即可进入恢复模式（m1 系统是这样，其他系统可能有差异）。

接着打开磁盘工具，抹去原系统（这里如果不放心，建议用另外一块盘安装恢复试试看先）。

然后退出磁盘工具，点击制作好的启动盘，根据提示进行安装即可。

恢复系统数据

安装完成后，点击完成一系列的初始化操作后，将会出现迁移助手，恢复数据选项选择时间机器，选择之前的备份进行恢复即可。

我这里大概 200 G 数据，花了不到 1 小时就完成了。

迁移后遇到的问题

从高版本系统退回低版本系统后，多少会出现一些问题，这里持续记录下。

部分软件崩溃: runtime library is newer than runtime

LogiHub 和 maven 出现了类似问题：

1$ /usr/local/maven/3.6.3/bin/mvn    
2assertion failed [header->version <= kProjectSourceVersion]: runtime library is newer than runtime
3(Library.cpp:99 init)
4 [1]    5714 abort      /usr/local/maven/3.6.3/bin/mvn

google 一番后大概查出问题：

The app crashing problem appears to happen only when attempting to open apps that use Rosetta, the translator that allows Intel apps to run on Apple Silicon architecture.

大概就是因为 Rosetta 这个 translator 的问题，估计不同版本有差异，总之，实测重新安装 Rosetta 即可：

1/usr/sbin/softwareupdate --install-rosetta --agree-to-license

Apple Music 导入专辑

Import the folder, sort the songs by date added, select the latest songs, edit the Album field in the properties.

另外建议可以勾选 compliation。

Apple Map 修改语言

系统语言为英文时修改内置地图软件语言为中文。

先将 [View]-> [Labels]-> [Always Show Labels in English] 取消即可在地图上显示中文。

如果需要将搜索内容也改成中文，需要设置 macOS 特定 app 的语言。

1defaults write com.apple.maps AppleLanguages '(zh-CN)'
2# defaults write com.apple.maps AppleLanguages '(en-US)'

可以将菜单栏，搜索内容变为中文。（想变回英文只需将最后改成’(“en-US”)’）

Apple Book 将导出的 epub 文件夹转为 epub 文件

注：导出方法是拖动 Book 到 Finder。

Right click on the .epub file and click on Show Package Contents.

Select all the contents (CMD + A) → Right click → Compress.

This will create a .zip file. Simply change the extension from .zip to .epub and voila! The file has become an ePub document.

1ap_book_to_epub() {
2    filename=$(basename -- "$*")
3    filename="${filename%.*}"
4    cd $*
5    zip -r "$filename.zip" *
6    mv "$filename.zip" "/Users/zh/Library/Mobile Documents/com~apple~CloudDocs/Books/$filename.epub"
7    echo "Move $filename.epub to icloud > Books"
8}

MAC 禁用系统输入法

sudo open ~/Library/Preferences/com.apple.HIToolbox.plist

AppleEnabledInputSources -> remove {KeyboardLayout=ABC} -> save

访达 -> 进入文件夹 ~/Library/Preferences/com.apple.HIToolbox.plist -> 右键显示简介 -> 已锁定 v

PS: 在 Ventura 版本下成功

MAC Ventura 真正进入 Recovery

进入恢复模式操作步骤为：1.长按电源键 2.长按直到启动选项出现 3.正在载入启动选项 4.选项界面

而如果在【3.正在载入启动选项】页面时就松开电源键了，在选项界面后续操作中，虽然是在恢复模式的界面，但是系统却认为不是在恢复模式。

解决方式：

长按电源键直到【4.选项界面】出现后再松手即可！

文件夹默认显示隐藏文件

1defaults write com.apple.finder AppleShowAllFiles -bool true
2killall Finder

配置开机启动程序

1chmod +x startup.sh
2# 访达右键 startup.sh > 显示详情 > 打开方式选终端
3# 设置 > 通用 > 登录项添加 startup.sh

禁止系统更新和提示

1# /etc/hosts
2
3127.0.0.1 swdist.apple.com
4127.0.0.1 swscan.apple.com
5127.0.0.1 swcdn.apple.com  #optional, download url
6127.0.0.1 gdmf.apple.com
7127.0.0.1 mesu.apple.com
8127.0.0.1 xp.apple.com

1alias fkred="defaults delete com.apple.systempreferences AttentionPrefBundleIDs; defaults delete com.apple.systempreferences DidShowPrefBundleIDs; killall Dock"
2fkred

Hostname

1sudo scutil --set HostName MacBookPro-Jzh
2scutil --get HostName
3
4# setting -> general -> sharing -> Local hostname
5sudo scutil --set LocalHostName MacBookPro-Jzh
6scutil --get LocalHostName

SMB 共享

mac 通用 -> 共享 -> 文件共享开启 -> 指定共享文件夹和权限控制(可选)

iphone 文件 -> 连接服务器 -> 输入 Mac-Jzh.local(本机名称 + .local) -> 输入 Mac 账号密码(或以客人模式登录)

将快速操作和快捷指令添加到右键

Automator 创建快速操作（注意输入类型和适用 APP），然后设置 -> 键盘 -> 键盘快捷键 -> 服务 -> 勾选

快捷指令详细信息勾选快速操作, 编辑快捷指令，然后设置 -> 隐私与安全性 -> 扩展 -> 访达 -> 勾选

Steam 下载 Windows 游戏文件

Navigate to /Users/YOUR_USERNAME_HERE/Library/Application Support/Steam/steamapps/. Create a file called appmanifest_22320.acf (the number is based on its Steam App ID). If using TextEdit, make sure that your document is in plain text mode by going to the menu bar and choosing “Format” -> “Make Plain Text”. Also, ensure that it’s not named with the extension .acf.txt. Add the following into that file:

1"AppState"
2{
3        "AppID" "22320"
4        "Universe" "1"
5        "StateFlags" "1026"
6        "installdir" "The Elder Scrolls III - Morrowind"
7}

Launch the Steam client and let it download. You can then find Morrowind.esm at ~/Library/Application Support/Steam/steamapps/common/The Elder Scrolls III - Morrowind/Data Files/

SRC

Mac 重要软件

yutto (bilibili downloader)

 1brew tap siguremo/tap
 2brew install yutto
 3# -c 指定 cookie:sessdata
 4
 5# 下载番剧
 6yutto -c "xxx" \
 7--danmaku-display-region-ratio 0.25 \
 8--danmaku-font-size 28 \
 9-b -p 201~400 \
10https://www.bilibili.com/bangumi/play/ep109726
11
12# 下载合集
13yutto -c "xxx" \
14--no-subtitle \
15--danmaku-display-region-ratio 0.25 \
16--danmaku-font-size 28 \
17-b \
18https://space.bilibili.com/13199099/lists/700383?type=season

XML 弹幕样式

 1pip install biliass
 2
 3# one
 4biliass "xxx.xml" -s 1920x1080 -o "xxx.ass" --display-region-ratio 0.25 -dm 10 -a 0.75 -fn "黑体"
 5# batch
 6find "." -type f -name "*.xml" | while read -r xml_file; do
 7    ass_file="${xml_file%.xml}.ass"
 8    biliass "$xml_file" \
 9        -s 1920x1080 \
10        -o "$ass_file" \
11        --display-region-ratio 0.25 \
12        -dm 10 \
13        -a 0.75 \
14        -fn "黑体"
15    echo "✅ Done: $xml_file -> $ass_file"
16done
17
18# 删除弹幕：
19# batch delete .ass files
20find . -type f -name "*.ass" -delete

yt-dlp

1brew install yt-dlp
2# yt-dlp "https://youtu.be/15ezpwCHtJs\?si\=95fukd8TRH3ZtbnA" -x --audio-quality 0 --audio-format alac

图片转换工具

1brew install imagemagick
2brew install ghostscript
3
4magick image.jpg image.png

REST 测试插件

vsc: rest client
idea: http client

环境变量分别写在:

.vscode/settings.json
.http 同一目录下

http 文件内字符串变量统一不加引号

textutil

用于转换 webarchive 为文件夹，好像是内置的。

1textutil -convert html /Users/USERNAME/NAME.webarchive

dart

1brew tap dart-lang/dart
2brew install dart

Jenkins

1wget http://mirrors.jenkins.io/war-stable/latest/jenkins.war
2java -jar jenkins.war --httpPort=8080
3open http://localhost:8080 # and then set up in browser

RocketMQ

1wget https://dist.apache.org/repos/dist/release/rocketmq/5.1.4/rocketmq-all-5.1.4-bin-release.zip
2unzip rocketmq-all-5.1.4-bin-release.zip
3sudo mkdir -p /usr/local/share/rocketmq && sudo mv rocketmq-all-5.1.4-bin-release /usr/local/share/rocketmq/
4
5# start
6cd /usr/local/share/rocketmq/rocketmq-all-5.1.4-bin-release/bin

alist

 1cd $dld
 2wget https://github.com/alist-org/alist/releases/download/v3.30.0/alist-darwin-arm64.tar.gz
 3tar -zxvf alist-darwin-arm64.tar.gz
 4chmod +x alist
 5sudo mv alist /Applications/Bin/alist
 6echo 'export PATH="$PATH:/Applications/Bin"' >> ~/.zprofile
 7source ~/.zprofile
 8
 9data_dir="/Users/zh/.alist"
10# mkdir data folder
11mkdir "$data_dir"
12# start server
13cd "$data_dir" && alist server
14# get admin info
15cd "$data_dir" && alist admin
16# add some storages
17# ...

后台服务，开机自启，vim ~/Library/LaunchAgents/ci.nn.alist.plist:

 1<?xml version="1.0" encoding="UTF-8"?>
 2<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 3<plist version="1.0">
 4    <dict>
 5        <key>Label</key>
 6        <string>ci.nn.alist</string>
 7        <key>KeepAlive</key>
 8        <true/>
 9        <key>ProcessType</key>
10        <string>Background</string>
11        <key>RunAtLoad</key>
12        <true/>
13        <key>WorkingDirectory</key>
14        <string>/Users/zh/.alist</string>
15        <key>ProgramArguments</key>
16        <array>
17            <string>/Applications/Bin/alist</string>
18            <string>server</string>
19        </array>
20    </dict>
21</plist>

1launchctl load ~/Library/LaunchAgents/ci.nn.alist.plist
2# 开启: launchctl start ~/Library/LaunchAgents/ci.nn.alist.plist
3# 关闭: launchctl stop ~/Library/LaunchAgents/ci.nn.alist.plist
4# 卸载配置: launchctl unload ~/Library/LaunchAgents/ci.nn.alist.plist

Applite

一个方便地卸载、安装、更新 Mac 各类软件（含 brew 源）的工具。

1brew install --cask applite

graphviz

1brew install libtool
2brew link libtool
3brew install graphviz
4brew link --overwrite graphviz

By default, the dot executable is expected:

Firstly in: /usr/local/bin/dot
Then in: /usr/bin/dot

You can also specify the environment variable GRAPHVIZ_DOT to set the exact location of your GraphViz executable.

ffmpeg

1brew install ffmpeg

Pngpaste

1brew install pngpaste

ftp

1brew install inetutils

Vsce

Vscode 扩展开发工具，用于打包和发布等。

1npm install -g vsce
2# usage
3vsce package

MySQL

 1brew search mysql     
 2# ==> Formulae
 3# automysqlbackup       mysql-client          mysql-client@8.4      mysql@5.7             mysqltuner
 4# mysql                 mysql-client@5.7      mysql-connector-c++   mysql@8.0             qt-mysql
 5# mysql++               mysql-client@8.0      mysql-search-replace  mysql@8.4
 6
 7# ==> Casks
 8# mysql-connector-python              mysqlworkbench                      sqlpro-for-mysql
 9# mysql-shell                         navicat-for-mysql
10
11brew install mysql@8.4
12brew services start mysql@8.4
13echo 'export PATH="/opt/homebrew/opt/mysql@8.4/bin:$PATH"' >> ~/.zprofile && source ~/.zprofile
14mysql_secure_installation
15mysql -u root -p

Github CLI

1brew install gh

Hugo

1brew install hugo

SteamCMD

1cd /usr/local/share
2curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_osx.tar.gz" | tar zxvf -
3./steamcmd
4login {username} {password}
5
6# 下载创意工坊物品
7workshop_download_item {game-id} {id}
8# Wallpaper Engine
9workshop_download_item 431960 {id}

InfluxDb

1brew install influxdb influxdb-cli
2# start influxdb
3influxdb
4# setup a bucket
5influx setup
6# currently v2, use v1 shell by:
7influx v1 shell

解压缩工具

p7zip

1brew install p7zip
27za x test.7z
3
4# 分卷解压【其他格式类似】
5cat t1.7z > t.7z
6cat t1.7z.001 >> t.7z
7cat t1.7z.002 >> t.7z
87za x t.7z

unzip

1brew install unzip
2unzip test.zip

rar

1brew install rar
2unrar x test.rar

tar

1tar -zxf test.tar.gz

python(多版本)

 1brew update
 2brew install pyenv
 3
 4# add to .zprofile
 5export PYENV_ROOT="$HOME/.pyenv"
 6[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
 7eval "$(pyenv init - zsh)"
 8
 9v="3.10.9"
10pyenv install $v
11pyenv versions
12pyenv global $v
13
14python -V
15pip -V
16
17# 针对某个项目指定 python 版本
18v="3.9.13"
19pyenv install $v
20cd your_project
21~/.pyenv/versions/$v/bin/python -m venv venv
22source ./venv/bin/activate

bat

加强版 cat。

1brew install bat

ripgrep

加强版 grep。

1brew install ripgrep

fzf

命令行模糊搜索工具。

1brew install fzf

rclone mount

首先安装 macfuse

文档需知: “rclone will locate the macFUSE libraries without any further intervention”

接着:

1# 后台运行时不可使用 kill 操作，需要使用 umount ~/Pikpak 操作
2nnohup rclone mount --vfs-cache-mode writes pikpak: ~/Pikpak

pikpakcli

1wget https://github.com/52funny/pikpakcli/releases/download/v0.15/pikpakcli_0.15_Darwin_arm64.tar.gz
2tar -zxvf pikpakcli_0.15_Darwin_arm64.tar.gz
3mv ./pikpakcli /usr/local/bin/
4pikpakcli -h
5mkdir -p ~/.config/pikpakcli
6echo "username:" >> ~/.config/pikpakcli/config.yml
7echo "password:" >> ~/.config/pikpakcli/config.yml
8vim ~/.config/pikpakcli/config.yml

hiddenbar

1brew install --cask hiddenbar

node

同 linux, 详见 Linux 重要软件安装和配置记录。

maven

若需要特定版本，操作方法同 linux, 详见 Linux 重要软件安装和配置记录。

否则可直接通过 brew：

1brew install maven

brew

1/bin/zsh -c "$(curl -fsSL https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh)"

1# use mirror
2# disable proxy first
3export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles

docker

1brew install --cask docker
2open /Applications/Docker.app

syncthing

1brew install syncthing
2brew services start syncthing

redis

1brew install redis
2brew services start redis
3redis-cli
4
5vim /opt/homebrew/etc/redis.conf
6requirepass xxx
7brew services restart redis

man zh page

1wget https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/manpages-zh/manpages-zh-1.5.1.tar.gz --no-check-certificate
2tar -zxvf manpages-zh-1.5.1.tar.gz
3cd manpages-zh-1.5.1 
4./configure --disable-zhtw
5sudo make && sudo make install
6man -M /usr/local/share/man/zh_CN grep
7alias mann="man -M /usr/local/share/man/zh_CN"

postgresql

1brew install postgresql@15
2brew services start postgresql@15
3## vim ~/.zprofile
4export PATH="/opt/homebrew/opt/postgresql@15/bin:$PATH"
5export LDFLAGS="-L/opt/homebrew/opt/postgresql@15/lib"
6export CPPFLAGS="-I/opt/homebrew/opt/postgresql@15/include"
7psql postgres

jq

1brew install jq

lux

一个视频下载器

1brew install lux

汇编语言重要知识整理

akynazh@gmail.com (zhihang) — Tue, 04 Oct 2022 23:18:24 +0800

8086 PC 机内存地址空间分配

00000~9FFFF: 主存储器地址空间（RAM）
A0000~BFFFF: 显存地址空间
C0000~FFFFF: 各类ROM地址空间

段寄存器

8086CPU 不支持将数据直接送入段寄存器的操作，ds 是一个段寄存器，所以 mov ds，1000H 这条指令是非法的。

要将 1000H 送入 ds，只好用一个寄存器来进行中转，即先将 1000H 送入一个一般的寄存器，如 bx，再将 bx 中的内容送入 ds。

关于 SS，SP

8086CPU 中，有两个寄存器，段寄存器 SS 和寄存器 SP，栈顶的段地址存放在 SS 中，偏移地址存放在 SP 中。

任意时刻，SS:SP 指向栈顶元素。push 指令和 pop 指令执行时，CPU 从 SS 和 SP 中得到栈顶的地址。

伪指令

在汇编语言源程序中，包含两种指令，一种是汇编指令，一种是伪指令。

汇编指令是有对应的机器码的指令，可以被编译为机器指令，最终为 CPU 所执行。

而伪指令没有对应的机器指令，最终不被 CPU 所执行。那么谁来执行伪指令呢?

伪指令是由编译器来执行的指令，编译器根据伪指令来进行相关的编译工作。

寻址方式

立即寻址：mov ax, 1234H or mov ax, VARW or mov ax, [VARW] （VARW 是内存字变量）
直接寻址：mov ax, [1234H]
寄存器直接寻址：mov ax, bx
寄存器间接寻址：mov ax, [bx]
寄存器相对寻址：mov ax, [bx+1]
基址+变址寻址：mov ax, [bx+si] or mov ax, [bx][si]
基址+变址+相对寻址：mov ax, [bx+si+1]

注：在汇编源程序中，数据不能以字母开头，所以要在前面加 0。比如，9138h 在汇编源程序中可以直接写为 9138h，而 A000h 在汇编源程序中要写为 0A000h。

Debug

R命令：查看、改变 CPU 寄存器的内容；
D命令：查看内存中的内容；
E命令：改写内存中的内容；
U命令：将内存中的机器指令翻译成汇编指令；
T命令：执行一条机器指令；
A命令：以汇编指令的格式在内存中写入一条机器指令；
P命令：可用于快速结束一段LOOP，遇到loop时使用；
G命令：可以让指令直接执行到某个地址处，如-g 0016执行到0016处代码。

实模式和保护模式

实模式是 Intel 80286 和之后的 x86 兼容 CPU 操作模式。

实模式的特性是一个 20 位元的区段存储器地址空间（意思为只有1MB的存储器可以被寻址），软件可以直接访问 BIOS 例程以及周边硬件，没有任何硬件等级的存储器保护观念或多任务。

保护模式是一种 80286 系列和之后的 x86 兼容CPU的运行模式。

保护模式有一些新的特性，如存储器保护，标签页系统以及硬件支持的虚拟内存，能够增强多任务处理和系统稳定度。

现今大部分的 x86 操作系统都在保护模式下运行，包含 Linux、FreeBSD、以及微软 Windows 2.0 和之后版本。

在纯 DOS 方式（实模式）下，可以不理会 DOS，直接用汇编语言去操作真实的硬件。

因为运行在 CPU 实模式下的 DOS，没有能力对硬件系统进行全面、严格的管理。

但在 Windows 2000、Unix 这些运行于 CPU 保护模式下的操作系统中，不理会操作系统，用汇编语言去操作真实的硬件，是根本不可能的。硬件已被这些操作系统利用 CPU 保护模式所提供的功能全面而严格地管理了。

Mul 与 Div

mul bl ; al * bl => ax
mul bx ; ax * bx => dx(H) ax(L)
div bl ; ax / bl => ah(余) al(商)
div bx ; dx(H) ax(L) / bx => dx(余) ax(商)

有符号和无符号比较

cmp:

无符号比较：

JA JB JNAE: above | below | equal | not

有符号比较：

JG JL JNGE: great | low | equal | not

如果是立即数的比较，cmp 不会识别是 8 位还是 16 位。如果通过 word ptr 或 byte ptr 进行指定：

1cmp byte ptr[di], 55h

标志位

OF overflow，溢出标志，针对有符号数，1 => 溢出
DF direction，方向标志，控制数据串操作指令的步进方向，1 => 递减
IF interupt，中断允许标志，1 => 开中断
TF trap，陷阱标志，1 => CPU 单步执行指令（程序调试）
SF sign，符号标志，最高位为 0/1
ZF zero，零标志，1 => 结果为零
AF auxiliary carry，辅助进位标志，供 BCD 码使用，1 => D3 位出现进位或借位
PF parity，奇偶标志，1 => 有偶个“1”出现
CF carry，进位标志，针对无符号数，1 => 进位

In 和 Out

在 in 和 out 指令中，只能使用 ax 或 al 来存放从端口中读入的数据或要发送到端口中的数据。

访问 8 位端口时用al，访问 16 位端口时用 ax。

对 0~255 以内的端口进行读写时：

1in al, 20h ; 从 20h 端口读入一个字节
2out 20h, al ; 往 20h 端口写入一个字节

对 256~65535 的端口进行读写时，端口号放在 dx 中：（超出 8 位的接口地址必须用 dx 提供）

1mov dx, 3f8h ; 将端口号 3f8h 送入dx
2in al, dx ; 从 3f8h 端口读入一个字节
3out dx, al ; 向 3f8h 端口写入一个字节

问题

向内存 0:200~0:23F 依次传送 0~63(3FH)：

注意 0:200~0:23F 等同于 0020:0~0020:3f，它们描述的是同一内存单元。

 1assume cs:code
 2code segment
 3    
 4    mov  bx, 20h
 5    mov  ds, bx
 6    mov  bx, 0
 7    mov  cx, 40h
 8  s:mov  [bx], bx
 9    inc  bx
10    loop s
11
12    mov  ax, 4c00h
13    int  21h
14
15code ends
16end

将 mov ax, 4c00h 之前的指令复制到内存 0:200 处：

CX寄存器在debug调试一个可执行程序时，初始值为该程序的字节尺寸大小，要复制 mov ax, 4c00h 之前的指令，需要减去 mov ax,4c00h 和 int 21h 包含的 5 个字节。而由于程序指令的起始地址由 CS:IP 指定，所以将 ds 赋值为 cs。

 1assume cs:code
 2code segment
 3    mov ax, cs ; 程序指令的起始地址由CS:IP指定
 4    mov ds, ax
 5    mov ax, 0020h
 6    mov es, ax
 7    mov bx, 0
 8    sub cx, 5 ; 减去5个字节 mov ax, 4c00h 和 int 21h
 9  s:mov al, [bx]
10    mov es:[bx], al
11    inc bx
12    loop s
13    
14    mov ax, 4c00h
15    int 21h
16code ends
17end

实践: 自旋锁

自旋锁，顾名思义，即自己不断旋转重复进行的锁，当多个线程访问同一资源时，为实现互斥访问，必须给目标资源加锁，此时只允许一个线程访问，此时其他线程无法访问，并且一直重复请求访问，直到该锁被释放。访问完资源的线程及时释放锁以供其他资源访问。

自旋锁可以通过比较替换算法实现：设锁为1时被占用，为0时空闲。当一个线程请求锁时，即进入请求锁循环“spinlock”，设预期值为 0，修改值为 1，让锁值与预期值比较，若锁值等于预期值，则锁空闲，将锁值置为修改值，退出 spinlock 循环；若锁值不等于预期值，则证明锁被占用，继续 spinlock 循环。

为验证是否成功实现自旋，开启一个释放锁线程，请求锁线程自旋一段时间后，释放锁线程进行锁的释放，即把锁值置为预期值0。此时，请求锁线程成功获得锁并退出 spinlock 循环。

下面使用 x86_64 汇编实现自旋锁。

Intel 语法

 1// 尝试获取锁
 2void lock(long *p) {
 3    long a = 0, c = 1;
 4    printf("try to get lock...\n");
 5    __asm__(
 6        "push rax \n\t"
 7        "push rcx \n\t"
 8        "spin_lock: \n\t"
 9        "mov rcx, %[c] \n\t"
10        "mov rax, %[a] \n\t"
11        // 比较并替换算法，若p==rax==0则获得锁并使p=rcx(==1)，若p(==1)!=rax则进入自旋。
12        "lock cmpxchg %[p], rcx \n\t"
13        "jne spin_lock \n\t"
14        "pop rcx \n\t"
15        "pop rax \n\t"
16        : [p]"+m"(*p)
17        : [a]"r"(a), [c]"r"(c)
18        : "rcx", "rax"
19    );
20}
21// 释放锁
22void unlock(long *p) {
23    __asm__(
24        "mov %[p], 0; \n\t"
25        : [p]"+m"(*p)
26    );
27}

AT&T 语法

 1void lock(long *p) {
 2    long a = 0, c = 1;
 3    printf("try to get lock...\n");
 4    __asm__(
 5        "pushq %%rax \n\t"
 6        "pushq %%rcx \n\t"
 7        "spin_lock: \n\t"
 8        "movq %1, %%rcx \n\t"
 9        "movq %2, %%rax \n\t"
10        "lock cmpxchg %%rcx, %0 \n\t"
11        "jne spin_lock \n\t"
12        "popq %%rcx \n\t"
13        "popq %%rax \n\t"
14        : "+m"(*p)
15        : "r"(c), "r"(a)
16        : "%rcx", "%rax"
17    );
18}
19void unlock(long *p) {
20    __asm__(
21        "movq $0, %0; \n\t"
22        : "+r"(*p)
23    );
24}

测试自旋锁

初始化锁值为 1，主线程尝试获取锁，进入自旋，子线程在一段时间后释放锁，锁值置为 0，接着，主线程获得锁并把锁置为 1。

 1#include <stdio.h>
 2#include <pthread.h>
 3#include <unistd.h>
 4
 5// intel语法实现自旋锁 > gcc -pthread -masm=intel -o s spinlock.c
 6// 尝试获取锁
 7void lock(long *p) {
 8    long a = 0, c = 1;
 9    printf("try to get lock...\n");
10    __asm__(
11        "push rax \n\t"
12        "push rcx \n\t"
13        "spin_lock: \n\t"
14        "mov rcx, %[c] \n\t"
15        "mov rax, %[a] \n\t"
16        // 比较并替换算法，若p==rax==0则获得锁并使p=rcx(==1)，若p(==1)!=rax则进入自旋。
17        "lock cmpxchg %[p], rcx \n\t"
18        "jne spin_lock \n\t"
19        "pop rcx \n\t"
20        "pop rax \n\t"
21        : [p]"+m"(*p)
22        : [a]"r"(a), [c]"r"(c)
23        : "rcx", "rax"
24    );
25}
26// 释放锁
27void unlock(long *p) {
28    __asm__(
29        "mov %[p], 0; \n\t"
30        : [p]"+m"(*p)
31    );
32}
33
34// 释放锁线程
35void *mythread(void* args) {
36    long* p = (long*) args;
37    // 推迟释放锁，此时自旋在进行中
38    sleep(2);
39    // 释放锁
40    unlock(p);
41    printf("after unlock: %ld\n", *p);
42}
43
44int main() {
45    long a = 1; // 设刚开始锁已被获取
46    long *p = &a;
47    // 开启一个用于释放锁的线程
48    pthread_t t1;
49    pthread_create(&t1, NULL, mythread, (void*)p);
50    printf("before lock: %ld\n", *p);
51    // 主线程尝试获取
52    lock(p);
53    pthread_join(t1, NULL);    
54    printf("after lock: %ld\n", *p);
55    return 0;
56}

这里采用 intel 语法编写的自旋锁进行测试，执行命令 gcc -pthread -masm=intel -o s spinlock.c 进行编译。

若采用 AT&T，执行命令 gcc -pthread -o s spinlock.c 进行编译，无需 -masm=intel，因为 gcc 底层默认采用 AT&T。

运行结果

运行结果如下：

1before lock: 1
2try to get lock...
3after unlock: 0
4after lock: 1

一开始锁值为 1，请求锁线程（即主线程）请求获得锁，进入自旋。2s 后释放锁线程进行锁的释放，接着请求锁线程成功获得锁，锁值又被置为 1，成功实现自旋与锁的释放。

参考

维基百科
王爽《汇编语言》

作为忍者狼的战斗记忆

akynazh@gmail.com (zhihang) — Mon, 15 Aug 2022 16:11:17 +0800

在这篇博客记录下沉浸在只狼的世界中的那段时光里，让我印象深刻的一些地方。

我在只狼中一共经历了六次轮回，在六周目下以双难模式通关，也击败了 DLC 狼心中的所有头目。只狼流程不长，算是一部小而美的作品，在我心中，它是一部精美的艺术品，值得反复游玩。

这是白雪覆盖之下的苇名城，颇具美感。

第一个感觉难缠的 BOSS 是赤鬼，但凡多贪一刀就很容易被抓住干掉，同时如果不知道红眼怪怕火这个特点，那么只能跟它一来一回磨血量了。

后面双难模式下打赤鬼，虽然被抓到就是秒杀，但是知道使用火刀了，所以可以轻松拿下。和赤鬼的战斗十分刺激，也十分绝望，当时花了不少时间，在一次又一次的死亡中，吸取教训，提高熟练度，最终战胜强敌。

之后打完赤鬼往前走，在悬崖峭壁之间，我初遇白蛇，开始真正被这个游戏所吸引：

这是一条巨大无比的白蛇，据考证应该是一条双头蛇，要么就是有两条这样的蛇，因为后期忍杀了一条后，还能发现在洞窟里发现另一个蛇头在动。它曾经是当地人信仰的白蛇神。遇见这条蛇时，我欣赏了许久（也挂了不少次），颇有趣味，感觉来到了一个奇异的世界。

对战义父，父慈子孝。选择了保护神子，坚持自己的信念，就必须和义父反目成仇。此时的天守阁正是黄昏时刻，一场艰苦卓绝的战斗即将开始：

这是一场无比艰难的战斗。义父的攻击时快时慢，各种招数层出不穷。他的韧性很高，想把他逼入绝境，必须不断地进攻。

最后，狼是从背后忍杀了义父，留下一句“落影，物归原主”，取回落樱。而同时也是狼还给义父的一刀，还的是三年前义父背刺狼的那一刀。

在前往狮子猿所在地的路上，悬崖绝壁之间，筑有许多巨大佛雕，额外有意思，也令人生畏：

置身源之宫，如梦如画。满湖落樱，清水如镜。第一次来时的确感觉来到了世外桃源。但是后来慢慢深入内部，才发现这华美的景象背后潜藏着多么丑陋的东西……

初见樱龙，气势凌人，这虽然只是一场表演战，但是还是特别有意思。第一次见的时候完全被樱龙的气势震撼到：

拿到龙泪后，便回到苇名城，准备最后的对决了。此时的苇名城已经混乱不堪，战斗愈演愈烈。

最后对战剑圣苇名一心。它无疑是只狼中难度仅次于怨恨之鬼的 BOSS 了。但在一周目时感觉和义父也五五开吧，在双难模式下就比义父难多了。

第一次遇见一心，很难不为他的剑圣风范所震慑到：

最后作为介错人处死一心，也能感受到他无比的剑圣气质。

在三周目尝试堕为修罗，这的确算是是最坏的结局，狼最后甚至把义父也杀了……在高周目玩了一次这个结局，感觉没有动力再玩一次修罗结局了。

于火光中结束一切……

个人最满意的结局，也是官方指定结局，龙之还乡：

狼和皇子都活了下来，和神子一道前往西方，送还樱龙，断绝不死之诅咒，走向新的征程：

到此结束。感谢 FS 社给我带来的这一段珍贵的经历！

挪威的森林与披头士

akynazh@gmail.com (zhihang) — Sat, 14 May 2022 11:47:43 +0800

飞机一着陆，禁烟显示牌倏然消失，天花板扩音器中低声流出背景音乐，那是一个管弦乐队自鸣得意地演奏的甲壳虫乐队的《挪威的森林》。那旋律一如往日地使我难以自已，不，比往日还要强烈地摇撼着我的身心。

《挪威的森林》—— Norwegian Wood

她一边这样说着，一边弹起《米歇尔》，弹得极其精彩。 “好曲子，我，无比喜欢！”说完，玲子喝了一口葡萄酒，吸了口烟，“简直就像霏霏细雨轻轻洒在无边无际的草原。”

《米歇尔》—— Michelle

接着，她弹了《没有归宿的人》，弹了《朱丽娅》。有时边弹边闭上眼摇着头，然后又呷口酒吸口烟。

《没有归宿的人》—— Nowhere Man
《朱丽娅》—— Julia

店里的女孩说，如果肯弹甲壳虫乐队的《太阳从这里升起》，冷藏牛奶可算店里请客。玲子伸出拇指，做出OK的表示，随即边哼歌词边弹《太阳从这里升起》。音量并不大，而且大概由于过度吸烟的关系，嗓音有些沙哑，但很有厚度，娓娓动人。我喝着啤酒，望着远山，耳听她的歌声，恍惚觉得太阳会再次从那里探出脸来，那心境实在太温馨、太平和了。

《太阳从这里升起》—— Here Comes The Sun

“我也喜爱，非常委婉感人。”她又轻轻弹了几小节《宝贝儿》的旋律，呷了口葡萄酒。“喝醉之前能弹上几首呢。嗯，这样的葬礼不凄凉，还可以吧？” 玲子转向甲壳虫。弹了《挪威的森林》，弹了《昨日》，弹了《米歇尔》，弹了《有一件事》，边唱边弹了《太阳从这里升起》，弹了《山峰上的傻子》。我排出了七根火柴。

《昨日》—— Yesterday
《有一件事》—— Something
《山峰上的傻子》—— The Fool On The Hill

“七首，”玲子说着，呷口酒，吸口烟。“这几个人对人生的伤感和温情确实深有体会啊。” 这几个人当然是Ｊ．列农、Ｐ．麦卡特尼，加上Ｇ．哈里森。她换了口气，熄掉烟，又抱起吉他。弹了《细雨》，弹了《黑鸟》，弹了《朱莉娅》，弹了《年届六十四》，弹了《没有归宿的人》，弹了《而且我爱她》，弹了《喂，乔德》。

《细雨》—— Penny Lane
《黑鸟》—— Black Bird
《年届六十四》—— When I’m Sixty Four
《而且我爱她》—— And I Love Her
《喂，乔德》—— Hey, Jude

我放上唱片，第一张听完便把唱针移到第二张。全部听完之后，又从头听起。唱片只有六张。第一张是《佩珀军士寂寞的心俱乐部乐队》，最后是比尔·埃文斯的《献给黛比的华尔兹》。窗外雨下个不停，时间缓缓流逝，直子一个人絮絮不止。

《佩珀军士寂寞的心俱乐部乐队》—— Sgt. Pepper’s Lonely Hearts Club Band

山脉游览录

akynazh@gmail.com (zhihang) — Mon, 21 Mar 2022 18:02:04 +0800

前言

每一座山都有独特的感觉，每一座山都有自己的故事。

圭峰山

攀登于二三年四月份。

圭峰山属于秦岭支脉，海拔 1528 米，因其外形就像汉字“圭”，故得名圭峰山。此山有“天上一轮月，圭峰十二圆”的美誉，范仲淹曾在此处饮酒赏月，“圭峰明月”为鄠邑八大景之一。

此次登山印象很深刻。圭峰山是一座自然山，途中没有任何台阶，攀登过程较为艰难。

山顶上有一座小庙，空旷的蓝天和茂密的绿叶相得益彰。

翠华山

攀登于二二年二月冬日之时。

翠华山系终南山的一个支峰，位于秦岭北麓，主峰终南山海拔 2604 米。因汉武帝曾在这里祭祀过太乙神，故又名太乙山。山腰有翠华庙，内供翠华姑娘塑像。民间传说翠华姑娘为争取自由婚姻，逃奔这里，后来成仙而去，此山便得名翠华山。

寒假时前去游览，这也是我第一次爬雪山。由于是淡季，山上很安静，只能听见风的声音，以及细碎的脚步声。此时，一只孤独的鸟飞了过去。

步行至天池附近，仿佛进入了画中世界，在这里驻足观赏许久才肯离去。

南五台

攀登于二一年十月秋日之时。

南五台为秦岭终南山中段的一个支脉，海拔 1688 米。因山上有清凉、文殊、舍身、灵应、观音五个台，故名五台山。

蓝天白云，清风拂面，一切都很好。

百二邱田

攀登数次，也曾骑行上山。

山中的藏莲寺历史悠久，创建于明朝隆庆四年，距今已有 430 多年。建有慈悲娘殿、三圣殿、地藏阁、珍秀阁、半天娘殿、南天门伯公庙等宗教建筑。

这是一个清晨时的山顶，是一种朦胧而梦幻的感觉：

这是一次雨后的山景，白云密密麻麻的。

华山

攀登于二一年五月。

华山，古称“西岳”，为五岳之一。南接秦岭山脉，北瞰黄渭，自古以来就有“奇险天下第一山”的说法。

攀登后果真感受到了华山的险与奇。行至对弈亭，仿佛进入仙境：

攀登之日风云突变，天气转阴，有点扫兴。幸运的是在山雨来临之前就登顶了，赶上了最后一班缆车下山。

铁山

曾攀登数次。

铁山，又名铁尖山、铁嶂。清乾隆十年《普宁县志》载：“铁山，以崖石俱作铁色，故名”。

后记

持续更新本文中……

强风吹拂，步履不停。呐，你喜欢登山吗？

开发工具重要使用记录

akynazh@gmail.com (zhihang) — Sun, 17 Jan 2021 21:46:42 +0800

VSCode

Nginx 嵌套问题

不支持嵌套 IF
嵌套的 Location 不会应用外层 IF，但是 root、index、add_header 可以应用

Code 命令

1command palette -> shell command -> select: install 'code' command in PATH

配置文件自动换行规则

1"editor.wordWrap": "off"

快速变换：cmd -> wordWrap -> toggle

单独配置 markdown 自动换行：

1"[markdown]": {
2"editor.wordWrap": "on",
3},

当前工作区不显示 .gitignore 中忽略的文件

编辑: .vscode/settings.json:

1{
2    "explorer.excludeGitIgnore": true,
3}

单击文件在新标签页打开

单击文件在新标签页打开 workbench.editor.enablePreview 为 false

使用多标签模式

Windows -> Native Tabs [v]

tabs 多行模式

workbench.editor.wrapTabs [v]

IDEA

自动生成注释

File | Settings | Editor | File and Code Templates | Includes

Add File Header:

1/**
2 * @Author jiangzhh
3 * @Description: 
4 * @Date: Create in ${TIME} ${DATE}
5 */

使用 \n 作为换行符

Editor | Code Style.

From the Line separator list, select the line separator style you want to apply.

选择 Unix and macOS (\n)。

使用 tab 缩进

根据阿里巴巴 Java 开发手册：

【强制】采用 4 个空格缩进，禁止使用 tab 字符。

说明：如果使用 tab 缩进，必须设置 1 个 tab 为 4 个空格。IDEA 设置 tab 为 4 个空格时，请勿勾选 Use tab character；而在 eclipse 中，必须勾选 insert spaces for tabs。

Uncheck:

File > Settings > Editor > Code Style > Java > Tabs and Indents > Use tab character

控制台中文乱码解决

菜单栏HELP->Edit Custom VM OPtions中加 -Dfile.encoding=utf-8
重启idea

IDEA 开启RunDashboard

1# .idea/workspace.xml
2
3<component name="RunDashboard">
4    <option name="configurationTypes">
5        <set>
6            <option value="SpringBootApplicationConfigurationType" />
7        </set>
8    </option>
9</component>

IDEA 关闭拼写

1Settings -> Editor -> Inspection -> Proofreading -> 关闭Typo

IDEA 配置快捷输入

1editor -> live template

IDEA 常用快捷键

1alt + 上下键：将当前行移到上或下一层
2
3alt + 左右键：代码阅读必备，回到上或下一层代码

禁用 double shift

对于2021.2.2之前的版本，方法如下：

Ctrl+Shift+A (Mac下为 Comand+Shift+A) => 输入 Registry => 找到 "ide.suppress.double.click.handler" 并勾选，再 Apply 即可。

对于2021.2.2及之后的版本，可以这么做：

菜单栏依次点击 File => Settings => Advanced Settings => User Interface => 勾选 "Disable double modifier key shortcuts"，或者打开设置之后搜索 disable，可快速定位。

忽略文件或目录

忽略文件或目录：

Editor -> File Types -> Ignored Files And Folders

忽略目录，并可以方便的显示和隐藏：

隐藏：右键目录，Mark Directory As -> Excluded
显示：右键Projects左侧空白处，Tree Apperance -> Show Excluded Files

单击文件不要在新标签页打开

Editor - General - Editor Tabs - Opening Policy - Enable preview tabs [v]

Matlab 重要用法整理

akynazh@gmail.com (zhihang) — Thu, 06 Feb 2020 20:41:12 +0800

基本语法

提取矩阵某行或某列

1A(:, [2 3]) 返回第 2 和第 3 列

获取随机数

1randi(100); % 1 到 100 之间的随机整数

初始化数组

1zeros(1, 30); % 1 行 30 列的全 0 数组

控制语句

 1for i = 0 : 100
 2    for j = 1 : 10
 3        if (...) 
 4          ...
 5        else 
 6          ...
 7        end
 8    end
 9    ...
10end

格式化输出

1fprintf("若选手选择改变，则成功次数为：%d, 成功率为：%f\n", count, count / SUM);

初等数学

求解方程组

注：solve 已经改版，不可传入字符串

实例：求解二元一次方程

1syms x y;
2s = x - 6 * y == 2;
3t = 5 * x + 4 * y == 3;
4result = solve(s, t);

求平均值，中值与标准差

1A = [12 13 7 18 16 21 9 10 2 18];
2A = sort(A);
3ave = mean(A);
4md = median(A);
5sigma = std(A);

解一阶导数方程

1syms x y;
2y = -0.0283 * x^2 + 0.7387 * x + 8.9191;
3my_x = solve(diff(y)); % diff(A)用于求导数
4my_y = subs(y, x, my_x); % 当x=my_x时求y的值
5fprintf("(%.2f, %.2f)\n", my_x, my_y);

基础绘图

绘制二维图

绘制二维图并设置x,y轴通过坐标原点

1x = [-2.5*pi:0.1:2.5*pi];
2y = [-1:0.1:1];
3y = cos(x);
4plot(x,y)
5ax = gca;
6ax.XAxisLocation = 'origin';
7ax.YAxisLocation = 'origin';

绘制三维图

使用 mesh 或 surf，subplot 进行分区

1[x, y] = meshgrid(-5:0.1:5, -3:0.1:3);
2z = x.^2 + y.^2;
3subplot(1,2,1)
4surf(x, y, z);
5subplot(1,2,2)
6mesh(x,y,z)

绘制等高线

1[x, y] = meshgrid(-5:0.1:5, -3:0.1:3);
2z = x.^2 + y.^2;%z就是高度
3contour(x,y,z)%绘制等高线
4subplot(2,2,1)
5[C,h] = contour(x,y,z, 'ShowText', 'on');
6% [M,c] = contour(___) 返回等高线矩阵和等高线对象 c。
7% 显示等高线图后，使用 c 设置属性。

高等数学

泰勒级数第n项展开

1T = taylor(f, x, 'Order', n);

线性代数

求极大线性无关组

 1A =
 2
 3     1     2     3     1
 4     0     1     2    -2
 5     2     1     0     8
 6
 7>> [R j] = rref(A)
 8
 9R =
10
11     1     0    -1     5
12     0     1     2    -2
13     0     0     0     0
14
15%主元所在列数
16j =
17
18     1     2
19
20% 即得到极大线性无关组
21
22>> M = A(:,[1,2])
23
24M =
25
26     1     2
27     0     1
28     2     1

求 Ax = 0 基础解系

 1A =
 2
 3     2    -2     1     3
 4     9    -5     2     8
 5
 6%求出最小有理数解
 7>> r = rank(A);
 8>> X = null(A, 'r')
 9
10X =
11
12    0.1250   -0.1250
13    0.6250    1.3750
14    1.0000         0
15         0    1.0000
16
17%求出规范正交基
18>> X = null(A)
19
20X =
21
22    0.1293   -0.1052
23    0.3860    0.7386
24    0.9041   -0.2092
25   -0.1302    0.6322

左除与右除

1右除正斜杠： A / B -> A * inv(B)
2左除反斜杠： A \ B -> inv(A) * B

求 Ax = b 特解

1A非方阵时，无法利用x = A^(-1) * b
2
3应该使用x = A \ b

计算特征多项式及特征值

 1>> A = [1 2 3; 2 1 3; 3 3 6]
 2
 3A =
 4
 5     1     2     3
 6     2     1     3
 7     3     3     6
 8
 9>> f = poly(A)
10
11f =
12
13    1.0000   -8.0000   -9.0000   -0.0000
14
15>> lamda = roots(f)
16
17lamda =
18
19    9.0000
20   -1.0000
21   -0.0000

计算特征值的简易方法

1>> eig(A)
2
3ans =
4
5   -1.0000
6   -0.0000
7    9.0000

计算特征值及对应特征向量

 1>> [Q, D] = eig(A)
 2
 3Q =
 4
 5    0.7071    0.5774    0.4082
 6   -0.7071    0.5774    0.4082
 7         0   -0.5774    0.8165
 8
 9
10D =
11
12   -1.0000         0         0
13         0   -0.0000         0
14         0         0    9.0000

使用命令 eig 把二次型标准化

1同上，由D可得标准型，由Q可得正交变换法。

使用命令 eig 判断二次型的正定性

1同上，观察D对角线元素正负性即可。

使用命令 orth 把向量组正交规范化

 1A =
 2
 3     2    -2     1     3
 4     9    -5     2     8
 5   
 6>> B = orth(A)
 7
 8B =
 9
10   -0.2982    0.9545
11   -0.9545   -0.2982
12
13%满足B * B' == eye(rank(A))
14
15>> B * B'
16
17ans =
18
19    1.0000    0.0000
20    0.0000    1.0000
21

网站变更日志

akynazh@gmail.com (zhihang) — Thu, 01 Jan 1970 00:00:00 +0000

2025/06/27

原域名 akynazh.site 将停用，改用 zhihang.org。

1970/01/01

本文 Slug 基于更新日期动态变更，用于实现 RSS 通知。

About

akynazh@gmail.com (zhihang) — Mon, 01 Jan 0001 00:00:00 +0000

本站由 Hugo 驱动，通过 Nginx 部署在个人服务器上，主要记录计算机技术、个人生活和音乐相关内容。

本人目前从事软件后端开发工作，业余时间有在进行软件开源相关工作，具体可以访问我的 Github。我主要的爱好是弹琴和游泳，目前在练习弹奏巴赫的哥德堡变奏曲，睡前弹奏一遍咏叹调是我治疗失眠问题的好方法。

如果你对我的博客文章有任何问题，欢迎沟通交流。