哈希 · XB 现场笔记

哈希索引复核碰撞，也要维护变化的键

Mon, 24 Jan 2028 00:00:00 +0000

PostgreSQL 哈希索引先利用哈希码缩小等值查询的候选范围，再回到表中核对原始值。哈希匹配只说明“可能相等”，不能直接证明相等。两个不同值可能具有相同哈希码，不同哈希码也可能映射到同一个桶。正常复核存在时，碰撞和共享桶都不意味着查询会返回错误结果；它们是实现需要处理的普通情况，而不是可以忽略的例外。

桶里究竟保存什么

索引条目包含四字节哈希值和指向表元组的引用，不保存完整的被索引列值。桶映射把查询导向相关索引页面。桶是共享存储空间，并不是给每个不同键单独分配一个专属位置。一个桶的主页装满后，可以继续连接溢出页，查询这个桶时也需要访问这些页面。因此，“一次算出桶”不等于“永远只读取一个页面”。

PostgreSQL 可以在单个索引页内部按哈希码排序，以便加速局部搜索，但这不会提供原始列值的顺序。哈希索引不能满足键范围或有序输出，只支持单列等值访问，不能强制唯一性，也不支持 IS NULL。B-tree 仍然可以服务等值查询，同时支持更广的一组操作，不能因为键看起来适合哈希就自动排除其他候选。

由于条目中没有原始值，哈希扫描是有损候选扫描，需要用表中实际值复核。因此，碰撞可以在执行计划中表现为 Rows Removed by Index Recheck。这说明数据库正确剔除了只在哈希上匹配的候选，而不是把两个碰撞值都当成相等返回。解读这项指标时，应把候选数量与最终答案区分开。

坏掉的样子

把索引键更新描述为“只碰一个桶”，掩盖了实际工作。修改被索引列会改变元组对应的索引值，新条目可能进入另一个桶。PostgreSQL 使用行版本与延后索引清理，旧引用不一定立刻从结构中消失。数据增长还可能触发桶分裂，溢出页也会增加读写。因此不能用一个理想化的哈希表赋值过程来解释数据库的全部更新成本。

高度重复的值、快速增长的表，与近乎唯一而稳定的等值负载，表现可能很不一样。哈希查询不是无条件的恒定延迟承诺。现代 PostgreSQL 的哈希索引支持崩溃恢复，但持久性既不会消除维护成本，也不会让它突然具备唯一性约束能力。读性能、写维护和数据契约必须分别确认。

快速验证

在可丢弃的 PostgreSQL 18 数据库中，用 psql 执行下面代码。它建立二十万个采用 C 排序规则的临时文本键，使用当前服务器自己的 hashtext 找到一组碰撞，再验证等值查询和键更新。实验没有把哈希码当成跨版本稳定的业务标识，最后回滚会移除所有夹具。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE hash_items (key text COLLATE "C");
INSERT INTO hash_items SELECT 'key-'||g FROM generate_series(1,200000) AS g;
CREATE TEMP TABLE collision_pair AS
SELECT min(key) AS a,max(key) AS b FROM hash_items
GROUP BY hashtext(key) HAVING count(*)>1 ORDER BY hashtext(key) LIMIT 1;
SELECT a AS collision_a,b AS collision_b FROM collision_pair \gset
SELECT a,b,hashtext(a),hashtext(b) FROM collision_pair;
CREATE INDEX hash_items_key ON hash_items USING hash(key);
ANALYZE hash_items;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT key FROM hash_items WHERE key=:'collision_a';
UPDATE hash_items SET key='changed-'||key WHERE key=:'collision_a';
SELECT count(*) AS old_key_rows FROM hash_items WHERE key=:'collision_a';
SELECT count(*) AS new_key_rows FROM hash_items WHERE key='changed-'||:'collision_a';
DO $$ BEGIN
 IF (SELECT hashtext(a)=hashtext(b) AND a<>b FROM collision_pair) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'fixture did not establish a collision';
 END IF;
 IF (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key=p.a) <> 0 OR
 (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key='changed-'||p.a) <> 1 OR
 (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key=p.b) <> 1 THEN
 RAISE EXCEPTION 'hash lookup or indexed update returned wrong keys';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 中找到的两个键是 key-129539 与 key-7295，哈希码都是 -1960436116。等值计划使用 hash_items_key，最终只返回一行，同时报告一行被索引复核移除。两段字符串虽然哈希相同，却仍然是不同的值。这是反对“哈希码没有碰撞”这一错误假设的实际负向验证，不能用普通的无碰撞点查替代。

