Mục lục:
- Tại sao nhà tuyển dụng lại đưa ra một câu hỏi mở như vậy?
- Mô hình sản xuất - tiêu thụ và cấu trúc dữ liệu cốt lõi
- Kiến trúc phân tán hỗ trợ ghi dữ liệu cấp TB
- Kiến trúc khả dụng cao trong trường hợp lỗi dữ liệu
- Cơ chế ack hỗ trợ dữ liệu không bị mất
- Kết luận
1. Tại sao nhà tuyển dụng lại đưa ra một câu hỏi mở như vậy?
Bài viết này sẽ thảo luận về một câu hỏi phỏng vấn Java tại các công ty Internet hàng đầu: Nếu bạn được yêu cầu thiết kế một hệ thống message broker (hệ thống trung gian thông điệp), bạn sẽ làm như thế nào?
Thực ra, vấn đề này đã được thảo luận sơ lược trước đây, về cơ bản là nhà tuyển dụng đang đánh giá khả năng thiết kế hệ thống của một kỹ sư Java cấp cao.
Họ đưa cho bạn một hệ thống message broker thường được sử dụng làm đề bài, yêu cầu bạn trình bày một cách tự do trong lúc phỏng vấn, ngay lập tức vận dụng trí não để suy nghĩ về cách thiết kế một hệ thống message broker như vậy nếu bạn được giao nhiệm vụ.
Yêu cầu bạn xem xét từ nhiều góc độ, bao gồm architecture (kiến trúc) tổng thể, core process (quy trình cốt lõi), data structure (cấu trúc dữ liệu), v.v., làm thế nào để hoàn thành thiết kế này?
Thực tế, bất kỳ nhà tuyển dụng nào cũng nên biết rằng nếu một người chưa từng thực sự phát triển message broker, thì rất khó để họ có thể đưa ra một phương án thiết kế architecture đáng tin cậy trong thời gian ngắn.
Tuy nhiên, việc sử dụng câu hỏi này làm một đề bài mở, lợi ích lớn nhất của nó là có thể khai thác tối đa khả năng thiết kế hệ thống và kiến thức cơ bản tương đối thực tế của ứng viên.
Tại sao lại nói như vậy?
Bởi vì nếu trong quá trình phỏng vấn, nhiều câu hỏi đều là những câu hỏi kỹ thuật phổ biến, ví dụ như:
- Message broker đảm bảo dữ liệu không bị mất như thế nào?
- Nói về nguyên lý architecture và performance optimization (tối ưu hóa hiệu suất) của ElasticSearch?
- Kiến trúc microservice của công ty bạn được thiết kế như thế nào?
Những câu hỏi này tương đối cố định.
Nói cách khác, miễn là bạn dành thời gian để học hỏi các kỹ thuật liên quan hoặc có một số kinh nghiệm thực tế trong công ty của mình, thì việc trả lời những câu hỏi này thường không phải là vấn đề lớn.
Tuy nhiên, những câu hỏi này không đủ mở, nếu hai ứng viên đều có khả năng trả lời những câu hỏi thông thường như nhau, thì lúc này, bằng một câu hỏi mở có chiều sâu, có thể nhanh chóng phân biệt được ai có kiến thức cơ bản kỹ thuật tốt hơn, ai có khả năng thiết kế architecture mạnh hơn.
Vậy bài viết này sẽ hướng dẫn mọi người suy nghĩ từ nhiều góc độ, giả sử bạn được hỏi câu hỏi này, bạn có thể bắt đầu suy nghĩ và trả lời từ những khía cạnh nào?
2. Mô hình sản xuất - tiêu thụ và cấu trúc dữ liệu cốt lõi
Trước tiên, điểm đầu tiên, hệ thống message broker cần thực hiện là cho phép người ta produce messages (sản xuất thông điệp) và cũng cho phép người ta consume messages (tiêu thụ thông điệp).
Vậy điểm đầu tiên cần xem xét ở đây là data structure (cấu trúc dữ liệu) cốt lõi của hệ thống message broker.
Nói cách khác, nếu ai đó tạo ra một thông điệp, với tư cách là một hệ thống message broker, bạn nên lưu trữ dữ liệu này như thế nào?
Bạn sẽ lưu trữ trong memory (bộ nhớ) hay lưu trữ trong disk files (tệp trên đĩa)? Hoặc cả hai đồng thời cùng tồn tại?
Có thể cho phép dữ liệu ghi vào memory làm bộ đệm, sau đó mỗi vài giây lại ghi dữ liệu vào disk files? Sau khi ghi dữ liệu vào disk files, disk files này có bao nhiêu?
Bạn không thể cứ mãi tạo ra một disk files để lưu trữ tất cả dữ liệu được chứ? Vậy theo quy tắc nào để phân chia disk files?
Sau khi ghi dữ liệu vào disk files, liệu có cần một số metadata (thông tin bổ sung về dữ liệu) tương ứng để xác định thông tin cụ thể của dữ liệu này hay không? Ví dụ như offset (vị trí) của dữ liệu này, hoặc một id duy nhất tích hợp?
Tiếp theo, hiện tại dữ liệu được lưu trữ trong disk files, vậy làm cách nào để bạn truyền dữ liệu này đến các consumers (máy tiêu thụ) ở hạ lưu?
Consumption model (Mô hình tiêu thụ) của bạn là gì? Ví dụ như dữ liệu trong một queue, sẽ được phân bổ đều cho mỗi instance của consumer hay sẽ làm gì?
Ở đây tôi muốn đưa ra một gợi ý cho mọi người, hãy nghiên cứu nguyên lý lưu trữ disk files ở mức độ thấp của Kafka, đó là một kiến trúc thực hiện lưu trữ dữ liệu hiệu năng cao, song song cao rất điển hình của message broker.
Ngoài ra, bạn có thể tham khảo trang web chính thức của RabbitMQ và Kafka, nghiên cứu cách thức triển khai consumption model của các message broker khác nhau.
3. Kiến trúc phân tán hỗ trợ ghi dữ liệu cấp TB
Tiếp theo, bạn nên xem xét vấn đề lớn thứ hai, hệ thống message broker của bạn chắc chắn sẽ gặp phải tình huống ghi dữ liệu hàng loạt với tốc độ cao và lưu lượng lớn hàng ngày.
Vậy architecture (kiến trúc) của hệ thống message broker của bạn sẽ hỗ trợ như thế nào?
Vì vậy, ở đây bạn cần xem xét liệu dữ liệu của bạn có nên được lưu trữ theo cách phân tán hay không?
Ví dụ, giả sử bạn ghi hàng trăm TB dữ liệu mỗi ngày, thì không thể lưu trữ tất cả trên một máy được. Vậy distributed storage (lưu trữ phân tán) có phải là một vấn đề quan trọng khác mà bạn cần xem xét hay không?
Liệu bạn có nên xem xét partitioning (chia nhỏ) tập dữ liệu lớn thành các data partitions (phân vùng dữ liệu), ví dụ như chia thành N data partitions, mỗi data partition được lưu trữ trên một máy, theo cách này có thể tận dụng tối đa tài nguyên của nhiều máy để chịu đựng khối lượng dữ liệu lớn cấp TB.
Ngoài ra, bạn cần xem xét liệu data partitions của bạn có thể hỗ trợ scaling (mở rộng) hay không?
Ví dụ như ban đầu bạn đặt số lượng partitions là 10, tồn tại trên 10 máy. Sau đó, bạn phát hiện ra rằng 10 máy không thể chịu đựng được, cần phải scale up (mở rộng) thành 20 partitions, được lưu trữ trên 20 máy.
Vậy liệu bạn có nên hỗ trợ scaling up và tự động data load balancing and migration (cân bằng tải dữ liệu và di chuyển dữ liệu)? Có nghĩa là dữ liệu của 10 partitions được phân bổ đều tự động cho 20 partitions sau khi scale up.
Vì vậy, distributed architecture (kiến trúc phân tán) và scalability (khả năng mở rộng) này là một điểm cốt lõi khác.
Cá nhân tôi cũng khuyên mọi người nên nghiên cứu thiết kế architecture của Kafka trong khía cạnh này, rất xuất sắc, nó sử dụng khái niệm partitions để thực hiện data partitioning, hỗ trợ distributed storage và cũng hỗ trợ dynamic scaling.
4. Kiến trúc khả dụng cao trong trường hợp lỗi dữ liệu
Mọi người giờ cần xem xét một vấn đề khác, đó là sau khi dữ liệu được lưu trữ phân tán, thì mỗi máy đều có một phần dữ liệu.
Nếu máy này bị lỗi thì sao? Vậy dữ liệu có bị mất hay không?
Đúng vậy! Vì vậy, high availability architecture (kiến trúc khả dụng cao) ở đây phải được xem xét.
Hệ thống phân tán thường sử dụng cơ chế replication (sao chép) để thực hiện high availability architecture.
Nói cách khác, một phần dữ liệu được tạo bản sao trên nhiều máy, theo cách này, bất kể máy nào bị lỗi, dữ liệu chắc chắn sẽ không bị mất, bạn vẫn có thể tiếp tục sử dụng bản sao dữ liệu trên các máy khác để hỗ trợ producing và consuming messages.
Tương tự, tôi khuyên mọi người nên nghiên cứu cơ chế replication của Kafka, mỗi partition của nó đều có nhiều replicas (bản sao), bất kể máy nào bị lỗi, mất một partition, các replicas của partition đó trên các máy khác vẫn có thể hỗ trợ dữ liệu không bị mất.
5. Cơ chế ack hỗ trợ dữ liệu không bị mất
Cuối cùng, hãy xem xét một vấn đề nữa, hệ thống message broker của bạn chắc chắn phải hỗ trợ dữ liệu không bị mất hoàn toàn phải không?
Vậy bạn phải hỗ trợ acknowledgement mechanism (ack mechanism) (cơ chế xác nhận) của producers (máy sản xuất) và consumers (máy tiêu thụ):
Ở đây bạn phải xem xét hai phần ack mechanism, một là producer, sau khi gửi một thông điệp, phải yêu cầu nó ghi dữ liệu vào nhiều replicas trước khi trả về phản hồi ack.
Nếu không nhận được ack trong một thời gian dài, thì cần phải retry sending the message (gửi lại thông điệp), đảm bảo việc gửi thông điệp của producer thành công.
Hai là consumer, sau khi xử lý thành công một thông điệp, phải trả về một ack cho message broker, sau đó message broker mới có thể xóa thông điệp này.
Nếu không, một khi consumer bị lỗi, thì phải retry sending the message (gửi lại thông điệp) này cho các instance consumer khác, đảm bảo thông điệp nhất định được xử lý thành công.
6. Kết luận
Loại câu hỏi mở này liên quan đến rất nhiều chi tiết ở mức độ thấp và architectural design (thiết kế kiến trúc), rất khác biệt về trình độ kỹ thuật của mỗi người. Nếu bạn trả lời đơn giản, thì chỉ cần nói sơ lược về những thứ được đề cập trong bài viết này, về cơ bản là có thể vượt qua.
Tuy nhiên, nếu bạn muốn áp đảo mọi người, thì bạn phải thực sự nghiên cứu kỹ mã nguồn ở mức độ thấp của các message broker khác nhau dựa trên những thứ được nhắc đến trong từng phần của bài viết này, sau đó mới có thể thể hiện "áp đảo người khác" về kiến thức cơ bản kỹ thuật và sức mạnh architectural design khi trả lời câu hỏi này.