最近在用 Golang 语言实现一个短链接服务Tiny-URL，这期间了解了一些关于短链接服务的设计思路，以及分布式系统中 ID 生成、缓存、限流、负载均衡等方面的知识，这篇文章将会对短链接服务的设计思路进行总结。

概述

在社交媒体、用户增长、广告投放等场景中，经常会遇到长链接转短链接的需求，提高用户点击率更高，同时能规避原始链接中一些关键词、域名屏蔽等。常见微博、微信等社交软件中，比如微博限制字数为140，如果包含的链接过长，会占用很多字数，所以需要将长链接转换为短链接，以节省字数。

短链接除了具有美观清爽的特性外，利用短链每次跳转都需要经过后端的特性，可以在跳转过程中做异步埋点，用于效果数据统计，常见的应用场景如下：

• 注册、收藏、加购、下单、支付效果统计；
• 用户分享效果追踪；
• 减少字符占用。

本文将会介绍短链接服务的设计思路，以及在实现过程中遇到的问题与解决方案。

需求与预算评估

功能需求

• 短链接生成：给定一个长链接，能够生成一个唯一的短链接，即使多次输入同一个长链接，也能够得到唯一的短链接；
• 短链接重定向：通过短链接能够访问到原始的长链接，通过 302 临时重定向的方式，将用户重定向到原始的长链接，临时重定向的方式可以保证搜索引擎不会抓取短链接，而是抓取原始的长链接，并且便于统计短链接的访问次数。
• 访问限流：对短链接的生成与访问进行限流，防止恶意刷短链接，保证服务的稳定性。
• 短链接删除：短链接可以删除，删除之后，短链接将失效，无法再访问到原始的长链接。
• 过期时间：短链接可以设置过期时间，过期时间到了之后，短链接将失效，无法再访问到原始的长链接。

非功能需求

• 高可用：短链接服务需要保证高可用，即使某个节点宕机，也不影响整个服务的正常使用。
• 高性能：短链接服务需要保证高性能，能够支撑每秒十万 QPS 的访问量。
• 低延迟：短链接服务需要保证低延迟，用户访问短链接时，能够快速的重定向到原始的长链接。
• 高可扩展性：短链接服务需要保证高可扩展性，能够支持大量的短链接生成和访问。
• 高可靠性：短链接服务需要保证高可靠性，能够保证短链接的生成和访问的正确性。

资源预算

1. 假设我们的系统每天有 100M 用户在线，即 1亿日活；
2. 每天平均每10个用户写 1 个帖子，为每个帖子生成一个对应的短链接，即每天总共生成 10M 个短链接：
   • 平均每个短链接-长链接映射关系占用 500Bytes 空间，即每天总共需要 5GB 的存储空间；
   • 每日 10,000,000 次写入操作，1kw/86400s ≈ 116，即平均每秒需要处理 116qps 的写入操作；
   • 假设峰值写入量约平均写入量的 10 倍，即 1160qps，为便于估算，可理解写峰值 qps 为 1k；
3. 平均每个用户每天访问 10 个帖子，即每天总共访问 10亿次短链接，读写比例为 100:1：
   • 平均每秒需要处理 11600 的读取操作，即约为 10k/s；
   • 假设峰值读取量约平均读取量的 10 倍，即约为 100k/s；
4. 缓存资源预算：
   • 由于短链服务具有明显的热点数据特征，因此需要使用缓存来提高访问性能，我们假设 20% 的数据贡献了 99% 的访问量
   • 每日 10亿次的访问量中，我们假设 99% 的访问量是固定在 10% 的热点数据上，即需要缓存 2亿条数据，缓存服务器需要 100GB 内存空间；
   • 再进一步，我们利用本地缓存来缓存最热的 1% 的数据，即需要缓存 2M 条数据，每台 Server 节点需要 1GB 内存空间用于本地缓存；
   • 缓存命中率为 99%，即每日 10亿次的访问量中，有 1% 的访问量需要访问数据库，即 10M 次/日，即每秒需要处理 116 次数据库读取操作，即约为 100qps；

综上所述：

1. 数据库存储空间：每日消耗 5GB 磁盘，三年时间需要约 5.5TB；
2. 数据库读写请求数：平均每秒 116qps 的写入操作与读取操作，峰值 1k/qps 的写入操作与读取操作；
3. 缓存服务器内存空间：总共需要 50GB 内存空间，缓存约 1亿条数据；
4. 本地缓存存储空间：每台 Server 节点需要 500MB 内存空间用于本地缓存，缓存约 1M 条数据；

时序流程

短链接服务的写数据时序流程如下：

1. 用户发起创建短链接请求，服务端接收到请求，将会生成一个唯一的短链接，并尝试将短链接-长链接映射关系写入数据库中；
2. 数据存储端需要保证短链接-长链接映射关系的一致性，即使多次为同一个长链接生成短链接，也能保证生成的短链接是唯一的，因此可以在数据库中为 original URL 设置唯一索引；
3. 当插入的长链接已经存在时，可以直接返回已经存在的短链接，无需再次生成短链接；
4. 当插入的长链接不存在时，需要生成一个唯一的短链接，可以使用分布式 ID 生成器生成唯一的短链接 ID，然后将短链接 ID 转换为 Base58 编码，即可生成短链接；
5. 长链接写入数据库成功后，服务端将短链接-长链接映射关系写入分布式缓存与本地缓存中，以提高访问性能；

短链接服务的读数据时序流程如下：

1. 用户访问短链接时，服务端接收到请求，将会有限从本地缓存中获取短链接-长链接映射关系，如果本地缓存中不存在，则从分布式缓存中获取，如果分布式缓存中不存在，则从数据库中获取；
2. 如果本地缓存不存在，分布式缓存中存在，则将接映射关系写入本地缓存中，以提高访问性能；如果缓存中不存在，数据库中存在，则将映射关系写入缓存中；
3. 如果数据库中也不存在，则返回 404 错误，表示短链接不存在，同时可以设置黑名单，对恶意访问进行限制；
4. 如果获取短链接成功，通过 302 临时重定向的方式，将用户重定向到原始的长链接；
5. 访问短链接成功后，可以统计短链接的访问次数，以便后续分析短链接的访问情况；

模块设计

短链接服务涉及 分布书 ID 生成器、数据库存储、缓存系统、访问限流等模块，下面将会对这些模块进行详细设计。

分布式 ID 生成器

短链接发号器需要保证生成的短链接是唯一的，可以使用分布式 ID 生成器，如 Twitter 的 Snowflake 算法，或者使用数据库自增 ID 生成器等等，下面将描述不同方案的优缺点：

数据库自增 ID

数据库的主键是唯一且自增的，可以保证生成的 ID 是唯一的。将数据库自增 ID 作为短链接 ID，然后将 UID 转换为 Base58 编码，即可生成短链接。

优点：简单易用，生成的 ID 是唯一的； 缺点：依赖于数据库，数据库的性能将成为瓶颈，不适合高并发场景，如果采用数据库集群，需要避免 ID 重复；并且数据库自增 ID 是有序的，可能会暴露业务规模；

Redis 自增序列

Redis 的自增序列可以使用 INCR 命令，每次调用 INCR 命令，Redis 会将自增序列加 1，并返回自增后的值。因此可以将 Redis 的自增序列作为短链接 ID，然后将 UID 转换为 Base58 编码，即可生成短链接。

优点：高性能，生成的 ID 是唯一的； 缺点：Redis 是基于内存的，如果 Redis 宕机，可能会导致 ID 重复，需要保证 Redis 的高可用；ID 自增是有序的，可能会暴露业务规模；

UUID

UUID 是由一组 16 个字节（128 位）组成的标识符，可以用于唯一标识信息。UUID 的生成方式有多种，其中最为常用的是基于算法的 UUID 生成方式和基于硬件的 UUID 生成方式。 基于时间戳的 UUID 生成方式，可以保证生成的 UUID 是唯一的，并且是有序的，但是如果多台机器的时钟存在差异，或时钟回拨或闰秒，可能会导致 ID 重复。基于硬件的 UUID 生成方式，可以保证生成的 UUID 是唯一的，且随机性更强。但是 UUID 是 128 位的，转换为 Base58 编码后，短链接长度过长，不适合短链接服务；且 UUID 是无序的，插入数据时可能会导致数据库的性能问题；

优点：生成的 ID 是唯一的，不依赖于数据库； 缺点：UUID 是 128 位的，转换为 Base58 编码后，短链接长度过长，不适合短链接服务；且 UUID 是无序的，插入数据时可能会导致数据库的性能问题；

Snowflake 算法

雪花算法（Snowflake）是 Twitter 开源的分布式 ID 生成算法，可以生成 64 位的唯一 ID，结构如下：

• 1 位符号位，始终为 0；
• 41 位时间戳，精确到毫秒级，可以使用 69 年；
• 10 位机器 ID，可以部署 1024 台机器；
• 12 位序列号，每毫秒可以生成 4096 个 ID。

Snowflake 算法生成的 ID 是有序的，可以保证 ID 的唯一性，但是需要依赖于时钟，时钟回拨会导致 ID 重复，需要保证时钟的稳定性。同时，Snowflake 算法存在较大的序列号浪费问题，因为每毫秒只能生成 4096 个 ID，即使不使用完，也会浪费掉。

优点：高性能，高可用，生成的 ID 是唯一的； 缺点：需要依赖于时钟，时钟回拨或闰秒调整会导致 ID 重复，需要保证时钟的稳定性；存在较大的序列号浪费。

目前也出现了一些基于雪花算法的改进版本，其中时间戳不依赖于系统时钟，而是使用逻辑时钟，服务启动后，每次生成 ID 时，都会从逻辑时钟中获取时间戳，这样可以避免时钟回拨导致 ID 重复的问题，但仍然无法避免较大的序列号浪费问题。

TDDL 序列

TDDL 序列是指在数据库中创建一个序列表，用于存储序列的当前值，然后通过数据库的 CAS 原子操作来获取下一个序列区间，然后在内存中递增序列值，当序列值用尽时，再次获取下一个序列区间。

• 优点：生成的 ID 是唯一的，避免了数据库自增 ID 的性能瓶颈；同时减小了序列号浪费；
• 缺点：具有一定的维护成本；

表结构

综上所述，我们可以选择 TDDL 序列算法作为短链接发号器，保证生成的短链接是唯一的，同时 TDDL 序列算法也便于根据 short ID 进行分库分表，适合高并发场景。

可以选择关系型数据库、NoSQL 数据库等维护 TDDL 的序列表，Tiny-URL 首要支持 MySQL 等关系型数据库，未来考虑支持 MongoDB 等 NoSQL 数据库。

MySQL 数据库表结构可参考 sequences.sql。

数据库存储

短链接服务需要存储短链接-长链接映射关系，可以使用关系型数据库、NoSQL 数据库等存储短链接-长链接映射关系，下面将介绍使用 MySQL 数据库存储短链接-长链接映射关系的设计。

tiny_urls 表的几个关键字段：

• id：数据库自增 ID，作为主键，保证新插入的 record 是顺序写入的；
• long_url：原始的长链接，作为唯一索引，保证长链接是唯一的；
• short：短链接 ID，作为唯一索引，保证短链接是唯一的；
• deleted_at：删除时间，用于标记短链接是否删除；

对应表结构如下：

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

create table tiny_urls
(
  id         bigint unsigned auto_increment
    primary key,
  created_at datetime(3)  null,
  updated_at datetime(3)  null,
  deleted_at datetime(3)  null,
  long_url   varchar(500) not null,
  short      bigint       not null,
  constraint idx_tiny_urls_long_url
    unique (long_url),
  constraint idx_tiny_urls_short
    unique (short)
);

create index idx_tiny_urls_deleted_at
  on tiny_urls (deleted_at);

在表结构中，我们对长链接与短链接分别建立了唯一索引，保证了长链接与短链接的唯一性。但我们并没有将 short ID 作为主键，因为 short ID 具有一定的离散性，将其作为主键会影响写入性能。

分布式缓存

短链接服务具有明显的热点数据特征，因此需要使用缓存来提高访问性能，我们可以使用 Redis、Memcached 等缓存服务器，将热点数据缓存到缓存服务器中，以提高访问性能。

分布式缓存需要考虑缓存的一致性、缓存的命中率、缓存的淘汰策略、缓存的预热、缓存的雪崩、缓存的击穿等问题。

• 缓存命中率：缓存命中率是衡量缓存性能的重要指标，可以通过缓存命中率来评估缓存的有效性，缓存命中率越高，说明缓存的有效性越好，缓存的性能越高。
• 缓存淘汰策略：缓存淘汰策略是指当缓存空间不足时，如何选择淘汰哪些缓存数据，常见的缓存淘汰策略有：FIFO（先进先出）、LRU（最近最少使用）、LFU（最少使用频率）等。
• 缓存预热：缓存预热是指在系统启动时，将热点数据加载到缓存中，以提高系统的访问性能，缓存预热可以通过定时任务、异步加载等方式来实现。
• 缓存雪崩：缓存雪崩是指缓存中的大量数据同时失效，导致大量请求直接访问数据库，从而导致数据库的性能问题，为了避免缓存雪崩，可以采用多级缓存、缓存预热、缓存失效时间随机等方式来避免。
• 缓存击穿：缓存击穿是指缓存中的某个数据失效，导致大量请求直接访问数据库，从而导致数据库的性能问题，为了避免缓存击穿，可以采用分布式锁、热点数据永不过期等方式来避免。

