Tech Chương V read in english →

Từ vựng trường dùng trong hệ thống phân tán

Và cũng thường nhầm lẫn

◔ thời gian đọc

10–15 phút · một lượt

độ nặng

cần biết trước

Vài hiểu biết trước về hệ thống phân tán sẽ có ích.

đọc khi

lúc rảnh hoặc đọc thiết kế cho hệ thống phân tán

Linearizability

(tính tuyến tính) là một đặc tính nhất quán mạnh (strong consistency), đảm bảo mọi thao tác trên một đối tượng được thực hiện giống như tức thời giữa lúc gọi và trả về. Tôn trọng thứ tự trong thời gian thực.

Để dễ hiễu hơn, hệ thống đáp ứng được tính chất này đảm bảo rằng, nếu thao tác tại thời điểm $t_{1}$ được xác nhận là thành công, thì thao tác tại mọi thời điểm $t_{2} (t_{2} > t_{1})$ phải thấy được kết quả của thao tác trước đó.

Tính chất

Tập trung vào một đối tượng (single-object focus): phát biểu của tính chất này chỉ nói đến một đối tượng
Ảo giác tức thời (Illusion of Instantaneity): mặc dù giữa lúc đọc và ghi tồn tại một khoảng thời gian để thực hiện, linearizabiliity tạo cảm giác như thao tác đó xảy ra tại một thời điểm duy nhất (single point in time) nằm giữa lúc gọi (invocation) và lúc trả về (response/return).
Tôn trọng thứ tự trong thời gian thực (respect real-time ordering)

Dễ sai khi

Dùng nhầm với các tính chất khác không phải trên một đối tượng, nhiều đối tượng hoặc giao dịch (transaction) ví dụ: Serializability

Serializability

(tính tuần tự) đảm bảo rằng các giao dịch đồng thời trên nhiều tiến trình sẽ cho ra kết quả cuối cùng giống như là chạy trên một máy theo một thứ tự tuần tự nhất định nào đó. Không tôn trọng thứ tự trong thời gian thực.

Ví dụ: có hai giao dịch đồng thời $T_{1}$ , $T_{2}$ , hệ thống đảm bảo rằng kết quả cuối cùng sẽ theo một thứ tự tuần tự $T_{1} \to T_{2}$ hoặc $T_{2} \to T_{1}$ . Với Account $A$ ban đầu có giá trị là $1$

$T_{1}$ : ADD A 5
$T_{2}$ : MUL A 2

Kết quả hợp lệ hệ thống chấp nhận là $12 = (1 + 5) \times 2$ hoặc $7 = (1 \times 2) + 5$ Không chấp nhận chồng chập, ghi đè thành $6$ hoặc $2$ .

Dễ sai khi

Dùng nhầm với linearizability

Strict Serializability

Là serializability cộng tôn trọng thời gian thực.

Dễ sai khi

Dùng nhầm với serializability đơn thuần

Eventual Consistency

(nhất quán cuối cùng/hội tụ cuối cùng) nói rằng, nếu không còn thay đổi nào đến dữ liệu, thì mọi bản sao (copies/replicas) của nó sẽ được đồng bộ và tiến về một trạng thái sau cùng như nhau.

Tính chất

Hội tụ sau cùng: mọi bản sao của dữ liệu tới cuối cùng sẽ được hội tụ về một trạng thái như nhau.
Không cam kết thời gian: tính chất này không cam kết thời gian để tiến về trạng thái hội tụ cuối cùng đó, mỗi hệ thống sẽ có cam kết khác nhau và cần kiểm chứng, không mặc định vài milli giây hay vài giây.

Dễ sai khi

Dùng nó mà không biết cam kết về thời gian đồng bộ.

Monotonic Reads / Monotonic Writes

(đọc đơn điệu) đảm bảo rằng một client/session/tiến trình nếu đã đọc được một giá trị cụ thể hoặc một phiên bản cụ thể của dữ liệu sẽ không bao giờ đọc lại được giá trị cũ hơn của dữ liệu đó.

Tương tự với (ghi đơn điện) đảm bảo rằng một client/session/tiến trình sẽ không thể ghi một version cũ của dữ liệu đè lên hiện tại được.

Read-your-writes

