Lamport 逻辑时钟如何用「happened-before」关系给分布式事件排序，它能否反映真实物理时间？
How do Lamport logical clocks order distributed events using the happened-before relation, and do they reflect real physical time?
逻辑时钟在进程内递增、在消息发送接收时取最大值加一，使若事件 a 先于 b 则 C(a)<C(b)。它只捕捉因果先后而不保证与物理时间一致，相同时间戳的事件可能并无因果关系，需向量时钟才能区分并发。
A logical clock increments within a process and on message send/receive takes the maximum plus one, so if event a happened before b then C(a)<C(b). It captures only causal order, not physical time; events with equal timestamps may be concurrent and require vector clocks to distinguish.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
Brewer 2000；Gilbert & Lynch 2002；Coulouris《分布式系统》
Brewer (2000); Gilbert & Lynch (2002); Coulouris, Distributed Systems
独立核验依据 · Independent verification: 核验依据 1 OPENLIBRARY 标识 /works/OL3609847W：Distributed systems（首版
#逻辑时钟 #happened-before #因果
实用拜占庭容错（PBFT）如何在存在 f 个恶意节点时仍达成共识，复杂度是多少？
How does practical Byzantine fault tolerance (PBFT) reach consensus despite f malicious nodes, and what is its complexity?
PBFT 要求节点总数 n≥3f+1，通过三阶段协议（pre-prepare、prepare、commit）使诚实节点就顺序达成一致。它容忍少于三分之一的拜占庭节点，每轮通信复杂度约为 O(n^2)。
PBFT requires n≥3f+1 nodes and uses a three-phase protocol (pre-prepare, prepare, commit) so honest nodes agree on ordering. It tolerates fewer than one third Byzantine nodes, with per-round communication complexity about O(n^2).
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 已核验 · Verified 2026-10-04
来源 · Source
Castro & Liskov, Practical Byzantine Fault Tolerance, USENIX OSDI 1999
Castro & Liskov, Practical Byzantine Fault Tolerance, USENIX OSDI 1999
独立核验依据 · Independent verification: 核验依据 1 DOI 10.1109/dsn.2001.941437
#PBFT #拜占庭容错 #共识
Paxos 算法如何保证即使部分节点失效或消息乱序，也只会选定唯一一个值（安全性）？
How does Paxos guarantee safety, i.e. that only a single value is ever chosen even if nodes fail or messages arrive out of order?
Paxos 通过「提议编号全序」与「接受者只接受编号更大的提议、且必须承诺曾见过的最大编号值」来保证安全性。只要多数派（quorum）相交，新选定的值必与已选定的值一致，从而杜绝分裂选定。
Paxos uses a total order on proposal numbers and the rule that acceptors only accept higher-numbered proposals while promising the highest-numbered value they have seen. Because any two quorums intersect, a newly chosen value must match an already chosen one, preventing split decisions.
难度 专业 · 适合 初中(12-15)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：本题原挂出处与答案内容不符，已撤回；具体书目待补，暂不展示来源。
本题原挂出处与答案内容不符，已撤回；具体书目待补。
Previous citation withdrawn as unsupported for this answer; a specific source is pending.
#Paxos #共识 #安全性
两支军队约好一起进攻却永远无法确保协同,拜占庭将军凭什么能做到?
Two armies can never coordinate an attack by messenger alone — why can Byzantine generals manage it?
两将军问题揭示不可靠信道的死结:「信使可能被杀」与「是否真已谈妥」互成循环怀疑,数学上无解。拜占庭将军更进一步——叛徒不仅丢消息还主动撒谎。冷峻结论:仅凭口头消息,容忍f个叛徒须N≥3f+1;有不可伪造签名则大幅放宽。Raft以多数派日志复制容忍宕机却不容忍作恶,比特币以算力成本模拟忠诚。容错的代价永远是冗余。
The two-generals problem exposes a deadlock on unreliable channels: lost messengers and provable agreement breed circular doubt no protocol can break — mathematically unsolvable. Byzantine generals go further: traitors not only drop messages but lie. The verdict stays cold: with bare oral messages tolerating f traitors takes N at least 3f+1, sharply relaxed once unforgeable signatures exist. Raft tolerates crashes via majority log replication but never treachery; Bitcoin simulates loyalty with computation cost. Redundancy is the eternal price of fault tolerance.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 已核验 · Verified 2026-11-04
来源 · Source
Lamport, Shostak, Pease,《The Byzantine Generals Problem》,ACM Transactions on Programming Languages and Systems,1982 (DOI: 10.1145/357172.357176)
Lamport, Shostak, Pease, 'The Byzantine Generals Problem', ACM Transactions on Programming Languages and Systems, 1982, DOI: 10.1145/357172.357176
独立核验依据 · Independent verification: 核验依据 1 Crossref DOI 10.1145/357172.357176
#拜占庭将军 #共识协议 #容错
Raft 如何选出集群领导人，任期（term）号起什么作用？
How does Raft elect a cluster leader, and what is the role of the term number?
Raft 中节点在超时未收到心跳时转为候选者并发起选举，获得多数票者成为领导人，任期号随之递增。任期号作为逻辑时钟标识领导代次，能快速检测并废弃过期领导人的决策。
In Raft a node that times out without a heartbeat becomes a candidate and starts an election; the one receiving a majority of votes becomes leader and increments the term. The term acts as a logical clock marking leadership epochs, quickly detecting and invalidating stale leaders.
难度 进阶 · 适合 大众
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：此条未指向带版次的可引用著作（通识性内容、机构文件或未展开的英文书名），本库不提供独立书目出处；如需精确引用，需由编辑补全具体篇目与版次。
Ongaro & Ousterhout, In Search of an Understandable Consensus Algorithm (Raft), USENIX ATC 2014
Ongaro & Ousterhout, In Search of an Understandable Consensus Algorithm (Raft), USENIX ATC 2014
#Raft #领导人选举 #任期
最终一致性是什么，它与强一致性的体验差异在哪里？
What is eventual consistency, and how does its experience differ from strong consistency?
最终一致性保证若无新写入，副本经过一段时间后会收敛到相同值，但期间可能读到旧数据。它用暂时不一致换取高可用与低延迟，常见于 DNS 与大规模键值存储。
Eventual consistency guarantees that replicas converge to the same value after some time without new writes, but reads in between may return stale data. It trades temporary inconsistency for high availability and low latency, common in DNS and large key-value stores.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
G. DeCandia 等人论文 Dynamo：亚马逊的高可用键值存储，发表于 SOSP 2007，DOI: 10.1145/1294261.1294281
G. DeCandia et al., Dynamo: Amazon's Highly Available Key-value Store, Proc. SOSP 2007, DOI: 10.1145/1294261.1294281
独立核验依据 · Independent verification: 核验依据 1 CROSSREF 标识 10.1145/1294261.1294281：Dynamo（2007，按著录自报 DO
#最终一致性 #弱一致性 #可用性
两阶段提交（2PC）如何协调分布式事务的提交与回滚？
How does two-phase commit (2PC) coordinate commit and rollback of a distributed transaction?
协调者先让所有参与者准备并就绪（阶段一），全部同意后发出提交指令，否则统一回滚（阶段二）。它保证原子性，但协调者阻塞是主要缺陷：若协调者在提交前崩溃，参与者将不确定而长时间持锁。
The coordinator first asks all participants to prepare and vote (phase one); if all agree it issues a commit, otherwise it rolls back uniformly (phase two). It guarantees atomicity, but a key flaw is coordinator blocking: if the coordinator crashes before committing, participants stay uncertain and hold locks.
难度 进阶 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-11-02
来源 · Source
Bernstein, Hadzilacos, Goodman, Concurrency Control and Recovery in Database Systems, 1987
Bernstein, Hadzilacos, Goodman, Concurrency Control and Recovery in Database Systems, 1987
独立核验依据 · Independent verification: 核验依据 1 OPENLIBRARY 标识 /works/OL3350481W：Concurrency control and
#两阶段提交 #分布式事务 #原子性
一致性哈希如何减少节点增减时数据迁移的范围？
How does consistent hashing reduce the amount of data that must move when nodes are added or removed?
一致性哈希把节点和数据键都映射到同一个环形空间，每个键由顺时针第一个节点负责。增加或移除节点只影响环上相邻区间的数据，因而把重新映射范围从全部数据降到局部。
Consistent hashing maps both nodes and keys into the same ring, with each key owned by the first node clockwise. Adding or removing a node only affects the adjacent interval on the ring, so remapping touches local data instead of the whole dataset.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
G. DeCandia 等人论文 Dynamo：亚马逊的高可用键值存储，发表于 SOSP 2007，DOI: 10.1145/1294261.1294281
G. DeCandia et al., Dynamo: Amazon's Highly Available Key-value Store, Proc. SOSP 2007, DOI: 10.1145/1294261.1294281
独立核验依据 · Independent verification: 核验依据 1 CROSSREF 标识 10.1145/1294261.1294281：Dynamo（2007，按著录自报 DO
#一致性哈希 #分布式哈希 #负载均衡
CAP 定理指出分布式系统在分区发生时必须在什么之间取舍？
What trade-off does the CAP theorem say a distributed system must make when a partition occurs?
CAP 定理说明当网络分区发生时，系统无法同时保证一致性和可用性，只能二选一。在分区之外，系统仍可同时追求一致性与可用性，因此实践上多为分区时降级的选择题。
The CAP theorem states that when a network partition occurs, a system cannot simultaneously guarantee consistency and availability, and must choose one. Outside partitions the system can still pursue both, so in practice it is a choice of which to sacrifice during partitions.
难度 进阶 · 适合 高中(15-18)
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
Brewer 2000；Gilbert & Lynch 2002；Coulouris《分布式系统》
Brewer (2000); Gilbert & Lynch (2002); Coulouris, Distributed Systems
独立核验依据 · Independent verification: 核验依据 1 OPENLIBRARY 标识 /works/OL3609847W：Distributed systems（首版
#CAP定理 #一致性 #可用性
集群里一半机器断电了,数据为什么还能一字不差地活着?
Half the machines lose power — why does the data survive byte-for-byte intact?
因为写入从不只落在一台机器上。以Raft为代表的共识复制要求每次变更由领导者追加日志并并行发给跟随者,只有多数派(如5台中的3台)确认落盘才算提交、才对客户端可见。此后领导者猝死,幸存多数派中必有一台持有全部已提交日志,新领导者据此补齐其他节点。线性一致读也需多数派仲裁以防读到旧主的陈旧数据。跨机往返正是强一致存储延迟的下限来源。
Because writes never live on one machine. Consensus replication like Raft appends each change to the leader's log, fans it to followers, and commits only once a majority (say three of five) confirm persistence; only then is it applied and acknowledged. If the leader dies instantly, every surviving majority contains at least one node holding all committed entries, and the new leader reconciles everyone from that record. Linearizable reads also quorum-check to avoid stale answers from a partitioned ex-leader. The price: cross-machine round trips per write — precisely where strongly consistent storage latency floors come from.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：著录含书名，但缺版次 / 出版社 / 年份中的一部分，需编辑补全后才能做独立比对。
Ongaro 与 Ousterhout,《In Search of an Understandable Consensus Algorithm》,USENIX ATC,2014
D. Ongaro and J. Ousterhout, In Search of an Understandable Consensus Algorithm (Raft), USENIX ATC, 2014
#Raft #日志复制 #多数派提交