分布式锁

什么是分布式锁

在计算机科学中，锁是在并发场景下用于强行限制资源访问的一种同步机制，即用于在并发控制中通过互斥手段来保证数据同步安全。

在 Java 进程中，可以使用 Lock、synchronized 等来支持并发锁。如果是同一台机器的不同进程，想要同时操作一个共享资源（例如修改同一个文件），可以使用操作系统提供的「文件锁」或「信号量」来做互斥。这些发生在同一台机器上的互斥操作，可以称为本地锁。

本地锁无法协同不同机器间的互斥操作。为了解决这个问题，需要引入分布式锁。

分布式锁，顾名思义，应用于分布式场景下，它和单进程中的锁并没有本质上的不同，只是控制对象由一个进程中的多个线程变成了多个进程中的多个线程。此外，临界区的资源也由进程内共享资源变成了分布式系统内部共享资源。

分布式锁典型应用场景是：

• 选举 Leader - 分布式锁可用于确保：在任何指定时间内，只有一个节点成为领导者。
• 任务调度 - 在分布式任务调度器中，分布式锁确保一个调度任务仅由一个 worker 节点执行，从而防止重复执行。
• 资源配置 - 在管理共享资源（如文件系统、网络 Socket 或硬件设备）时，分布式锁可确保一次只有一个进程可以访问资源。
• 微服务协调 - 当多个微服务需要执行协同操作时，例如更新不同数据库中的相关数据，分布式锁可以确保这些操作以可控和有序的方式执行。
• 库存管理 - 在电商系统中，分布式锁可以管理库存更新，以确保当多个用户尝试同时购买相同商品时，正确增减库存，防止超卖。
• 会话管理 - 在分布式环境中处理用户会话时，分布式锁可以确保用户会话一次只能由一个服务器修改，从而防止不一致。

图来自：https://blog.bytebytego.com/i/149472287/why-do-we-need-to-use-a-distributed-lock

分布式锁的设计目标

分布式锁的解决方案大致有以下几种：

• 基于数据库实现
• 基于缓存（Redis，Memcached 等）实现
• 基于 Zookeeper 实现

分布式锁的实现要点大同小异，仅在实现细节上有所不同。

互斥

分布式锁必须是独一无二的，表现形式为：向数据存储插入一个唯一的 key，一旦有一个线程插入这个 key，其他线程就不能再插入了。

• 保证 key 唯一性的最简单的方式是使用 UUID。
• 此外，可以参考 Snowflake ID（雪花算法），将机器地址（IP 地址、机器 ID、MAC 地址）、Jvm 进程 ID（应用 ID、服务 ID）、时间戳等关键信息拼接起来作为唯一标识。
• 应用自行保证

避免死锁

在分布式锁的场景中，部分失败和异步网络这两个问题是同时存在的。如果一个进程获得了锁，但是这个进程与锁服务之间的网络出现了问题，导致无法通信，那么这个情况下，如果锁服务让它一直持有锁，就会导致死锁的发生。

常见的解决思路是引入超时机制，即成功申请锁后，超过一定时间，锁失效（删除 key）。这样就不会出现锁一直不释放，导致其他线程无法获取锁的情况。Redis 分布式锁就采用了这种思路。

超时机制解锁了死锁问题，但又引入了一个新问题：如果应用加锁时，对于操作共享资源的时长估计不足，可能会出现：操作尚未执行完，但是锁没了的尴尬情况。为了解决这个问题，需要引入锁续期机制：当持有锁的线程尚未执行完操作前，不断周期性检测锁的超时时间，一旦发现快要过期，就自动为锁续期。

ZooKeeper 分布式锁避免死锁采用了另外一种思路。ZooKeeper 的存储单元叫 znode，它是以文件层级形式组织，天然就存在物理空间隔离。并且 ZooKeeper 支持临时节点 + Watch 机制，可以在客户端断连时主动删除临时节点，所以不存在死锁问题。

可重入

可重入指的是：同一个线程在没有释放锁之前，能否再次获得该锁。其实现方案是：只需在加锁的时候，记录好当前获取锁的节点 + 线程组合的唯一标识，然后在后续的加锁请求时，如果当前请求的节点 + 线程的唯一标识和当前持有锁的相同，那么就直接返回加锁成功；如果不相同，则按正常加锁流程处理。

公平性

当多个线程请求同一锁时，它们必须按照请求的顺序来获取锁，即先来先得的原则。锁的公平性的实现也非常简单，对于被阻塞的加锁请求，我们只要先记录好它们的顺序，在锁被释放后，按顺序颁发就可以了。

重试

有时候，加锁失败可能只是由于网络波动、请求超时等原因，稍候就可以成功获取锁。为了应对这种情况，加锁操作需要支持重试机制。常见的做法是，设置一个加锁超时时间，在该时间范围内，不断自旋重试加锁操作，超时后再判定加锁失败。

容错

分布式锁若存储在单一节点，一旦该节点宕机或失联，就会导致锁失效。将分布式锁存储在多数据库实例中，加锁时并发写入 N 个节点，只要 N / 2 + 1 个节点写入成功即视为加锁成功。

数据库分布式锁

数据库分布式锁原理

基于数据库实现分布式锁的思路是：维护一张锁记录表，为用于标识分布式锁的字段增加唯一性约束。利用唯一性约束的互斥性，当且仅当成功插入记录，即表示加锁成功。

（1）创建锁表

1
2
3
4
5
6
7
8
9
10
11

