[Series Hệ thống chịu tải cao] Bài 5: Hệ thống "bất tử" – Thiết kế cơ chế chịu lỗi (HA) cho Kafka & ES

Chào anh em! Chúng ta thường nói về việc hệ thống chịu được triệu người dùng, nhưng có một kịch bản đáng sợ hơn: Hệ thống đang chạy thì một con server bốc khói, hoặc cả một Data Center mất điện. Trong bài cuối này, mình sẽ chia sẻ cách cấu hình để Kafka và Elasticsearch vẫn mỉm cười vượt qua "giông bão".

1. Kafka: Sống sót nhờ Replication Factor

Trong Kafka, dữ liệu không bao giờ nằm cô đơn trên một server. Bí kíp ở đây là chỉ số replication.factor.

• Cấu hình chuẩn: Thường là bằng 3. Tức là mỗi mẩu dữ liệu quẹt thẻ Metro sẽ được nhân bản ra 3 bản, nằm trên 3 con Server (Brokers) khác nhau.
• Cơ chế Leader/Follower: Tại một thời điểm, chỉ có 1 con làm "Sếp" (Leader) để nhận dữ liệu. 2 con còn lại (Followers) lẳng lặng copy theo.
• Khi "Sếp" chết: Kafka sẽ tự động bầu một con Follower lên làm Sếp mới trong vài miligiây. Anh em Developer thậm chí còn không kịp nhận ra có sự cố vừa xảy ra.

Lưu ý "xương máu": Đừng bao giờ để min.insync.replicas = 1. Hãy để bằng 2 để đảm bảo dữ liệu ít nhất phải nằm trên 2 server mới được coi là thành công.

2. Elasticsearch: Sức mạnh của Replica Shards

Tương tự Kafka, ES cũng không "bỏ trứng vào một giỏ". Khi bạn tạo một Index, hãy chú ý đến number_of_replicas.

• Primary Shard: Nơi xử lý ghi dữ liệu chính.
• Replica Shard: Bản sao dự phòng.
• Tác dụng kép: Replica không chỉ để dự phòng khi Primary chết, mà nó còn giúp tăng tốc độ đọc. Khi có quá nhiều người cùng tra cứu báo cáo, ES sẽ điều hướng truy vấn sang cả các bản Replica để giảm tải cho bản Primary.

3. Chia để trị theo "Vùng địa lý" (Rack Awareness)

Một lỗi kinh điển: Bạn có 3 server nhưng cả 3 đều cắm chung một ổ điện hoặc chung một Rack (tủ rack) trong Data Center. Nếu cái tủ đó chập điện, coi như xong!

Cả Kafka và ES đều hỗ trợ cấu hình Rack Awareness:

Bạn khai báo Server 1 ở Rack-A, Server 2 ở Rack-B.

Hệ thống sẽ thông minh tự hiểu: "À, mình phải để bản sao của dữ liệu này sang Rack khác, lỡ Rack này có sập thì vẫn còn Rack kia".

4. Giám sát (Monitoring) – "Khám sức khỏe" định kỳ

Hệ thống HA không có nghĩa là bạn có thể "kê cao gối ngủ". Bạn cần biết khi nào một con node bắt đầu yếu đi trước khi nó chết hẳn.

Metric quan trọng: Under-replicated Partitions (trong Kafka) và Cluster Health: Yellow/Red (trong ES).

Công cụ khuyên dùng: Bộ đôi Prometheus & Grafana. Hãy cài đặt cảnh báo (Alert) qua Telegram/Slack ngay khi có một node "mất nhịp tim".

Tổng kết Series

Qua 5 bài viết, chúng ta đã đi từ việc hiểu Tư duy hệ thống, mổ xẻ nội tạng của Kafka & ES, kết nối chúng bằng Kafka Connect và cuối cùng là bảo vệ chúng bằng cơ chế HA.

Làm hệ thống chịu tải cao giống như việc xây một cây cầu: Không chỉ cần nó đẹp, nó nhanh, mà quan trọng nhất là nó phải Vững. Hy vọng những chia sẻ từ thực tế làm hệ thống Metro của mình sẽ giúp anh em tự tin hơn khi đối mặt với những bài toán "khủng" trong tương lai.