将第一个键改成带 changed- 前缀的新值后，旧值查到零行，新值查到一行，另一条碰撞记录仍然查到一行。最终断言分别验证这三件事，并确认原始两个值确实具有相同哈希而内容不同。仅仅看到更新命令成功，还不足以证明同桶或同哈希的其他记录没有受到错误影响。

具体碰撞键和计划形状来自这一版本的实测。如果其他环境没有找到碰撞对，脚本应停止，不能宣称已经验证碰撞复核。即使换个环境找到另一组键，语义要求仍然不变：精确相等只能返回原始值符合条件的记录；修改一个值，不得因为另一个值哈希相同而改变它。固定的结果契约比固定某个内部哈希码更重要。

把维护也放进性能评估

使用有代表性的分布一起测量页面访问、等值延迟、更新行为和索引大小。VACUUM 可以移除失效引用、回收溢出页供结构内部复用，但不会缩小哈希索引的桶数量，也不会把这部分分配直接归还操作系统。重建属于另外的维护操作，本身需要成本。较小的哈希条目确实可能有价值，但只有完整负载比较才能判断它是否抵得过复核、溢出页和写维护开销。

来源

PostgreSQL 18：哈希索引，碰撞复核与桶维护，已核验 2026-09-10。
PostgreSQL 18：索引类型，B-tree 与哈希索引支持的条件，已核验 2026-09-10。

一致性哈希减少重新映射

Sun, 19 Sep 2027 00:00:00 +0000

一致性哈希限制成员变化时的数据放置变化，但它本身不搬运数据、不让副本达成一致，也不把单个热键的请求自动分散。经典顺时针哈希环把键交给哈希位置之后遇到的第一个节点点位；如果位置恰好相等，就归该点，超过最大点位则绕回最小点位。理解这个查找方向，是判断迁移范围的前提。

先把归属区间画对

一个点拥有的是前驱之后到自身为止的区间，即 (前驱, 当前点]。假设 A 位于 20，B 位于 50，C 位于 80，那么 B 负责大于 20 且不大于 50 的位置；超过 80 的键绕回 A。这不是从 B 到其后继 C 的弧段，左右端点是否包含也不是可以随意改变的细节。

在 35 加入 D，它从顺时针后继 B 手中取得大于 20 到 35 的位置；移除 B，则将 B 原来负责的区间交给 C。未受影响的点位保持原位置及归属，这才是算法有用的性质。仅说“移动一小段弧”还不够，因为原来某段弧可能就占据整个环的很大一部分。

作为对照，直接用 hash(key) 对节点数量取模来选择数组下标，新增节点会改变除数，很多键随之选到别的下标。四个等容量且平衡的节点扩到五个时，理想哈希环大约需要迁移五分之一的键，但真实迁移比例取决于点位与键分布，不能把这个比例当成所有部署都成立的保证。

虚拟节点分散区间，不拆分单个键

为每台物理节点分配多个环上点位，通常能减轻少量随机点造成的不平衡。每台机器持有多个较小区间，新节点可以从不同邻居取得一部分归属；不同容量还可以通过权重分配不同数量的点。但点越多，路由表的内存和维护工作也会增加，并非只有收益没有成本。

