野花免费资源观看_上海企业招聘_百度竞价推广什么意思_推广方案如何写

---

1. Consistency Guarantees

Key Idea:
Systems must define what consistency means in their context, balancing between strict guarantees and practical performance.

• Eventual Consistency:

  • Definition: All replicas eventually converge to the same state if no new writes occur.
  • Use Case: Suitable for high availability (e.g., DNS, social media feeds).
  • Trade-off: Temporary inconsistencies may occur (“read your own writes” problem).

• Linearizability:

  • Definition: A strong consistency model where operations appear atomic and ordered in real time.
  • Requirements:
    • All reads reflect the most recent write.
    • No operation can observe intermediate states.
  • Challenges:
    • High latency due to coordination.
    • Conflicts with availability during network partitions (CAP theorem).

---

2. Linearizability (Strong Consistency)

Core Mechanics:

• Real-Time Order: Operations have a global timeline. If operation A completes before B starts, B sees A’s effects.
• Use Cases:
  • Lock services (e.g., ZooKeeper).
  • Leader election in consensus protocols.
• Implementation:
  • Synchronous replication (e.g., primary-replica systems with quorum writes).
  • Requires atomic broadcast or consensus protocols (e.g., Raft, Paxos).

Trade-offs:

• Performance: High latency due to coordination.
• Availability: Violates CAP theorem during partitions (CP systems).
• Complexity: Hard to scale in geographically distributed systems.

---

3. Ordering Guarantees

Why Order Matters:

• Causality preservation (e.g., replying to a message after it was sent).

• Replica synchronization (e.g., log replication in databases).

• Total Order:

  • All nodes agree on the exact sequence of operations.
  • Required for linearizability.
  • Example: Primary node serializing writes in a single-leader replication system.

• Partial Order:

  • Operations may not have a global sequence.
  • Used in conflict-free replicated data types (CRDTs).
  • Example: Version vectors in Dynamo-style systems.

---

4. Distributed Transactions and Consensus

Atomic Commit & 2PC:

• Two-Phase Commit (2PC):
  • Phase 1: Coordinator asks all participants to prepare.
  • Phase 2: Commit or abort based on participants’ votes.
  • Weaknesses:
    • Coordinator failure can block transactions indefinitely.
    • Not partition-tolerant (violates CAP).

Fault-Tolerant Consensus:

• Paxos:

  • Uses quorums and proposals to agree on values.
  • Complex to implement but widely studied.
  • Optimized for “safety over liveness.”

• Raft:

  • Leader-based protocol with log replication.
  • Easier to understand than Paxos.
  • Used in etcd, Consul, and Kubernetes.

• Zab:

  • Used in ZooKeeper.
  • Combines leader election with atomic broadcast.

FLP Impossibility:

• In asynchronous networks, no consensus algorithm can guarantee termination (liveness) under all failure scenarios.
• Workarounds: Timeouts and practical assumptions about network reliability.

---

5. Consensus in Practice

Applications:

• Leader Election: Ensuring only one node acts as leader (e.g., Raft).
• Atomic Broadcast: Replicating logs consistently (e.g., Kafka with ISR).
• Distributed Locks: Linearizable locks for coordination (e.g., ZooKeeper).

Challenges:

• Byzantine Faults:
  • Nodes may act maliciously (rarely handled in classic consensus protocols).
  • Requires BFT protocols (e.g., PBFT), common in blockchain systems.
• Performance Overhead:
  • Quorum writes increase latency.
  • Trade-off between consistency and throughput.

---

6. CAP Theorem Revisited

Key Takeaways:

• In a partition (network failure), systems choose between:
  • Consistency (CP): Reject requests to maintain linearizability (e.g., ZooKeeper).
  • Availability (AP): Serve stale data but remain responsive (e.g., Dynamo, Cassandra).
• No “CA” System: All distributed systems must handle partitions, making pure CA impossible.

---

7. Case Studies

• Spanner (Google):
  Uses TrueTime API for linearizability across global datacenters. Combates clock skew with synchronized atomic clocks.
• Cassandra:
  AP system with tunable consistency (quorum writes for stronger guarantees).
• Kafka:
  Achieves atomic broadcast via ISR (in-sync replicas) and leader-follower replication.

---

Summary of Challenges

1. Linearizability vs. Availability: Strong consistency limits scalability and partition tolerance.
2. Consensus Overhead: Protocols like Raft add latency but ensure safety.
3. Partial Failures: Handling network delays and node crashes requires careful trade-offs.
4. Clock Synchronization: Critical for time-based consistency (e.g., Spanner’s TrueTime).

Practical Takeaways

• Use linearizability sparingly (e.g., for critical metadata).
• Prefer eventual consistency for high-throughput systems.
• Leverage consensus protocols (Raft, Paxos) for fault-tolerant coordination.
• Always design for partition tolerance (embrace CAP constraints).

Multiple Choice Questions

---

Question 1: Linearizability
Which of the following statements about linearizability are true?
A) Linearizability ensures that all operations appear to execute instantaneously at some point between their invocation and response.
B) Linearizability guarantees strict serial execution of all operations across all replicas.
C) A system with linearizable reads and writes cannot tolerate network partitions (CAP theorem).
D) Linearizability is equivalent to serializability in database transactions.

---

Question 2: Ordering Guarantees
Which guarantees are provided by causal consistency but not by linearizability?
A) Preserving the order of causally related operations.
B) Ensuring that all replicas agree on a total order of operations.
C) Allowing concurrent operations to be reordered if they are not causally related.
D) Guaranteeing that a read always returns the most recent write.

---

Question 3: Consensus Algorithms
Which of the following are true about Paxos and Raft?
A) Both Paxos and Raft require a stable leader to make progress.
B) Raft uses a leader-based approach, while Paxos is leaderless.
C) Paxos guarantees safety but not liveness in asynchronous networks.
D) Raft splits consensus into separate phases: leader election and log replication.