Tiny URL 使用 Redis 作为缓存服务器，将热点数据缓存到 Redis 中，以提高访问性能。同时将淘汰策略设置为volatile-lfu，根据短链接的访问频率来淘汰缓存数据，以提高缓存的命中率。 缓存更新与访问流程如下：

1. 用户发起创建短链接请求，服务端在数据库中成功插入短链接-长链接映射关系；
2. 服务端将短链接-长链接映射关系写入 Redis 缓存中，假设配置的过期时间为 t，服务端会生成 [t,2t] 时间内的随机值，作为缓存的过期时间；
3. 用户访问短链接时，服务端会先从 Redis 缓存中获取短链接-长链接映射关系，如果缓存中不存在，则从数据库中获取，并写入 Redis 缓存中，同时更新缓存的过期时间；

本地缓存

单机 Redis 能够支持 3W～4W QPS 的访问量，同时我们也可以使用 Redis Proxy 来负载均衡，以支撑更大的缓存容量和访问量。当如果某个热点 key 的访问量过大，可能会导致 Redis 的性能问题，此时可以使用本地缓存来缓存热点数据，以提高访问性能。

本地缓存可以使用 bigcache、freecache 等内存缓存库，将热点数据缓存到本地内存中，以提高访问性能。本地缓存的更新与访问流程如下：

1. 用户访问短链接时，服务端会先从本地缓存中获取短链接-长链接映射关系，如果本地缓存中不存在，则从 Redis 缓存中获取，如果 Redis 缓存中不存在，则从数据库中获取；
2. 如果本地缓存中不存在，Redis 缓存或数据库中存在，则更新本地缓存，并设置缓存的过期时间；

本地缓存能够解决热点 Key 问题，单机支撑上万 QPS 的访问量，同时也可以使用本地缓存来缓存最热的 1% 的数据，以降低访问延迟。

本地缓存与分布式缓存作为一个独立的模块，可以定义统一的Cache接口，然后实现RedisCache、LocalCache、混合缓存器等多种具体实现，在不同的场景下选择更合适的缓存器。

1
2
3
4
5
6
7
8
9

// Interface cache interface
type Interface interface {
	// Set the key value to cache
	Set(ctx context.Context, k string, v []byte, ttl time.Duration) error
	// Get the key value from cache
	Get(ctx context.Context, k string) ([]byte, error)
	// Close the cache
	Close() error
}

访问限流

短链接服务需要对短链接的生成与访问进行限流，防止恶意刷短链接，保证服务的稳定性。可以使用令牌桶算法、漏桶算法等限流算法，对短链接的生成与访问进行限流。

令牌桶算法是一种固定容量的令牌桶，按照固定速率往桶中放入令牌，如果桶中令牌已满，则不再放入令牌，当请求到来时，如果桶中有令牌，则允许通过，否则拒绝请求。令牌桶算法能够对单位时间内的请求进行限流，保证服务的稳定性，同时又可以平滑处理突发流量，保证服务的稳定性。

Tiny-URL 采用了 Redis 分布式令牌桶与单机令牌桶两种实现，对短链接的生成与访问进行全局限流，如果 Redis 故障，则会回退到单机令牌桶限流。

限流器的实现通过定义统一的RateLimiter接口，然后实现RedisRateLimiter、LocalRateLimiter、混合限流器等多种具体实现，在不同的场景下选择更合适的限流器。

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

// RateLimiter is an interface that knows how to limit the rate at which something is processed
// It provides methods to decide how long an item should wait, to stop tracking an item, and to get the number of failures an item has had.
type RateLimiter[T comparable] interface {
	// Take gets an item and gets to decide whether it should run now or not,
	// use this method if you intend to drop / skip events that exceed the rate.
	Take(ctx context.Context, item T) bool
	// When gets an item and gets to decide how long that item should wait,
	// use this method if you wish to wait and slow down in accordance with the rate limit without dropping events.
	When(ctx context.Context, item T) time.Duration
	// Forget indicates that an item is finished being retried. Doesn't matter whether it's for failing
	// or for success, we'll stop tracking it
	Forget(ctx context.Context, item T)
	// Retries returns back how many failures the item has had
	Retries(ctx context.Context, item T) int
}

小结

本章节介绍了 Tiny URL 主要模块的设计思路与技术选型，包括分布式 ID 生成器、数据库存储、缓存系统、访问限流等模块，以及实现这些模块的接口定义与实现。在编码过程中，我们要尽可能将模块的能力抽象出来，定义统一的接口，然后提供多种具体的实现，以便在不同的场景下选择更合适的实现。

部署方案

Tiny URL 服务依赖 MySQL8 与 Redis 作为存储与缓存，Tiny URL 服务本身是无状态的，可以通过 Docker 镜像部署到 Kubernetes 集群中，以提高服务的可用性与可扩展性。

Tiny URL 服务支持读写分离模式，可以将读请求与写请求分发到不同的服务节点，以提高服务的性能。默认情况下，Server 会以读写模式运行，添加启动参数--readonly可以将 Server 设置为只读模式。

快速体验

在 Git Repo 中提供了 docker compose all in one 方案，确保本地已经安装了 Docker 与 Docker Compose，然后执行以下命令：

1

make deploy

终端输出turl service containers start successfully后，说明服务已经启动成功。 该模式会部署 MySQL 与 Redis 服务，作为本地存储与缓存服务器。同时会启动两个服务节点，一个用于读写操作，另一个用于只读操作。

• 读写服务：http://localhost:8080，用于生成短链接、更新远程缓存、更新数据库等；
• 只读服务：http://localhost:80，只用于访问短链接，不支持生成短链接，生产环境中可以部署多个只读服务节点，用于分流读取请求。

生成短链接

1

curl -X POST http://localhost:8080/api/shorten -H 'Content-Type: application/json' -d '{"long_url": "https://google.com"}'

返回结果：

1

{"short_url":"http://localhost/24rgcX","long_url":"https://google.com","created_at":"2024-07-08T15:06:26.434Z","deleted_at":null,"error":""}

访问短链接

访问短链接 http://localhost/24rgcX，将会被重定向到原始的长链接 https://google.com。

1

curl -L http://localhost/24rgcX

性能测试

上面一小节介绍了如果通过 Docker Compose 部署 Tiny URL 服务，下面将对 Tiny URL 服务进行性能测试，以验证服务的性能表现。

服务器：Apple MacBook Pro 14 M1Pro 2021, 16G Memory 512G SSD

测试数据：获取全球访问量前 10k 的域名，每个域名添加 10 个 API 后缀，共计 100k 条无重复数据。使用 100 个协程并发请求，统计写入耗时。

写入性能测试代码可参考：api_benchmark_test

测试结果如下：

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

Benchmark_Create
api_benchmark_test.go:93: send requests: 4550
api_benchmark_test.go:93: send requests: 10040
api_benchmark_test.go:93: send requests: 15422
api_benchmark_test.go:93: send requests: 20977
api_benchmark_test.go:93: send requests: 26532
api_benchmark_test.go:93: send requests: 32452
api_benchmark_test.go:93: send requests: 38095
api_benchmark_test.go:93: send requests: 42921
api_benchmark_test.go:93: send requests: 47579
api_benchmark_test.go:93: send requests: 52629
api_benchmark_test.go:93: send requests: 58464
api_benchmark_test.go:93: send requests: 63961
api_benchmark_test.go:93: send requests: 69651
api_benchmark_test.go:93: send requests: 75325
api_benchmark_test.go:93: send requests: 80952
api_benchmark_test.go:93: send requests: 87016
api_benchmark_test.go:93: send requests: 92535
api_benchmark_test.go:93: send requests: 98344
api_benchmark_test.go:111: success requests:  100000 costs 18.365219458s

读取性能测试的情况比较复杂，涉及到分布式缓存命中率、本地缓存命中率、数据库读取性能等多个因素，因此需要综合实际应用场景，才能得出准确的性能测试结果。

下面是使用wrk 针对单个短链接的 API 性能测试，即所有流量都命中本地缓存的情况下，测试结果如下：

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

 wrk -t4 -c100 -d30s --latency http://localhost/24rgcY
Running 30s test @ http://localhost/24rgcY
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.12ms    1.75ms  63.13ms   98.39%
    Req/Sec    12.18k     1.27k   15.10k    70.17%
  Latency Distribution
     50%    1.96ms
     75%    2.36ms
     90%    2.78ms
     99%    4.56ms
  1454811 requests in 30.01s, 260.83MB read
Requests/sec:  48481.30
Transfer/sec:      8.69MB

综合来看，API 的性能表现良好，理想条件下写操作能够达到 5000+ QPS。在单一测试场景下（命中本地缓存），极限读取性能能够达到 50000 QPS，p99 延迟在 5ms 内。

总结

本文介绍了短链接服务的设计思路与实现，包括需求与预算评估、时序流程、模块设计、部署方案、性能测试等内容。短链接服务是一个典型的高并发、低延迟、高可用的服务，需要考虑到短链接的生成与访问的性能、可用性、可扩展性等方面的问题，以保证服务的稳定性与可靠性。

短链接服务可以足够简单，最核心的接口只有两个：生成短链接与访问短链接，但是在实现过程中，有足够复杂，需要考虑到短链接的生成与访问的性能、可用性、可扩展性等方面的问题，涉及到数据库、缓存、限流、分布式 ID 生成器等多个模块，需要综合考虑这些模块的设计与实现。

Zookeeper 是最常用的分布式协调服务之一，用于配置管理、分布式锁、服务注册与发现等。笔者在使用 Zookeeper 的过程中，也意识到了 Zookeeper 局限性，本文将对这些痛点问题进行总结与分析，并提出一些可行的解决方案。

概述

Zookeeper 是大名鼎鼎的谷歌分布式锁服务 Chubby 的开源实现，它提供了一种分布式系统数据一致性的解决方案，通过类 Paxos 算法（ZAB 协议）保证数据的一致性与服务的高可用，同时也提供了一些高级特性：比如 Watcher 机制、ACL 权限控制等。Zookeeper 的出现大大简化了分布式系统的开发，但是由于初期的系统设计缺陷，也积累了一些问题，本文将对这些局限性进行总结与分析，并与后起之秀分布式 KV 存储系统 ETCD 进行对比，分析他们在设计思想上的差异。

本文建立在对分布式共识算法、Zookeeper/ETCD 的基本原理有一定了解的基础上，如果对这些概念不熟悉，建议先阅读相关资料。漫谈分布式共识算法与数据一致性、分布式键值存储 etcd 原理与实现

存储性能

Zookeeper 是一个分布式 KV 存储系统，内部实现了一个内存数据库ZKDatabase，其中有两个核心数据结构，一个是以基数树为逻辑数据模型的纯内存的存储引擎DataTree，另一个是基于文件系统的持久化存储模块snapLog。这两部分组成了 Zookeeper 的 KV 数据库ZKDatabase，并保证服务重启后数据不会丢失。

1
2
3
4