在本文的主归属模型中，一个键仍然只选择一台物理机器。如果绝大部分请求都针对这个键，增加虚拟节点不会让这些请求自动跨机器分担。即使每台机器的键数量接近，也不意味着字节数、请求频率或处理成本接近。复制、读流量分配和热键处理需要另外的策略。

稳定性也不等于平衡。所有参与方需要对成员集合、持久节点身份、键的字节编码、哈希规则和点数达成一致。稳定摘要可以让大家重现位置，却无法弥补成员视图不同或工作负载倾斜。如果每次成员变化都重新生成全部旧节点的点，保持既有归属的性质也就被破坏了。

放置结果不是迁移协议或一致性协议

路由算出了新归属，不代表缓存值或持久数据已经到达新节点。缓存可能经历未命中和源站负载上升，持久存储则需要数据迁移与所有权切换协议。发布期间仍使用旧环和已经使用新环的客户端，可能对同一个键作出不同选择；恢复与同步语义要由外围系统解决。

实际产品还使用不同算法和元数据。Redis Cluster 重新分配固定哈希槽的归属，并不是本文这种直接映射节点点位的环；Cassandra 还叠加副本放置和 token 管理规则，Envoy 则用哈希选择上游服务。不能从一个产品的放置示意图，推导另一个产品的故障安全保证。

坏掉的样子

每台机器只有一个点时可能严重失衡，重命名节点也可能意外迁移其点位。改变字节编码或哈希配置，即使没有任何机器加入，也能让大量键重新分配。应把这些映射输入视为部署配置，并在发布前比较新旧归属，而不是只检查服务进程是否正常运行。

还应把迁移键数、迁移字节数和真实请求流量分开测量。虚拟节点改善的是统计上的放置分布，不保证最大负载上界。成员频繁变化时，应为数据迁移或冷缓存回源预留资源，并检查客户端如何学习新视图。放置计算实验不能代替可用性与数据完整性验收。

快速验证

把以下代码保存为 ring_check.py，使用 Python 3.10 以上版本执行 python3 ring_check.py。本例已用 Python 3.14.4 运行，只依赖标准库，不启动服务，也不进行网络请求或文件写入。固定的 SHA-256 和明确的 UTF-8 输入，让生成的测试数据可以复现。

from bisect import bisect_left
from collections import Counter
from hashlib import sha256


def token(value):
 return int.from_bytes(sha256(value.encode("utf-8")).digest(), "big")


def ring(nodes, copies):
 entries = sorted(
 (token(f"node:{node}:{copy}"), node)
 for node in nodes for copy in range(copies)
 )
 positions, owners = zip(*entries)
 assert len(set(positions)) == len(positions), "fixture token collision"
 return positions, owners


def lookup(layout, position):
 positions, owners = layout
 return owners[bisect_left(positions, position) % len(positions)]


simple = ((20, 50, 80), ("A", "B", "C"))
joined = ((20, 35, 50, 80), ("A", "D", "B", "C"))
removed = ((20, 80), ("A", "C"))
assert [lookup(simple, value) for value in (0, 20, 21, 50, 51, 80, 81)] == [
 "A", "A", "B", "B", "C", "C", "A",
]
for value in range(100):
 assert lookup(joined, value) == ("D" if 20 < value <= 35 else lookup(simple, value))
 assert lookup(removed, value) == ("C" if 20 < value <= 50 else lookup(simple, value))
assert lookup(joined, 35) == "D"
assert lookup(removed, 50) == "C"
print("a point owns (predecessor, point]; lookups wrap clockwise")

