Raft 算法相比 Paxos 为什么更容易被人理解和实现？
Why is the Raft algorithm easier to understand and implement than Paxos?
Raft 把共识拆成领导者选举、日志复制和安全性三个独立子问题，并用随机超时等直观机制保证强领导者模型。Ongaro 与 Ousterhout 在 2014 年明确提出『可理解性』为首要设计目标，被 etcd、Consul 等采用。
Raft decomposes consensus into leader election, log replication, and safety, using an intuitive strong-leader model with randomized timeouts. Ongaro and Ousterhout made understandability the explicit top goal in 2014, and etcd and Consul adopted it.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：著录含书名，但缺版次 / 出版社 / 年份中的一部分，需编辑补全后才能做独立比对。
Ongaro 与 Ousterhout《Raft 共识算法》(USENIX ATC, 2014)
Ongaro & Ousterhout, 'In Search of an Understandable Consensus Algorithm (Raft)' (USENIX ATC, 2014)
#Raft #领导者选举 #日志复制 #可理解性
CAP 定理说的是什么？为什么在分区时只能三选二？
What does the CAP theorem state, and why can only two of three be chosen under partition?
CAP 定理由布鲁尔在 2000 年提出、并由吉尔伯特与林奇在 2002 年严格证明：分布式系统在网络分区发生时，无法同时保证一致性（C）与可用性（A），只能在二者间权衡。由于分区在真实网络中不可避免，实际系统常选择 CP（保一致）或 AP（保可用）。它是理解分布式数据库取舍的基础框架。
The CAP theorem, conjectured by Brewer in 2000 and proved by Gilbert and Lynch in 2002, states that when a network partition occurs, a distributed system cannot simultaneously guarantee Consistency (C) and Availability (A), forcing a trade-off. Since partitions are unavoidable in real networks, practical systems choose CP (consistency) or AP (availability). It is a foundational framework for understanding distributed database trade-offs.
难度 专业 · 适合 高中(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定理 #一致性 #可用性 #分区容错
Google 的 GFS 与 Bigtable 怎样支撑海量数据的存储与查询？
How do Google's GFS and Bigtable underpin storage and querying of massive data?
GFS 用廉价的普通服务器组成集群，把大文件切块复制到多台机器，以高吞吐应对失败频发的大规模顺序读写。Bigtable 在其上构建分布式的稀疏多维有序映射，按行键分片、按列族存储，支撑了搜索索引等应用。
GFS clusters cheap commodity servers, chunks files across machines with replication, trading latency for high throughput under frequent failures. Bigtable builds a distributed sparse, multidimensional sorted map on top, sharded by row key and stored by column family, powering search indexing and more.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 已核验 · Verified 2026-11-04
来源 · Source
Ghemawat 等《Google 文件系统》(SOSP, 2003)；Chang 等《Bigtable》(OSDI, 2006)
Ghemawat et al., 'The Google File System' (SOSP, 2003); Chang et al., 'Bigtable' (OSDI, 2006)
独立核验依据 · Independent verification: 核验依据 1 Crossref DOI 10.1145/945445.945450（本条出处含多部著作，按段登记，核到的是这一
#GFS #Bigtable #分片 #列式存储
什么是拜占庭故障？
What is a Byzantine fault?
拜占庭故障指系统中的节点可能任意出错甚至恶意谎报消息，就像将军们可能传递假情报。拜占庭容错（BFT）算法能在少数节点作恶时仍让诚实节点达成一致，是区块链共识的理论基础。
A Byzantine fault means nodes may fail arbitrarily or even lie maliciously, like generals sending false intelligence. Byzantine fault-tolerant (BFT) algorithms let honest nodes reach agreement even with some malicious ones—the theoretical basis of blockchain consensus.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：此条未指向带版次的可引用著作（通识性内容、机构文件或未展开的英文书名），本库不提供独立书目出处；如需精确引用，需由编辑补全具体篇目与版次。
Lamport、Shostak、Pease 1982 年拜占庭将军问题论文
Lamport, Shostak & Pease, The Byzantine Generals Problem (1982)
#拜占庭故障 #容错 #区块链
什么是共识算法（如 Paxos、Raft）？
What are consensus algorithms (e.g., Paxos, Raft)?
共识算法让分布式系统中的多个节点在部分节点可能故障的情况下，就某个值或操作顺序达成一致。Paxos 理论严谨但难懂，Raft 则以便理解和实现为目标。它们是构建高可靠分布式数据库和协调服务的基础。
A consensus algorithm lets nodes in a distributed system agree on a value or order of operations even when some nodes may fail. Paxos is theoretically rigorous but hard to grasp; Raft aims to be understandable and implementable. They underlie highly reliable distributed databases and coordination services.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：著录含书名，但缺版次 / 出版社 / 年份中的一部分，需编辑补全后才能做独立比对。
Ongaro 与 Ousterhout《Raft 共识算法》(USENIX ATC, 2014)
Ongaro & Ousterhout, 'In Search of an Understandable Consensus Algorithm (Raft)' (USENIX ATC, 2014)
#共识 #Paxos #Raft
Lamport 逻辑时钟解决了分布式系统中『谁先发生』的什么难题？
What problem of 'what happened first' does Lamport's logical clock solve in distributed systems?
物理时钟无法完美同步，因此 Lamport 在 1978 年用『发生在前』的偏序关系和逐消息递增的计数器，给事件标上全序标号。这使我们能判断事件的因果先后顺序，并辅助分布式排序与互斥等机制的实现。
Physical clocks cannot be perfectly synchronized; Lamport used a 'happened-before' partial order with counters that increment on each message, giving events a total order so causal precedence can be judged for distributed ordering and mutual exclusion. He introduced it in 1978.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：著录含书名，但缺版次 / 出版社 / 年份中的一部分，需编辑补全后才能做独立比对。
Lamport《时间、时钟与事件排序》(CACM, 1978)
Lamport, 'Time, Clocks, and the Ordering of Events' (CACM, 1978)
#逻辑时钟 #发生在前 #偏序 #全序
最终一致性（eventual consistency）是什么？它与强一致性有何不同？
What is eventual consistency, and how does it differ from strong consistency?
最终一致性是一种弱一致性模型：如果没有新的写入，经过一段时间后所有副本会自动收敛到相同状态，但期间可能读到旧值。它牺牲即时一致以换取高可用与低延迟，是 Amazon Dynamo 等大规模系统的设计选择，由沃赫尔斯在 2009 年系统阐述。强一致性则要求每次读都看到最新写入，代价是更高的协调开销。
Eventual consistency is a weak consistency model in which, if no new writes occur, all replicas converge to the same state after some time, though stale reads are possible in between. It trades immediate consistency for high availability and low latency, a design choice of large-scale systems like Amazon Dynamo, and was systematized by Vogels in 2009. Strong consistency requires every read to see the latest write, at the cost of higher coordination overhead.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Cormen, Leiserson, Rivest, Stein,《Introduction to Algorithms》第3版,MIT Press,2009
T. H. Cormen et al., Introduction to Algorithms, 3rd ed., MIT Press, 2009
独立核验依据 · Independent verification: 核验依据 2 ISBN 978-0-262-04630-5
#最终一致性 #强一致性 #Dynamo #可用性与一致性
设计一个支撑每秒数万笔交易的支付清结算系统时,如何保证分布式账本在多机房部署下的强一致性与可用性?
When designing a payment clearing and settlement system that sustains tens of thousands of transactions per second, how do you preserve strong consistency and availability for a distributed ledger across multiple data centers?
通常以 Paxos 或 Raft 等多数派共识协议作为账本写入的核心,配合分片将不同商户或渠道的流量路由到独立共识组,避免单一组的带宽成为瓶颈。跨机房部署时按地域放置多数派副本,并用区域内的本地仲裁降低提交延迟,跨区仅同步日志流。对账与冲正走异步通道,日切批处理通过幂等流水号保证重复执行不产生二次记账。
Most designs anchor ledger writes in a majority-quorum protocol such as Raft or Paxos and shard traffic by merchant or channel so each consensus group handles an independent slice of load. For multi-site deployment the majority replicas are placed across regions while local quorums absorb commits at low latency, with only the log stream replicated cross-region. Reconciliation and reversals run asynchronously over idempotent transaction IDs so replays never double-post.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：此条未指向带版次的可引用著作（通识性内容、机构文件或未展开的英文书名），本库不提供独立书目出处；如需精确引用，需由编辑补全具体篇目与版次。
Spanner：Google全球分布式数据库，OSDI 2012
Corbett et al., Spanner: Google's Globally-Distributed Database, OSDI, 2012
#支付系统 #分布式共识
什么是一致性哈希？
What is consistent hashing?
一致性哈希是一种把数据均匀分布到多台服务器的映射方法，把节点和数据都放在一个虚拟环上。当某台服务器加入或退出时，只需迁移少量相邻数据，而不是全部重新分配。它广泛用于缓存和分布式存储系统。
Consistent hashing is a way to map data evenly across servers by placing both nodes and data on a virtual ring. When a server joins or leaves, only a small amount of neighboring data moves, not everything. It is widely used in caching and distributed storage.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Tanenbaum & Bos,《Modern Operating Systems》第4版,Pearson,2014
A. S. Tanenbaum and H. Bos, Modern Operating Systems, 4th ed., Pearson, 2014
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL1970688W：Modern Operating System
#一致性哈希 #缓存 #分布式
什么是消息队列？
What is a message queue?
消息队列在多个程序之间传递消息，发送方把任务放入队列，接收方按自己的节奏取出处理，实现解耦和削峰。常见系统有 Kafka、RabbitMQ。它能提升系统的稳定性和可伸缩性。
A message queue passes messages between programs: the sender puts tasks into the queue, and the receiver takes them at its own pace, enabling decoupling and load smoothing. Common systems include Kafka and RabbitMQ. It improves system stability and scalability.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Tanenbaum & Bos,《Modern Operating Systems》第4版,Pearson,2014
A. S. Tanenbaum and H. Bos, Modern Operating Systems, 4th ed., Pearson, 2014
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL1970688W：Modern Operating System
#消息队列 #异步 #解耦
MapReduce 是怎样让普通工程师也能写大规模并行数据处理的？
How does MapReduce let ordinary engineers write large-scale parallel data processing?
用户只写 map（把输入映射成键值对）和 reduce（按键聚合）两个函数，框架负责把任务切分到成百上千台机器、处理失败重试与数据混洗。Dean 与 Ghemawat 在 2004 年提出，催生了 Hadoop 等生态。
You write just a map function (emit key-value pairs) and a reduce function (aggregate by key); the framework shards work across thousands of machines and handles failures and shuffling. Dean and Ghemawat introduced it in 2004 and it spawned the Hadoop ecosystem.
难度 进阶 · 适合 高中(15-18)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：著录含书名，但缺版次 / 出版社 / 年份中的一部分，需编辑补全后才能做独立比对。
Dean 与 Ghemawat《MapReduce: 大规模数据处理》(OSDI, 2004)；Google 内部实践
Dean & Ghemawat, 'MapReduce: Simplified Data Processing' (OSDI, 2004); Google engineering
#MapReduce #map #reduce #并行处理
一致性哈希（consistent hashing）和分布式哈希表（DHT）解决什么问题？
What problems do consistent hashing and distributed hash tables solve?
一致性哈希把节点和键都映射到一个环形空间，使节点增减时只需重定位少量数据，避免传统哈希大规模重新分片，常用于缓存与负载均衡（卡格等 1997）。分布式哈希表（如 Chord，Stoica 等 2001）则用类似思想在大量机器上分散存储与查找键值，支撑去中心化系统。二者都让分布式存储能平滑扩缩容。
Consistent hashing maps both nodes and keys onto a ring so that adding or removing a node only relocates a small fraction of data, avoiding massive re-sharding of traditional hashing; it is used in caching and load balancing (Karger et al. 1997). Distributed hash tables like Chord (Stoica et al. 2001) apply similar ideas to store and look up key-value pairs across many machines, supporting decentralized systems. Both let distributed storage scale smoothly.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-11-04
来源 · Source
Karger 等 1997；Stoica 等 2001（Chord，SIGCOMM）
Karger et al. (1997); Stoica et al. (2001), Chord, SIGCOMM
独立核验依据 · Independent verification: 核验依据 1 Crossref DOI 10.1145/964723.383071（复合著录按段核验：本标识只担保第二段 St
#一致性哈希 #分布式哈希表 #Chord #平滑扩缩容
支付系统为什么坚持复式记账而非直接维护一个余额字段?工程上如何保证一笔交易恰好入账一次?
Why do payment systems insist on double-entry bookkeeping instead of simply maintaining a balance field, and how do engineers guarantee a transaction is posted exactly once?
复式记账要求每笔交易的借贷两条分录金额恒等,任何单边错误都会打破守恒不变量,使审计和对账有据可依。幂等通常由客户端生成的请求 ID 配合数据库唯一索引实现,重试只会返回首次结果而不会重复入账。余额从不可变流水推导,或用快照加增量回放计算,避免并发写覆盖。
Double-entry demands that every transaction post debit and credit legs of equal amount, so any single-sided error violates a conservation invariant and gives audits and reconciliation solid ground. Idempotency is enforced with a client-generated request ID backed by a unique index, so retries return the original result instead of posting twice. Balances derive from immutable entries, either computed directly or via snapshots replayed incrementally, avoiding concurrent write-overwrite bugs.
难度 进阶 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-11-02
来源 · Source
Martin Kleppmann《Designing Data-Intensive Applications》第 7 章;Stripe API 文档 Idempotency Keys 章节
Martin Kleppmann, Designing Data-Intensive Applications, ch. 7; Stripe API documentation, Idempotency Keys section
独立核验依据 · Independent verification: 核验依据 1 OPENLIBRARY 标识 /works/OL19293745W：Designing Data-Intensi
#金融科技 #复式记账
事件驱动架构中的最终一致性是什么含义？它为什么常与发布-订阅消息机制搭配使用，又会带来哪些代价？
What does eventual consistency mean in event-driven architecture, and why is it often paired with publish-subscribe messaging, at what cost?
最终一致性指服务发出领域事件后不再同步等待所有下游更新，若无新事件产生，各副本状态终将收敛到一致。事件经发布-订阅代理（如 Kafka 主题）分发给多个订阅方，生产者与消费者解耦，可独立扩展和部署，天然契合该模型。代价是存在读到旧数据的时间窗、需处理消息重复与乱序，排障也更依赖事件溯源与关联追踪。
Eventual consistency means a service publishes domain events without synchronously waiting for every downstream update; absent new events, all replicas converge to the same state. Events flow through a publish-subscribe broker such as a Kafka topic, decoupling producers from consumers so each scales and deploys independently—a natural fit. The price is a window of stale reads, plus the need to handle duplicate and out-of-order messages, with troubleshooting leaning on event sourcing and correlation tracing.
难度 进阶 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
L. Bass、P. Clements、R. Kazman《软件构架实践》第3版质量属性与战术相关章节（Addison-Wesley, 2012）
L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 3rd ed., quality attributes and tactics chapters (Addison-Wesley, 2012)
独立核验依据 · Independent verification: 核验依据 1 OPENLIBRARY 标识 /works/OL2658332W：Software architecture i
#软件架构 #事件驱动 #最终一致性 #发布订阅
Paxos 共识算法解决什么问题？
What problem does the Paxos consensus algorithm solve?
Paxos 是在可能发生节点崩溃或消息丢失的异步网络中，让一组节点就某个值达成一致（共识）的算法，即使少数节点失效也能保证安全。它由兰波特在 1998 年的《兼职议会》中形式化，是后续多数分布式协调系统（如 Google Chubby）的理论基础。其难点在于证明与实现都相当复杂。
Paxos is an algorithm that lets a group of nodes agree on a single value (consensus) in an asynchronous network with possible crashes and lost messages, remaining safe even if a minority fails. Formalized by Lamport in his 1998 'The Part-Time Parliament', it underpins many distributed coordination systems such as Google's Chubby. Its difficulty lies in both proof and implementation being notoriously complex.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：此条未指向带版次的可引用著作（通识性内容、机构文件或未展开的英文书名），本库不提供独立书目出处；如需精确引用，需由编辑补全具体篇目与版次。
Lamport 1998；Google Chubby（Burrows 2006）
Lamport (1998); Google Chubby (Burrows 2006)
#Paxos #共识算法 #兰波特 #分布式协调
什么是容错？
What is fault tolerance?
容错指系统在部分组件出错（如硬盘损坏、网络中断）时仍能继续正确运行的能力。常用手段包括冗余备份、副本和自动切换。它是分布式系统和关键基础设施的核心目标之一。
Fault tolerance is a system's ability to keep running correctly when some components fail, such as disk damage or network outage. Common means include redundancy, replicas, and automatic failover. It is a core goal of distributed systems and critical infrastructure.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Tanenbaum & Bos,《Modern Operating Systems》第4版,Pearson,2014
A. S. Tanenbaum and H. Bos, Modern Operating Systems, 4th ed., Pearson, 2014
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL1970688W：Modern Operating System
#容错 #冗余 #可靠
什么是分布式系统？
What is a distributed system?
分布式系统由多台通过网络协作的计算机组成，对外看起来像一个整体，共同完成某项任务。它能通过增加机器来提升性能和可靠性，例如大型网站和云服务。难点在于处理机器故障和网络延迟。
A distributed system consists of multiple computers collaborating over a network that appears as a single coherent system to users, jointly completing a task. It scales performance and reliability by adding machines, as in large websites and cloud services. The hard part is handling machine failures and network delays.
难度 入门 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Tanenbaum & Bos,《Modern Operating Systems》第4版,Pearson,2014
A. S. Tanenbaum and H. Bos, Modern Operating Systems, 4th ed., Pearson, 2014
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL1970688W：Modern Operating System
#分布式 #网络 #协作