public class ZKDatabase {
    protected DataTree dataTree;
    protected FileTxnSnapLog snapLog;
    ...

DataTree

Zookeeper 对外暴露的数据模型是一个基于路径的树形结构，类似于文件系统的目录结构，在 Zookeeper 实现了一个内存数据库DataTree，每个路径节点都是一个 ZNode，我们可以向 DataTree 中添加、删除、更新 ZNode，同时也可以在 ZNode 上注册 Watcher。

ZNode 由五部分组成：path、data、stat、acl、children，其中path是以/开始的全路径，剩余的四部分都存储在一个独立的DataNode数据结构中：data是 ZNode 的数据，stat是 ZNode 的元数据如版本号、数据长度等，acl是 ZNode 的权限控制，children是 ZNode 的子节点集合，同时DataNode也包含了一些辅助方法，比如getChildren、getData、setData等，用于操作 ZNode 的数据。

DataTree 的所有path都被保存在一个哈希表中，path到DataNode的映射关系是一一对应，因此我们可以通过path在 O(1) 时间复杂度内找到对应的DataNode，这样就能够保证数据的快速查询。

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

public class DataTree {
    private final NodeHashMap nodes; // 路径到 ZNode 的映射
    private IWatchManager dataWatches; // 路径 Watcher 管理
    private IWatchManager childWatches; // 子节点 Watcher 管理器
    ...
}

public class DataNode implements Record {
    byte[] data; // ZNode 数据
    public StatPersisted stat; // ZNode 元数据
    Long acl; // ZNode 权限控制
    private Set<String> children = null; // ZNode 子节点集合
    ...
}

DataTree 本质上是一个巨大的哈希表，虽然单次查询非常快，但是 Zookeeper 需要使用哈希表来维护基数树的路径关系，在创建、删除 ZNode 时，需要多次查询哈希表，增加写操作的延迟，降低写入性能。同时，Zookeeper 的内存管理是基于 JVM 的，JVM 的 GC 机制会导致一些停顿，同样会影响读写性能。

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

// 代码逻辑有删减
public void createNode(final String path, byte data[], List<ACL> acl, long ephemeralOwner, int parentCVersion, long zxid, long time, Stat outputStat) {
    String parentName = path.substring(0, lastSlash);
    DataNode parent = nodes.get(parentName);
  
   synchronized (parent) {
        Set<String> children = parent.getChildren();
        if (children.contains(childName)) {
            throw new NodeExistsException();
        }
       // 更新 父节点的版本
        if (parentCVersion > parent.stat.getCversion()) {
            parent.stat.setCversion(parentCVersion);
            parent.stat.setPzxid(zxid);
        }
       // ..
   }
   // ..
}

SnapLog

SnapLog 是 Zookeeper 的持久化存储模块，用于将 Zookeeper 的内存数据备份到磁盘上。SnapLog 由两部分组成：事务日志（Transaction Log）和快照文件（Snapshot File）。事务日志用于记录所有的数据变更操作，快照文件会定期全量备份 DataTree 中的所有数据。当 Server 启动时，会先加载最近日期的快照文件，然后逐个加载事务日志文件，最终恢复到最新的状态。

1
2
3
4
5
6
7

public class FileTxnSnapLog {
    private final File dataDir; // 事务日志文件目录
    private final File snapDir; // 快照文件目录
    private TxnLog txnLog; // 事务日志管理器
    private SnapShot snapLog; // 快照管理器
    ...
}

客户端的每次写入操作都会同步到磁盘，这会增加写操作的延迟，因此事务日志的写入性能直接决定 Zookeeper Server 对请求的响应速度，为了增加写入性能，Zookeeper 采用磁盘预分配的策略，在事务日志文件创建之初就向操作系统预分配一个很大的磁盘块，默认是64M，而一旦已分配的文件剩余空间不足 4KB 时，那么将会再次进行预分配

性能瓶颈

相信各位读者看到这里，已经对 Zookeeper 的存储机制有熟悉的感觉了，可以将ZKDatabase看作是一个简化版本的 Redis 实现，只支持基数树这种 KV 数据结构，同样也使用 WAL 日志和快照文件来保证数据的持久化。Zookeeper 的数据存储是基于内存的，所有的数据都存储在内存中，虽然能够保证数据的快速查询，但是也会带来一些问题：

1. 内存空间：Zookeeper 的所有数据都存储在内存中，包括 DataNode、Key Path、Watcher 等，内存上限就是 Zookeeper Server 的数据存储上限，因此 Zookeeper 只能存储 GB 级别的数；另一方面过多的数据量也会增加 GC 的压力，降低哈希表查询的性能，都会请求响应速度；
2. 持久化：Zookeeper 的持久化机制是基于文件系统的，每次写入操作都会同步操作日志到磁盘，同样会增加写入操作的延迟，降低写入性能；

综上所述，内存空间是 Zookeeper 的死穴，内存决定了 Zookeeper 的数据存储上限，而磁盘 I/O 决定了 Zookeeper 的写入延迟与响应速度，使得 Zookeeper 只能支持几 GB 级别的数据存储，这是 Zookeeper 最大的局限性，也是 Zookeeper 在大规模集群中的瓶颈。

ETCD 存储实现

做为对比，我们再来看看 ETCD 的存储模块实现思路。ETCD 内部实现了一个基于 MVCC（多版本并发控制）的存储引擎，ETCD 的数据存储是基于磁盘的，所有的数据都存储在磁盘中，ETCD 的数据存储突破了内存的上限，因此 ETCD 能够存储几十甚至上百 GB 级别的数据。

ETCD 的 MVCC 模块实现了状态机存储功能，其底层使用的是开源的嵌入式键值存储数据库 BoltDB，但是这个项目已经由作者归档不再维护了，因此 ETCD 社区自己维护了一个 bbolt 版本。

为了实现多版本并发控制，ETCD 会将键值对的每个版本都保存到 BoltDB 中，ETCD 在 BoltDB 中存储的 Key 是修订版本reversion，Value 是客户端发送的键值对组合。为了更好地理解这一概念，假设我们通过读写事务接口写入了两个键值对，分别是(key1, value1)和(key2, value2)，之后我们再调用读写事务接口更新这两个键值对，更新后为(key1, update1)和(key2, update2)，虽然两次写操作更新的是两个键值对，实际上在 BoltDB 中写入了四条记录：

1
2
3
4

rev={1 0}, key=key1, value="valuel" 
rev={1 1}, key=key2, value="value2" 
rev={2 0}, key=key1, value="updatel"
rev={2 1}, key=key2, value="update2"

其中，reversion 主要由两部分组成， 第一部分是 main reversion，每次事务递增一；第二部分是 sub reversion，同一个事务的每次操作都会递增一，两者结合就可以保证 Key 唯一且递增。在上面的示例中，第一个事务的 main reversion 是 1，第二个事务的 main reversion 是 2。

从 MVCC 模块保存的数据格式我们可以看出，如果要从 BoltDB 中查询键值对，必须通过reversion进行查找。但客户端只知道具体键值对中的 Key 值，并不清楚每个键值对对应的 reversion 信息。

为了将客户端提供的原始键值对信息与reversion关联起来，ETCD 使用谷歌开源实现的 btree 数据结构维护 Key 与reversion之间的映射关系，BTree 的键部分存储了原始的 Key，值部分存储了一个 keyIndex 实例。一个 keyIndex 实例维护着某个 Key 全部历史修订版本信息。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// etcd/mvcc/backend/backend.go
type keyIndex struct {
    key []byte        // 客户端提供的原始 Key 值
    modified revision // 该 Key 值最后一次修改时对应的 revision 信息
    generations []generation
}

type revision struct {
    main int64
    sub int64
}

由此可见，ETCD 的存储实现是基于磁盘的，存储数据不会被限制在内存大小，同时也能够保证数据的持久化。另一方面，ETCD 核心团队对 BoltDB 的读写性能做了众多优化：Fully concurrent reads design proposal、Performance optimization of etcd in web scale data scenario 等，尽可能避免读写事务之间互相阻塞。虽然 ETCD 需要大量的内存来维护索引与数据缓存，当与 Zookeeper 相比，ETCD 能够支撑上百 GB 级别的数据存储，并且能够保证请求的响应速度。

危险的全局 Session

在 Zookeeper 中，Session 是个非常重要的概念，客户端与 Server 之间的任何交互都是通过 Session 来完成的，包含临时节点的生命周期、Watcher 通知、客户端与 Server 之间的心跳等。Zookeeper 的 Session 是一个全局的概念，每个客户端首先会与服务器建立一个 TCP Socket 连接，从连接建立开始，客户端会话的生命周期也开始了，并为该 Session 分配一个全局唯一的SessionId，标识客户端的身份。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向 Zookeeper Server 发送请求并接受响应，同时还能够通过该连接接收来自服务器的 Watch 事件通知。

实现原理

Session 通过心跳检测来保持有效，如果客户端在一定时间内没有向服务器发送心跳检测，那么服务器会认为客户端已经失效，Session 也会被关闭。如果 Session 超时，Zookeeper 服务器会将 Session 关联的所有临时节点删除。Session 设计在一定程度上简化了开发，能够在客户端故障时自动释放资源，在分布式锁、服务注册与发现等场景中也能够发挥作用，但是全局 Session 也带来了一些问题。

每个客户端实例同一时刻只能有一个 Session，这意味着如果一个客户端实例同时创建了多个临时节点，那么这些临时节点的生命周期是一致的。如果我们想要显式地删除某个临时节点，那么我们只能通过delete操作来删除，而不能通过关闭 Session 来让 ZNode 失效，这样操作会带来额外的复杂性：

• 增加 Client 实现的复杂度：由于 Session 是全局的，因此我们需要在客户端实现中维护 Session 的生命周期，确保 Session 超时后能够去激活所有的 Watcher，并在 Session 超时后重新创建 Session，这样会增加客户端实现的复杂性，也会增加客户端出现问题的概率；

• 异常处理：如果我们的客户端实例在删除临时节点时发生了异常，那么这个临时节点可能会一直存在，直到 Session 超时。因此我们在编写业务逻辑代码时，需要特别小心，确保我们的代码在发生异常时，能够处理异常并重试，保证临时节点能够被正确删除；

  1 2 3 4 5 6 7 8 9 10