đảm bảo nếu client/session/tiến trình đã thực hiện thao tác thay đổi lên đối tượng sẽ thấy được những thay đổi đó ngay lập tức.

Hầu hết (90%) các ca yêu cầu “nhất quán mạnh” có thể giải quyết bằng tính chất này mà không cần phải bỏ nhiều chi phí để lên linearizability .

Dễ sai khi

Nhảy thẳng lên linearizability

Causal Consistency

(nhất quán nhân quả) đảm bảo những thao tác có mối quan hệ nhân-quả sẽ được quan sát cùng một thứ tự tại mọi nút trong hệ thống, còn những thao tác khác, không liên quan, có thể quan sát được ở bất kì thứ tự nào.

Ví dụ: Thao tác “bình luận” vào bài viết, A viết một bài viết, B bình luận lên bài viết đó, hành động viết bài của A phải xảy ra trước hành đồng bình luận lên bài viết của A của B, nên hệ thống sẽ thấy tuần tự tại mọi nút rằng A viết bài $\to$ B bình luận lên bài. Còn các hành động khác như B thích một bài viết của C, hay D đăng một bài viết khác không liên quan đến thao tác viết bài của A, có thể theo bất kì thứ tự nào.

Tính chất này hầu hết là đáp ứng đủ cho các mạng xã hội.

Happens-before

là thứ tự có phạm vi ở một phần /bộ phận/cục bộ do tính chất nhân quả tạo ra, không phải là thứ tự toàn cục.

Happens-before thể hiện mối quan hệ nhân quả $A \to B$ , mối quan hệ này được xác nhận chỉ khi $A$ , $B$ rơi vào một trong ba trường hợp sau:

Trong cùng một tiến trình: Sự kiện $A$ xảy ra trước sự kiện $B$ trong cùng một tiến trình
Mối quan hệ gửi-nhận: khi $A$ là hành động gửi tin nhắn từ tiến trình 1, và $B$ là hành động nhận đúng tin nhắn đó ở tiến trình 2.
Tính chất bắc cầu: nếu $A \to B$ và $B \to C$ thì $A \to C$

Phân biệt và sắp xếp các dạng nhất quán

Các mô hình nhất quán trong hệ thống phân tán có thể sắp xếp từ mạnh $\to$ yếu theo bảng sau:

Bậc	Model	Ràng buộc thứ tự	Đạt được bằng
1	Strict consistency	Real-time tuyệt đối, đồng hồ toàn cục	Không hiện thực được, chỉ là trần lý thuyết
2	Linearizability (strong)	Real-time + một thứ tự toàn cục duy nhất	Raft/Paxos + , TrueTime (Spanner chấp nhận uncertainty window)
3		Một thứ tự toàn cục, khớp program order, không cần khớp real-time	Hiếm dùng độc lập trong DB thực tế, hay xuất hiện trong shared-memory model
4	Causal consistency	Chỉ thao tác có quan hệ nhân quả mới bị buộc thứ tự; thao tác đồng thời thấy khác nhau ở replica khác nhau cũng được	Vector clock, COPS, CRDT có causal delivery
5	PRAM / FIFO consistency	Chỉ per-writer FIFO, không bắc cầu qua tiến trình khác	Ghi log theo tiến trình, không cần vector clock đầy đủ
5.5	Session guarantees (read-your-writes, monotonic reads, monotonic writes, writes-follow-reads)	Từng ràng buộc cục bộ, cấp độc lập theo session/client	Sticky session, version vector theo client, read-your-writes token
6	Eventual consistency	Chỉ cam kết hội tụ sau cùng nếu ngừng ghi, không cam kết thứ tự nào giữa chừng, không nói về thời gian hội tụ	Anti-entropy, gossip, CRDT (nửa dàn đảm bảo hội tụ đúng nhưng không đảm bảo khi nào thấy gì)

Quorum

Quorum số lượng nhỏ nhất/tối thiểu của các máy/nút phải đồng thuận về một thao tác đọc hoặc ghi.

Thường là $R + W > N$ trong đó

$R$ (Read quorum): là số lượng tối thiểu các nút phải phản hồi khi thực hiện thao tác ghi
$W$ (Write quorum): là số lượng tối thiểu các nút phải xác nhận ghi thành công cho thao tác ghi
$N$ : là tổng số bản sao (replicas)