nodes = ("A", "B", "C", "D")
positions = [token(f"key:{index}") for index in range(20000)]
base = ring(nodes, 256)
expanded = ring(nodes + ("E",), 256)
contracted = ring(tuple(node for node in nodes if node != "B"), 256)
assert base == ring(tuple(reversed(nodes)), 256)
before = [lookup(base, position) for position in positions]
after_add = [lookup(expanded, position) for position in positions]
after_remove = [lookup(contracted, position) for position in positions]
add_count = sum(old != new for old, new in zip(before, after_add))
remove_count = sum(old != new for old, new in zip(before, after_remove))
assert 0 < add_count < len(positions)
assert add_count == after_add.count("E")
assert all(old == new or new == "E" for old, new in zip(before, after_add))
assert remove_count == before.count("B")
assert all(old == new or old == "B" for old, new in zip(before, after_remove))
modulo_count = sum(
 nodes[position % 4] != (nodes + ("E",))[position % 5]
 for position in positions
)
print(f"add E: {add_count}/20000 keys move ({add_count / 200:.2f}%)")
print(f"remove B: {remove_count}/20000 keys move ({remove_count / 200:.2f}%)")
print(f"modulo 4 -> 5: {modulo_count}/20000 keys move ({modulo_count / 200:.2f}%)")

single = ring(nodes, 1)
for label, layout in (("one point", single), ("256 points", base)):
 counts = Counter(lookup(layout, position) for position in positions)
 print(label, {node: counts[node] for node in nodes})

hot_owner = lookup(base, token("key:hot"))
synthetic_requests = Counter(before)
synthetic_requests[hot_owner] += 100000
assert synthetic_requests[hot_owner] == before.count(hot_owner) + 100000
print("100000 extra requests for one hot key all target", hot_owner)
print("synthetic request counts", dict(sorted(synthetic_requests.items())))

整数例子检查了从零到 99 的每个位置，覆盖区间端点和绕环情况。对 20,000 个确定生成的键，每台节点配置 256 个点时，新增 E 迁移 4,023 个键，移除 B 迁移 4,895 个，而取模方式扩容迁移 16,013 个。断言还要求新增造成的所有迁移都流向 E，删除造成的所有迁移都来自 B，验证的不只是数量看起来变少。

输出中的数量展示了这组数据使用 256 个点后的平衡改善，不是普遍的负载上界。再给一个热键增加 100,000 次合成请求，它们仍全部指向 D。这些是计算出来的归属和需求计数，并非实际发送的生产请求，也没有测量网络搬运字节数或故障恢复时间。

来源

Apache Cassandra 的 Dynamo 架构，顺时针归属、token 区间和虚拟节点，已核验 2026-09-08。
Envoy 负载均衡算法，环哈希、稳定节点身份、权重和分布，已核验 2026-09-08。
Python hashlib，可移植的 SHA-256 摘要构建，已核验 2026-09-08。
Redis Cluster 规范，采用固定槽映射的另一种放置设计，已核验 2026-09-08。

Redis 哈希把相关字段收拢在一个键下

Sat, 13 Mar 2027 00:00:00 +0000

Redis 哈希把多个字段名及其字节值放在一个键下，适合按属性独立读取或修改的对象，例如拥有姓名和积分的用户资料。HGET 与 HSET 各自都只需要一条命令，并不会因为多了一层字段组织，就天然比字符串多一次网络往返。类型选择的依据是实际访问粒度，而不是把内部结构想象成额外的远程查询。

只读取和更新目标字段

HGET 获取一个字段，HMGET 按请求顺序获取指定字段，HGETALL 则返回所有字段和值。Redis 不会自动把某个字段值解释为嵌套对象，不会把带点的字段名当作对象路径，也不会自动为任意属性组合建立查询索引。字段如何命名、值如何序列化，仍然由应用负责。

HSET 可以在一条命令里写多个字段，未指定的字段不会被替换。它的整数返回值统计新增字段数，而不是所有发生变化的值：更新已有字段即使成功，也可以返回零。HDEL 返回实际删除的字段数；最后一个字段删除后，整个哈希键也会消失。因此，不能用一个没有字段的哈希作为长期存在的占位对象。