  func deleteNode(client *zk.Conn, path string) error { for { err := client.Delete(path, -1) if err != nil { if errors.Is(err, zk.ErrNoNode) { return nil } } return nil }

• 重复创建：如果我们的客户端实例在执行create临时节点操作后，该临时节点在 Zookeeper 集群上创建成功，但是客户端没有及时接收到创建成功的响应，或是响应丢失，那么这个临时节点可能会一直存在，直到 Session 超时。例如在实现分布式锁时，我们需要为每个服务实例创建一个临时有序节点，如果某个实例第一次创建临时节点/service/lock-100成功，但是没有及时接收到创建成功的响应，那么它可能会再次创建一个临时节点/service/lock-102，这样就会导致同一个服务实例同时持有两个分布式锁节点，导致死锁：

  1 2 3

  # znode: /service/lock-100 session: node-1 # znode: /service/lock-101 session: node-2 # znode: /service/lock-102 session: node-1

  如上所示，node-1 同时持有/service/lock-100和/service/lock-102两个分布式锁节点，同时 node-2 持有/service/lock-101分布式锁节点，node-1 会认为自己持有/service/lock-102分布式锁节点，等待 node-2 释放/service/lock-101分布式锁节点，而 node-2 也在等待释放/service/lock-100节点，这样就会导致死锁，所有的实例都抢占到分布式锁而无法继续执行。

  由于 node-1 的所有临时节点的生命周期是一致的，上述问题只能在 node-1 的 Session 超时或主动关闭 Client 后才能解决，因此我们在编写业务逻辑代码时，需要针对这种情况进行处理：node-1 在创建临时节点后，如果没有及时接收到创建成功的响应，那么它需要检查自己是否已经创建了临时节点，遍历/service目录下的所有临时节点，检查是否有存在临时节点的 SessionID 与当前客户端一致，如果存在，则复用这个临时节点，否则创建新的临时节点；

上述问题是笔者在使用 Zookeeper 时踩到过的坑，虽然可以通过一些手段来规避——增加大量的重试代码与边界条件处理代码，但是这些方式会增加客户端与业务逻辑的复杂度，另一方面，在系统初期实现时，如果对 Zookeeper 的 Session 机制不够熟悉，我们很容易忽略这些问题，导致系统出现 BUG。

ETCD 设计思想

为了规避上述问题，在 ETCD 的设计中，采用了更加灵活的 Session 概念，客户端与服务端连接建立后，不需要绑定一个特定的 Session，每个客户端实例可以创建并持有多个 Session，每个 Session 可以关联一个或多个临时节点，单个 Session 的失效只会影响与其关联的临时节，避免了全局 Session 带来的安全性问题。

1
2
3
4
5
6
7

func NewLock(client clientv3.Client, lockKey string, ttl int) (concurrency.Mutex, error) {
    session, err := concurrency.NewSession(client, concurrency.WithTTL(ttl))
    if err != nil {
        rerurn nil, error
    }
    rerurn concurrency.NewMutex(session, lockKey), nil
}

在上面的示例代码中，我们可以看到，每次创建分布式锁时，我们都会创建一个新的 Session，并将其绑定到 key 上，单个 Session 的生命周期与绑定到这个 Session 的所有 key 的生命周期是一致的，当我们创建分布式锁失败时，无论错误原因是是什么，我们只需要确保 Session 被关闭，或停止续租，当 TTL 超时后绑定到这个 Session 的所有 key 都会被删除，最终临时 key 都会被清理。

不可靠的 Watcher

Zookeeper 的 Watcher 机制是 Zookeeper 提供的一种事件通知机制，当我们在某个 ZNode 上注册了 Watcher 时，如果这个 ZNode 发生了变化，Zookeeper 服务器会通知客户端，客户端可以通过 Watcher 机制来实现一些高级特性，比如分布式锁、配置管理等。

实现原理

WatchManager是 Zookeeper Watcher 机制的核心组件，它负责管理所有的 Watcher，其内部维护了两个哈希表：watchTable 和 watch2Paths，watchTable 是一个从 ZNode 到 Watcher 的映射表，watch2Paths 是一个从 Watcher 到 ZNode 的映射表，其内部实现如下：

1
2
3
4
5
6
7

public class WatchManager {
    private final HashMap<String, HashSet<Watcher>> watchTable =
        new HashMap<String, HashSet<Watcher>>();

    private final HashMap<Watcher, HashSet<String>> watch2Paths =
        new HashMap<Watcher, HashSet<String>>();
}

Watcher 机制的实现是通过在 ZNode 上注册 Watcher，当 ZNode 发生变化时，通过watchTable找到所有注册在这个 ZNode 上的 Watcher，然后通知这些 Watcher。Zookeeper Server 会将 Watcher 事件通知发送给客户端，从而实现 Watch 事件通知机制。但 Zookeeper 的 Watcher 机制存在一些问题。

Watcher 机制是一次性的，当 ZNode 发生变化时，Zookeeper Server 会调用WatchManager.triggerWatch方法触发数据变更事件，同时将这些 Watcher 从watchTable中删除，这意味着每个 Watcher 只能接收到一次通知，如果我们想要继续监听 ZNode 的变化，那么我们需要重新注册 Watcher。

1
2
3
4
5
6

public void process(WatchedEvent event) {
    if (event.getType() == Event.EventType.NodeDataChanged) {
        // 重新注册 Watcher
        zk.getData("/service/lock", this, null);
    }
}

并且 Watcher 与客户端的 Session 绑定，当 Session 超时或关闭时，所有的 Watcher 都会失效，客户端需要重新注册 Watcher，在重新建立连接前，任何 ZNode 的变化都不会通知客户端。那么我们在接收到通知后，或出现网络故障，都需要重新注册 Watcher，如果我们在重新注册 Watcher 之前，ZNode 发生了变化，那么我们就会错过这次变化，从而导致客户端观测到的数据变化过程少于真实的数据变化过程，因此 Zookeeper 的 Watcher 机制只能保证最终一致性，而不能保证线性一致性。

综上所述，Zookeeper 的 Watcher 机制是一次性的，且与 Session 绑定，当 Session 超时或关闭时，所有的 Watcher 都会失效，在重新建立连接前，任何 ZNode 数据变化事件都会丢失，无法保证 Watcher 事件通知的可靠性，因此 Watcher 机制只能保证最终一致性，而不能保证线性一致性或顺序一致性。

ETCD 实现思路

ETCD 也在 Watcher 机制上做了一些改进，ETCD 的 Watcher 机制是持久性的，当客户端收到通知后，Watcher 不会被删除，而是会一直保持有效，直到客户端主动删除 Watcher。ETCD Watcher 也与客户端的连接状态无关，即使客户端断开连接，Watcher 仍然有效，当客户端重新连接后，仍然可以接收到在断开期间发生的所有事件。具体来说，ETCD 的 Watcher 事件不会丢失的原理如下：

1. 当客户端注册 Watcher 后，ETCD Server 会创建watcher实例并加入到 boltdb 存储的 Watchers 集合中管理，同时将watcher绑定到 Key 上，当 Key 的值发生变化时，ETCD 服务器会将这个变化事件发送给所有注册在该 Key 上的 Watcher。

2. ETCD 的 Watcher 机制依赖于其多版本并发控制（MVCC）机制，实现了历史事件的持久化存储，如果客户端故障，Server 会将数据变更事件按照 FIFO 顺序持久化在存储引擎中，等待客户端恢复；

3. ETCD Watcher 能够在异常场景重试，并对历史事件进行重放：当客户端重新连接后，ETCD 服务器会将在断开期间发生的所有历史事件重新发送给客户端，确保客户端不会错过任何事件。

由此可见，ETCD 的 Watcher 机制是持久性的，且与客户端的连接状态无关，当客户端发生故障时，ETCD 服务器会保存这个事件，等待客户端重新连接后按照 FIFO 顺序重新发送，这样就能够保证 Watcher 事件通知的可靠性与有序性。ETCD 的 Watcher 机制具有更高的一致性级别，能够保证顺序一致性。

总结

本文总结了 Zookeeper 的存储性能、全局 Session、Watcher 机制等局限性，针对这些问题给出了一些可行的规避方案，并与新兴的 ETCD 实现原理进行了对比。

ZooKeeper 的出现填补了分布式协调组件的空白，在经历了多年的业务发展与技术迭代后，ZooKeeper 暴露了许多问题，难以支撑更大规模的集群。ETCD 是一个新兴的分布式 KV 存储系统，相较于 Zookeeper，ETCD 的存储性能更好，支持上百 GB 级别的数据存储；ETCD Watcher 机制更加灵活，支持持久性 Watcher，能够保证 Watcher 事件通知的可靠性与有序性。

在笔者看来，ETCD 与 ZooKeeper 并非是孰优孰劣的关系，ETCD 能够覆盖 Zookeeper 的应用场景，并且对 Zookeeper 暴露的许多问题进行了改进，是 ZooKeeper 的上位替代品，社区内的许多中间件也在考虑剥离对 Zookeeper 的依赖，替换为 Raft 实现或其它分布式协调服务：Kafka Needs No Keeper - Removing ZooKeeper Dependency (confluent.io)、Moving Toward a ZooKeeper-Less Apache Pulsar (streamnative.io)。在新的分布式系统设计中，我们可以考虑使用 ETCD 来替代 Zookeeper，提高系统的性能与可靠性。

本文是 Golang 程序编码指南，主要介绍 Golang 程序的编码风格、项目结构、开发工具链等，从而快速了解 Golang 程序的开发规范，提高代码质量。希望通过这篇文章，能够帮助大家快速地上手 Golang 程序的开发，减少后期维护成本。

概述

Golang 是一门非常优秀的编程语言，它的设计目标是提高程序员的生产力，因此 Golang 语言的设计非常注重简洁、高效、易用。经过数十年的发展，Golang 社区已经积累了大量的最佳实践，也形成了一些比较成熟的编码风格和项目结构规范。在构建多人协作的大型应用时，遵循这些规范可以提高代码的可读性、可维护性，减少代码的重构成本。

本文将从项目结构、代码质量、自动化工具与 CI/CD、项目拆分与重构、编程模式等多个方面介绍 Golang 编程规范与实用技巧，这些内容是我在实际项目中总结的经验，希望能够帮助大家构建可持续维护的 Golang 应用。

项目结构

Golang 项目的结构对于项目的可维护性和可读性非常重要，一个好的项目结构可以让团队成员快速地定位到模块的位置，了解模块的功能和用法。Golang 社区中的优秀的项目结构大致可以分为两种：一种是以构建 SDK、开发框架为主的平铺式项目结构，另一种是以构建一个或多个二进制文件为主的标准 Go 项目结构。这两种项目结构都有各自的适用场景，需要根据实际的项目需求来选择。

平铺式项目结构

平铺式项目结构适用于构建 SDK、开发框架等需要提供给其他开发者使用的项目，这种项目结构的特点是将所有的代码放在一个目录下，方便其他开发者快速地了解框架的功能和用法。由于在 Go 语言中一个目录就是一个 Namespace，采用平铺式结构的项目，可以将框架的所有功能都放在同一个命名空间下，其他开发者只需要通过 import 一个包路径就可以使用框架的所有功能。

1
2
3
4
5
6
7
8

.
├── LICENSE
├── README.md
├── go.mod
├── go.sum
├── gin.go
├── context.go
├── xxx.go

平铺式项目结构的优点是简单、易用，适合于小型项目，但是当项目规模变大时，这种项目结构会导致代码文件过多，不利于代码的维护和管理，所以一些复杂的开发框架会将不同的子模块放在不同的目录下，以便于更好地组织代码。例如 go-pretty 将不同的子模块具有独立的依赖路径，并且可能存在依赖关系：

1
2
3
4
5

.
├── list/
├── progress/
├── table/
├── text

常见的平铺式项目结构案例有：

• Web 开发框架 Gin；
• 数据库 ORM 引擎 Gorm；
• 社区为 Golang 开发人员提供的 API SDK 或 Client，例如 Consul API SDK、Redis GO Client 等。

标准 Go 项目结构

Standard Go Project Layout 是 Golang 社区常见的项目布局模式，虽然它不是 Go 核心开发团队定义的官方标准，但已经被 Golang 社区广泛采用。

标准项目结构的优点是清晰、通用，每个目录都有特定的作用，适用于大型项目。如果开发者都遵循这种项目结构，可以帮助团队成员快速地定位到模块的位置，了解模块的功能和用法。

标准项目结构详细介绍了其组织结构和每个目录的作用，感兴趣的读者可以点击链接查看，本小节仅阐述一些常用的目录：

1
2
3
4
5
6
7
8
9

.
├── api
├── build
├── cmd
├── docs
├── internal
├── pkg
├── third_party
├── tools

api

api目录用于存放 OpenAPI 或者 gRPC Proto 的定义文件，这些文件可以用于生成客户端代码、服务端代码、Swagger 文档等。通过 api 目录，能够清晰地了解项目的接口定义，方便其他开发者快速地了解项目的 API 功能和用法。

某些项目会将 api 目录作为对外的 SDK 或者 Client 的封装，例如 Consul API SDK，这也符合 api 目录的作用。

build

build目录用于存放构建 shell 脚本、Dockerfile、CI 等配置文件，这些文件可以用于自动化构建、测试、部署。将构建相关的文件放在 build 目录下，可以避免将构建脚本和业务代码混在一起，使得项目的结构更加简洁清晰。

cmd

cmd目录是 Golang 项目的入口目录，用于存放项目的main.go文件。通常一个 Golang 项目需要构建出多个二进制可执行文件，由于每一个二进制文件的入口函数都需要一个独立的 main Package，我们可以将每个入口文件放在子目录下，例如cmd/server/main.go、cmd/cli/main.go等。

cmd 目录不应该包含业务逻辑，只包含 main 函数的入口文件，代码行数也应该尽量少，只包含一些简单的初始化逻辑。业务逻辑应该放在 internal 或 pkg 目录下，由 main 函数调用。

docs

docs目录用于存放项目的文档，包括设计文档、API 文档、使用手册等。通过 docs 目录，能够清晰地了解项目的设计思路、接口定义、使用方法等。

internal

internal是一个特殊的目录，它是 Golang 1.4 Release Notes 版本引入的一个新特性，用于限制包的可见性。

Go 语言鼓励模块化和封装，将代码组织成 Package 的形式，提高代码的可读性和复用性。但在某些场景下，我们希望某些 Package 只能在当前模块中使用，而不希望被其他模块引用。这种情况下，就可以使用 internal 目录来限制包的可见性：internal 目录下的代码只能被当前项目的其他 Package 引用，当其他项目引用当前项目时，internal 目录下的代码是不可见的。

我们可以将项目的私有代码，例如项目的内部核心逻辑、不希望被其他项目引用的客户端代码等，放在 internal 目录下，但外部模块引用该项目时，也无法访问内部的逻辑，并且减少了不必要的依赖。

pkg

pkg目录用于存放项目的通用 Package，pkg 目录下的模块应该具有良好的封装和抽象，以便于业务代码复用。pkg 目录下的模块可以被其他项目引用，但是某些模块可能只是当前项目的内部实现细节，不希望被其他项目引用，这种情况下，可以将模块放在 internal 目录。

third_party

third_party目录用于存放第三方 repo 的依赖，例如 swagger、依赖的 submodules、fork 的 repo 等。当项目需要独自维护第三方代码时，可以将第三方代码放在 third_party 目录下，以便于管理和维护。

tools

tools目录是 golang 项目的独有目录，用于约定项目的内/外部工具链，可以是/pkg或/internal目录下的内部工具，也可以 import 外部工具。

如下代码所示，我们利用tools/tools.go文件来约定项目的外部工具链，通过匿名导入的方式，将工具链的版本锁定在go.mod文件中。每次初始化开发环境时，只需要执行go generate -tags tools tools/tools.go命令，就可以自动安装工具链。

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

//go:build tools

//go:generate go install github.com/swaggo/swag/cmd/swag
//go:generate go install github.com/fatih/gomodifytags
//go:generate go install go.uber.org/mock/mockgen
import (
	_ "github.com/swaggo/swag/cmd/swag"

	_ "github.com/fatih/gomodifytags"

	_ "go.uber.org/mock/mockgen"
)

代码质量

Golang 语言的设计目标是提高程序员的生产力，因此 Golang 语言的设计非常注重简洁、高效、易用。Golang 社区已经形成了一些比较成熟的编码风格，在构建多人协作的大型应用时，遵循这些规范可以提高代码的可读性、可维护性，减少代码的编写与维护成本。

编码规范与代码格式化

做为有技术追求的软件工程师，我们应该在条件允许的情况下，遵循 Golang 社区的编码规范，保持代码的一致性，Uber Go Style Guide 是 Golang 社区比较成熟的编码格式，它提供了一些比较成熟的编码技巧，例如代码规范、性能优化技巧、编程范式等。感兴趣的读者可以阅读上述链接内容，以助于我们编写出更加优雅的 Golang 代码。

Go 语言天然注重代码的格式化，它内置了gofmt、goimports等工具，可以帮助我们自动格式化代码，保持代码的一致性。在笔者看来，代码格式化是 Golang 语言的一大特色，它可以让开发者专注于业务的逻辑，而不用花费时间在争论代码的格式上。

笔者倾向于使用 golangci-lint 进行代码格式化，它是一个集成了多种代码检查工具的运行器，可以帮助开发者自动格式化代码、检查命名规范、控制圈复杂度、并发安全检查等。使用 golangci-lint 可以帮助我们保持代码风格的一致性，减少 easy issue 的发生概率。通常情况下，笔者会开启所有的默认检查规则，并补充额外的检查规则，下面是我个人常用的 golangci-lint 配置文件，可以在此基础上根据自己的需求进行修改：

  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
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198

# 检测基本配置
run:
  # The default concurrency value is the number of available CPU.
  concurrency: 8
  # Timeout for analysis, e.g. 30s, 5m.
  # Default: 1m
  timeout: 5m
  tests: false
  # Which dirs to skip: issues from them won't be reported.
  skip-dirs:
    - test
    - third_party
  # Which files to skip: they will be analyzed, but issues from them won't be reported.
  skip-files:
    - _test.go
    - _mock.go
    - ".*\\.pb\\.go"
    - ".*\\.gen\\.go"
linters:
  disable-all: true
  enable: # please keep this alphabetized
    # Don't use soon to deprecated[1] linters that lead to false
    # https://github.com/golangci/golangci-lint/issues/1841
    - bodyclose
    - dogsled
    - dupl
    - errcheck
    - exportloopref
    - exhaustive
    - goconst
    - gocritic
    - gofmt
    # - gomnd
    - gocyclo
    # - gosec
    - gosimple
    - govet
    - ineffassign
    - misspell
    - nolintlint
    - nakedret
    - prealloc
    - predeclared
    - revive
    - staticcheck
    - stylecheck
    - thelper
    - tparallel
    - unconvert
    - unparam
    - whitespace
    - wsl
    # - unused

linters-settings: # please keep this alphabetized
  revive:
    ignore-generated-header: true
    severity: error
    confidence: 0.8
    errorCode: 2
    warningCode: 0
    rules:
      - name: atomic
        severity: warning
      - name: package-comments
      - name: unhandled-error
        arguments : ["fmt.Printf"]
      - name: blank-imports
      - name: context-as-argument
      - name: context-keys-type
      - name: dot-imports
      - name: error-return
      - name: error-strings
      - name: error-naming
      - name: exported
        severity: warning
        arguments:
          - disableStutteringCheck
      - name: if-return
      - name: increment-decrement
      - name: var-naming
      - name: var-declaration
      - name: package-comments
      - name: range
      - name: receiver-naming
      - name: time-naming
      - name: unexported-return
      - name: indent-error-flow
      - name: errorf
      - name: argument-limit
        arguments:
          - 6
      - name: function-result-limit
        arguments:
          - 3
      - name: empty-block
      - name: confusing-naming
      - name: superfluous-else
      #      - name: unused-parameter
      - name: unreachable-code
      - name: unnecessary-stmt
      - name: struct-tag
      - name: atomic
      - name: empty-lines
      - name: duplicated-imports
      - name: import-shadowing
      - name: confusing-results
      - name: modifies-parameter
      - name: redefines-builtin-id

  staticcheck:
    checks:
      - "all"
      - "-SA1019" # TODO(fix) Using a deprecated function, variable, constant or field
  stylecheck:
    checks:
      - "ST1019"  # Importing the same package multiple times.

  lll:
    line-length: 120
  gocyclo:
    # Minimal code complexity to report.
    # Default: 30 (but we recommend 10)
    min-complexity: 8

issues:
  # List of regexps of issue texts to exclude.
  include:
    - EXC0012  # EXC0012 revive: exported (.+) should have comment( \(or a comment on this block\))? or be unexported
    - EXC0013  # EXC0013 revive: package comment should be of the form "(.+)...
    - EXC0014  # EXC0014 revive: comment on exported (.+) should be of the form "(.+)..."
    - EXC0015  # EXC0015 revive: should have a package comment
  # Excluding configuration per-path, per-linter, per-text and per-source
  exclude-rules:
    # Exclude some `typecheck` messages.
    - linters:
        - typecheck
      text: "undeclared name:"
    - linters:
        - revive
      text: "var-naming: don't use an underscore in package name"
    # Exclude `lll` issues for long lines with `go:generate`.
    - linters:
        - lll
      source: "^//go:generate "
  # Fix found issues (if it's supported by the linter).
  fix: true
# output configuration options
output:
  # Format: colored-line-number|line-number|json|tab|checkstyle|code-climate|junit-xml|github-actions
  #
  # Multiple can be specified by separating them by comma, output can be provided
  # for each of them by separating format name and path by colon symbol.
  # Output path can be either `stdout`, `stderr` or path to the file to write to.
  # Example: "checkstyle:report.json,colored-line-number"
  #
  # Default: colored-line-number
  format: colored-line-number,github-actions
  # Print lines of code with issue.
  # Default: true
  print-issued-lines: false
  # Print linter name in the end of issue text.
  # Default: true
  print-linter-name: true
  # Make issues output unique by line.
  # Default: true
  uniq-by-line: true
  # Add a prefix to the output file references.
  # Default is no prefix.
  path-prefix: ""
  # Sort results by: filepath, line and column.
  sort-results: true

severity:
  # Set the default severity for issues.
  #
  # If severity rules are defined and the issues do not match or no severity is provided to the rule
  # this will be the default severity applied.
  # Severities should match the supported severity names of the selected out format.
  # - Code climate: https://docs.codeclimate.com/docs/issues#issue-severity
  # - Checkstyle: https://checkstyle.sourceforge.io/property_types.html#SeverityLevel
  # - GitHub: https://help.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-error-message
  #
  # Default value is an empty string.
  default-severity: error
  # If set to true `severity-rules` regular expressions become case-sensitive.
  # Default: false
  case-sensitive: true
  # When a list of severity rules are provided, severity information will be added to lint issues.
  # Severity rules have the same filtering capability as exclude rules
  # except you are allowed to specify one matcher per severity rule.
  # Only affects out formats that support setting severity information.
  #
  # Default: []
  rules:
    - linters:
        - revive
      severity: error

显式声明

Golang 团队对显式声明非常看重，他们认为显式声明可以提高代码的可读性，减少代码的歧义。在 Golang 语言中，显式声明主要体现在以下几个方面：

• 变量声明时需要显式指定类型；
• 函数声明时需要显式指定参数和返回值的类型；
• 结构体声明时需要显式指定字段的类型。
• 接口声明时需要显式指定接口的方法。
• …

可以看到，Golang 语言中的显式声明非常严格，一些 Java 工程师可能会觉得 Golang 的显式声明过于繁琐，倾向于使用依赖注入、反射等技术来减少代码的重复。依赖注入通常在运行时解析依赖关系，因此可能会导致运行时错误，例如，如果一个依赖项没有被正确地注入，那么在运行时可能会出现空指针错误。过度使用依赖注入还会导致过度抽象，在 debug 代码分析时需要 trace 大量的依赖关系，才能找到真正的被注入对象，使得代码更难理解和维护。

笔者不会在 Golang 项目中使用依赖注入，而是遵循 Golang 团队的显式声明原则，尽量减少代码的歧义。在编写代码时，我们应该尽量避免使用隐式声明：

1
2
3
4
5
6
7
8

func NewUserServer() *UserServer {
    return &UserServer{}
}

func main()  {
    server := NewUserServer()
    ...
}

Go 语言中另一个常见的隐式声明是init函数，它会在包被引用时自动执行，用于初始化包的状态。下面的示例代码是经典的init函数错误使用案例，它在 package 被引用时自动执行，用于初始化包的状态，创建数据库连接对象，并将连接对象分配给了一个全局变量。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

var DB *sql.DB

func init() {
    db, err := sql.Open("mysql",os.Getenv("dataSource"))
    if err != nil {
        panic(err)
    }

    DB = db
}

init函数会增加程序的不确定性，由于init函数是没有参数和返回值的，因此在示例中，需要通过环境变量来获取数据库连接的配置信息，这样就使得init函数的行为不可预料，如果环境变量设置错误，那么init函数无法处理连接建立失败的情况，只能粗暴地调用panic函数来终止程序执行。

init函数还会降低代码的文档性，初次使用包时，开发者可能并不知道这里执行了一个init函数，也不知道init函数有哪些隐形的环境变量依赖或配置，也无从得知这个init函数的执行结果。因此它的执行结果是不可预料的，可能会导致一些难以预料的问题。在编写init函数时需要特别小心，避免在init函数中执行一些复杂的逻辑，尽量保持init函数的简单和干净。

上述代码中的init函数带来的另一个不确定性是将数据库连接对象分配给了全局变量DB，我们可能会在程序中的任何地方更改DB变量的值，这就使得DB变量的生命周期不可控，也不利于单元测试的编写。

这并不意味着init函数是一个坏东西，它在某些场景下是非常有用的，例如在database/sql包中，init函数用于自动注册数据库驱动，这样在程序中就可以通过sql.Open函数来创建数据库连接对象。

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

package db

import (
	"database/sql"

	_ "github.com/go-sql-driver/mysql"
)

func New(dsn string) (*sql.DB, error) {
	db, err := sql.Open("mysql", dsn)
	if err != nil {
		return nil, err
	}

	if err := db.Ping(); err != nil {
		return nil, err
	}

	return db, nil
}

在日常编码中，笔者也会注意避免使用隐式声明与隐式依赖，提高代码的可读性与 debug 的可追踪性。

错误处理

Go 的错误处理也遵循了显式声明的原则，不同于 Python 或 Java 等语言的 Try-Catch 机制，Go 语言中的错误处理是通过显式声明错误来实现的，我们可以在任何地方返回错误，并在错误发生时及时处理。

Go error 设计的也具有一定的缺陷，例如err != nil条件成立时不再意味着一定发生了错误，在标准库中io.Reader返回io.EOF Error来告知调用者数据已经读取完毕，虽然这并不意味着发生了错误，但是我们仍然需要显式地处理这个错误。

显式错误处理的也具有一些缺点，我们需要在每个函数调用处都进行错误处理，业务逻辑中编写大量的if err != nil会使得代码段看起来较为冗余。 为了简化错误处理的逻辑，Go 1.13 版本借鉴了github.com/pkg/error的设计思想，引入了errors.Is和errors.As、fmt.Errorf("%w", err)等函数，使得错误处理更加简洁：

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

package main

import (
    "errors"
    "fmt"
)

var ErrNotFound = errors.New("not found")

func main() {
    err := do()
    if errors.Is(err, ErrNotFound) {
        fmt.Println("not found")
    }
}

显式错误处理使得代码的行为更加可预测。当函数遇到错误时，它会显式地返回一个错误值，调用者可以根据这个错误值来决定如何处理错误。这种方式使得错误处理的逻辑更加清晰，也利于编写单元测试，我们可以模拟函数返回错误，然后检查调用者是否正确地处理了这个错误，提高代码的质量。

单元测试

单元测试是保证代码质量的重要手段，Golang 语言内置了testing单元测试框架，可以帮助开发者编写高质量的单元测试用例，提高代码的正确性。在面向测试的开发中，要有意识地编写可测试的代码，笔者也积累了一些小技巧：

• 编写可测试的代码，避免使用全局变量、单例模式等，模块之间的依赖关系应该通过 interface 来定义；
• 使用测试框架 gomock 对 interface 进行 Mock，以便于验证上层模块的逻辑；
• 使用猴子补丁*gomonkey* 对不便于测试的函数或方法进行 monkey patch；
• 使用断言库 testify 对测试结果进行断言，以保证测试用例的正确性；
• 在执行单元测试时执行go test -race静态竞争检查，以保证代码的并发安全性；
• 测试用例要尽可能地覆盖所有的分支，包括正常分支、异常分支、边界分支等，避免将单元测试当做 Happy Path。

单元测试可以自动化地执行大量的测试用例，从而节省了手动测试的时间，提高了开发效率。除此之外，我们在标准库的源码中还可以看到example_test.go文件，这些文件中包含了函数的使用示例，通过示例代码来展示函数的使用方法，作为函数的 API 文档。

当我们需要对代码进行重构时，单元测试可以作为一个安全网，确保重构不会引入新的错误，也不会更改现有的逻辑，提高代码的可维护性。

总体来说，单元测试是保证代码质量的必要手段，它可以帮助我们提早发现代码中的错误，即使项目经历了多名工程师的迭代开发，也能够通过单元测试了解代码的用途和行为。

自动化工具与 CI/CD

Golang 语言的工具链非常丰富，在前面的内容中我们已经介绍了代码格式化工具golangci-lint、测试框架gomock、testify等，Go 社区十分喜欢使用自动化工具来自动生成代码，减少重复劳动，提高开发效率。本章节我们将介绍一些常用的 Golang 工具链：

• buf.build：buf 是一个用于管理 Protocol Buffers 文件的工具，它可以帮助开发者管理 Protocol Buffers 文件的版本、依赖、生成代码等，简化项目开发配置；
• gomodifytags：gomodifytags 是一个用于修改 Golang 结构体标签的工具，它可以帮助开发者自动添加、删除、修改结构体标签，简化代码的维护；
• go-gorm gen：go-gorm gen 是一个用于生成 GORM 模型的工具，它可以帮助开发者自动生成数据库 CRUD 代码，简化数据库操作；
• swaggo：swaggo 是一个基于注释自动生成 Swagger API 文档的工具，简化 API 文档的维护；

上述工具可以帮助我们自动生成代码、文档，简化项目的开发配置，当配置发生变化时，也能够自动更新代码，替代人工的重复劳动，提高人效比。

除了自动生成代码、文档外，我们还需要使用 CI/CD 工具来自动化构建、测试、部署，常见的 CI/CD 工具有 GitHub Actions、Jenkins 等，通常情况下，我们会在项目中维护一个Makefile文件，用于定义项目的构建、测试、部署等命令，然后在 CI/CD 工具中调用make命令来执行这些命令。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

.PHONY: lint
lint:
    golangci-lint run

.PHONY: test
test:
    go test -race -coverprofile=coverage.out ./...

.PHONY: build
    go build -o build/bin/app1 cmd/app1/main.go

自动化在软件开发中有许多优点，一个稳定、完善的 CI/CD 系统可以帮助我们实现以下目标：

1. 提高效率：通过自动执行耗时的任务（如构建和测试），可以节省大量时间，使工程师可以将更多的时间和精力投入到解决问题和添加新功能上，专注于更复杂的业务逻辑，减少不必要的心智负担，从而提高生产力；
2. 减少错误：人为操作更容易出错，例如我们在更新结构体标签时可能会有 typo，而自动化工具可以确保每次执行任务时都遵循相同的步骤和标准，从而提高结果的一致性，避免这种低级错误；
3. 快速反馈：CI/CD 可以在代码提交后立即运行，提供快速反馈，帮助工程师及时发现并修复问题；
4. 文档化过程：CI/CD 不仅能够自动执行任务，还记录了任务的执行过程，当任务失败时，可以通过 CI/CD 工具的日志来查看任务的执行过程，帮助工程师定位问题；

编程范式与设计模式

编程范式与设计模式是软件工程师在编写代码时需要考虑的问题，它们可以帮助我们编写出更加优雅、扩展性更高的代码。在 Golang 语言中，我们可以使用一些编程范式和设计模式来提高代码的质量。

Go 语言是一门多范式编程语言，它支持面向对象编程、函数式编程、面向接口编程等多种编程范式，我们可以根据项目的需求选择合适的编程范式。而设计模式可以弥补编程语言表达能力的不足，它可以帮助我们解决一些常见的问题，提高代码的可维护性。本小节将会介绍一些常见的编程范式和设计模式。

面向接口编程

面向接口编程是 Golang 语言的一大特色，它可以帮助我们提高代码的可扩展性。在 Golang 语言中，接口是一种抽象类型，它定义了一组方法，任何实现了这组方法的类型都可以被赋值给这个接口类型的变量。这种特性使得 Golang 语言可以很方便地实现依赖注入、多态等特性。

在 Golang 语言中，我们可以使用接口来定义模块的依赖关系，例如：

1
2
3
4

type Repository interface {
    FindByID(id int) (*User, error)
    Save(user *User) error
}

在上面的代码中，我们定义了一个 Repository 接口，它定义了两个方法：FindByID和Save。任何实现了这两个方法的类型都可以被赋值给Repository类型的变量。这种特性使得我们可以很方便地实现依赖注入，例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

type UserService struct {
    Repository Repository
}

func (s *UserService) FindByID(id int) (*User, error) {
    return s.Repository.FindByID(id)
}

func (s *UserService) Save(user *User) error {
    return s.Repository.Save(user)
}

面向接口编程也可以帮助我们实现多态，在下面的代码中，我们定义了一个MockRepository类型与MySQLRepository类型，它实现了 Repository 接口的两个方法。在业务逻辑中我们可以根据上下文来选择不同的 Repository 实现：：

 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

type MockRepository struct {
}

func (r *MockRepository) FindByID(id int) (*User, error) {
    return &User{}, nil
}

func (r *MockRepository) Save(user *User) error {
    return nil
}

type MySQLRepository struct {
}

func (r *MySQLRepository) FindByID(id int) (*User, error) {
    return &User{}, nil
}

func (r *MySQLRepository) Save(user *User) error {
    return nil
}

func main() {
    var repository Repository
    if os.Getenv("ENV") == "test" {
        repository = &MockRepository{}
    } else {
        repository = &MySQLRepository{}
    }
    
    userService := &UserService{Repository: repository}
    userService.FindByID(1)
}

interface 接口可以将具体的实现和使用者解耦，使得代码更加模块化。使用者只需要知道接口的定义，而不需要关心具体的实现，这使得我们可以在不改变使用者代码的情况下更换实现，或者为同一个接口提供多种实现。interface 还可以让我们更容易地为代码编写测试，前文介绍过我们可以使用 gomock 创建 mock 对象来实现接口，在测试中使用这些 mock 对象，在不依赖外部系统的情况下测试代码。

面向对象编程

面向对象编程是一种常见的编程范式，具有 封装、继承、多态三大特性，它将数据和操作数据的方法封装在一起，使得对象的功能更加聚合。相比于其他编程语言 Go 的面向对象模型更为简洁。在 Go 语言中，没有类（class）和继承（inheritance），而是通过结构体（struct）和接口（interface）来实现面向对象编程。这种简洁的设计使得 Go 语言的面向对象编程更易于理解和使用：

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

type User struct {
    ID   int
    Name string
}

func (u *User) id() int {
	return u.ID
}

func (u *User) Save() error {
    fmt.Printf("save user %s", u.Name)
    return nil
}

func main() {
    user := &User{ID: 1, Name: "Tom"}
    user.Save()
}

在上面的代码中，我们定义了一个 User 结构体，它有两个字段ID和Name，以及一个公开的Save方法。这种方式使得我们可以将数据和操作数据的方法封装在一起。

在继承方面，Go 语言采用了组合优于继承的方式，我们可以通过嵌入（embedding）其他的结构体或接口来复用代码，而不需要通过继承来实现代码的复用。这种设计使得我们可以更灵活地组合代码，而不需要考虑复杂的继承关系。

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

type NewUser struct {
    User
    Age int
}

func (u *User) Save() error {
    fmt.Printf("save user %s, age %d", u.Name, u.Age)
    return nil
}

func main() {
    user := &NewUser{User: User{ID: 1, Name: "Tom"}, Age: 18}
    user.Save()
}

在上面的代码中，我们定义了一个NewUser结构体，它嵌入了User结构体，这使得NewUser结构体拥有了User结构体的所有字段和方法。我们也可以重写NewUser的Save方法，来实现多态特性。

我们已经介绍了 Go 语言的面向接口与面向对象编程，面向对象编程能够封装数据和操作数据的方法，隐藏对象的内部状态，只暴露必要的方法给外部，增强内聚度。面向接口编程能够将具体的实现和使用者解耦，使得代码更加模块化。它们可以帮助我们编写出更加模块化、可扩展的代码，降低模块的耦合度。在实际的项目中，我们可以根据实际需要选择合适的编程范式。

选项模式

选项模式（Functional Options）可以说是 Go 语言中最常见的设计模式之一，它可以帮助我们简化代码的配置。选项模式的核心思想是将配置选项封装为一个函数，这个函数会返回一个可执行函数来更新构建时的配置项，这样我们就可以通过链式调用的方式来配置对象。

使用选项模式的原因是，不同于 Python 的构造函数在初始化时支持选择性传入多个参数，并为每个参数提供默认值，即使我们不传入任何参数，也可以创建一个新对象：

1
2
3
4
5
6
7
8

class User:
    def __init__(self, name="Tom", age=18):
        self.name = name
        self.age = age

user = User(name="Jerry")
print(user.name)  # Jerry
print(user.age)   # 18

要解决这个问题，最常见的方式是使用一个配置对象，如下所示，我们将非必要的选项都移到一个结构体里，：

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

type Config struct {
    Timeout  time.Duration
    TLS      *tls.Config
}

type Request struct {
    host string
    port int
    config *Config
}

func NewRequest(host string, port int, config *Config) *Request {
    return &Request{host: host, port: port, config: config}
}

在上面的代码中，我们定义了一个Config结构体，它包含了一些可选的配置选项，然后我们在NewRequest函数中传入了一个Config结构体，与必要的参数，这样我们就可以通过NewRequest函数来创建一个Request对象。这种解决方式已经能够满足需求了，但还不够优雅，因为即使在我们并不需要配置这些选项的情况下，我们仍需要传入一个Config结构体，并要对其进行是否为 nil 校验。

选项模式可以进一步优化这个问题，我们定义一个Option 函数类型，它接收一个Request指针类型的参数，然后返回一个函数，这个函数的参数是一个Request指针类型的参数，这样我们就可以通过链式调用的方式来配置Request对象：

 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

type Option func(*Request)

type Request struct {
    host string
    port int
    tls *tls.Config
    timeout time.Duration
}

func WithTimeout(timeout time.Duration) Option {
    return func(r *Request) {
        r.timeout = timeout
    }
}

func WithTLS(tls *tls.Config) Option {
    return func(r *Request) {
        r.tls = tls
    }
}

func NewRequest(host string, port int, options ...Option) *Request {
  r := &Request{host: host, port: port, timeout: 10*time.Second}
    for _, option := range options {
        option(r)
    }
    return r
}

func main() {
    request := NewRequest("localhost", 8080, WithTimeout(5*time.Second), WithTLS(&tls.Config{}))
    request := NewRequest("localhost", 8080)
}

使用选项模式可以选择性地配置对象，使得代码更加灵活，当我们需要添加新的配置选项时，只需要添加一个新的函数和配置字段即可。

修饰器模式

修饰器模式（Decorator Pattern）是一种常见的设计模式，它可以帮助我们动态地为对象添加新的功能，降低代码的重复编写。在 Python 语言中，我们可以使用语法糖@来实现修饰器模式，例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

def log(func):
    def wrapper(*args, **kwargs):
        print(f"call {func.__name__}")
        return func(*args, **kwargs)
    return wrapper
    
@log
def add(a, b):
    return a + b

add(1, 2)

在上面的代码中，我们定义了一个log修饰器，它接收一个函数作为参数，然后返回一个函数，这个函数的参数是一个函数，这样我们就可以通过@log语法糖来为add函数添加日志功能。

在 Golang 语言中，我们可以使用函数封装来实现修饰器模式：

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

func log(f func(int, int) int) func(int, int) int {
    return func(a, b int) int {
        fmt.Printf("call %s\n", runtime.FuncForPC(reflect.ValueOf(f).Pointer()).Name())
        return f(a, b)
    }
}

func add(a, b int) int {
    return a + b
}

func main() {
    add = log(add)
    add(1, 2)
}

相比之下，Golang 语言中的修饰器模式没有 Python 语言中的语法糖那么优雅，但它同样可以帮助我们动态地为对象添加新的功能。Go 语言中装饰器最常见的应用场景是自定义中间件，例如 Gin 框架中的中间件就大量使用了修饰器模式：

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

func Logger() gin.HandlerFunc {
    return func(c *gin.Context) {
        t := time.Now()
        c.Next()
        latency := time.Since(t)
        log.Print(latency)
    }
}

func main() {
    r := gin.Default()
    r.Use(Logger())
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "pong",
        })
    })
    r.Run()
}