Có công thức này là vì theo nguyên lý Dirichlet (Pigeonhole Principle), khi $R + W > N$ , tập hợp các node thực hiện đọc ( $R$ ) và tập hợp các node thực hiện ghi ( $W$ ) chắc chắn sẽ giao nhau tại ít nhất 1 node. Node giao nhau này sẽ giữ phiên bản dữ liệu mới nhất, giúp hệ thống không bao giờ trả về dữ liệu cũ.

Dễ sai khi

Nhầm với Majority (đa số), quorum bản chất không nói về đồng thuận đa số.

Split-brain

là trường hợp sai khi có hai nút hay nhiều hơn đều nghĩ mình là leader từ đó dẫn đến tình trạng chấp nhận ghi xung đột.

Hiện tượng này có thể xảy ra bởi nhiều nguyên nhân, thường là do phân mảnh mạng (network partition) hoặc do Garbage Collection Pause (GC Pause).

Lease

là quyền/khóa/token được cấp cho phép một tiến trình thao tác trên đối tượng dữ liệu, có giới hạn về thời gian Time-to-live (TTL).

Sau khi hết TTL, lease sẽ tự động hết hạn, tiến trình không được phép thao tác trên đối tượng dữ liệu nữa. Tiến trình cũng có thể nhả lease sớm hoặc gia hạn thêm nếu cần.

Được sử dụng để tránh một tiến trình block sử sụng đối tượng liệu mãi không cho người khác dùng.

Dễ sai khi

Nghĩ chỉ cần với lease là đủ, thực chất lease là nữa đầu của câu chuyện, sau đó người đang giữ lease vẫn có thể không biết lease của mình đã hết hạn dẫn tới tình trạng ghi xung đột với người thực sự đang giữ lease mới.

Fencing token

là token được cấp dùng để ngăn chặn việc một tiến trình đang giữ lease cũ. Thường là một số tăng đơn điệu.

Là cặp bài trùng với lease.

Idempotent

(lũy đẵng) là tính chất thể hiện một thao tác có thể thực hiện nhiều lần mà kết quả cuối cùng thu được giống hệt như nó thực hiện một lần.

Ví dụ: Thao tác SET A 5, sẽ luôn cho kết quả A bằng 5 dù có thực hiện nó bao nhiêu lần, nhưng ADD A 5 thì không.

Tính chất này là nền tảng của mọi cơ chế retry an toàn.

Trong HTTP các phương thức như GET, PUT, DELETE là idempotent ở mức độ giao thức (protocol). Lưu ý, idempotent ở mức độ protocol không tự nhiên đem lại tính chất idempotent cho toàn hệ thống.

Dễ sai khi

Nhầm lẫn với tình chất commutative (giao hoán)
Hoặc được dùng với an toàn khi gọi lại chung chung

Commutative

(giao hoán) là tính chất đảm bảo thứ tự của các thao tác không làm ảnh hưởng đến kết quả cuối cùng.

Ví dụ: ADD A 5, rồi ADD A 2, hay ADD A 2 rồi ADD A 5, thì kết quả cuối cùng đều cho ra A + 7, không phụ thuộc thứ tự thao tác. Nhưng MUL A 2 với ADD A 3 thì khác, thứ tự có ảnh hưởng đến kế quả cuối cùng.

Đây là tính chất nền tảng của các CRDT (Conflict-free Replicated Data type).

Associative

(kết hợp) là tính chất mà một thao tác gộp dữ liệu đảm bảo sơ đồ chia nhỏ và đóng gói các gói tin để gộp không làm thay đổi kết quả cuối cùng.

$Merge (Merge (A, B), C) = Merge (A, Merge (B, C))$

Một hệ thống/cấu trúc mà đám ứng đủ $Associative + Commutative + Idempotent = Bounded Semi-lacttice$ là một nền tảng hoàn hảo cho đồng bộ dữ liệu phân tán.

Monotonic

(đơn điệu) chỉ giá trị/trạng thái chỉ tiến về trước, theo một chiều thường là chỉ tăng/mới hơn, không bao giờ đi ngược lại hoặc sử dụng lại giá trị/trạng thái trong quá khứ.