CREATE TABLE `distributed_lock` (
	`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键',
	`resource` VARCHAR(64) NOT NULL DEFAULT '' COMMENT '资源',
	`count` INT(10) UNSIGNED NOT NULL DEFAULT '0' COMMENT '锁次数，统计可重入锁',
	`desc` TEXT DEFAULT NULL COMMENT '备注',
	`create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
	`update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
	PRIMARY KEY (`id`),
	UNIQUE KEY `uniq_resource`(`resource`)
)
	ENGINE = InnoDB DEFAULT CHARSET = `utf8mb4`;

（2）获取锁

想要锁住某个方法时，执行以下 SQL：

1

insert into methodLock(method_name,desc) values (‘method_name’,‘desc’)

因为我们对 method_name 做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

成功插入则获取锁。

（3）释放锁

当方法执行完毕之后，想要释放锁的话，需要执行以下 Sql:

1

delete from methodLock where method_name ='method_name'

数据库分布式锁小结

数据库分布式锁的问题：

• 死锁：一旦释放锁操作失败，或持有锁的机器宕机、断连，就会导致锁记录一直存在，其他线程无法再获得锁。解决办法：为锁增加失效时间字段，启动一个定时任务，隔一段时间清除一次过期的数据。
• 非阻塞：因为 insert 操作一旦失败就会报错，因此未获得锁的线程并不会进入排队队列，要想获得锁就要再次触发加锁操作。解决办法：循环重试，直到插入成功，这么做会产生一定额外开销。
• 非重入：同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。解决办法：在数据库表中加个字段，记录当前获得锁的节点信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。
• 单点问题：如果数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。解决办法：单点问题可以用多数据库实例，同时写入 N 个节点，N / 2 + 1 个成功就加锁成功。

数据库分布式锁的利弊：

• 优点：直接借助数据库，简单易懂。
• 缺点：会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。此外，数据库性能易成为瓶颈。

ZooKeeper 分布式锁

ZooKeeper 分布式锁原理

ZooKeeper 分布式锁的实现基于 ZooKeeper 的两个重要特性：

• 顺序临时节点：ZooKeeper 的存储类似于 DNS 那样的具有层级的命名空间。ZooKeeper 节点类型可以分为持久节点（PERSISTENT）、临时节点（EPHEMERAL），每个节点还能被标记为有序性（SEQUENTIAL），一旦节点被标记为有序性，那么整个节点就具有顺序自增的特点。
• Watch 机制：ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在特定事件触发的时候，ZooKeeper 服务端会将事件通知给用户。

下面是 ZooKeeper 分布式锁的工作流程：

1. 创建一个目录节点，比如叫做 /locks；
2. 线程 A 想获取锁，就在 /locks 目录下创建临时顺序 zk 节点；
3. 获取 /locks目录下所有的子节点，检查是否存在比自己顺序更小的节点：若不存在，则说明当前线程创建的节点顺序最小，获取锁成功；
4. 此时，线程 B 试图获取锁，发现自己的节点顺序不是最小，设置监听锁号在自己前一位的节点；
5. 线程 A 处理完，删除自己的节点。线程 B 监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

Apache Curator 提供了基于 ZooKeeper 实现的可重入公平锁 InterProcessMutex，它正是采用了上面所述的工作流程。

:::details ZooKeeper 分布式锁实现示例

下面是一个简单的 InterProcessMutex 封装示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

import cn.hutool.core.collection.CollectionUtil;
import lombok.extern.slf4j.Slf4j;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;

import java.util.List;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.TimeUnit;

@Slf4j
public class ZookeeperReentrantDistributedLock {

    /**
     * 锁路径，即锁的唯一标识，对应 zk 的一个 PERSISTENT 节点，加锁时会在该节点下新建 EPHEMERAL 节点
     */
    private final String path;

    /**
     * zk 的客户端
     */
    private final CuratorFramework client;

    /**
     * curator 客户端提供的 zk 可重入公平锁
     */
    private final InterProcessMutex mutex;

    public ZookeeperReentrantDistributedLock(String lockId, CuratorFramework client) {
        this.client = client;
        this.path = "/locks/" + lockId;
        this.mutex = new InterProcessMutex(this.client, this.path);
    }

    public void lock() {
        try {
            mutex.acquire();
            System.out.println("lock success");
        } catch (Exception e) {
            log.error("lock exception", e);
        }
    }

    public boolean tryLock(long timeout, TimeUnit unit) {
        try {
            boolean isOk = mutex.acquire(timeout, unit);
            if (isOk) {
                System.out.println("tryLock success");
            }
            return isOk;
        } catch (Exception e) {
            log.error("tryLock exception", e);
            return false;
        }
    }

    public void unlock() {
        try {
            mutex.release();
            System.out.println("unlock success");
        } catch (Throwable e) {
            log.error("unlock exception", e);
        } finally {
            // 清除根路径
            // 生产环境中应指定线程池
            CompletableFuture.runAsync(() -> {
                try {
                    List<String> list = client.getChildren().forPath(path);
                    if (CollectionUtil.isEmpty(list)) {
                        client.delete().forPath(path);
                    }
                } catch (Exception e) {
                    log.error("final unlock exception", e);
                }
            });
        }
    }

}

测试代码：

1
2
3
4
5
6
7
8

RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
CuratorFramework client = CuratorFrameworkFactory.newClient("127.0.0.1:2181", retryPolicy);
client.start();
ZookeeperReentrantDistributedLock lock = new ZookeeperReentrantDistributedLock("订单流水号", client);
lock.lock();
System.out.println("do something");
lock.unlock();
client.close();

:::

ZooKeeper 分布式锁小结

ZooKeeper 分布式锁的优点是较为可靠：

• 避免死锁：ZooKeeper 通过临时节点 + 监听机制，可以保证：如果持有临时节点的线程主动解锁或断连，Zk 会自动删除临时节点，这意味着锁的释放。所以，不存在锁永久不释放从而导致死锁的问题。
• 单点问题：ZooKeeper 采用主从架构，并确保主从同步是强一致的，因此不会出现单点问题。

ZooKeeper 分布式锁的缺点是：加锁、解锁操作，本质上是对 ZooKeeper 的写操作，全部由 ZooKeeper 主节点负责。如果加锁、解锁的吞吐量很大，容易出现单点写入瓶颈。

Redis 分布式锁

相比于用数据库来实现分布式锁，基于缓存实现的分布式锁的性能会更好。目前有很多成熟的分布式产品，包括 Redis、memcache、Tair 等。这里以 Redis 举例。

Redis 分布式锁原理

极简版本

我们先来看一下，如何实现一个极简版本的 Redis 分布式锁。

（1）加锁

Redis 中的 setnx 命令，表示当且仅当 key 不存在时，才会写入 key。由于其互斥性，所以可以基于此来实现分布式锁。

执行 setnx key val，若返回 1，表示写入成功，即加锁成功；若返回 0，表示该 key 已存在，写入失败，即加锁失败。

（2）解锁

Redis 分布式锁如何解锁呢？

很简单，删除 key 就意味着释放锁，即执行 del key 命令。

避免死锁

极简版本的解决方案有一个很大的问题：存在死锁的可能。持有锁的节点如果执行业务过程中出现异常或机器宕机，都可能导致无法释放锁。这种情况下，其他节点永远也无法再获取锁。

对于异常，在 Java 中，可以通过 try...catch...finally 来保证：最终一定会释放锁，其他编程语言也有相似的语法特性。

对于机器宕机这种情况，如何处理呢？通常的对策是：为锁加上超时机制，过期自动删除。

在 Redis 中，expire 命令可以为 key 设置一个超时时间，一旦过期，Redis 会自动删除 key。如此看来，setnx + expire 组合使用，就能解决死锁问题了。可惜，没那么简单。Redis 只能保证单一命令的原子性，不保证组合命令的原子性。

那么，Redis 中有没有一条命令可以实现 setnx + expire 的组合语义呢？还真有，可以通过下面的命令来实现：

1
2
3

# 下面两条命令是等价的
SET key val NX PX 30000
SET key val NX EX 30

参数说明：

• NX：该参数表示当且仅当 key 不存在，才能写入成功
• PX：超时时间，单位毫秒
• EX：超时时间，单位秒

超时续期

为了避免死锁，我们为锁添加了超时时间。但这里有一个问题，如果应用加锁时，对于操作共享资源的时长估计不足，可能会出现：操作尚未执行完，但是锁没了的尴尬情况。为了解决这个问题，很自然会想到，时间不够，就续期呗。

具体来说，如何续期呢？一种方案是：加锁后，启动一个定时任务，周期性检测锁是否快要过期，如果快要过期并且操作尚未结束，就对锁进行自动续期。自行实现这个方案似乎有点繁琐，好在开源 Redis 客户端 Redisson 中已经为锁的超时续期提供了一个成熟的机制——WatchDog（看门狗）。我们可以直接拿来主义即可。

安全解锁

前文提到了，解锁的操作，实际上就是 del key。这里存在一个问题：因为没有任何判断，任何节点都可以随意删除 key，换句话说，锁可能会被其他节点释放。如何避免这个问题呢？解决方法就是：为锁添加唯一性标识来进行互斥。唯一性标识可以是 UUID，可以是雪花算法 ID 等。

在 Redis 分布式锁中，唯一性标识的具体实现就是在 set key val 时，将唯一性标识 id 作为 val 写入。解锁前，先判断 key 的 value，必须和 set 时写入的 id 值保持一致，以此确认锁归属于自己。解锁的伪代码如下：

1
2

if (redis.get("key") == id)
	redis.del("key");

这里依然存在一个问题，由于需要在 Redis 中，先 get，后 del 操作，所以无法保证操作的原子性。为了保证原子性，可以将这段伪代码用 lua 脚本来实现，这么做的理由是 Redis 中支持原子性的执行 lua 脚本。下面是安全解锁的 lua 脚本代码：

1
2
3
4
5

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

自旋重试

有时候，加锁失败可能只是由于网络波动、请求超时等原因，稍候就可以成功获取锁。为了应对这种情况，加锁操作需要支持重试机制。常见的做法是，设置一个加锁超时时间，在该时间范围内，不断自旋重试加锁操作，超时后再判定加锁失败。

下面是一个自旋重试获取锁的伪代码示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

try {
    long begin = System.currentTimeMillis();
    while (true) {
        String result = jedis.set(lockKey, uniqId, "NX", "PX", expireTime);
        if ("OK".equals(result)) {
            // 加锁成功，执行业务操作
            return true;
        }

        long time = System.currentTimeMillis() - begin;
        if (time >= timeout) {
            return false;
        }
        try {
            Thread.sleep(50);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
} catch (Exception e) {
    // 异常处理
} finally {
    // 释放锁
}

Redis 分布式锁小结

在前文中，为了实现一个靠谱的 Redis 分布式锁，我们讨论了避免死锁、超时续期、安全解锁几个问题以及应对策略。但是，依然存在一些其他问题：

• 不可重入 - 同一个线程无法多次获取同一把锁。
• 单点问题 - Redis 主从同步存在延迟，有可能导致锁冲突。举例来说：线程一在主节点加锁，如果主节点尚未同步给从节点就发生宕机；此时，Redis 集群会选举一个从节点作为新的主节点。此时，新的主节点没有锁的数据，若有其他线程试图加锁，就可以成功获取锁，即出现同时有多个线程持有锁的情况。解决这个问题，可以使用 RedLock 算法。

RedLock 分布式锁

RedLock 分布式锁，是 Redis 的作者 Antirez 提出的一种解决方案。

扩展：RedLock 官方文档

RedLock 分布式锁原理

RedLock 分布式锁在普通 Redis 分布式锁的基础上，进行了扩展，其要点在于：

• （1）加锁操作不是写入单一节点，而是同时写入多个主节点，官方推荐集群中至少有 5 个主节点。
• （2）只要半数以上的主节点写入成功，即视为加锁成功。
• （3）大多数节点加锁的总耗时，要小于锁设置的过期时间。
• （4）解锁时，要向所有节点发起请求。

下面来逐一解释以上各要点的用意：

（1）RedLock 加锁时，为什么要同时写入多个主节点？

这是为了避免单点问题，即使有部分实例出现异常，依然可以正常提供加锁、解锁能力。

（2）为什么要半数以上的主节点写入成功，才视为加锁成功？

在分布式系统中，为了达成共识，常常采用“多数派”策略来进行决策：大多数节点认可的行为，就视为整体通过。

（3）为什么加锁成功后，还要计算加锁的累计耗时？

因为操作的是多个节点，所以耗时肯定会比操作单个实例耗时更久。而且，网络情况是复杂的，可能存在延迟、丢包、超时等情况。网络请求越多，异常发生的概率就越大。所以，即使大多数节点加锁成功，但如果加锁的累计耗时已经超过了锁的过期时间，那此时有些实例上的锁可能已经失效了，这个锁就没有意义了。

（4）解锁时，为什么要向所有节点发起请求？

因为网络环境的复杂性，可能会存在这种情况：向某主节点写入锁信息，实际写入成功，但是响应超时或丢包。

所以，释放锁时，不管之前有没有加锁成功，需要释放所有节点的锁，以保证清理节点上残留的锁。

RedLock 分布式锁小结

RedLock 分布式锁的解决方案看上去考虑的面面俱到，似乎已经万无一失了，但真的是如此吗？

分布式领域典中典著作《数据密集型应用系统设计》的作者 Martin 就曾对 RedLock 提出了质疑，他和 Redis 以及 RedLock 的作者 Antirez 掀起了一场激烈的争论。

二人的讨论文章如下，有兴趣可以看一下：

• Martin 质疑 RedLock 的文章：How to do distributed locking
• Antirez 的辩驳文章：Is Redlock safe?

Martin 的观点：

（1）RedLock 不能完全保证安全性

分布式系统会遇到三座大山：NPC

• N：Network Delay，网络延迟；
• P：Process Pause，进程暂停（GC）；
• C：Clock Drift，时钟漂移。

RedLock 在遇到以上情况时，不能保证安全性。

（2）RedLock 加锁、解锁需要处理多个节点，代价太高

（3）提出 fencing token 的方案，保证正确性

这个模型流程如下：

• 客户端在获取锁时，锁服务可以提供一个递增的 token
• 客户端拿着这个 token 去操作共享资源
• 共享资源可以根据 token 拒绝后来者的请求

Antirez 的观点：

• 同意时钟跳跃对 Redlock 的影响，但认为时钟跳跃是可以避免的，取决于基础设施和运维。并且如果误差不大，也是可以接受的。
• Redlock 在设计时，充分考虑了 NPC 问题，在 Redlock 步骤 3 之前出现 NPC，可以保证锁的正确性，但在步骤 3 之后发生 NPC，不止是 Redlock 有问题，其它分布式锁服务同样也有问题，所以不在讨论范畴内。

总结来说，已知的分布式锁，无论采用什么解决方案，在极端情况下，都无法保证百分百的安全。

Redisson 提供的分布式锁

Redisson 是一个流行的 Redis Java 客户端，它基于 Netty 开发，并提供了丰富的扩展功能，如：分布式计数器、分布式集合、分布式锁 等。

Redisson 支持的分布式锁有多种：Lock, FairLock, MultiLock, RedLock, ReadWriteLock, Semaphore, PermitExpirableSemaphore, CountDownLatch，可以根据场景需要去选择，非常方面。一般而言，使用 Redis 分布式锁，推荐直接使用 Redisson 提供的 API，功能全面且较为可靠。

下面是 Redisson Lock API 的一个简单示例：

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

RLock lock = redisson.getLock("myLock");

// traditional lock method
lock.lock();

// or acquire lock and automatically unlock it after 10 seconds
lock.lock(10, TimeUnit.SECONDS);

// or wait for lock aquisition up to 100 seconds
// and automatically unlock it after 10 seconds
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
if (res) {
   try {
     ...
   } finally {
       lock.unlock();
   }
}

分布式锁技术选型

下面是主流分布式锁技术方案的对比，可以在技术选型时作为参考：

参考资料

• 分布式锁实现汇总
• 分布式锁实现原理与最佳实践 - 阿里云开发者
• 聊聊分布式锁 - 字节跳动技术团队
• Redis、ZooKeeper、Etcd，谁有最好用的分布式锁？ - 腾讯云开发者

传输控制协议 TCP

简介

什么是 TCP

TCP（Transmission Control Protocol），即传输控制协议，它是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP 由 RFC 793 定义。

TCP 的特性

• 面向连接的 - 面向连接是指 TCP 需要通过三次握手、四次挥手原则建立和断开双向连接。
• 可靠的 - 可靠是指 TCP 传输的数据包保证以原始顺序到达目的地，且数据包不被损坏。为了实现这点，TCP 通过以下技术来保证：
  • 数据包的序列号和校验码
  • 确认包和自动重传
    • 如果发送者没有收到正确的响应，它将重新发送数据包。如果多次超时，连接就会断开。
    • TCP 实行流量控制和拥塞控制。这些确保措施会导致延迟，而且通常导致传输效率比 UDP 低。
• 基于字节流的
  • 虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序看成是一连串的无结构的字节流。TCP 有一个缓冲，当应用程序传送的数据块太长，TCP 就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP 也可以等待积累有足够多的字节后再构成报文段发送出去。
  • 在 TCP 建立连接前两次握手的 SYN 报文中选项字段的 MSS 值，通信双方商定通信的最大报文长度。如果应用层交付下来的数据过大，就会对数据分段，然后发送；否则通过滑动窗口来控制通信双发的数据。

TCP 的适用场景

基于以上特性，为了确保高吞吐量，Web 服务器可以保持大量的 TCP 连接，从而导致高内存使用。但要注意的是，在 Web 服务器线程间拥有大量开放连接可能开销巨大，消耗资源过多，这时可以考虑在适用情况下切换到 UDP。

TCP 对于需要高可靠性但时间紧迫的应用程序很有用。比如包括 Web 服务器，数据库信息，SMTP，FTP 和 SSH。

以下情况使用 TCP 代替 UDP：

• 你需要数据完好无损。
• 你想对网络吞吐量自动进行最佳评估。

TCP 报文

报文字段不一一阐述，重点关注以下几点：

• TCP 的包是没有 IP 地址的，那是 IP 层上的事。但是有源端口和目标端口。
• 一个 TCP 连接需要四个元组来表示是同一个连接（src_ip, src_port, dst_ip, dst_port）准确说是五元组，还有一个是协议。但因为这里只是说 TCP 协议，所以，这里我只说四元组。
• 注意上图中的四个非常重要的东西：
  • Sequence Number是包的序号，用来解决网络包乱序（reordering）问题。
  • Acknowledgement Number就是 ACK——用于确认收到，用来解决不丢包的问题。
  • Window 又叫 Advertised-Window，也就是著名的滑动窗口（Sliding Window），用于解决流控的。
  • TCP Flag，也就是包的类型，主要是用于操控 TCP 的状态机的。

TCP 通信流程

TCP 完整的通信分为三块：

1. 三次握手建立连接
2. 数据传输
3. 四次挥手端口连接

三次握手

（1）三次握手有什么用？

• 三次握手负责建立 TCP 双向连接。

（2）什么是三次握手？

如上图所示，三次握手流程如下：

1. 第一次握手 - 客户端向服务端发送带有 SYN 标志的数据包。
2. 第二次握手 - 服务端向客户端发送带有 SYN/ACK 标志的数据包。
3. 第三次握手 - 客户端向服务端发送带有带有 ACK 标志的数据包。

至此，TCP 三次握手完成，客户端与服务端已建立双向连接。

💡 说明：SYN 为 synchronize 的缩写，ACK 为 acknowledgment 的缩写。

（3）为什么需要三次握手？

为了便于说明，假设客户端为 A, 服务端为 B。

1. 第一次握手，A 向 B 发同步消息。B 收到消息后，B 认为：A 发消息没问题；B 收消息没问题。
2. 第二次握手，B 向 A 发同步消息和确认消息。A 收到消息后，A 认为：A 发消息、收消息都没问题；B 发消息、收消息都没问题。但是，此时 B 不确定自己发消息是否没问题，所以就需要第三次握手。
3. 第三次握手，A 向 B 发确认消息。B 收到消息后。B 认为：B 发消息没问题。

四次挥手

（1）四次挥手有什么用？

• 四次挥手负责断开 TCP 连接。

（2）什么是四次挥手？

如上图所示，四次挥手流程如下：

1. 第一次挥手 - 客户端向服务端发送一个 FIN 包，用来关闭客户端到服务端的数据传送。
2. 第二次挥手 - 服务端收到这个 FIN 包，向客户端发送一个 ACK 包，确认序号为收到的序号加 1。和 SYN 一样，一个 FIN 将占用一个序号。
3. 第三次挥手 - 服务端关闭与客户端的连接，向客户端发送一个 FIN 包。
4. 第四次挥手 - 客户端向服务端发送 ACK 包，并将确认序号设置为收到序号加 1。

（3）为什么建立连接是三次握手，关闭连接确是四次挥手呢？

• 建立连接的时候， 服务器在 LISTEN 状态下，收到建立连接请求的 SYN 报文后，把 ACK 和 SYN 放在一个报文里发送给客户端。
• 而关闭连接时，服务器收到对方的 FIN 报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送 FIN 报文给对方来表示同意现在关闭连接，因此，己方 ACK 和 FIN 一般都会分开发送，从而导致多了一次。

滑动窗口

什么是滑动窗口？

滑动窗口是 TCP 的一种控制网络流量的技术。

TCP 必需要解决的可靠传输以及包乱序（reordering）的问题，所以，TCP 必需要知道网络实际的数据处理带宽或是数据处理速度，这样才不会引起网络拥塞，导致丢包。

TCP 头里有一个字段叫 Window，又叫 Advertised-Window，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

滑动窗口原理是什么？

1. 已发送已确认 - 数据流中最早的字节已经发送并得到确认。这些数据是站在发送端的角度来看的。上图中的 31 个字节已经发送并确认。
2. 已发送但尚未确认 - 已发送但尚未得到确认的字节。发送方在确认之前，不认为这些数据已经被处理。上图中的 32 ~ 45 字节为第 2 类。
3. 未发送而接收方已 Ready - 设备尚未将数据发出 ，但接收方根据最近一次关于发送方一次要发送多少字节确认自己有足够空间。发送方会立即尝试发送。上图中的 46 ~ 51 字节为第 3 类。
4. 未发送而接收方 Not Ready - 由于接收方 not ready，还不允许将这部分数据发出。上图中的 52 以后的字节为第 4 类。

这张图片相对于上一张图片，滑动窗口偏移了 5 个字节，意味着有 5 个已发送的字节得到了确认。

TCP 重传机制

TCP 要保证所有的数据包都可以到达，所以，必需要有重传机制。

TCP 重传机制主要有两种：

• 超时重传机制
• 快速重传机制

超时重传机制

超时重传机制是指：发送数据包在一定的时间周期内没有收到相应的 ACK，等待一定的时间，超时之后就认为这个数据包丢失，就会重新发送。这个等待时间被称为 RTO(Retransmission TimeOut)，即重传超时时间。

没有确认的数据包不会从窗口中移走，定时器在重传时间到期内，每个片段的位置不变。

这种机制的重点是 RTO 的设置：

• RTO 设长了，重发就慢，丢了老半天才重发，没有效率，性能差；
• RTO 设短了，会导致可能并没有丢就重发。于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发

快速重传机制

快速重传机制，实现了另外的一种丢包评定标准，即如果连续收到 3 次重复 ACK，发送方就认为这个 seq 的包丢失了，立刻进行重传。

当接收方收到乱序片段时，需要重复发送 ACK。

参考资料

• TCP 的那些事儿（上）
• TCP 的那些事儿（下）
• 图解 TCP 三次握手与四次分手
• TCP 的三次握手与四次挥手（详解+动图）
• TCP 详解

用户数据报协议 UDP

简介

UDP 是无连接的。数据报（类似于数据包）只在数据报级别有保证。数据报可能会无序的到达目的地，也有可能会遗失。UDP 不支持拥塞控制。虽然不如 TCP 那样有保证，但 UDP 通常效率更高。

UDP 可以通过广播将数据报发送至子网内的所有设备。这对 DHCP 很有用，因为子网内的设备还没有分配 IP 地址，而 IP 对于 TCP 是必须的。

UDP 可靠性更低但适合用在网络电话、视频聊天，流媒体和实时多人游戏上。

以下情况使用 UDP 代替 TCP：

• 你需要低延迟
• 相对于数据丢失更糟的是数据延迟
• 你想实现自己的错误校正方法

UDP 特点

1. 无连接的，即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
2. 不保证可靠交付，因此主机不需要为此复杂的连接状态表
3. 面向报文的，意思是 UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界，在添加首部后向下交给 IP 层。
4. 没有阻塞控制，因此网络出现的拥塞不会使发送方的发送速率降低。
5. 支持一对一、一对多、多对一和多对多的交互通信，也即是提供广播和多播的功能。
6. 首部开销小，首部只有 8 个字节，分为四部分。

UDP 应用场景

1. 名字转换（DNS）
2. 文件传送（TFTP）
3. 路由选择协议（RIP）
4. IP 地址配置（BOOTP，DHTP）
5. 网络管理（SNMP）
6. 远程文件服务（NFS）
7. IP 电话
8. 流式多媒体通信

UDP 报文

UDP 数据报分为数据字段和首部字段。
首部字段只有 8 个字节，由四个字段组成，每个字段的长度是 2 个字节。

首部各字段意义：

1. 源端口：源端口号，在需要对方回信时选用，不需要时可全 0.
2. 目的端口：目的端口号，在终点交付报文时必须要使用到。
3. 长度：UDP 用户数据报的长度，在只有首部的情况，其最小值是 8 。
4. 检验和：检测 UDP 用户数据报在传输中是否有错，有错就丢弃。

网络技术之 WebSocket

Socket

Socket 作为一种抽象层，应用程序通过它来发送和接收数据，使用 Socket 可以将应用程序与处于同一网络中的其他应用程序进行通信交互。简而言之，Socket 提供了应用程序内部与外界通信的端口以及为通信双方提供了数据传输的通道。

Socket 用法

很多编程语言都支持 Socket。这里以 Java 的 Socket 用法为例。

在 Java 的 SDK 中，socket 的共有两个接口：用于监听客户连接的 ServerSocket 和用于通信的 Socket。使用 socket 的步骤如下：

• 创建 ServerSocket 并监听客户连接
• 使用 Socket 连接服务端
• 通过 Socket 获取输入输出流进行通信

Socket 长连接

Socket 长连接，指的是在客户和服务端之间保持一个 socket 连接长时间不断开。

1

socket.setKeepAlive(true);

WebSocket

WebSocket 简介

WebSocket 是什么

WebSocket 是一种网络通信协议。RFC6455 定义了它的通信标准。

WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。

为什么需要 WebSocket

了解计算机网络协议的人，应该都知道：HTTP 协议是一种无状态的、无连接的、单向的应用层协议。它采用了请求/响应模型。通信请求只能由客户端发起，服务端对请求做出应答处理。

这种通信模型有一个弊端：HTTP 协议无法实现服务器主动向客户端发起消息。

这种单向请求的特点，注定了如果服务器有连续的状态变化，客户端要获知就非常麻烦。大多数 Web 应用程序将通过频繁的异步 JavaScript 和 XML（AJAX）请求实现长轮询。轮询的效率低，非常浪费资源（因为必须不停连接，或者 HTTP 连接始终打开）。

因此，工程师们一直在思考，有没有更好的方法。WebSocket 就是这样发明的。WebSocket 连接允许客户端和服务器之间进行全双工通信，以便任一方都可以通过建立的连接将数据推送到另一端。WebSocket 只需要建立一次连接，就可以一直保持连接状态。这相比于轮询方式的不停建立连接显然效率要大大提高。

WebSocket 如何工作

Web 浏览器和服务器都必须实现 WebSockets 协议来建立和维护连接。由于 WebSockets 连接长期存在，与典型的 HTTP 连接不同，对服务器有重要的影响。

基于多线程或多进程的服务器无法适用于 WebSockets，因为它旨在打开连接，尽可能快地处理请求，然后关闭连接。任何实际的 WebSockets 服务器端实现都需要一个异步服务器。

WebSocket 使用

WebSocket 客户端

在客户端，没有必要为 WebSockets 使用 JavaScript 库。实现 WebSockets 的 Web 浏览器将通过 WebSockets 对象公开所有必需的客户端功能（主要指支持 Html5 的浏览器）。

以下 API 用于创建 WebSocket 对象。

1

var Socket = new WebSocket(url, [protocol] );

以上代码中的第一个参数 url, 指定连接的 URL。第二个参数 protocol 是可选的，指定了可接受的子协议。

WebSocket 属性

以下是 WebSocket 对象的属性。假定我们使用了以上代码创建了 Socket 对象：

WebSocket 事件

以下是 WebSocket 对象的相关事件。假定我们使用了以上代码创建了 Socket 对象：

WebSocket 方法

以下是 WebSocket 对象的相关方法。假定我们使用了以上代码创建了 Socket 对象：

WebSocket 客户端代码示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 初始化一个 WebSocket 对象
var ws = new WebSocket('ws://localhost:9998/echo')

// 建立 web socket 连接成功触发事件
ws.onopen = function() {
  // 使用 send() 方法发送数据
  ws.send('发送数据')
  alert('数据发送中...')
}

// 接收服务端数据时触发事件
ws.onmessage = function(evt) {
  var received_msg = evt.data
  alert('数据已接收...')
}

// 断开 web socket 连接成功触发事件
ws.onclose = function() {
  alert('连接已关闭...')
}

WebSocket 服务端

WebSocket 在服务端的实现非常丰富。Node.js、Java、C++、Python 等多种语言都有自己的解决方案。

以下，介绍我在学习 WebSocket 过程中接触过的 WebSocket 服务端解决方案。

Node.js

常用的 Node 实现有以下三种。

• µWebSockets
• Socket.IO
• WebSocket-Node

Java

Java 的 web 一般都依托于 servlet 容器。

我使用过的 servlet 容器有：Tomcat、Jetty、Resin。其中 Tomcat7、Jetty7 及以上版本均开始支持 WebSocket（推荐较新的版本，因为随着版本的更迭，对 WebSocket 的支持可能有变更）。

此外，Spring 框架对 WebSocket 也提供了支持。

虽然，以上应用对于 WebSocket 都有各自的实现。但是，它们都遵循RFC6455 的通信标准，并且 Java API 统一遵循 JSR 356 - JavaTM API for WebSocket 规范。所以，在实际编码中，API 差异不大。

Spring

Spring 对于 WebSocket 的支持基于下面的 jar 包：

1
2
3
4
5

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-websocket</artifactId>
  <version>${spring.version}</version>
</dependency>

在 Spring 实现 WebSocket 服务器大概分为以下几步：

创建 WebSocket 处理器

扩展 TextWebSocketHandler 或 BinaryWebSocketHandler ，你可以覆写指定的方法。Spring 在收到 WebSocket 事件时，会自动调用事件对应的方法。

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

import org.springframework.web.socket.WebSocketHandler;
import org.springframework.web.socket.WebSocketSession;
import org.springframework.web.socket.TextMessage;

public class MyHandler extends TextWebSocketHandler {

    @Override
    public void handleTextMessage(WebSocketSession session, TextMessage message) {
        // ...
    }

}

WebSocketHandler 源码如下，这意味着你的处理器大概可以处理哪些 WebSocket 事件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public interface WebSocketHandler {

   /**
    * 建立连接后触发的回调
    */
   void afterConnectionEstablished(WebSocketSession session) throws Exception;

   /**
    * 收到消息时触发的回调
    */
   void handleMessage(WebSocketSession session, WebSocketMessage<?> message) throws Exception;

   /**
    * 传输消息出错时触发的回调
    */
   void handleTransportError(WebSocketSession session, Throwable exception) throws Exception;

   /**
    * 断开连接后触发的回调
    */
   void afterConnectionClosed(WebSocketSession session, CloseStatus closeStatus) throws Exception;

   /**
    * 是否处理分片消息
    */
   boolean supportsPartialMessages();

}

配置 WebSocket

配置有两种方式：注解和 xml 。其作用就是将 WebSocket 处理器添加到注册中心。

1. 实现 WebSocketConfigurer

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

import org.springframework.web.socket.config.annotation.EnableWebSocket;
import org.springframework.web.socket.config.annotation.WebSocketConfigurer;
import org.springframework.web.socket.config.annotation.WebSocketHandlerRegistry;

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(myHandler(), "/myHandler");
    }

    @Bean
    public WebSocketHandler myHandler() {
        return new MyHandler();
    }

}

2. xml 方式

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

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:websocket="http://www.springframework.org/schema/websocket"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://www.springframework.org/schema/websocket/spring-websocket.xsd">

    <websocket:handlers>
        <websocket:mapping path="/myHandler" handler="myHandler"/>
    </websocket:handlers>

    <bean id="myHandler" class="org.springframework.samples.MyHandler"/>

</beans>

更多配置细节可以参考：Spring WebSocket 文档

javax.websocket

如果不想使用 Spring 框架的 WebSocket API，你也可以选择基本的 javax.websocket。

首先，需要引入 API jar 包。

1
2
3
4
5
6

<!-- To write basic javax.websocket against -->
<dependency>
  <groupId>javax.websocket</groupId>
  <artifactId>javax.websocket-api</artifactId>
  <version>1.0</version>
</dependency>

如果使用嵌入式 jetty，你还需要引入它的实现包：

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

<!-- To run javax.websocket in embedded server -->
<dependency>
  <groupId>org.eclipse.jetty.websocket</groupId>
  <artifactId>javax-websocket-server-impl</artifactId>
  <version>${jetty-version}</version>
</dependency>
<!-- To run javax.websocket client -->
<dependency>
  <groupId>org.eclipse.jetty.websocket</groupId>
  <artifactId>javax-websocket-client-impl</artifactId>
  <version>${jetty-version}</version>
</dependency>

@ServerEndpoint

这个注解用来标记一个类是 WebSocket 的处理器。

然后，你可以在这个类中使用下面的注解来表明所修饰的方法是触发事件的回调

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// 收到消息触发事件
@OnMessage
public void onMessage(String message, Session session) throws IOException, InterruptedException {
	...
}

// 打开连接触发事件
@OnOpen
public void onOpen(Session session, EndpointConfig config, @PathParam("id") String id) {
	...
}

// 关闭连接触发事件
@OnClose
public void onClose(Session session, CloseReason closeReason) {
	...
}

// 传输消息错误触发事件
@OnError
public void onError(Throwable error) {
	...
}

ServerEndpointConfig.Configurator

编写完处理器，你需要扩展 ServerEndpointConfig.Configurator 类完成配置：

1
2
3
4
5
6
7

public class WebSocketServerConfigurator extends ServerEndpointConfig.Configurator {
    @Override
    public void modifyHandshake(ServerEndpointConfig sec, HandshakeRequest request, HandshakeResponse response) {
        HttpSession httpSession = (HttpSession) request.getHttpSession();
        sec.getUserProperties().put(HttpSession.class.getName(), httpSession);
    }
}

然后就没有然后了，就是这么简单。

WebSocket 代理

如果把 WebSocket 的通信看成是电话连接，Nginx 的角色则像是电话接线员，负责将发起电话连接的电话转接到指定的客服。

Nginx 从 1.3 版开始正式支持 WebSocket 代理。如果你的 web 应用使用了代理服务器 Nginx，那么你还需要为 Nginx 做一些配置，使得它开启 WebSocket 代理功能。

以下为参考配置：

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

server {
  # this section is specific to the WebSockets proxying
  location /socket.io {
    proxy_pass http://app_server_wsgiapp/socket.io;
    proxy_redirect off;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 600;
  }
}

更多配置细节可以参考：Nginx 官方的 websocket 文档

WebSocket 应用示例

如果需要完整示例代码，可以参考我的 Github 代码：

• Spring 对 WebSocket 支持的示例
• 嵌入式 Jetty 服务器的 WebSocket 示例

spring-websocket 和 jetty 9.3 版本似乎存在兼容性问题，Tomcat 则木有问题。

我尝试了好几次，没有找到解决方案，只好使用 Jetty 官方的嵌入式示例在 Jetty 中使用 WebSocket 。

FAQ

Http vs. Socket

Http 通信与 Socket 通信方式有何差异？

• Http
  • 基于请求/响应模式，采取一问一答方式（客户端请求，服务端才会响应）
• Socket
  • 客户端和服务端建立双向连接。连接成功后，任意一方都可主动发送消息。
  • 数据丢失率低，使用简单，易于移植。

HTTP 和 WebSocket 有什么关系？

Websocket 其实是一个新协议，跟 HTTP 协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是 HTTP 协议上的一种补充。

Html 和 HTTP 有什么关系？

Html 是超文本标记语言，是一种用于创建网页的标准标记语言。它是一种技术标准。Html5 是它的最新版本。

Http 是一种网络通信协议。其本身和 Html 没有直接关系。

参考资料

• 知乎高票答案——WebSocket 是什么原理 - 对 WebSocket 原理的阐述简单易懂。
• WebSocket 教程 - 阮一峰大神的科普一如既往的浅显易懂。
• WebSockets - by fullstackpython
• Nginx 官方的 websocket 文档
• Spring WebSocket 文档
• Tomcat7 WebSocket 文档
• Jetty WebSocket 文档
• Socket，你需要知道的事儿
• 手把手教你写 Socket 长连接

网络技术之 CDN

简介

CDN 是什么

CDN(Content Delivery Network)，即内容分发网络。

CDN 是一个全球性的代理服务器分布式网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。它从靠近用户的位置提供内容。通常，HTML/CSS/JS，图片和视频等静态内容由 CDN 提供。CDN 的 DNS 解析会告知客户端连接哪台服务器。CDN 的关键技术主要有内容存储和分发技术。

CDN 的优缺点

• 优点
  • 访问加速 - 由于 CDN 就近服务，大大降低了网络传播时延，所以自然提高了访问速度。
  • 降低负载 - 如果 CDN 已经能获取数据，那么就不必请求源站，这自然降低了源站（服务器）的负载。
• 缺点
  • CDN 成本可能因流量而异，可能在权衡之后你将不会使用 CDN。
  • 如果在 TTL 过期之前更新内容，CDN 缓存内容可能会过时。
  • CDN 需要更改静态内容的 URL 地址以指向 CDN。

CDN 原理

CDN 的基本原理是：

• 广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中；
• 在用户访问网站时，实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息来选择最佳缓存服务器；
• 然后，将用户的请求重新导向最佳的缓存服务器上，由缓存服务器直接响应用户请求。

CDN 网络架构主要由两大部分，分为中心和边缘两部分：

• 中心指 CDN 网管中心和 DNS 重定向解析中心，负责全局负载均衡，设备系统安装在管理中心机房；
• 边缘主要指异地节点，CDN 分发的载体，主要由 Cache 和负载均衡器等组成。

CDN 是一个策略性部署的整体系统，包括分布式存储、负载均衡、内容管理和网络请求的重定向４个要件。

分布式存储

CDN 网络将存储资源分布到各个地理位置、各个网段。存储系统作为 CDN 系统密不可分的一部分，将 CDN 分发的文件和数据库表记录内容存储起来，提供持续服务。存储系统采用三级存储架构，包括核心存储、CDN 服务节点分布式缓存和终端本地缓存。任意一个点的存储崩溃或失效，并不影响系统服务的可用性。

如 CDN 系统在 5 大运营商（中国电信、中国网通、中国铁通、中国移动、中国联通）以及 2 大专有网络（中国教育和科研计算机网、中国科技网）都布有 CDN 节点。这样就消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量。

内容管理

内容管理和全局的网络流量管理(Traffic Management)是 CDN 的核心所在。通过用户就近性和服务器负载的判断，CDN 确保内容以一种极为高效的方式为用户的请求提供服务。总的来说，内容服务基于缓存服务器，也称作**代理缓存(Surrogate)**，它位于网络的边缘，距用户仅有”一跳”(Single Hop)之遥。同时，代理缓存是内容提供商源服务器（通常位于 CDN 服务提供商的数据中心）的一个透明镜像。这样的架构使得 CDN 服务提供商能够代表他们客户，即内容供应商，向最终用户提供尽可能好的体验，而这些用户是不能容忍请求响应时间有任何延迟的。据统计，采用 CDN 技术，能处理整个网站页面的 70%～ 95％的内容访问量，减轻服务器的压力，提升了网站的性能和可扩展性。

负载均衡

CDN 负载均衡系统实现 CDN 的内容路由功能。它的作用是将用户的请求导向整个 CDN 网络中的最佳节点。最佳节点的选定可以根据多种策略，例如距离最近、节点负载最轻等。负载均衡系统是整个 CDN 的核心，负载均衡的准确性和效率直接决定了整个 CDN 的效率和性能。通常负载均衡可以分为两个层次：全局负载均衡（GSLB）和本地负载均衡（SLB）。

网络请求的重定向

当用户访问了使用 CDN 服务的资源时，DNS 域名服务器通过 CNAME 方式将最终域名请求重定向到 CDN 系统中的智能 DNS 负载均衡系统。智能 DNS 负载均衡系统通过一组预先定义好的策略（如内容类型、地理区域、网络负载状况等），将当时能够最快响应用户的节点地址提供给用户，使用户可以得到快速的服务。

同时，它还与分布在不同地点的所有 CDN 节点保持通信，搜集各节点的健康状态，确保不将用户的请求分配到任何一个已经不可用的节点上。

参考：

• CDN-内容推送网络
• 闲话 CDN

CDN 访问流程

1. 用户在浏览器中访问域名，域名解析的请求被发往网站的 DNS 域名解析服务器；
2. 由于网站的 DNS 域名解析服务器对此域名的解析设置了 CNAME，请求被指向 CDN 网络中的智能 DNS 负载均衡系统；
3. 智能 DNS 负载均衡系统对域名进行智能解析，将响应速度最快的节点 IP 返回给用户；浏览器在得到速度最快节点的 IP 地址以后，向 CDN 节点发出访问请求；
4. 由于是第一次访问，CDN 节点将回到源站取用户请求的数据并发给用户；
5. 当有其他用户再次访问同样内容时，CDN 将直接将数据返回给客户，完成请求/服务过程。

同时，它还与分布在不同地点的所有 CDN 节点保持通信，搜集各节点的健康状态，确保不将用户的请求分配到任何一个已经不可用的节点上。

参考：

• CDN-内容推送网络
• 闲话 CDN

推送和拉取

CDN 服务有推送和拉取两种方式：

CDN 推送

当你服务器上内容发生变动时，推送 CDN 接受新内容。直接推送给 CDN 并重写 URL 地址以指向你的内容的 CDN 地址。你可以配置内容到期时间及何时更新。内容只有在更改或新增是才推送，流量最小化，但储存最大化。

优点在于节省源站带宽，提前将要分发的内容放到 CDN 节点上了，当某个流量高峰来临时，不会把你的源站带宽占满（源站还要留点带宽提供动态 HTML 啊）。

缺点是需要针对 CDN 做接口开发，在被分发内容生成时主动上传给 CDN。

CDN 拉取

CDN 拉取是当第一个用户请求该资源时，从服务器上拉取资源。你将内容留在自己的服务器上并重写 URL 指向 CDN 地址。直到内容被缓存在 CDN 上为止，这样请求只会更慢，

存活时间（TTL）决定缓存多久时间。CDN 拉取方式最小化 CDN 上的储存空间，但如果过期文件并在实际更改之前被拉取，则会导致冗余的流量。

高流量站点使用 CDN 拉取效果不错，因为只有最近请求的内容保存在 CDN 中，流量才能更平衡地分散。

优点在于实现简单。

参考：推送式与拉取式 CDN 服务的优劣问题

资源

• 文章
  • Wikipedia - CDN
  • CDN-内容推送网络
  • 闲话 CDN
  • CDN 技术详解
  • 推送式与拉取式 CDN 服务的优劣问题
• CDN 资源
  • https://staticfile.org/
  • https://unpkg.com/
  • https://cdnjs.com/
  • https://github.com/ossrs/srs
  • https://github.com/jsdelivr/jsdelivr

Vscode 快速入门

快捷键

命令面板（Command Palette）

根据您当前的上下文访问所有可用命令。

Mac: cmd+shift+p or f1
Windows / Linux: ctrl+shift+p or f1

快速打开文件（Quick Open）

Mac: cmd+p
Windows / Linux: ctrl+p

Status Bar

Mac: shift+cmd+m
Windows / Linux: ctrl+shift+m

改变语言模式

Mac: cmd+k m
Windows / Linux: ctrl+k m

设置

Mac: cmd+,
Windows / Linux: File > Preferences > Settings or ctrl+,

插件

• Chinese (Simplified) Language Pack for Visual Studio Code
• Prettier - Code formatter
• IntelliJ IDEA Keybindings
• EditorConfig for VS Code
• Git History

更多内容

• 官方
  • https://github.com/Microsoft/vscode
  • https://github.com/Microsoft/vscode-docs
  • https://github.com/Microsoft/vscode-tips-and-tricks
• 更多资源
  • https://github.com/viatsko/awesome-vscode

Maven 教程之 pom.xml 详解

pom.xml 简介

什么是 pom

POM 是 Project Object Model 的缩写，即项目对象模型。

pom.xml 就是 maven 的配置文件，用以描述项目的各种信息。

pom 配置一览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <!-- The Basics -->
  <groupId>...</groupId>
  <artifactId>...</artifactId>
  <version>...</version>
  <packaging>...</packaging>
  <dependencies>...</dependencies>
  <parent>...</parent>
  <dependencyManagement>...</dependencyManagement>
  <modules>...</modules>
  <properties>...</properties>

  <!-- Build Settings -->
  <build>...</build>
  <reporting>...</reporting>

  <!-- More Project Information -->
  <name>...</name>
  <description>...</description>
  <url>...</url>
  <inceptionYear>...</inceptionYear>
  <licenses>...</licenses>
  <organization>...</organization>
  <developers>...</developers>
  <contributors>...</contributors>

  <!-- Environment Settings -->
  <issueManagement>...</issueManagement>
  <ciManagement>...</ciManagement>
  <mailingLists>...</mailingLists>
  <scm>...</scm>
  <prerequisites>...</prerequisites>
  <repositories>...</repositories>
  <pluginRepositories>...</pluginRepositories>
  <distributionManagement>...</distributionManagement>
  <profiles>...</profiles>
</project>

基本配置

• project - project 是 pom.xml 中描述符的根。
• modelVersion - modelVersion 指定 pom.xml 符合哪个版本的描述符。maven 2 和 3 只能为 4.0.0。

一般 jar 包被识别为： groupId:artifactId:version 的形式。

1
2
3
4
5
6
7
8
9
10
11

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.codehaus.mojo</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0</version>
  <packaging>war</packaging>
</project>

maven 坐标

在 maven 中，根据 groupId、artifactId、version 组合成 groupId:artifactId:version 来唯一识别一个 jar 包。

• groupId - 团体、组织的标识符。团体标识的约定是，它以创建这个项目的组织名称的逆向域名(reverse domain name)开头。一般对应着 java 的包结构。
• artifactId - 单独项目的唯一标识符。比如我们的 tomcat、commons 等。不要在 artifactId 中包含点号(.)。
• version - 一个项目的特定版本。
  • maven 有自己的版本规范，一般是如下定义 major version、minor version、incremental version-qualifier ，比如 1.2.3-beta-01。要说明的是，maven 自己判断版本的算法是 major、minor、incremental 部分用数字比较，qualifier 部分用字符串比较，所以要小心 alpha-2 和 alpha-15 的比较关系，最好用 alpha-02 的格式。
  • maven 在版本管理时候可以使用几个特殊的字符串 SNAPSHOT、LATEST、RELEASE。比如 1.0-SNAPSHOT。各个部分的含义和处理逻辑如下说明：
    • SNAPSHOT - 这个版本一般用于开发过程中，表示不稳定的版本。
    • LATEST - 指某个特定构件的最新发布，这个发布可能是一个发布版，也可能是一个 snapshot 版，具体看哪个时间最后。
    • RELEASE ：指最后一个发布版。
• packaging - 项目的类型，描述了项目打包后的输出，默认是 jar。常见的输出类型为：pom, jar, maven-plugin, ejb, war, ear, rar, par。

依赖配置

dependencies

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <dependencies>
    <dependency>
     <groupId>org.apache.maven</groupId>
      <artifactId>maven-embedder</artifactId>
      <version>2.0</version>
      <type>jar</type>
      <scope>test</scope>
      <optional>true</optional>
      <exclusions>
        <exclusion>
          <groupId>org.apache.maven</groupId>
          <artifactId>maven-core</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    ...
  </dependencies>
  ...
</project>

• groupId, artifactId, version - 和基本配置中的 groupId、artifactId、version 意义相同。
• type - 对应 packaging 的类型，如果不使用 type 标签，maven 默认为 jar。
• scope - 此元素指的是任务的类路径（编译和运行时，测试等）以及如何限制依赖关系的传递性。有 5 种可用的限定范围：
  • compile - 如果没有指定 scope 标签，maven 默认为这个范围。编译依赖关系在所有 classpath 中都可用。此外，这些依赖关系被传播到依赖项目。
  • provided - 与 compile 类似，但是表示您希望 jdk 或容器在运行时提供它。它只适用于编译和测试 classpath，不可传递。
  • runtime - 此范围表示编译不需要依赖关系，而是用于执行。它是在运行时和测试 classpath，但不是编译 classpath。
  • test - 此范围表示正常使用应用程序不需要依赖关系，仅适用于测试编译和执行阶段。它不是传递的。
  • system - 此范围与 provided 类似，除了您必须提供明确包含它的 jar。该 artifact 始终可用，并且不是在仓库中查找。
• systemPath - 仅当依赖范围是系统时才使用。否则，如果设置此元素，构建将失败。该路径必须是绝对路径，因此建议使用 propertie 来指定特定的路径，如$ {java.home} / lib。由于假定先前安装了系统范围依赖关系，maven 将不会检查项目的仓库，而是检查库文件是否存在。如果没有，maven 将会失败，并建议您手动下载安装。
• optional - optional 让其他项目知道，当您使用此项目时，您不需要这种依赖性才能正常工作。
• exclusions - 包含一个或多个排除元素，每个排除元素都包含一个表示要排除的依赖关系的 groupId 和 artifactId。与可选项不同，可能或可能不会安装和使用，排除主动从依赖关系树中删除自己。

parent

maven 支持继承功能。子 POM 可以使用 parent 指定父 POM ，然后继承其配置。

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>my-parent</artifactId>
    <version>2.0</version>
    <relativePath>../my-parent</relativePath>
  </parent>

  <artifactId>my-project</artifactId>
</project>

• relativePath - 注意 relativePath 元素。在搜索本地和远程存储库之前，它不是必需的，但可以用作 maven 的指示符，以首先搜索给定该项目父级的路径。

dependencyManagement

dependencyManagement 是表示依赖 jar 包的声明。即你在项目中的 dependencyManagement 下声明了依赖，maven 不会加载该依赖，dependencyManagement 声明可以被子 POM 继承。

dependencyManagement 的一个使用案例是当有父子项目的时候，父项目中可以利用 dependencyManagement 声明子项目中需要用到的依赖 jar 包，之后，当某个或者某几个子项目需要加载该依赖的时候，就可以在子项目中 dependencies 节点只配置 groupId 和 artifactId 就可以完成依赖的引用。

dependencyManagement 主要是为了统一管理依赖包的版本，确保所有子项目使用的版本一致，类似的还有plugins和pluginManagement。

modules

子模块列表。

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.codehaus.mojo</groupId>
  <artifactId>my-parent</artifactId>
  <version>2.0</version>
  <packaging>pom</packaging>

  <modules>
    <module>my-project</module>
    <module>another-project</module>
    <module>third-project/pom-example.xml</module>
  </modules>
</project>

properties

属性列表。定义的属性可以在 pom.xml 文件中任意处使用。使用方式为 ${propertie} 。

1
2
3
4
5
6
7
8
9
10

<project>
  ...
  <properties>
    <maven.compiler.source>1.7<maven.compiler.source>
    <maven.compiler.target>1.7<maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
  </properties>
  ...
</project>

构建配置

build

build 可以分为 “project build” 和 “profile build”。

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <!-- "Project Build" contains more elements than just the BaseBuild set -->
  <build>...</build>

  <profiles>
    <profile>
      <!-- "Profile Build" contains a subset of "Project Build"s elements -->
      <build>...</build>
    </profile>
  </profiles>
</project>

基本构建配置：

1
2
3
4
5
6
7
8
9

<build>
  <defaultGoal>install</defaultGoal>
  <directory>${basedir}/target</directory>
  <finalName>${artifactId}-${version}</finalName>
  <filters>
    <filter>filters/filter1.properties</filter>
  </filters>
  ...
</build>

defaultGoal : 默认执行目标或阶段。如果给出了一个目标，它应该被定义为它在命令行中（如 jar：jar）。如果定义了一个阶段（如安装），也是如此。

directory ：构建时的输出路径。默认为：${basedir}/target 。

finalName ：这是项目的最终构建名称（不包括文件扩展名，例如：my-project-1.0.jar）

filter ：定义 * .properties 文件，其中包含适用于接受其设置的资源的属性列表（如下所述）。换句话说，过滤器文件中定义的“name = value”对在代码中替换$ {name}字符串。

resources

资源的配置。资源文件通常不是代码，不需要编译，而是在项目需要捆绑使用的内容。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <build>
    ...
    <resources>
      <resource>
        <targetPath>META-INF/plexus</targetPath>
        <filtering>false</filtering>
        <directory>${basedir}/src/main/plexus</directory>
        <includes>
          <include>configuration.xml</include>
        </includes>
        <excludes>
          <exclude>**/*.properties</exclude>
        </excludes>
      </resource>
    </resources>
    <testResources>
      ...
    </testResources>
    ...
  </build>
</project>

• resources: 资源元素的列表，每个资源元素描述与此项目关联的文件和何处包含文件。
• targetPath: 指定从构建中放置资源集的目录结构。目标路径默认为基本目录。将要包装在 jar 中的资源的通常指定的目标路径是 META-INF。
• filtering: 值为 true 或 false。表示是否要为此资源启用过滤。请注意，该过滤器 * .properties 文件不必定义为进行过滤 - 资源还可以使用默认情况下在 POM 中定义的属性（例如$ {project.version}），并将其传递到命令行中“-D”标志（例如，“-Dname = value”）或由 properties 元素显式定义。过滤文件覆盖上面。
• directory: 值定义了资源的路径。构建的默认目录是${basedir}/src/main/resources。
• includes: 一组文件匹配模式，指定目录中要包括的文件，使用*作为通配符。
• excludes: 与 includes 类似，指定目录中要排除的文件，使用*作为通配符。注意：如果 include 和 exclude 发生冲突，maven 会以 exclude 作为有效项。
• testResources: testResources 与 resources 功能类似，区别仅在于：testResources 指定的资源仅用于 test 阶段，并且其默认资源目录为：${basedir}/src/test/resources 。

plugins

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <build>
    ...
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>2.6</version>
        <extensions>false</extensions>
        <inherited>true</inherited>
        <configuration>
          <classifier>test</classifier>
        </configuration>
        <dependencies>...</dependencies>
        <executions>...</executions>
      </plugin>
    </plugins>
  </build>
</project>

• groupId, artifactId, version ：和基本配置中的 groupId、artifactId、version 意义相同。

• extensions ：值为 true 或 false。是否加载此插件的扩展名。默认为 false。

• inherited ：值为 true 或 false。这个插件配置是否应该适用于继承自这个插件的 POM。默认值为 true。

• configuration - 这是针对个人插件的配置，这里不扩散讲解。

• dependencies ：这里的 dependencies 是插件本身所需要的依赖。

• executions ：需要记住的是，插件可能有多个目标。每个目标可能有一个单独的配置，甚至可能将插件的目标完全绑定到不同的阶段。执行配置插件的目标的执行。

  • id: 执行目标的标识。
  • goals: 像所有多元化的 POM 元素一样，它包含单个元素的列表。在这种情况下，这个执行块指定的插件目标列表。
  • phase: 这是执行目标列表的阶段。这是一个非常强大的选项，允许将任何目标绑定到构建生命周期中的任何阶段，从而改变 maven 的默认行为。
  • inherited: 像上面的继承元素一样，设置这个 false 会阻止 maven 将这个执行传递给它的子代。此元素仅对父 POM 有意义。
  • configuration: 与上述相同，但将配置限制在此特定目标列表中，而不是插件下的所有目标。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.1</version>
        <executions>
          <execution>
            <id>echodir</id>
            <goals>
              <goal>run</goal>
            </goals>
            <phase>verify</phase>
            <inherited>false</inherited>
            <configuration>
              <tasks>
                <echo>Build Dir: ${project.build.directory}</echo>
              </tasks>
            </configuration>
          </execution>
        </executions>

      </plugin>
    </plugins>
  </build>
</project>

pluginManagement

与 dependencyManagement 很相似，在当前 POM 中仅声明插件，而不是实际引入插件。子 POM 中只配置 groupId 和 artifactId 就可以完成插件的引用，且子 POM 有权重写 pluginManagement 定义。

它的目的在于统一所有子 POM 的插件版本。

directories

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <build>
    <sourceDirectory>${basedir}/src/main/java</sourceDirectory>
    <scriptSourceDirectory>${basedir}/src/main/scripts</scriptSourceDirectory>
    <testSourceDirectory>${basedir}/src/test/java</testSourceDirectory>
    <outputDirectory>${basedir}/target/classes</outputDirectory>
    <testOutputDirectory>${basedir}/target/test-classes</testOutputDirectory>
    ...
  </build>
</project>

目录元素集合存在于 build 元素中，它为整个 POM 设置了各种目录结构。由于它们在配置文件构建中不存在，所以这些不能由配置文件更改。

如果上述目录元素的值设置为绝对路径（扩展属性时），则使用该目录。否则，它是相对于基础构建目录：${basedir}。

extensions

扩展是在此构建中使用的 artifacts 的列表。它们将被包含在运行构建的 classpath 中。它们可以启用对构建过程的扩展（例如为 Wagon 传输机制添加一个 ftp 提供程序），并使活动的插件能够对构建生命周期进行更改。简而言之，扩展是在构建期间激活的 artifacts。扩展不需要实际执行任何操作，也不包含 Mojo。因此，扩展对于指定普通插件接口的多个实现中的一个是非常好的。

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <build>
    ...
    <extensions>
      <extension>
        <groupId>org.apache.maven.wagon</groupId>
        <artifactId>wagon-ftp</artifactId>
        <version>1.0-alpha-3</version>
      </extension>
    </extensions>
    ...
  </build>
</project>

reporting

报告包含特定针对 site 生成阶段的元素。某些 maven 插件可以生成 reporting 元素下配置的报告，例如：生成 javadoc 报告。reporting 与 build 元素配置插件的能力相似。明显的区别在于：在执行块中插件目标的控制不是细粒度的，报表通过配置 reportSet 元素来精细控制。而微妙的区别在于 reporting 元素下的 configuration 元素可以用作 build 下的 configuration ，尽管相反的情况并非如此（ build 下的 configuration 不影响 reporting 元素下的 configuration ）。

另一个区别就是 plugin 下的 outputDirectory 元素。在报告的情况下，默认输出目录为 ${basedir}/target/site。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <reporting>
    <plugins>
      <plugin>
        ...
        <reportSets>
          <reportSet>
            <id>sunlink</id>
            <reports>
              <report>javadoc</report>
            </reports>
            <inherited>true</inherited>
            <configuration>
              <links>
                <link>http://java.sun.com/j2se/1.5.0/docs/api/</link>
              </links>
            </configuration>
          </reportSet>
        </reportSets>
      </plugin>
    </plugins>
  </reporting>
  ...
</project>

项目信息

项目信息相关的这部分标签都不是必要的，也就是说完全可以不填写。

它的作用仅限于描述项目的详细信息。

下面的示例是项目信息相关标签的清单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...

  <!-- 项目信息 begin -->

  <!--项目名-->
  <name>maven-notes</name>

  <!--项目描述-->
  <description>maven 学习笔记</description>

  <!--项目url-->
  <url>https://github.com/dunwu/maven-notes</url>

  <!--项目开发年份-->
  <inceptionYear>2017</inceptionYear>

  <!--开源协议-->
  <licenses>
    <license>
      <name>Apache License, Version 2.0</name>
      <url>https://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
      <comments>A business-friendly OSS license</comments>
    </license>
  </licenses>

  <!--组织信息(如公司、开源组织等)-->
  <organization>
    <name>...</name>
    <url>...</url>
  </organization>

  <!--开发者列表-->
  <developers>
    <developer>
      <id>victor</id>
      <name>Zhang Peng</name>
      <email>forbreak at 163.com</email>
      <url>https://github.com/dunwu</url>
      <organization>...</organization>
      <organizationUrl>...</organizationUrl>
      <roles>
        <role>architect</role>
        <role>developer</role>
      </roles>
      <timezone>+8</timezone>
      <properties>...</properties>
    </developer>
  </developers>

  <!--代码贡献者列表-->
   <contributors>
    <contributor>
      <!--标签内容和<developer>相同-->
    </contributor>
  </contributors>

  <!-- 项目信息 end -->

  ...
</project>

这部分标签都非常简单，基本都能做到顾名思义，且都属于可有可无的标签，所以这里仅简单介绍一下：

• name - 项目完整名称

• description - 项目描述

• url - 一般为项目仓库的 host

• inceptionYear - 开发年份

• licenses - 开源协议

• organization - 项目所属组织信息

• developers - 项目开发者列表

• contributors - 项目贡献者列表，<contributor> 的子标签和 <developer> 的完全相同。

环境配置

issueManagement

这定义了所使用的缺陷跟踪系统（Bugzilla，TestTrack，ClearQuest 等）。虽然没有什么可以阻止插件使用这些信息的东西，但它主要用于生成项目文档。

1
2
3
4
5
6
7
8
9
10
11

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <issueManagement>
    <system>Bugzilla</system>
    <url>http://127.0.0.1/bugzilla/</url>
  </issueManagement>
  ...
</project>

ciManagement

CI 构建系统配置，主要是指定通知机制以及被通知的邮箱。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <ciManagement>
    <system>continuum</system>
    <url>http://127.0.0.1:8080/continuum</url>
    <notifiers>
      <notifier>
        <type>mail</type>
        <sendOnError>true</sendOnError>
        <sendOnFailure>true</sendOnFailure>
        <sendOnSuccess>false</sendOnSuccess>
        <sendOnWarning>false</sendOnWarning>
        <configuration><address>continuum@127.0.0.1</address></configuration>
      </notifier>
    </notifiers>
  </ciManagement>
  ...
</project>

mailingLists

邮件列表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <mailingLists>
    <mailingList>
      <name>User List</name>
      <subscribe>user-subscribe@127.0.0.1</subscribe>
      <unsubscribe>user-unsubscribe@127.0.0.1</unsubscribe>
      <post>user@127.0.0.1</post>
      <archive>http://127.0.0.1/user/</archive>
      <otherArchives>
        <otherArchive>http://base.google.com/base/1/127.0.0.1</otherArchive>
      </otherArchives>
    </mailingList>
  </mailingLists>
  ...
</project>

scm

SCM（软件配置管理，也称为源代码/控制管理或简洁的版本控制）。常见的 scm 有 svn 和 git 。

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <scm>
    <connection>scm:svn:http://127.0.0.1/svn/my-project</connection>
    <developerConnection>scm:svn:https://127.0.0.1/svn/my-project</developerConnection>
    <tag>HEAD</tag>
    <url>http://127.0.0.1/websvn/my-project</url>
  </scm>
  ...
</project>

prerequisites

POM 执行的预设条件。

1
2
3
4
5
6
7
8
9
10

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <prerequisites>
    <maven>2.0.6</maven>
  </prerequisites>
  ...
</project>

repositories

repositories 是遵循 Maven 存储库目录布局的 artifacts 集合。默认的 Maven 中央存储库位于https://repo.maven.apache.org/maven2/上。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <repositories>
    <repository>
      <releases>
        <enabled>false</enabled>
        <updatePolicy>always</updatePolicy>
        <checksumPolicy>warn</checksumPolicy>
      </releases>
      <snapshots>
        <enabled>true</enabled>
        <updatePolicy>never</updatePolicy>
        <checksumPolicy>fail</checksumPolicy>
      </snapshots>
      <id>codehausSnapshots</id>
      <name>Codehaus Snapshots</name>
      <url>http://snapshots.maven.codehaus.org/maven2</url>
      <layout>default</layout>
    </repository>
  </repositories>
  <pluginRepositories>
    ...
  </pluginRepositories>
  ...
</project>

pluginRepositories

与 repositories 差不多。

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <distributionManagement>
    ...
    <downloadUrl>http://mojo.codehaus.org/my-project</downloadUrl>
    <status>deployed</status>
  </distributionManagement>
  ...
</project>

distributionManagement

它管理在整个构建过程中生成的 artifact 和支持文件的分布。从最后的元素开始：

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <distributionManagement>
    ...
    <downloadUrl>http://mojo.codehaus.org/my-project</downloadUrl>
    <status>deployed</status>
  </distributionManagement>
  ...
</project>

• repository - 与 repositories 相似

• site - 站点信息

• relocation - 项目迁移位置

profiles

activation 是一个 profile 的关键。配置文件的功能来自于在某些情况下仅修改基本 POM 的功能。这些情况通过 activation 元素指定。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <profiles>
    <profile>
      <id>test</id>
      <activation>
        <activeByDefault>false</activeByDefault>
        <jdk>1.5</jdk>
        <os>
          <name>Windows XP</name>
          <family>Windows</family>
          <arch>x86</arch>
          <version>5.1.2600</version>
        </os>
        <property>
          <name>sparrow-type</name>
          <value>African</value>
        </property>
        <file>
          <exists>${basedir}/file2.properties</exists>
          <missing>${basedir}/file1.properties</missing>
        </file>
      </activation>
      ...
    </profile>
  </profiles>
</project>

参考资料

• maven 官方文档之 pom

Maven 教程之 settings.xml 详解

settings.xml 简介

settings.xml 有什么用

从 settings.xml 的文件名就可以看出，它是用来设置 maven 参数的配置文件。settings.xml 中包含类似本地仓储位置、修改远程仓储服务器、认证信息等配置。

• settings.xml 是 maven 的全局配置文件。
• pom.xml 文件是本地项目配置文件。

settings.xml 文件位置

settings.xml 文件一般存在于两个位置：

• 全局配置 - ${maven.home}/conf/settings.xml
• 用户配置 - ${user.home}/.m2/settings.xml

🔔 注意：用户配置优先于全局配置。${user.home} 和和所有其他系统属性只能在 3.0+版本上使用。请注意 windows 和 Linux 使用变量的区别。

配置优先级

重要：局部配置优先于全局配置。

配置优先级从高到低：pom.xml > user settings > global settings

如果这些文件同时存在，在应用配置时，会合并它们的内容，如果有重复的配置，优先级高的配置会覆盖优先级低的。

settings.xml 元素详解

顶级元素概览

下面列举了settings.xml中的顶级元素

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

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                          https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <localRepository/>
  <interactiveMode/>
  <usePluginRegistry/>
  <offline/>
  <pluginGroups/>
  <servers/>
  <mirrors/>
  <proxies/>
  <profiles/>
  <activeProfiles/>
</settings>

LocalRepository

作用：该值表示构建系统本地仓库的路径。

其默认值：~/.m2/repository。

1

<localRepository>${user.home}/.m2/repository</localRepository>

InteractiveMode

作用：表示 maven 是否需要和用户交互以获得输入。

如果 maven 需要和用户交互以获得输入，则设置成 true，反之则应为 false。默认为 true。

1

<interactiveMode>true</interactiveMode>

UsePluginRegistry

作用：maven 是否需要使用 plugin-registry.xml 文件来管理插件版本。

如果需要让 maven 使用文件~/.m2/plugin-registry.xml 来管理插件版本，则设为 true。默认为 false。

1

<usePluginRegistry>false</usePluginRegistry>

Offline

作用：表示 maven 是否需要在离线模式下运行。

如果构建系统需要在离线模式下运行，则为 true，默认为 false。

当由于网络设置原因或者安全因素，构建服务器不能连接远程仓库的时候，该配置就十分有用。

1

<offline>false</offline>

PluginGroups

作用：当插件的组织 id（groupId）没有显式提供时，供搜寻插件组织 Id（groupId）的列表。

该元素包含一个 pluginGroup 元素列表，每个子元素包含了一个组织 Id（groupId）。

当我们使用某个插件，并且没有在命令行为其提供组织 Id（groupId）的时候，Maven 就会使用该列表。默认情况下该列表包含了 org.apache.maven.plugins 和 org.codehaus.mojo。

1
2
3
4
5
6
7
8
9
10

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      https://maven.apache.org/xsd/settings-1.0.0.xsd">
  ...
  <pluginGroups>
    <!--plugin的组织Id（groupId） -->
    <pluginGroup>org.codehaus.mojo</pluginGroup>
  </pluginGroups>
  ...
</settings>

Servers

作用：一般，仓库的下载和部署是在 pom.xml 文件中的 repositories 和 distributionManagement 元素中定义的。然而，一般类似用户名、密码（有些仓库访问是需要安全认证的）等信息不应该在 pom.xml 文件中配置，这些信息可以配置在 settings.xml 中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      https://maven.apache.org/xsd/settings-1.0.0.xsd">
  ...
  <!--配置服务端的一些设置。一些设置如安全证书不应该和pom.xml一起分发。这种类型的信息应该存在于构建服务器上的settings.xml文件中。 -->
  <servers>
    <!--服务器元素包含配置服务器时需要的信息 -->
    <server>
      <!--这是server的id（注意不是用户登陆的id），该id与distributionManagement中repository元素的id相匹配。 -->
      <id>server001</id>
      <!--鉴权用户名。鉴权用户名和鉴权密码表示服务器认证所需要的登录名和密码。 -->
      <username>my_login</username>
      <!--鉴权密码 。鉴权用户名和鉴权密码表示服务器认证所需要的登录名和密码。密码加密功能已被添加到2.1.0 +。详情请访问密码加密页面 -->
      <password>my_password</password>
      <!--鉴权时使用的私钥位置。和前两个元素类似，私钥位置和私钥密码指定了一个私钥的路径（默认是${user.home}/.ssh/id_dsa）以及如果需要的话，一个密语。将来passphrase和password元素可能会被提取到外部，但目前它们必须在settings.xml文件以纯文本的形式声明。 -->
      <privateKey>${usr.home}/.ssh/id_dsa</privateKey>
      <!--鉴权时使用的私钥密码。 -->
      <passphrase>some_passphrase</passphrase>
      <!--文件被创建时的权限。如果在部署的时候会创建一个仓库文件或者目录，这时候就可以使用权限（permission）。这两个元素合法的值是一个三位数字，其对应了unix文件系统的权限，如664，或者775。 -->
      <filePermissions>664</filePermissions>
      <!--目录被创建时的权限。 -->
      <directoryPermissions>775</directoryPermissions>
    </server>
  </servers>
  ...
</settings>

Mirrors

作用：为仓库列表配置的下载镜像列表。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      https://maven.apache.org/xsd/settings-1.0.0.xsd">
  ...
  <mirrors>
    <!-- 给定仓库的下载镜像。 -->
    <mirror>
      <!-- 该镜像的唯一标识符。id用来区分不同的mirror元素。 -->
      <id>planetmirror.com</id>
      <!-- 镜像名称 -->
      <name>PlanetMirror Australia</name>
      <!-- 该镜像的URL。构建系统会优先考虑使用该URL，而非使用默认的服务器URL。 -->
      <url>http://downloads.planetmirror.com/pub/maven2</url>
      <!-- 被镜像的服务器的id。例如，如果我们要设置了一个Maven中央仓库（http://repo.maven.apache.org/maven2/）的镜像，就需要将该元素设置成central。这必须和中央仓库的id central完全一致。 -->
      <mirrorOf>central</mirrorOf>
    </mirror>
  </mirrors>
  ...
</settings>

Proxies

作用：用来配置不同的代理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      https://maven.apache.org/xsd/settings-1.0.0.xsd">
  ...
  <proxies>
    <!--代理元素包含配置代理时需要的信息 -->
    <proxy>
      <!--代理的唯一定义符，用来区分不同的代理元素。 -->
      <id>myproxy</id>
      <!--该代理是否是激活的那个。true则激活代理。当我们声明了一组代理，而某个时候只需要激活一个代理的时候，该元素就可以派上用处。 -->
      <active>true</active>
      <!--代理的协议。 协议://主机名:端口，分隔成离散的元素以方便配置。 -->
      <protocol>http</protocol>
      <!--代理的主机名。协议://主机名:端口，分隔成离散的元素以方便配置。 -->
      <host>proxy.somewhere.com</host>
      <!--代理的端口。协议://主机名:端口，分隔成离散的元素以方便配置。 -->
      <port>8080</port>
      <!--代理的用户名，用户名和密码表示代理服务器认证的登录名和密码。 -->
      <username>proxyuser</username>
      <!--代理的密码，用户名和密码表示代理服务器认证的登录名和密码。 -->
      <password>somepassword</password>
      <!--不该被代理的主机名列表。该列表的分隔符由代理服务器指定；例子中使用了竖线分隔符，使用逗号分隔也很常见。 -->
      <nonProxyHosts>*.google.com|ibiblio.org</nonProxyHosts>
    </proxy>
  </proxies>
  ...
</settings>

Profiles

作用：根据环境参数来调整构建配置的列表。

settings.xml 中的 profile 元素是 pom.xml 中 profile 元素的裁剪版本。

它包含了id、activation、repositories、pluginRepositories 和 properties 元素。这里的 profile 元素只包含这五个子元素是因为这里只关心构建系统这个整体（这正是 settings.xml 文件的角色定位），而非单独的项目对象模型设置。如果一个 settings.xml 中的 profile 被激活，它的值会覆盖任何其它定义在 pom.xml 中带有相同 id 的 profile。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20