小结

本小节简单介绍了 Golang 语言中的一些编程范式和设计模式，它们可以帮助我们编写出更加优雅、高可扩展的代码。如果读者想要深入了解这些编程范式和设计模式，可以参考已故程序员《左耳朵耗子》的 GO编程模式 系列文章。

总的来说，Go 的语法本身就已经非常简洁，而且 Go 语言的接口和函数式编程特性使得我们可以更加灵活地组合代码，而不需要过多地依赖设计模式。但是设计模式仍然是一种很好的编程范式，它可以帮助我们解决一些 Go 语言的设计缺陷，让我们的代码更加优雅。

项目拆分与重构

在大型的 Golang 项目中，随着业务的发展，代码的规模会变得越来越大，这时候就需要考虑对项目进行拆分与重构。项目拆分可以提高代码的可读性和可维护性，也可以提高开发效率。以下是一些常见的 Golang 项目拆分策略。

水平拆分

水平拆分或按照功能模块拆分是最常见的拆分策略，将不同的功能模块放在不同的包（Package）中。例如，用户管理、订单管理、商品管理等功能可以分别放在 user、order、product 等包中。这样做的好处是可以清晰地看到每个包的职责。

1
2
3
4
5
6
7
8

├── user
│   ├── entity.go
│   ├── user.go
│   └── user_test.go
├── order
│   ├── entity.go
│   ├── order.go
│   └── order_test.go