---

Question 4: Total Order Broadcast
Which properties are required for implementing total order broadcast?
A) Exactly-once message delivery.
B) Agreement: All correct processes deliver the same sequence of messages.
C) Validity: If a process broadcasts a message, it will eventually be delivered.
D) Total order: All messages are delivered in the same order to all processes.

---

Question 5: Two-Phase Commit (2PC)
Which challenges are inherent to the Two-Phase Commit protocol?
A) It requires a perfectly synchronous network.
B) The coordinator becomes a single point of failure.
C) Participants may block indefinitely if the coordinator crashes.
D) It cannot guarantee atomicity across multiple partitions.

---

Question 6: Distributed Transactions
Which of the following are true about distributed transactions?
A) A distributed transaction ensures ACID properties across multiple nodes.
B) The “read committed” isolation level prevents write skew anomalies.
C) The Two-Phase Locking (2PL) protocol ensures serializability but can lead to deadlocks.
D) The “write skew” anomaly occurs when two transactions update disjoint data items based on stale reads.

---

Question 7: CAP Theorem
Which statements correctly describe the CAP theorem trade-offs?
A) In a network partition, a CP system prioritizes consistency over availability.
B) An AP system allows stale reads to ensure availability during partitions.
C) Linearizable systems are always CA systems (no partition tolerance).
D) Most real-world distributed systems optimize for AP over CP.

---

Question 8: Byzantine Faults
Which systems are designed to tolerate Byzantine faults?
A) ZooKeeper (ZAB consensus)
B) Bitcoin’s Proof-of-Work mechanism
C) Raft consensus algorithm
D) Practical Byzantine Fault Tolerance (PBFT)

---

Question 9: Consensus in Practice
Which of the following are used by ZooKeeper for consensus?
A) ZAB (ZooKeeper Atomic Broadcast) protocol.
B) Leader election with epoch numbers.
C) Quorum-based voting similar to Paxos.
D) Gossip protocol for state synchronization.

---

Question 10: Eventual Consistency
Which scenarios are compatible with eventual consistency?
A) A social media feed where users tolerate slight delays in seeing new posts.
B) A banking system requiring immediate balance updates after transfers.
C) A distributed cache where staleness is acceptable for performance.
D) A collaborative document editor requiring real-time synchronization.

---

Answers and Explanations

---

Question 1
Correct Answers: A, C

• A: True. Linearizability requires that every operation appears atomic at some point between invocation and completion.
• C: True. By CAP, linearizable systems must choose consistency over availability during partitions.
• B: False. Linearizability does not require strict serial execution (e.g., concurrent operations can interleave).
• D: False. Serializability allows arbitrary order as long as equivalent to some serial order; linearizability enforces real-time constraints.

---

Question 2
Correct Answers: A, C

• A: True. Causal consistency preserves causal dependencies (e.g., reply-after-post).
• C: True. Concurrent operations (no causal link) can be reordered.
• B: False. Total order is a property of linearizability, not causal consistency.
• D: False. Linearizability ensures “most recent write,” not causal consistency.

---

Question 3
Correct Answers: C, D

• C: True. Paxos guarantees safety (no conflicting decisions) but may stall in asynchronous networks (liveness not guaranteed).
• D: True. Raft separates leader election and log replication phases.
• A: False. Paxos does not require a stable leader (multi-leader proposals allowed).
• B: False. Both Paxos and Raft use leaders, but Raft formalizes the role explicitly.

---

Question 4
Correct Answers: B, D

• B and D: True. Total order broadcast requires agreement and total order.
• A: False. Exactly-once delivery is unrelated to ordering guarantees.
• C: False. Validity is optional (some systems may drop messages under failure).

---

Question 5
Correct Answers: B, C

• B: True. Coordinator failure halts the protocol until recovery.
• C: True. Participants cannot unilaterally commit/abort without the coordinator.
• A: False. 2PC works in asynchronous networks but may block.
• D: False. 2PC ensures atomicity but requires all participants to be reachable.

---

Question 6
Correct Answers: A, C, D

• A: True. Distributed transactions enforce ACID across nodes.
• C: True. 2PL ensures serializability but can deadlock.
• D: True. Write skew occurs when transactions read overlapping data and update disjoint items.
• B: False. “Read committed” prevents dirty reads but not write skew.

---

Question 7
Correct Answers: A, B, C

• A: True. CP systems block or return errors during partitions to preserve consistency.
• B: True. AP systems serve stale data to remain available.
• C: True. Linearizability requires C and A only when the system is not partitioned.
• D: False. Many systems (e.g., databases) prioritize CP over AP.

---

Question 8
Correct Answers: B, D

• B: True. Bitcoin tolerates Byzantine miners via Proof-of-Work.
• D: True. PBFT handles Byzantine nodes in trusted environments.
• A/C: False. ZAB/Raft assume non-Byzantine (crash-stop) failures.

---

Question 9
Correct Answers: A, B

• A: True. ZooKeeper uses ZAB, a variant of Paxos optimized for leader-driven consensus.
• B: True. Leaders use epochs to prevent split-brain scenarios.
• C: False. ZAB differs from Paxos in log replication mechanics.
• D: False. ZooKeeper uses quorums, not gossip.

---

Question 10
Correct Answers: A, C

• A/C: True. Eventual consistency allows temporary inconsistency for availability.
• B/D: False. Banking and real-time editors require strong consistency.

---

These questions target advanced concepts in distributed systems, emphasizing trade-offs, protocol mechanics, and real-world implementations. The explanations reinforce key distinctions (e.g., linearizability vs. serializability) and practical constraints (e.g., CAP trade-offs).