字段缺失和空值是两种状态。redis-py 关闭自动解码时，HMGET 对缺失字段返回 None，对已存在但内容为空的字段返回空字节串。直接用真假值判断会混淆两者，应按明确的返回值区分。HGETALL 对小对象很方便，但处理量和响应大小会随整个哈希增长；调用方只需要几个属性时，应该直接读取这些字段，避免每次搬运全部数据。

过期时间分为两层

键级过期会删除整个哈希，HSET 会保留该键已有的截止时间。从 Redis 7.4 开始，还可以通过 HEXPIRE 和 HPEXPIRE 给单个字段设置期限。普通 HSET 覆盖字段时会清除这个字段自己的过期时间，HINCRBY 则保留被修改字段的已有期限。字段 TTL 返回 -1，只表示它没有独立的字段期限，不代表它能逃过父键到期后整体删除。

Redis 8.0 及更新版本提供 HSETEX，可以把字段值与字段期限放在同一条命令里写入；其 KEEPTTL 选项能在替换字段值时保留已有字段截止时间。先 HSET、再 HPEXPIRE 仍然是两条操作，中间失败会产生值已经变更、期限尚未附加的窗口。应根据希望保留、重置还是新建期限来选命令，并在采用字段过期能力前核对实际部署版本，不能把键级与字段级期限混为一谈。

坏掉的样子

局部更新可以避免无意覆盖其他属性，却不能让 HGET、本地计算和 HSET 自动合并成一个原子操作。两个客户端可能先读到相同积分，各自加一后写回同一个结果，于是实际少计了一次。HINCRBY 把整数变更放在一条命令内完成，并拒绝非法整数内容。如果业务要求多个字段共同满足某个条件，仍需明确的原子操作协议，单纯把数据放入哈希并不能提供这种保证。

序列化的 JSON 字符串仍是字符串，对它执行 HGET 会报 WRONGTYPE。另一方面，单字段很大或字段数量不受控，也会增加传输和操作成本。一个哈希仍然是一个 Redis 键，不会自动成为跨节点拆分的数据方案。应用始终整块交换载荷时，可以使用不透明字符串；只有确实按属性独立访问，哈希带来的局部读写能力才有实际价值。

快速验证

原有实验记录使用 macOS、Python 3.14.4、Redis 8.10.1 和 redis-py 8.1.0；本轮审阅没有重新执行服务实验，下面的结果说明保留原有观察范围。准备 POSIX 环境、C 编译器、make、curl、tar 与 Python 3.10 或更新版本。安装步骤仅用 libc 构建 Redis 核心，并把客户端装入临时虚拟环境。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

在同一个终端使用 "$redis_lab/venv/bin/python" 执行下面的 Python 代码。临时 Redis 仅通过 /tmp 下的私有 Unix socket 通信，不开放 TCP，不安排快照，也不启用追加日志。程序退出时关闭自己的客户端，终止自己创建的进程，再移除临时运行目录。下载依赖需要网络，实验不会访问默认本机 Redis，也不会清理其他实例的数据。

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance():
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", "noeviction",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()