由于 Golang 语言中的包是一个独立的 Namespace，因此不同的包可以有相同的函数名，我们可以通过包名来区分不同的函数：user.FindByID、order.FindByID。

随着业务的发展，单体应用可能会变得越来越复杂，这时候可能hui考虑将项目拆分为多个微服务。每个微服务都是一个独立的应用，微服务之间通过 API 进行通信，可以独立部署和扩展。如果我们在项目中使用了水平拆分的策略，那么将项目拆分为多个微服务会变得更加容易，因为每个子模块都是一个独立的包，天然具有独立性，降低微服务拆分时的改动成本。

垂直拆分

垂直拆分或按照层次结构拆是另一种常见的拆分策略，将不同的层次放在不同的包中。例如，将数据访问层（Repository）、业务逻辑层（Service）、控制器层（Controller）放在独立的子目录中。每个层次都有其特定的职责，例如数据访问层负责与数据库交互，业务逻辑层负责处理业务逻辑，控制器层负责处理 HTTP 请求。

垂直拆分通常与水平拆分结合使用，以确保模块间是完全解耦的，每个功能模块都有自己的数据访问层、业务逻辑层、控制器层，例如将用户管理模块拆分为 order/repository、order/service、order/controller 等包。不同功能模块的内部代码对其它模块是不可见的，只能通过暴露的 Interface 进行通信。

1
2
3
4
5
6
7
8

├── order
│   ├── repository
│   │   ├── history.go
│   │   ├── order.go
│   ├── service
│   │   ├── order.go
│   └── controller
│       ├── order.go

重构

重构是一种常见的优化代码的手段，可以帮助我们提高性能、甩掉历史包袱、提高可扩展性等。重构可以帮助我们优化代码的设计，当新的需求出现时，我们可以更容易地在现有的代码基础上进行扩展。在前面的内容中我们介绍过了一些 Golang 的自动化工具、代码格式化、单元测试等，在重构的过程中，我们可以使用这些工具来确保重构前后功能一致性，避免引入新的错误。

重构往往发生在项目的后期，当项目的代码规模变得越来越大，代码的质量变得越来越差，或是项目的业务需求发生了变化，现有的代码无法满足新的需求时，我们就需要考虑对项目进行重构。但在笔者看来，重构不仅仅是在项目的后期才需要考虑的问题，它应该是项目的一部分，随着项目的发展时时刻刻都在进行。

我们在开发新需求或是维护项目的过程中，可能会遇到一些代码质量不高的代码，例如：

