- Kỹ sư hệ thống phân tán trong nhiều trường hợp học được bài học thông qua những vết sẹo do sai lầm ngoài thực tế gây ra
- Bài viết này được viết ra để các kỹ sư mới không phải trải qua những vết sẹo như vậy
Hệ thống phân tán thường xuyên thất bại
- Không giống các lĩnh vực kỹ thuật phần mềm khác, hệ thống phân tán có xác suất thất bại cao hơn. Đặc biệt, xác suất thất bại từng phần là rất cao.
- Những kỹ sư hệ thống chưa từng làm việc với điện toán phân tán thường đưa ra các ý tưởng như "cứ gửi ghi đến hai hệ thống là được" hoặc "chỉ cần tiếp tục thử ghi lại cho đến khi thành công"
- Hệ thống mạng thất bại thường xuyên hơn một máy đơn lẻ, và những thất bại này có xu hướng là thất bại từng phần
- Một lần ghi có thể thành công còn lần ghi kia có thể thất bại, vậy thì làm sao để có được một góc nhìn nhất quán về dữ liệu? Những thất bại từng phần như vậy khó suy luận hơn rất nhiều
- Có thể xảy ra các vấn đề như switch bị down, leader "biến mất" do garbage collection, hoặc ghi socket trông như đã thành công nhưng thực tế lại thất bại. Đọc từ bộ nhớ cục bộ đáng tin cậy hơn nhiều so với đọc qua vài switch
- Cần phải "thiết kế cho thất bại"
Viết hệ thống phân tán vững chắc tốn kém hơn
- Để tạo ra một giải pháp phân tán vững chắc sẽ tốn kém hơn một giải pháp chạy trên máy đơn lẻ.
- Máy ảo và công nghệ đám mây giúp kỹ thuật hệ thống phân tán rẻ hơn, nhưng vẫn đòi hỏi chi phí đáng kể.
- Mô phỏng rất hữu ích, nhưng không thể giải quyết hết mọi vấn đề phát sinh trong môi trường phân tán thực tế.
Hệ thống phân tán mã nguồn mở vững chắc là thứ hiếm gặp
- Chi phí vận hành nhiều máy trong thời gian dài là gánh nặng với cộng đồng mã nguồn mở.
- Những người viết mã nguồn mở như một sở thích thường thiếu nguồn lực tài chính để khám phá hoặc giải quyết nhiều vấn đề của hệ thống phân tán.
- Một số vấn đề được kỹ sư trong doanh nghiệp giải quyết, nhưng ưu tiên của họ không phải lúc nào cũng trùng khớp.
Điều phối là việc cực kỳ khó. Hãy tránh điều phối bất cứ khi nào có thể
- Cốt lõi của khả năng mở rộng theo chiều ngang là tính độc lập. Cần giảm thiểu giao tiếp và đồng thuận giữa các máy.
- Mỗi khi hai máy phải đồng thuận về điều gì đó, việc triển khai dịch vụ lại trở nên khó hơn.
- Thuật toán Paxos cực kỳ khó triển khai.
Nếu có thể nhét vấn đề vào bộ nhớ, có lẽ đó là vấn đề tầm thường
- Với kỹ sư hệ thống phân tán, bài toán chỉ giới hạn trong một máy đơn lẻ được xem là dễ.
- Khi dữ liệu nằm cách vài switch, việc xử lý dữ liệu nhanh sẽ khó hơn nhiều.
"Chậm" là vấn đề khó nhất
- "Chậm" có thể có nghĩa là một hay nhiều hệ thống trong số các hệ thống thực hiện yêu cầu của người dùng đang phản hồi chậm.
- Thất bại từng phần không hiện ra trên biểu đồ, và cho đến khi nó trở nên rõ ràng thì rất khó nhận được nguồn lực cần thiết để xử lý vấn đề.
Cần triển khai backpressure trên toàn hệ thống
- Backpressure là cách hệ thống cung cấp báo hiệu lỗi cho hệ thống gửi yêu cầu, và cách hệ thống gửi yêu cầu xử lý các lỗi đó.
- Nếu không có cơ chế backpressure, rất dễ xảy ra thất bại dây chuyền hoặc mất thông điệp ngoài ý muốn.
Cần tìm cách duy trì khả năng sẵn sàng từng phần
- Điều này có nghĩa là ngay cả khi một phần của hệ thống thất bại, hệ thống vẫn có thể trả về một phần kết quả.
- Ví dụ, hệ thống tìm kiếm có thể trả về các kết quả đã thu thập được nếu không thể tìm hết mọi tài liệu trong một khoảng thời gian nhất định.
Metric là cách duy nhất để hoàn thành công việc
- Việc công khai metric là cách duy nhất để hiểu hệ thống thực sự vận hành như thế nào.
- File log hữu ích, nhưng thường nói dối. Log thành công trong đa số trường hợp là dư thừa nên không được ghi lại.
Hãy dùng percentile thay vì trung bình
- Percentile chính xác và hữu ích hơn trung bình. Trung bình thường dẫn đến các quyết định sai lầm.
Cần học cách ước lượng dung lượng
- Biết cần bao nhiêu máy để thực hiện công việc là điều quan trọng.
- Ví dụ, bạn sẽ thường xuyên phải làm những phép tính nháp như tính xem có thể lưu bao nhiêu tweet ID trong bộ nhớ.
Feature flag là cách rollout hạ tầng
- Feature flag là cách phổ biến để rollout tính năng mới vào hệ thống.
- Dùng feature flag giúp tăng sự tự tin với dự án và giảm chi phí của thất bại.
Cần chọn không gian ID một cách khôn ngoan
- Không gian ID của hệ thống định hình cấu trúc của hệ thống.
- Ví dụ, tweet ID trong Twitter API chỉ là một số 64-bit đơn giản, không gắn với dữ liệu nào khác.
Cần tận dụng tính cục bộ của dữ liệu
- Giữ việc xử lý và caching dữ liệu ở gần nơi lưu trữ bền vững sẽ hiệu quả hơn.
- Mạng gặp nhiều lỗi và độ trễ hơn so với dereference con trỏ và
fread(3).
Ghi ngược dữ liệu đã cache vào kho lưu trữ bền vững là điều tệ hại
- Nhiều hệ thống gặp phải vấn đề này. Đặc biệt thường thấy ở các hệ thống do những người ít kinh nghiệm về hệ thống phân tán thiết kế.
Máy tính làm được nhiều việc hơn bạn nghĩ
- Có rất nhiều thông tin sai lệch về khả năng của máy tính từ những người thực hành còn ít kinh nghiệm.
- Máy chủ web hiện đại có thể xử lý hàng nghìn yêu cầu chỉ trong vài trăm mili giây.
Hãy dùng định lý CAP để phê bình hệ thống
- Định lý CAP không phải thứ có thể dùng để xây dựng hệ thống. Tuy nhiên, nó hữu ích khi phê bình thiết kế hệ thống phân tán.
Cần tách dịch vụ ra
- Ở đây, dịch vụ nghĩa là hệ thống phân tán chứa logic ở mức cao hơn so với hệ thống lưu trữ.
- Việc tách dịch vụ có thể được triển khai nhanh và dễ hơn so với việc tạo thư viện.
Tóm tắt của GN⁺
- Kỹ thuật hệ thống phân tán khác với các lĩnh vực kỹ thuật phần mềm khác vì xác suất thất bại cao và có nhiều thất bại từng phần.
- Viết hệ thống phân tán vững chắc tốn kém hơn, và điều này hiếm thấy trong cộng đồng mã nguồn mở.
- Điều quan trọng là phải hiểu và triển khai các khái niệm như điều phối, tính cục bộ của dữ liệu, backpressure và khả năng sẵn sàng từng phần.
- Có thể nâng cao hiệu quả và độ ổn định của hệ thống bằng metric, percentile, feature flag và lựa chọn không gian ID phù hợp.
- Nên dùng định lý CAP để phê bình hệ thống, và tách dịch vụ ra khi cần thiết.
1 bình luận
Ý kiến trên Hacker News
Nguyên tắc CALM (Consistency as Logical Monotonicity) dễ hiểu hơn CAP và là một kết quả nền tảng hơn
Việc chuyển phát đúng chính xác một lần là bất khả thi; bạn phải chọn либо tối đa một lần hoặc tối thiểu một lần
Bài viết rất hay. Dù là bài từ 8 năm trước, vẫn còn nhiều nội dung giá trị đến nay
Liên kết đến các thảo luận trước đây:
Phần giải thích rất thực tế và mang tính ứng dụng. Không có các từ buzzword như "microservices"
Khi làm việc tại Lookout, Jeff Hodges đã giới thiệu bài tiểu luận này
Tôi từng có kinh nghiệm làm việc cùng tác giả của bài này
Từ năm 2013 đến nay, nhiều thứ đã thay đổi