Đây là tính chất nền tảng của CALM (Consistency As Logical Monotonicity), nói rằng một chương trình/hệ thống có thể đạt được Nhất quán kết quả (Eventual Consistency) mà KHÔNG CẦN sự phối hợp (Coordination-free) giữa các nút nếu và chỉ nếu logic của chương trình đó là Đơn điệu (Monotonic).

At-least-once / At-most-once / Exactly-once / Effectively-once

At-least-once (ít nhất một): đảm bảo không bị mất tin nhắn (No Data Loss), chấp nhận có thể bị xử lý trùng lặp (Duplicates).
At-most-once (nhiều nhất một): đảm bảo không bị trùng lặp (No Duplicates), chấp nhận tin nhắn có thể bị mất mát (Data Loss).
Exactly-once (chính xác một): đảm bảo tin nhắn được xử lý hiệu quả đúng 1 lần (không mất mát, không trùng lặp).

Người ta luôn hướng về Exactly-once trong toàn hệ thống, nhưng nó đòi hỏi chi phí và độ phức tạp rất cao. Do đó, thực tế thường áp dụng bằng cách kết hợp giữa At-least-once và khử trùng/lũy đẳng (Deduplication / Idempotence) để đảm bảo trạng thái hệ thống thay đổi đúng một lần kể cả khi tin nhắn bị lặp lại. Với các tác dụng phụ (Side Effects) ra bên ngoài như gửi Email hay gọi API bên thứ 3, bản thân các tác dụng phụ đó cũng cần tích hợp cơ chế khử trùng riêng để tránh bị thực hiện nhiều lần.

Dễ sai khi

Sử dụng Kafka và nghĩ rằng sẽ tự nhiên có tính chất Exactly-once ở toàn bộ hệ thống. Đây là niềm tin sai lầm phổ biến, tính năng Exactly-Once Semantics (EOS) của Kafka thực chất chỉ đảm bảo cho luồng xử lý nội bộ (Stream-to-Stream processing giữa các Topic). Consumer vẫn hoàn toàn có khả năng nhận và xử lý lại một message hai lần (ví dụ do crash trước khi commit offset). Nếu tầng ứng dụng không có cơ chế khử trùng/lũy đẳng (Deduplication / Idempotence), hệ thống vẫn sẽ bị xử lý trùng lặp.
Nhầm lẫn effectively-once với exactly-once thực thụ: Exactly-once tuyệt đối trên toàn hệ thống mạng phân tán (End-to-End) là điều bất khả thi về mặt lý thuyết. Thực tế mọi hệ thống hoạt động chính xác đều là nhờ đạt được Effectively-once (kết hợp At-least-once + Idempotence).

Byzantine

Byzantine/Byzantine Fraud là tình trạng sai của hệ thống khi các nút gửi thông tin sai, ác ý, xung đột tới các phần khác nhau trong mạng.

Khái niệm liên quan là Tolerance (BFT), khả năng chịu lỗi Byzantine Fault của hệ thống, thường theo công thức $N \geq 3 f + 1$ . Tức là để chịu được $1$ nút bị Byzantine, thì hệ thống cần $3 (1) + 1 = 4$ nút.

Với $f$ là số nút bị Byzantine, còn $N$ là tổng số nút cần có.

Dễ sai khi

Dùng cho lỗi thường, thông thường là crash-stop.

Safety / Liveness

Safety

(an toàn) là tính chất thể hiện cho câu “không có gì xấu xảy ra hết”, đảm bảo rằng hệ thống không rơi vào trạng thái sai (incorrect) hoặc không hợp lệ (invalid).

Liveness

(sống sót) là tính chất thể hiện cho câu “cuối cùng sẽ có điều gì đó tốt xảy ra”, đảm bảo rằng, hệ thống tiếp tục hoạt động, xử lý, chứ không chết, không đứng vô hạn.

Đây là cặp tính chất dùng để phân tích hệ thống chứ không dùng để đánh đổi, một hệ thống tốt bắt buộc phải thỏa mãn cả hai tính chất trên.

Grey failure

là tình trạng sai khi nút bị giảm performance, hoặc trả về lỗi, nhưng vẫn vượt qua được những bài kiểm tra sức khỏe (health-check).

Static Stability

(ổn định tĩnh) là tính chất đảm bảo hệ thống phục vụ người dùng tiếp tục vận hành khi có sự cố mà không cần sự can thiệp chủ động từ hệ thống điều khiển, cấu hình.