• 重复的代码段：在不同的地方出现了相同的代码段，这样的代码段不利于维护，因为每次修改都需要修改多个地方，或是发生了遗漏，我们可以将这些代码段抽取出来，维护在一个函数或方法中，在需要的地方调用这个函数；
• 不合理的结构体或接口：结构体或接口的定义不合理，我们可以通过重构来简化结构体或接口的定义；
• 冗余的参数：函数或方法的参数过多，或是参数的类型不合理，我们可以通过重构来简化参数。

在项目早期，往往由于排期紧张、需求频繁变化等原因，我们的项目可能不会那么规范，只关注功能的实现，所以在功能迭代的过程中，我们可能每天都会对小段的代码进行重构，提高代码的整洁。

总结

本篇文章主要介绍了 Golang 语言的一些最佳实践，包括代码格式化、错误处理、单元测试、自动化、编程模式、拆分与重构等。归根结底，我们的终极目标是写出优雅、干净、整洁的代码，提高项目的可维护性、可扩展性，降低维护的成本

在实际的工程中，我们需要在项目早期就开始执行严格的代码审查和 Code Review，遵循「先紧后松」的原则，保证代码的质量，如果我们在项目的早期没有注重代码规范，那么随着项目的发展，往往会变得越来越难以维护，即使想要添加更为严格的代码规范也会遭到许多质疑和反对的声音。

在项目的中后期，我们需要不断进行重构，对子模块进行重新设计与拆分，保持代码的整洁。在重构的过程中，我们可以使用自动化工具来确保重构前后功能一致性，避免引入新的错误。

希望本篇文章能够帮助各位工程师实现更加稳定可靠的 Go 服务。

通常情况下，我们的应用程序会涉及到很多配置，比如 HTTP/RPC 监听端口、日志相关配置、数据库配置等。这些配置可以来自不同的配置源，例如本地配置文件、环境变量、命令行参数，或是 Consul 一类的远程配置中心，同时一项配置可能在多个不同的配置源中同时存在，需要进行优先级处理。这篇文章介绍使用 koanf 在 Golang 程序中进行配置管理。

viper 是 Golang 程序中被广泛使用的配置解析库，是一个开箱即用的配置 SKD，但是在使用过程中，viper 也暴露出来一些问题：

• 强制规定配置 key 为小写格式，破坏了 TOML、HCL 等配置文件原有的语义定义：forcibly lowercasing keys；
• 强制规定配置源的优先级：default precedence order；
• File、CLI、ENV 等配置解析实现硬编码在代码库中，没有提供在应用层面新增 Parser 或定制解析过程的 API，无法进行扩展；
• 一次拉取所有的第三方依赖，即使没有使用到对应的配置源和 Parser，viper 依然会拉取相应的依赖，例如 ETCD、Consul、gRPC 等：Why all the new dependencies?；

viper 的代码库实现很复杂，短时间内很难了解它的设计思路。viper 对外没有暴露可扩展的语义，在实际使用过程中，如果遇到无法覆盖的应用场景，往往需要在业务层进行单独处理，会对业务逻辑增加额外的侵入性。因此需要一个更加轻量级，且易于扩展的配置管理实现。

概述

knanf 是一个轻量且易于扩展定制的 Golang 配置库，v2 版本通过独立的 Golang Module，将外部依赖项都与核心分离，并且可以根据需要单独安装，使得其核心代码只有一千余行：

• JSON、Yaml 等数据格式的解析扩展，只需要实现Parser接口，独立于 Parser 目录中：koanf/parsers；

  1 2 3 4

  type Parser interface { Unmarshal([]byte) (map[string]interface{}, error) Marshal(map[string]interface{}) ([]byte, error) }

• Consul、File、Env 等配置源的数据解析，只需要实现Provider接口，独立 Provider 目录中：koanf/providers；

  1 2 3 4

  type Provider interface { ReadBytes() ([]byte, error) Read() (map[string]interface{}, error) }

• koanf 提供了 Provider 与 Parser 接口，通过实现对应的接口，可以接入更多的配置解析方式；

• koanf 自身并未规定配置源的优先级，koanf 会按照 Provider 的调用顺序，覆盖已有的值；

koanf 的基础操作可以参考 knanf/readme，文中将不再赘述，以下内容将会在了解使用方式的基础上进行介绍。

配置优先级

koanf 会按照 Provider 的调用顺序，覆盖已有的值。因此我们可以通过封装统一的配置解析步骤，达到默认优先级的效果。例如下面的代码实现了一个 Parse() 函数，其参数有配置路径与数据格式，以及对应的 Parser（在示例中，支持本地文件与 Consul）：

 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

func Parse(configPath, format string, reader ParserFunc, opts ...OptionFunc) error {
	var parser koanf.Parser

	switch format {
	case ConfigFormatYAML:
		parser = kyaml.Parser()
	case ConfigFormatJSON:
		parser = kjson.Parser()
	default:
		return fmt.Errorf("unsupported config format: %s", format)
	}

	if err := reader(configPath, parser); err != nil {
		return err
	}
}

// OptionFunc is the option function for config.
type OptionFunc func(map[string]any)

// ParserFunc Parse config option func
type ParserFunc func(path string, parser koanf.Parser) error

func ReadFromFile(filePath string, parser koanf.Parser) error {
	if err := k.Load(kfile.Provider(filePath), parser); err != nil {
		// Config file was found but another error was produced
		return fmt.Errorf("error loading config from file [%s]: %w", filePath, err)
	}

	return nil
}

// ReadFromConsul read config from consul with format
func ReadFromConsul(configPath string, parser koanf.Parser) error {
	if err := k.Load(kconsul.Provider(kconsul.Config{}), parser); err != nil {
		return fmt.Errorf("error loading config from consul: %w", err)
	}

	return nil
}

配置数据可以以不同的数据格式与存储方式进行组织，得益于 koanf 优秀的解耦思想，我们可以很容易的支持内部的配置中心

在容器化部署的情况下，我们还会根据环境变量来修改当前程序的某些配置项，以便于在不修改镜像内容的情况下，进行动态配置。ENV Provider 通过统一前缀来标识所需要解析的环境变量，并提供了一个可选的 callback 函数，让用户自定义环境变量名称的处理逻辑。在示例代码中，我们自定义的回调函数去除了统一前缀，并将所有大写字符转为小写：

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

	// Second, read config from environment variables,
	// Parse environment variables and merge into the loaded config.
	// "PUDDING" is the prefix to filter the env vars by.
	// "." is the delimiter used to represent the key hierarchy in env vars
	// The (optional, or can be nil) function can be used to transform
	// the env var names, for instance, to lowercase them
	if err := k.Load(kenv.Provider("PUDDING/", defaultDelim, func(s string) string {
		return strings.ReplaceAll(strings.ToLower(
			strings.TrimPrefix(s, "PUDDING/")), "/", ".")
	}), nil); err != nil {
		return fmt.Errorf("error loading config from env: %w", err)
	}

CLI 优先级

CLI 优先级是一个特殊的场景，他具有默认值，但是可以被命令行参数覆盖。由于 koanf repo 内并未实现 Golang 标准库 flag 的配置解析。因此需要自己实现一个 Provider。

为了便于理解，以下代码段仅贴出了关键部分。Golang flagSet 提供了VisitAll方法，以便于调用方能够访问 flagSet 中所有被命令行参数设置与未被设置的 flag。同时标准库中的所有 flag Value 类型都实现了flag.Getter方法，能够获取该 flag 的当前值，以及该值的字符串类型表示方法。我们将当前值与初始值进行比对，就能感知到命令行参数是否被设置。同时 koanf 也实现了 Exist 方法，用来判断 key 是否已经存在：

• 如果命令行参数没有设置，并且低优先级的配置文件也没有设置，那么就使用 CLI 默认值；
• 如果命令行参数没有设置，但是低优先级的配置文件设置了，那么就使用低优先级的配置文件的值；
• 如果命令行参数设置了，那么就使用命令行参数的值；

 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

// Read reads the flag variables and returns a nested conf map.
func (p *Flag) Read() (map[string]any, error) {
	mp := make(map[string]any)

	p.flagSet.VisitAll(func(f *flag.Flag) {
		var (
			key   string
			value any
		)

		if p.cb != nil {
			key, value = p.cb(f.Name, f.Value)
		} else {
			// All Value types provided by flag package satisfy the Getter interface
			// if user defined types are used, they must satisfy the Getter interface
			getter, ok := f.Value.(flag.Getter)
			if !ok {
				panic(fmt.Sprintf("flag %s does not implement flag.Getter", f.Name))
			}
			key, value = f.Name, getter.Get()
		}

		// if the key is set, and the flag value is the default value, skip it
		if p.ko.Exists(key) && f.Value.String() == f.DefValue {
			return
		}

		mp[key] = value
	})

	return maps.Unflatten(mp, p.delim), nil
}

最后Read方法的返回值是一个map[string]any哈希表，koanf 会将该哈希表与已有的配置进行合并覆盖。

配置 Watch

配置的Watch方法并不包含在 koanf 的核心模块中，而是由 Provider 独自实现。我们需要向 Provider 注册一个回调函数，当有配置变更事件到来时，加载新的配置信息，并让业务模块感知到配置的变化。

1
2
3
4
5
6
7
8

	f := file.Provider("mock/mock.json")
	if err := k.Load(f, json.Parser()); err != nil {}

	f.Watch(func(event interface{}, err error) {
		k.Load(f, json.Parser())
		k.Print()
    // trigger reload config
	})

配置反序列化

koanf 所有的配置都会被保存在一个全局的 map 中，但是 map 是一个无类型的容器，是一个宽松的数据结构，不利于做类型检查与数据校验。 在实际使用过程中，我们往往需要将配置反序列化为结构体，以便于在代码中使用。koanf 提供了Unmarshal方法，可以将配置反序列化为结构体，因此我们需要在结构体中添加mapstructure标签，以便于 koanf 反序列化时能够正确的解析字段：

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

type BaseConfig struct {
	HostDomain string `json:"host_domain" yaml:"host_domain" mapstructure:"host_domain"`
	GRPCPort int `json:"grpc_port" yaml:"grpc_port" mapstructure:"grpc_port"`
	HTTPPort int `json:"http_port" yaml:"http_port" mapstructure:"http_port"`
	EnableTLS bool `json:"enable_tls" yaml:"enable_tls" mapstructure:"enable_tls"`
}

func UnmarshalToStruct(path string, c any) error {
	if err := k.UnmarshalWithConf(path, c, koanf.UnmarshalConf{Tag: "mapstructure"}); err != nil {
		return fmt.Errorf("failed to unmarshal config: %w", err)
	}

	return nil
}

总结

koanf 最精髓的设计之处在于，将 Parser、Provider 与 Core 解耦，通过插件的形式引入，每一个模块都可以根据需要单独安装。并且自定义实现 Provider 的成本低廉，能够便捷地进行功能扩展。

分布式锁是控制分布式系统之间同步访问共享资源的一种方式，本文介绍了使用 Redlock、etcd 等常见分布式锁的实现方式与 Google Chubby 的设计思路，并探讨不同类型的分布式锁的适用场景。

在分布式系统与微服务架构中，不同的系统或同一个系统的不同节点之间共享同一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰，保证一致性。

分布式锁提供了分布式环境下共享资源的互斥访问，业务依赖分布式锁追求效率提升，或者依赖分布式锁追求访问的绝对互斥。同时，在接入分布式锁服务过程中，要考虑接入成本、服务可靠性、分布式锁切换精度以及正确性等问题，正确和合理的使用分布式锁，是需要持续思考并予以优化的。

概述

一般来说，分布式锁需要满足以下特性：

1. 排他性：在任意时刻，只有一个客户端能持有锁；
2. 无死锁：即使有一个客户端在持有锁期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁；
3. 加锁和解锁必须是同一个客户端，客户端不能把其他客户端加的锁释放掉；
4. 容错性：少数节点失效，锁服务仍可以对外提供加解锁服务。

其中分布式锁的死锁与编程语言提供锁的死锁概念不同，后者死锁描述的是多个线程由于相互等待而永远被阻塞的情况，分布式锁的死锁是指，如果请求执行因为某些原因意外退出了，导致创建了锁但是没有释放锁，那么这个锁将一直存在，以至于后续锁请求被阻塞住。为了防止死锁通常会给分布式锁设置 TTL(Time To Live)，TTL 过期后被自动释放。TTL 策略也有一定的弊端，如果执行任务的进程还没有执行完，但是锁因为 TTL 过期被自动释放，可能被其它进程重新加锁，这就造成多个进程同时获取到了锁。

Redis 分布式锁

Redis 单机锁

Redis 单机锁的实现十分简单，只需要执行指令SET key random_value NX PX 60000 就可以获得一个 TTL 60s 的锁。如果这个 key 已经被强占了，那么客户端会获取锁失败。Redis 锁需要客户端实现算法保证所有获取锁请求生成随机的唯一 value，并将 value 保存下来，当客户端执行完代码释放锁时，需要先获取 Redis value 并与本地存储的 value 进行比较，只有两者一致时才会执行DEL操作释放锁：

1
2
3
4
5

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

random value 是为了保证某个客户端持有的锁不会被其它客户端错误地释放掉，试想一种场景：客户端 A 拿到了 key1 的锁，但被某个耗时操作阻塞了很长时间，达到超时时间后 Redis 自动释放了这个锁；随后客户端 B 拿到了 key1 的锁，这时客户端 A 操作完成，尝试删除已经被客户端 B 持有的 key1 锁。使用上面的原子操作脚本可以保证每个客户端用一个随机字符串作为「签名」，保证每个锁只能被获得锁的客户端删除释放。