with instance() as client:
 assert client.hset("profile", mapping={
 "name": b"Ada", "score": b"0", "empty": b"",
 }) == 3
 assert client.hset("profile", "name", b"Ada L") == 0
 assert client.hmget("profile", ["name", "empty", "missing"]) == [
 b"Ada L", b"", None,
 ]
 assert client.hlen("profile") == 3
 print("HSET reports added fields, not updates; empty bytes differ from None")

 assert client.pexpire("profile", 60000)
 key_deadline = client.pexpiretime("profile")
 assert client.hpexpire("profile", 30000, "name", "score") == [1, 1]
 field_deadlines = client.hpexpiretime("profile", "name", "score")
 assert all(value > 0 for value in field_deadlines)
 assert client.hset("profile", "name", b"Grace") == 0
 assert client.pexpiretime("profile") == key_deadline
 assert client.hpttl("profile", "name") == [-1]
 assert client.hincrby("profile", "score", 1) == 1
 assert client.hpexpiretime("profile", "score") == [field_deadlines[1]]
 print("HSET keeps key TTL but clears its field TTL; HINCRBY keeps field TTL")

 assert client.hsetex("session", mapping={"token": b"A"}, px=60000) == 1
 token_deadline = client.hpexpiretime("session", "token")
 assert token_deadline[0] > 0
 assert client.hsetex("session", mapping={"token": b"B"}, keepttl=True) == 1
 assert client.hget("session", "token") == b"B"
 assert client.hpexpiretime("session", "token") == token_deadline
 print("HSETEX writes field value and TTL together; KEEPTTL preserves its deadline")

 client.hset("race", "score", 0)
 a = int(client.hget("race", "score"))
 b = int(client.hget("race", "score"))
 client.hset("race", "score", a + 1)
 client.hset("race", "score", b + 1)
 assert client.hget("race", "score") == b"1"
 client.hset("race", "score", 0)
 assert client.hincrby("race", "score", 1) == 1
 assert client.hincrby("race", "score", 1) == 2
 print("controlled stale-read schedule loses an update; two HINCRBY calls yield 2")

 client.hset("bad", "score", b"3.5")
 try:
 client.hincrby("bad", "score", 1)
 except redis.ResponseError:
 pass
 else:
 raise AssertionError("HINCRBY requires an integer")
 assert client.hget("bad", "score") == b"3.5"
 client.set("blob", b'{"name": "Ada"}')
 try:
 client.hget("blob", "name")
 except redis.ResponseError as error:
 assert "WRONGTYPE" in str(error)
 else:
 raise AssertionError("a serialized string is not a Redis hash")
 print("invalid counters and wrong key types are rejected")

 client.hset("single", "field", b"value")
 assert client.hdel("single", "missing") == 0
 assert client.hdel("single", "field") == 1
 assert client.exists("single") == 0
 print("HDEL of the last field removes the key")

第一次 HSET 新增三个字段，返回三；第二次成功替换姓名，返回零。HMGET 的结果保留了空字节串与缺失值的区别。比较绝对截止时间可以看到，修改姓名保留了整键期限，却移除了姓名字段的独立期限；积分自增仍保留原字段期限。HSETEX 则验证了字段值和期限一次写入，以及随后在替换值时保留相同截止时间。

丢失更新部分刻意安排了两个假想客户端的读写交错，是可确定复现的操作顺序，不是多线程并发压测。两次先读后写最终只得到一，两条 HINCRBY 得到二。非法计数值和错误键类型均被拒绝；删除唯一字段后，对应键不再存在。这些断言证明的是命令行为，不是内存效率、吞吐量、集群扩展效果，也不能保证网络失败后重试不会重复计数。

来源

Redis 哈希，字段式数据建模与命令行为，已核验 2026-09-08。
Redis HSET，局部更新与新增字段计数，已核验 2026-09-08。
Redis HEXPIRE，字段期限与覆盖行为，已核验 2026-09-08。
Redis HSETEX，字段值和过期时间的原子更新及 KEEPTTL，已核验 2026-09-08。
Redis HDEL，删除计数及最后一个字段的清理，已核验 2026-09-08。
Redis 8.10.1 构建说明，只编译核心及分配器选择，已核验 2026-09-08。

哈希 · XB 现场笔记

哈希索引复核碰撞，也要维护变化的键

桶里究竟保存什么

坏掉的样子

快速验证

把维护也放进性能评估

来源

一致性哈希减少重新映射

先把归属区间画对

虚拟节点分散区间，不拆分单个键

放置结果不是迁移协议或一致性协议

坏掉的样子

快速验证

延伸阅读

来源

Redis 哈希把相关字段收拢在一个键下

只读取和更新目标字段

过期时间分为两层

坏掉的样子

快速验证

来源