Nó thường được tạo ra bằng sự chuẩn bị trước và thiết kế để Control Plane và Data Plane độc lập.

Nếu chỉ nhớ một câu from The vocabulary of distributed systems

Linearizability is a promise about one object in real time; serializability is a promise about many objects in some order. Most designs pay for the first while needing neither.

Thuật ngữ

được đánh dấu trong bài

associative tính từ · hệ phân tán: Một phép gộp mà cách nhóm không quan trọng: gộp A với B rồi với C bằng gộp A với kết quả gộp của B và C.
Byzantine fault danh từ · hệ phân tán: Một nút không chỉ dừng lại mà nói dối — và có thể nói những lời dối khác nhau với những láng giềng khác nhau.
đọc đơn điệu danh từ · hệ phân tán: Một bảo đảm theo session: khi đã đọc được một phiên bản của dữ liệu, bạn không bao giờ đọc lại một phiên bản cũ hơn.
effectively-once danh từ · hệ phân tán: Giao nhận at-least-once cộng tính lũy đẳng ở phía nhận: tin nhắn có thể tới hai lần, nhưng trạng thái chỉ đổi một lần.
fencing token danh từ · hệ phân tán: Một con số tăng đơn điệu được cấp kèm với lease, để tầng lưu trữ dùng mà từ chối bất cứ ai đang giữ con số cũ hơn.
ghi đơn điệu danh từ · hệ phân tán: Một bảo đảm theo session: các lần ghi của chính bạn được áp dụng theo đúng thứ tự bạn phát ra, không bao giờ đảo.
giao hoán tính từ · hệ phân tán: Một thao tác mà thứ tự thực hiện không làm thay đổi kết quả cuối cùng.
grey failure danh từ · hệ phân tán: Một nút đã suy giảm hoặc đang trả về lỗi, nhưng vẫn vượt qua chính những bài kiểm tra sức khỏe của nó.
happens-before danh từ · hệ phân tán: Thứ tự bộ phận mà tính nhân quả cho: trong cùng một tiến trình, từ một lần gửi tới lần nhận tương ứng, và bắc cầu qua cả hai.
lease danh từ · hệ phân tán: Quyền được thao tác lên một thứ, cấp kèm thời điểm hết hạn — một cái khóa có TTL, chứ không phải khóa giữ tới khi nào nhả.
liveness danh từ · hệ phân tán: Lớp tính chất nói rằng cuối cùng sẽ có điều gì tốt xảy ra — hệ thống tiếp tục tiến triển chứ không đứng lại.
lũy đẳng tính từ · hệ phân tán: Một thao tác mà kết quả sau khi thực hiện nhiều lần giống hệt như sau khi thực hiện một lần.
monotonic tính từ · hệ phân tán: Một giá trị hay trạng thái chỉ đi theo một chiều — về trước, mới hơn, lớn hơn — và không bao giờ quay lại hay dùng lại thứ nó đã đi qua.
nhất quán cuối cùng danh từ · hệ phân tán: Lời hứa rằng nếu ngừng ghi thì mọi bản sao sẽ hội tụ về cùng một trạng thái — và không hứa gì thêm nữa.
nhất quán nhân quả danh từ · hệ phân tán: Các thao tác có quan hệ nhân quả được thấy theo cùng một thứ tự ở mọi nơi; các thao tác không liên quan có thể thấy theo thứ tự nào cũng được, và khác nhau ở các bản sao khác nhau.
quorum danh từ · hệ phân tán: Số lượng nút tối thiểu phải tham gia vào một thao tác để nó được tính — thường được chọn sao cho tập đọc và tập ghi buộc phải giao nhau.
read-your-writes danh từ · hệ phân tán: Một bảo đảm theo session: một client vừa ghi thứ gì thì thấy được thay đổi của chính mình ở lần đọc kế tiếp.
safety danh từ · hệ phân tán: Lớp tính chất nói rằng không có gì xấu xảy ra — hệ thống không bao giờ rơi vào một trạng thái sai hoặc không hợp lệ.
sequential consistency danh từ · hệ phân tán: Một thứ tự toàn cục duy nhất mà mọi nút đều thống nhất và khớp với program order của từng tiến trình — nhưng không cần khớp thời gian thực.
split-brain danh từ · hệ phân tán: Dạng lỗi khi hai nút hoặc nhiều hơn đều tin mình là leader, và mỗi nút đều nhận ghi.
static stability danh từ · hệ phân tán: Tính chất mà đường phục vụ vẫn chạy được suốt một sự cố mà không cần control plane phải làm gì.
tính tuần tự danh từ · hệ phân tán: Bảo đảm rằng các giao dịch đồng thời kết thúc với cùng kết quả như khi chạy lần lượt theo một thứ tự tuần tự nào đó — thứ tự nào cũng được.
tính tuyến tính danh từ · hệ phân tán: Bảo đảm rằng mọi thao tác trên một đối tượng đều trông như xảy ra tại một thời điểm duy nhất nằm giữa lúc gọi và lúc trả về, theo đúng thứ tự thời gian thực.