得益于 Redis 基于内存存储数据与优秀的程序设计，单机 Redis 能够支撑 10w+ QPS 的请求量，可以满足大多数场景。而单机锁的问题在于一是无法保障容错性，如果 Redis 发生单点故障，那么所有需要获取分布式锁的服务将全部阻塞，二是即使 Redis 采用主从复制架构，主节点崩溃时还未将最新的数据复制到从节点，使得从节点接替主节点时部分数据丢失，违反了锁的排他性。

Redlock 分布式锁

Redlock 是 Redis 的作者 antirez 给出的集群模式的 Redis 分布式锁，可以看作是单机锁实现的一种扩展。它基于 N 个完全独立的 Redis Master 节点实现，这些主节点间不会复制数据或使用任何隐含的分布式协调算法。一个客户端要获得锁，需要执行以下步骤：

1. 客户端获取当前时间，单位是毫秒；
2. 客户端用相同的 key 和 random_value 顺序地在 N 个节点上请求锁。在这一步中，客户端在每个 Master 上请求锁时，会有一个比总的锁 TTL 时长小的多的超时时间，例如如果锁自动释放时间是 10s，那每个节点锁请求的超时时间可能是 5~50ms 的范围。超时时间可以防止客户端在某个宕掉的 Master 节点上阻塞过长时间，如果一个 Master 节点不可用了，客户端会尽快尝试下一个 Master 节点；
3. 客户端计算第二步中获取锁所花的时间，如果客户端在超过 N/2 +1 个 Master 节点上成功获取了锁，并且总消耗的时间不超过 TTL，那么这个锁就认为是获取成功了；
4. 如果锁获取成功，那么锁的真正 TTL 为原有的 TTL - 总消耗时间；
5. 如果锁获取失败，不管是因为获取成功的锁不超过一半（N/2+1)还是因为总消耗时间超过了锁释放时间，客户端都会向每个 Master 节点释放锁，包括那些没有获取锁。

Redlock 获取锁失败后，会在随机延时后不断进行重试，直至最大次数，采用随机延时是为了避免不同客户端同时重试，导致谁都无法拿到锁的情况出现。

虽然 Redlock 采用过半写入策略来保障锁的互斥性，但是严重依赖于客户端反复请求锁服务。如果我们的节点没有开启数据持久化，假设一共有 5 个 Redis 节点：A、B、C、D、E，发生了如下的事件序列：

1. Client1 成功锁住了 A、B、C，获取锁成功，但 D 和 E 没有锁住；
2. 节点 C 崩溃宕机，Client1 在 C 上加的锁丢失；
3. 节点 C 重启后，Client2 锁住了C、D、E，获取锁成功。

这样，Client1 和 Client2 在同一时刻都获得了锁，为了解决这个问题，Redis 的作者 antirez 提供了两个解决方案：

• 开启 AOF 持久化：因为 Redis key 的过期机制是基于时间戳的，在节点宕机期间时间依旧在流逝，重启之后锁状态不会受到污染。但是 AOF 数据刷回磁盘默认是每秒写一次磁盘，可能部分数据还未刷写到磁盘上数据就已经丢失了，因此需要我们配置策略为 fsnyc = always，但这会降低 Redis 的性能。
• 解决这个问题的另一个方法是，为 Redis 锁服务规定一个 Max TTL，当一个节点重启之后，这个节点在 Max TTL 期间是不可用的，这样它就不会干扰原本已经申请到的锁，等到它 crash 前的历史锁都过期了，这个节点才会重新加入集群。这个方案的缺点在于如果 Max TTL 设置得过长，那么会导致重启的节点在数个小时内不可用的，即使这个节点是正常的。

争论

Redlock 是一个没有使用共识算法、基于时间实现的分布式锁，这也让很多人怀疑它的可靠性。《DDIA》的作者 Martin Kleppmann 在 2016 年就发表了一篇文章*How to do distributed locking* ，从以下两个方面批判了 Redlock 的安全性：

• Redlock 构建在一个基于时间戳的系统模型之上，多台服务器难以保证时间一致，这使得锁的实际失效时间是不同的；
• 带有自动过期功能的分布式锁，必须提供某种 fencing token（唯一性约束）机制，例如单调递增的 ID，来保证对共享资源的互斥性，而 Redlock 没有提供这样一种机制。

关于第二点中提到的 fencing token 机制，我们将在下文 Chubby 一节中详细论述。

随后 antirez 在*Is Redlock safe?* 一文中也进行了回应。这里先讨论第一种情况：当时钟发生跳跃时，当前服务器的时间会突然变大或变小，这都会影响锁的过期时间。例如 Client1 成功锁住了 A、B、C，但是节点 C 的时间突然向前跳跃了 5 秒钟提前失效，这时 Client2 成功锁住了 C、D、E，这种情况下就违反了锁的互斥性。

antirez 认为第一种情况可以通过合理的运维手段来避免：将一次时钟同步过程中大范围的时钟跳跃改为多次小范围时钟跳跃，并尽可能地保证服务器间的时间差保持在较低的范围内。其实从 antirez 的回应可以看出 redlock 是无法解决服务器间时钟不同步问题的。

对于第二点，antirez 认为锁 ID 的大小顺序与操作真正执行的顺序是无关的，只需要保障互斥访问就即可。因此，锁的 ID 是递增的，还是一个随机字符串，自然也就不那么重要了。Redlock 虽然无法提供递增的 fencing token，但利用 Redlock 产生的 random value 可以达到同样的效果。这个随机字符串虽然不是递增的，但却是唯一的。所以 Redlock 是可以保证锁的唯一性约束的。

小结

综上所述，Redlock 是一种自旋式分布式锁实现，是基于异步复制的分布式系统，需要客户端反复请求锁服务来判断能否获取锁。

Redlock 通过 TTL 的机制承担细粒度的锁服务，适用于对时间很敏感，期望设置一个较短有效期，并且丢锁对业务影响相对可控的服务。

etcd 分布式锁

etcd 是一个基于 Raft 共识算法实现的分布式键值存储服务，并提供了分布式锁的功能。一个 etcd 集群包含若干个服务器节点，并通过『领导选举机制』选举出一个 Leader，所有的写请求都会被转发给 Leader，由它全权管理日志复制来实现一致性。其他的节点其实都是当前节点的副本，它们只是维护一个数据的拷贝并会在主节点更新时对它们持有的数据库进行更新，并只响应客户端的读请求。

基于共识算法的分布式系统，会内置一些措施来防止脑裂和过期的数据副本，进而实现线性化的数据存储，即整个集群表现得好像只有一个数据副本，且其上的所有操作都是原子的。客户端无论将请求发送到哪一个节点，最后都能得到相同的结果。

有关 etcd 的实现原理可参考文章*分布式键值存储 etcd 原理与实现*，本节主要讨论基于 etcd 的分布式锁实现。

etcd 锁的使用

etcd 可以为存储的键值对设置租约，当租约到期，键值对将失效删除。同时也支持续租，客户端可以在租约到期之前续约， 当一个客户端持有锁期间，其它客户端只能等待，为避免等待期间租约失效， 客户端需创建一个定时任务 KeepAlive 作为「心跳」不断进行续约，以避免处理还未完成而锁已经过期失效。

如果客户端在持有锁期间崩溃，心跳停止，key 将因租约到期而被删除，从而释放锁，避免死锁。

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

func NewSession(client *v3.Client, opts ...SessionOption) (*Session, error) {
    ops := &sessionOptions{ttl: defaultSessionTTL, ctx: client.Ctx()}
    for _, opt := range opts {
        opt(ops)
    }

    id := ops.leaseID

    ctx, cancel := context.WithCancel(ops.ctx)
    keepAlive, err := client.KeepAlive(ctx, id)

    donec := make(chan struct{})
    s := &Session{client: client, opts: ops, id: id, cancel: cancel, donec: donec}

    // keep the lease alive until client error or cancelled context
    go func() {
        defer close(donec)
        for range keepAlive {
            // eat messages until keep alive channel closes
        }
    }()

    return s, nil
}

为了更方便理解 etcd 锁的使用，下面贴出了一个简单的示例程序，go1 与 go2 协程抢占同一个锁，即使 go1 协程只设置了 2s 的 TTL 而 5s 后才能释放锁，客户端也可以自动续约保证锁的独占：

 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

func main() {
    c := make(chan int)

    client, err := clientv3.New(clientv3.Config{
        Endpoints:   []string{"9.135.90.44:2379"},
        DialTimeout: 5 * time.Second,
    })
    if err != nil {
        log.Fatal(err)
    }
    defer client.Close()

    lockKey := "/test_lock"

    go func() {
        session, err := concurrency.NewSession(client, concurrency.WithTTL(2))
        if err != nil {
            log.Fatal(err)
        }
        m := concurrency.NewMutex(session, lockKey)
        if err := m.Lock(context.TODO()); err != nil {
            log.Fatal("go1 get mutex failed " + err.Error())
        }
        log.Printf("go1 get mutex key: %s\n", m.Key())
        time.Sleep(5 * time.Second)
        m.Unlock(context.TODO())
        log.Printf("go1 release lock\n")
    }()

    go func() {
        time.Sleep(1 * time.Second)
        session, err := concurrency.NewSession(client)
        if err != nil {
            log.Fatal(err)
            return
        }
        m := concurrency.NewMutex(session, lockKey)
        log.Print("go2 try to get mutex")
        if err := m.Lock(context.TODO()); err != nil {
            log.Fatal("go2 get mutex failed " + err.Error())
        }
        log.Printf("go2 get mutex key: %s\n", m.Key())
        time.Sleep(time.Duration(2) * time.Second)
        m.Unlock(context.TODO())
        log.Printf("go2 release lock\n")
        c <- 0
    }()

    os.Exit(<-c)
}

etcd 锁机制

除了上文提到的租约机制，etcd 的还提供了以下三个特性来保障分布式锁的安全性。

统一前缀

在上面的示例程序中，两个协程争抢一个名为/test_lock的锁，而 etcd 实际写入的 key 分别为 key1/test_lock/LeaseID1和 key2/test_lock/LeaseID2。其中，LeaseID 是一个经由 raft 协议广播生成的全局 UUID，确保两个 key 的唯一性。

统一前缀与 Redlock 中客户端生成的随机 value 的作用是一致的，保证锁不会被其它客户端错误地删除。

Revision

etcd 为每个 key 生成一个 64 位的 Revision 版本号，每进行一次数据的写操作就加一，因此 Revision 是全局唯一且递增的， 通过 Revision 的大小就可以知道 etcd Server 处理写操作的顺序。

在上面的程序示例中，这两个 key 都会写入成功，但他们的 Revision 信息是不同的。客户端需要通过区间查询获取所有前缀为/test_lock的 key 的版本号，通过 Revision 大小可判断自己是否获得锁。

在实现分布式锁时，如果出现多个客户端同时抢锁，那么根据 Revision 号大小可以依次获得锁，避免「惊群效应」，实现公平锁。

Watch

Watch 机制支持 Watch 某个固定的 key，也支持 Watch 一个区间范围。当被 Watch 的 key 发生变化，客户端将收到通知。

在实现分布式锁时，如果抢锁失败，可通过区间查询返回的 Key-Value 列表获得 Revision 相差最小的 pre-key， 并对它进行监听，当 watch 到 pre-key 的 DELETE 事件， 说明 pre-key 已经释放，此时才能持有锁。

etcd 锁实现

了解了上述的四个机制的概念后，再来看 etcd 加锁解锁的过程就很简单了：

1. 组装需要持有的锁名称和 LeaseID 为真正写入 etcd 的 key；
2. 执行 put 操作，将创建的 key 绑定租约写入 etcd，客户端需记录 Revision 以便下一步判断自己是否获得锁；
3. 通过前缀查询键值对列表，如果自己的 Revision 为当前列表中最小的则认为获得锁；否则监听列表中前一个 Revision 比自己小的 key 的删除事件，一旦监听到 pre-key 则自己获得锁；
4. 完成业务流程后，删除对应的 key 释放锁。

 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

// 代码已删减
func (m *Mutex) Lock(ctx context.Context) error {
    m.myKey = fmt.Sprintf("%s%x", m.pfx, s.Lease())
  
    cmp := v3.Compare(v3.CreateRevision(m.myKey), "=", 0)
    // put self in lock waiters via myKey; oldest waiter holds lock
    put := v3.OpPut(m.myKey, "", v3.WithLease(s.Lease()))
    // reuse key in case this session already holds the lock
    get := v3.OpGet(m.myKey)
    // fetch current holder to complete uncontended path with only one RPC
    getOwner := v3.OpGet(m.pfx, v3.WithFirstCreate()...)
    resp, err := client.Txn(ctx).If(cmp).Then(put, getOwner).Else(get, getOwner).Commit()
  
    m.myRev = resp.Header.Revision

    // wait for deletion revisions prior to myKey
    hdr, werr := waitDeletes(ctx, client, m.pfx, m.myRev-1)
    // release lock key if wait failed
    if werr != nil {
        m.Unlock(client.Ctx())
    }
    return werr
}

func (m *Mutex) Unlock(ctx context.Context) error {
    client := m.s.Client()
    if _, err := client.Delete(ctx, m.myKey); err != nil {
        return err
    }
    m.myKey = "\x00"
    m.myRev = -1
    return nil
}