Consensus and Raft algorithm (Vietnamese version)
0 likes369 views
Tài liệu trình bày về thuật toán đồng thuận Raft trong hệ thống phân tán, nhấn mạnh tầm quan trọng của việc đạt được đồng thuận giữa các node và các vấn đề như bầu chọn leader, sao chép log và điều kiện để một node trở thành leader. Thuật toán Raft sử dụng cơ chế bầu chọn và đồng bộ hóa log để đảm bảo tính nhất quán trong việc xử lý dữ liệu, đồng thời giải quyết các vấn đề như 'split brain' và 'Byzantine general's problem'. Cuối cùng, tài liệu cung cấp các ví dụ và kịch bản trong quá trình bầu chọn và sao chép log để minh họa cách Raft hoạt động trong thực tế.
![# initialise state
2020/06/06 14:34:23 id=0 [Follower] [term=0] enter follower loop. Leader=-1
2020/06/06 14:34:23 id=1 [Follower] [term=0] enter follower loop. Leader=-1
2020/06/06 14:34:23 id=2 [Follower] [term=0] enter follower loop. Leader=-1
# all followers move to the candidate state
2020/06/06 14:34:23 id=2 [Candidate] [term=0] enter candidate loop. Leader=-1
2020/06/06 14:34:23 id=0 [Candidate] [term=0] enter candidate loop. Leader=-1
2020/06/06 14:34:23 id=1 [Candidate] [term=0] enter candidate loop. Leader=-1
# all candidate votes for itself
2020/06/06 14:34:23 id=2 [Candidate] [term=1] [voteResult] server=2 received vote from
server=2 with term=1. Total: 1
2020/06/06 14:34:23 id=1 [Candidate] [term=1] [voteResult] server=1 received vote from server=1 with term=1. Total: 1
2020/06/06 14:34:23 id=0 [Candidate] [term=1] [voteResult] server=0 received vote from server=0 with term=1. Total: 1
# candidate rejects vote from other (because they're same term)
2020/06/06 14:34:23 id=2 [Candidate] [term=1] [rpcRequestVote] [server=2] denied vote: candidate=0 != vote_for=
2020/06/06 14:34:23 id=1 [Candidate] [term=1] [rpcRequestVote] [server=1] denied vote: candidate=2 != vote_for=1
2020/06/06 14:34:23 id=0 [Candidate] [term=1] [rpcRequestVote] [server=0] denied vote: candidate=1 != vote_for=0
2020/06/06 14:34:23 id=2 [Candidate] [term=1] [rpcRequestVote] [server=2] denied vote: candidate=1 != vote_for=2
2020/06/06 14:34:23 id=1 [Candidate] [term=1] [rpcRequestVote] [server=1] denied vote: candidate=0 != vote_for=1
2020/06/06 14:34:23 id=0 [Candidate] [term=1] [rpcRequestVote] [server=0] denied vote: candidate=2 != vote_for=0](https://image.slidesharecdn.com/consensusandraft-201018164246/85/Consensus-and-Raft-algorithm-Vietnamese-version-29-320.jpg)
![# NodeID=1 timeout Wirst
2020/06/06 14:34:23 id=1 [Candidate] [term=1] [voteResult] server=1 election timeout
2020/06/06 14:34:23 id=1 [Candidate] [term=1] enter candidate loop. Leader=1
2020/06/06 14:34:23 id=1 [Candidate] [term=2] [voteResult] server=1 received vote from server=1 with term=2. Total: 1
# NodeID={2,3} timeout next
2020/06/06 14:34:23 id=2 [Candidate] [term=1] [rpcRequestVote] down to follower because larger term: old_term=1 -> (server=1)new_term=2
2020/06/06 14:34:23 id=0 [Candidate] [term=1] [rpcRequestVote] down to follower because larger term: old_term=1 -> (server=1)new_term=2
# NodeID={2,3} receive votes with term=2 from NodeID=1
2020/06/06 14:34:23 id=2 [Follower] [term=2] [rpcRequestVote] accepted vote for server=1 with term=2
2020/06/06 14:34:23 id=2 [Follower] [term=2] enter follower loop. Leader=1
2020/06/06 14:34:23 id=0 [Follower] [term=2] [rpcRequestVote] accepted vote for server=1 with term=2
2020/06/06 14:34:23 id=0 [Follower] [term=2] enter follower loop. Leader=1
# NodeID=1 receives major vote. become leader
2020/06/06 14:34:23 id=1 [Candidate] [term=2] [voteResult] server=1 received vote from server=2 with term=2. Total: 2
2020/06/06 14:34:23 id=1 [Candidate] [term=2] [voteResult] server=1 become leader at term 2
2020/06/06 14:34:23 id=1 [Leader] [term=2] enter leader loop. Leader=1](https://image.slidesharecdn.com/consensusandraft-201018164246/85/Consensus-and-Raft-algorithm-Vietnamese-version-30-320.jpg)
![Các vấn đề khác …
Log Compaction
• việc để log grow liên tục là không khả thi trên thực tế.
• cần có cơ chế, để sau khi update log vào FSM, có thể xoá đi các log cũ. ví dụ [x -> 1; x -> 2]
• Khó khăn: nếu ta "vô tình" xoá đi những log entry mà chưa được replicate qua các server khác, ta sẽ
không thể phục hồi nó lại được.
ConEiguration Changes
• Raft không có đặc tả về việc thêm / bớt node.
Byzantine Problem
Giả sử có một node luôn cố gắng làm leader: luôn reply “accept” cho mọi RequestVote request, nhưng
đồng thời lại không accept request đó ở local và gửi RequestVote cho mọi node khác ở term lớn hơn.](https://image.slidesharecdn.com/consensusandraft-201018164246/85/Consensus-and-Raft-algorithm-Vietnamese-version-42-320.jpg)
Consensus and Raft algorithm (Vietnamese version)
- 2. Giới thiệu về hoạt động nhóm • Tìm hiểu các vấn đề cơ bản về distributed system như consensus / clock synchronization / … • Follow theo course MIT distributed system 6.824, bao gồm làm bài tập • Trình bày các vấn đề gặp phải trong công việc (envoy proxy / memcache / KaWka /…)
- 3. Consensus
- 6. Tại sao đồng thuận trong hệ thống phân tán khó 1. Put / Get K/V Key Value Master Key Value Slave Key Value Slave replicate
- 7. Tại sao đồng thuận trong hệ thống phân tán khó 1. Put / Get K/V Key Value Master Key Value Slave replicate Key Value Master replicate ??? ??? Split Brain Problem
- 11. Raft Algorithm
- 12. Architecture
- 13. Key Value Raft 2. call Key Value Raft Key Value Raft3. replicate 3. replicate 4. return to FSM 1. Put / Get K/V 5. return Leader Follower 1 Follower 2 waiting quorum Flow diagram khi user gửi một request
- 14. Key Value Raft 2. call Key Value Raft Key Value Raft3. replicate 3. replicate 4. return to FSM 1. Put / Get K/V 5. return Leader Follower 1 Follower 2 waiting quorum call denied leader: 127.0.0.2 Flow diagram khi user gửi một request
- 15. Raft Decomposition Leader election - Bầu chọn một node để trở thành leader - Phát hiện việc crash để bầu chọn leader mới Log replication • Leader nhận request từ client, nối thêm vào cuối cùng của log. • Leader replicate log qua các node khác (và ghi đè những log inconsistent) Safety • Đảm bảo logs consistent giữa các node • Chỉ có server có log up-to-date mới được trở thành leader. Source: https://raft.github.io/slides/uiuc2016.pdf
- 16. Raft State Follower: chỉ giữ nhiệm vụ trả lời lại các lời gọi RPC, và không trả lời command từ phía user (trừ việc redirect qua leader) Candidate: • Là trạng thái trung gian, cố gắng để trở thành leader. • Ở trạng thái này, node sẽ khởi tạo request để vote đến các node khác. Leader: • là một node chủ động trong cluster. • Node này sẽ handle các request từ clients, và replicate log qua các node con khác. • Có thể có nhiều hơn một node “nghĩ rằng” mình là leader.
- 17. Term • Term là số tự nhiên, đánh số liên tục, đóng vai trò như logical timestamp. • Chỉ có tối đa một leader cho mỗi term. • Thông tin về term luôn được trao đổi giữa các server mỗi khi gửi nhận message. Nếu một server thấy message từ server khác mà có term lớn hơn term hiện tại: • Update term hiện tại thành term mới nhận • Chuyển về trạng thái follower, vì chắc chắn có một node khác đang làm server ở term mới hơn đấy.
- 18. Log • Log Entry: data + index + term • Committed entry: khi một log entry được gửi thành công trên quá bán node (bao gồm chính nó), log entry đấy sẽ được chuyển sang trạng thái commit. • Khi log chuyển sang trạng thái commit, có thể an toàn update vào FSM và trả về cho client. Thuật toán Raft đảm bảo rằng: mọi committed message sẽ được replicate đúng thứ tự và đầy đủ trên mọi node đang chạy đúng.
- 19. Request Type Raft chỉ có 2 dạng request: RequestVote: dùng để bầu chọn leader. AppendEntries: • dùng cho giao thức heartbeat. Khi đó, mảng các log cần replicate là empty. • dùng cho việc replicate log: initialize các Wield khác tương tự như heartbeat, tuy nhiên thêm mảng các log cần replicate qua các follower (theo một số điều kiện cần thiết). • Thông qua cơ chế replication, leader đồng thời gửi luôn thông tin latest commit ID. Dựa vào đó, các follower có thể biết và commit các log entries vào FSM (Finite State Machine)
- 25. Leader Election
- 26. Leader Election • Khi một node không nhận được heartbeat từ leader trong thời gian cho phép. Node đó sẽ chuyển từ trạng thái Follower --> Candidate • Candidate sẽ tăng term hiện tại lên 1. Sau đó, gửi request vote cho toàn bộ các node khác trong hệ thống. • Các node khác trong hệ thống khi nhận được request vote mà có term cao hơn term hiện tại (kèm theo các điều kiện khác liên quan về log): đồng ý và chuyển về trạng thái follower. Khi một candidate nhận được kết quả: • Tồn tại một term lớn hơn nó: chuyển từ Candidate về Follower • Timeout nhưng không nhận được quá bán vote: tăng term lên 1, bắt đầu lại quá trình leader election (vẫn ở Candidate) • Quá bán số vote: • chuyển từ Candidate qua Leader. • Bắt đầu định kì gửi heartbeat request tới các node còn lại để thông báo và tiếp tục giữ trạng thái leader. • Có thể bắt đầu phase log replication cho các node không catchup kịp với leader ở các term trước.
- 32. S1: 5 S2: 5 S3: 5 • S1 là leader của term 5 • Sau đó, S1 bị crash và fast-restart trước khi các node khác nhận được time out. • S1 start quá trình bầu chọn ở term 6. S1: 5 6 S2: 5 S3: 5 • S1 là leader của term 6 • Một client insert data vào S1 tại term 6. Log sẽ được append vào local của S1. • S1 chưa kịp replicate log qua các node khác thì node S1 bị crash và fast-restart trở lại (!!!) S1: 5 6 7 S2: 5 S3: 5 • S1 tiếp tục là leader của term 7 • Tương tự như trên, một client insert data vào S1 ở term 7 • Tương tự, S1 chưa kịp replicate log qua các node khác thì node S1 bị crash S1: 5 6 7 S2: 5 8 S3: 5 8 • Lần này, các node khác nhận ra S1 bị crash do timeout, khởi tạo quá trình bầu chọn. • S2 trở thành leader tại term 8. • Client insert data vào S2 tại term 8. • S2 replicate log qua S3 —> majority. Như vậy, chắc chắn data tại term 8 buộc phải available trên toàn bộ machine. S1: 5 6 7 9 S2: 5 8 S3: 5 8 • Sau khi S1 phục hồi, bắt đầu lại quá trình bầu chọn leader với term 9 • Nếu ta chọn giải pháp “candidate nào có độ dài log dài hơn là leader” —> S1 sẽ chiến thắng • Khi đó, log ở S1 sẽ replicate qua S2 và S3 (log ở leader không bao giờ xoá) S1: 5 6 7 9 S2: 5 6 7 9 S3: 5 6 7 9 • Khi đó, log ở term 8 bị mất —> vi phạm tính chất thuật toán: một log khi đã replicate qua quá bán các node, log đấy sẽ không bao giờ bị thay đổi.
- 33. Log Replication
- 39. Node 2 Node 1 M T T M M Log Matching Property Phát biểu 1: Nếu 2 entry ở 2 đoạn log có chung index và term, 2 entry này có chung data. Phát biểu 2: Nếu 2 entry ở 2 đoạn log có chung index và term tại vị trí T, toàn bộ log từ đầu đến T đều tương đồng nhau.
- 41. State Machine Safety Property if a server has applied a log entry at a given index to its state machine, no other server will ever apply a different log entry for the same index. Giải thích Nếu một server đã apply một log entry vào State machine, không tồn tại server nào apply một log entry khác ở cùng một index. Nói cách khác, ở một node bất kì: • Nếu node đó có term < T, node đấy sẽ chưa được apply log entry tại vị trí T • Nếu node đó có term >= T, tại vị trí T, node đấy sẽ apply cùng log entry giống với mọi server khác. Chứng minh Ta có thể chứng minh phản chứng như sau: • Giả sử tồn tại một follower mà có index tại K khác với bất kì một node nào có index tại K những đã commit lên FSM → leader truyền cho node mà index tại K cũng phải có giá trị khác. • Dựa vào định lí Leader completeness, tất cả các leader của các term sau đó đều phải lưu trữ các log entry tương tự nhau → vô lí. • Do vậy, follower có index tại K phải chung giá trị với các node khác. • Do việc apply lên FSM diễn ra tuần tự theo index=0,1,2,… → dẫn đến định lí State Machine Safety Property
- 42. Các vấn đề khác … Log Compaction • việc để log grow liên tục là không khả thi trên thực tế. • cần có cơ chế, để sau khi update log vào FSM, có thể xoá đi các log cũ. ví dụ [x -> 1; x -> 2] • Khó khăn: nếu ta "vô tình" xoá đi những log entry mà chưa được replicate qua các server khác, ta sẽ không thể phục hồi nó lại được. ConEiguration Changes • Raft không có đặc tả về việc thêm / bớt node. Byzantine Problem Giả sử có một node luôn cố gắng làm leader: luôn reply “accept” cho mọi RequestVote request, nhưng đồng thời lại không accept request đó ở local và gửi RequestVote cho mọi node khác ở term lớn hơn.
- 45. Q&A Session