Toàn bộ từ điển ở đây

Nguồn tham khảo

được trích dẫn trong bài

01
Linearizability: A Correctness Condition for Concurrent Objects Bài báo

Herlihy, Maurice P.; Wing, Jeannette M. · 1990

Bài báo định nghĩa ra chính từ này, và là lý do định nghĩa của nó chỉ nói về một đối tượng. Tính đúng ở đây là một đặc tính của lịch sử thao tác trên một đối tượng: mọi thao tác trông như thể đã xảy ra tại một thời điểm nằm giữa lúc gọi và lúc trả về, và các thời điểm đó tôn trọng thời gian thực. Đọc một lần là chuyện nhầm nó với serializability không còn xảy ra được nữa — cái kia nói về nhiều đối tượng và không có đồng hồ nào.
02
The serializability of concurrent database updates Bài báo

Papadimitriou, Christos H. · 1979

Nửa còn lại của cặp khái niệm, viết từ phía cơ sở dữ liệu và sớm hơn mười một năm. Serializability chỉ yêu cầu kết quả khớp với *một* thứ tự tuần tự nào đó của các giao dịch — thứ tự nào thì không chỉ định, và không nhất thiết phải là thứ tự thời gian thực. Chữ "một nào đó" ấy chính là toàn bộ khác biệt, và là lý do strict serializability phải có một cái tên riêng.
03
Time, Clocks, and the Ordering of Events in a Distributed System Bài báo

Lamport, Leslie · 1978

Nơi happens-before sinh ra. Lập luận của bài là: một hệ thống phân tán không có đồng hồ toàn cục nào để viện đến, nên thứ tự duy nhất bạn thực sự xác lập được là thứ tự bộ phận mà tính nhân quả cho: trong cùng một tiến trình, qua một lần gửi và lần nhận tương ứng, và bắc cầu. Mọi thứ ở dòng causal consistency trong bảng đều là hậu duệ của tám trang giấy này.
04
Session guarantees for weakly consistent replicated data Bài báo

Terry, Douglas B.; Demers, Alan J.; Petersen, Karin; Spreitzer, Mike J.; Theimer, Marvin M.; Welch, Brent B. · 1994

Bốn bảo đảm theo session, được đặt tên và tách bạch: read-your-writes, monotonic reads, monotonic writes, writes-follow-reads. Đây là bài báo nằm sau bậc 5.5, và sau nhận định rằng phần lớn các yêu cầu "nhất quán mạnh" thực chất chỉ là yêu cầu một trong số này. Chúng được cấp theo từng session, nên giá phải trả là một version vector với một đường đi sticky, chứ không phải một vòng đồng thuận.
05
Conflict-free Replicated Data Types Bài báo

Shapiro, Marc; Preguiça, Nuno; Baquero, Carlos; Zawirski, Marek · 2011

Nơi tính kết hợp, giao hoán và lũy đẳng thôi là ba từ đại số riêng lẻ và trở thành một kết quả kỹ thuật duy nhất. Biến phép gộp thành phép hợp trên một nửa dàn thì các bản sao hội tụ mà không cần phối hợp — không leader, không quorum, không rollback. Bài viết nói nửa dàn bảo đảm hội tụ nhưng không bảo đảm khi nào; đây là bài báo chứng minh nửa đầu và thẳng thắn về nửa sau.
06
Keeping CALM: When Distributed Consistency is Easy Bài báo

Hellerstein, Joseph M.; Alvaro, Peter · 2020

Định lý CALM, phát biểu dưới dạng nếu-và-chỉ-nếu: một chương trình có cách hiện thực phân tán không cần phối hợp đúng khi logic của nó là đơn điệu. Cái làm nó đáng đọc chứ không chỉ đáng trích là chiều mà người ta hay bỏ qua — phi đơn điệu không phải một gợi ý rằng phối hợp có thể có ích, nó là một chứng minh rằng bạn không tránh được phối hợp.
07
The Byzantine Generals Problem Bài báo

Lamport, Leslie; Shostak, Robert; Pease, Marshall · 1982

Nơi biên 3f + 1 sinh ra, và lý do nó có hình dạng như vậy. Lỗi được mô hình hóa ở đây không phải một nút dừng hẳn mà là một nút nói dối, nói khác nhau với từng láng giềng khác nhau — đó là lý do ba nút không sống sót nổi một kẻ phản bội: hai nút trung thực không phân biệt được ai trong hai nút còn lại đang dối. Chỉ nên viện đến bài này khi lỗi thực sự là ác ý; crash thông thường là một bài toán rẻ hơn nhiều.
08
Spanner: Google’s Globally Distributed Database Bài báo

Corbett, James C.; Dean, Jeffrey; Epstein, Michael; et al. · 2013

Ô TrueTime trong bảng, kể bằng chính lời của nó. Spanner không đánh bại bài toán đồng hồ, nó chặn biên rồi công bố cái biên đó: TrueTime trả về một khoảng chứ không phải một thời điểm, và một lần commit phải chờ hết cửa sổ bất định. Đó là cái giá trung thực của việc bảo đảm thứ tự thời gian thực ở quy mô toàn cầu, và nó được trả bằng độ trễ.
09
How to do distributed locking Bài viết

Martin Kleppmann · 2016

Phát biểu sáng rõ nhất về việc vì sao một lease chỉ là nửa câu chuyện. Hình vẽ cần nhớ: một client dừng vì GC, lease của nó hết hạn, nó tỉnh lại và vẫn tin mình đang giữ khóa, rồi ghi. Không dịch vụ khóa nào ngăn được chuyện này từ phía nó — chỉ một fencing token tăng đơn điệu, được kiểm ở tầng lưu trữ, làm được.
10
Gray Failure: The Achilles’ Heel of Cloud-Scale Systems Bài báo

Huang, Peng; Guo, Chuanxiong; Zhou, Lidong; Lorch, Jacob R.; Dang, Yingnong; Chintalapati, Murali; Yao, Randolph · 2017

Đặt tên cho đúng cái khe mà dạng lỗi này sống trong đó: hệ thống tự quan sát sức khỏe của mình theo một cách khác với cách client trải nghiệm nó, và grey failure đúng là vùng mà hai cách đó không khớp nhau. Hệ quả hữu dụng là: một health-check trả lời thay cho nút chứ không trả lời thay cho yêu cầu thì không phải một bộ phát hiện, và thêm bao nhiêu cái nữa cũng không thành.
11
Static stability using Availability Zones Tài liệu kỹ thuật

Amazon Builders’ Library

Static stability được viết lại bởi chính những người phải vận hành nó. Nguyên tắc nó bảo vệ là: data plane phải tiếp tục phục vụ bằng những gì nó đã biết khi control plane không dùng được — nghĩa là cấp sẵn phần dung lượng bạn đang không dùng, và từ chối để việc phục hồi phụ thuộc vào bất cứ thứ gì phải thành công ngay trong lúc sự cố.
12
Designing Data-Intensive Applications Sách

Martin Kleppmann · 2017

Cuốn sách duy nhất nên đọc kèm cùng bảng từ vựng này. Chương 5 và chương 9 chính là bản dài của bảng nhất quán, và chúng làm được điều một cuốn từ điển không làm được: đi theo từng bảo đảm tới cùng, tới cái giá của nó trong sao bản, trong độ trễ, và trong những gì một client được phép giả định. Chỗ bài này đặt tên cho các nhầm lẫn, cuốn sách tính ra hệ quả của chúng.

Danh sách đầy đủ ở đây

một lời riêng cho tác giả không đăng · không hiện cho người đọc khác

Có gì ở đây làm bạn nghĩ khác đi về vấn đề không?