Chào anh em, lại là tôi đây! GAY trước, chúng ta đã biết cách dựng một "quán PHO" từ quy mô vỉa hè lên chuỗi cửa hàng triệu đô, biết cách tính toán vo và bỏ túi quy trình 4 bước để đi phỏng vấn.

Đến GAY này, độ khó sẽ tăng lên nhiều chút. Khi hệ thống của anh em lớn lên, không còn là câu chuyện của 1-2 cái máy chủ nữa, mà là một "đế chế phân tán" với cả trăm, cả ngàn máy chủ chạy song song. Lúc này, nếu không có những "Kẻ gác cổng" xịn và một hạ tầng phân bổ dữ liệu thông minh, hệ thống của anh em sẽ loạn cào cào lên ngay.

Tiền bối Alex Xu dành ra 4 chương để giải quyết bài toán này. Hãy cùng làm gỏi từng phần nhé!

💃 Less 4: Thiết kế bộ hãm phanh – Rate Limiter

Hãy tưởng tượng quán phở triệu đô của ông bỗng dưng bị một bọn "phá đám" vào order liên tục nhưng không ăn, hoặc một ông vào bật máy múc nước lèo mang về bán lại. Server của anh em cũng vậy, sẽ có lúc bị mấy ông rảnh rỗi dùng tool spam API liên tục, hoặc bị đối thủ tấn công DDoS cho sập nguồn. Đây không phải chuyện hiếm đối với các web có traffic tốt.

Lúc này, Rate Limiter chính là anh bảo vệ da đen đứng ở cửa, có nhiệm vụ "hãm phanh" những thành phần phá đám này. Ví dụ: "Một IP chỉ được phép gửi tối đa 5 requests trong vòng 1 giây, quá là ăn block ngay!".

Tiền bối Alex giới thiệu cho chúng ta 5 thuật toán làm Rate Limiter, nhưng đi phỏng vấn anh em chỉ cần nhớ nằm lòng 3 thằng kinh điển nhất sau:

1. Token Bucket (Thùng chứa thẻ):

• Ý tưởng là sử dụng một cái thùng, cứ mỗi giây hệ thống tự động thả vào đó 3 cái thẻ (Token). Khách vào muốn qua cửa phải thò tay lấy 1 cái thẻ. Nếu thùng hết thẻ, khách phải đứng đợi.

• Ưu điểm: Cực kỳ linh hoạt, cho phép một đợt khách ùa vào cùng lúc (Burst of traffic) miễn là trong thùng còn đủ thẻ. Đây là thuật toán mấy ông lớn như Amazon, Stripe cực kỳ chuộng.

2. Leaking Bucket (Thùng nước thủng đáy):

• Cái thùng này bị thủng một lỗ ở đáy. Requests của user giống như nước đổ vào thùng. Nước trong thùng sẽ rò rỉ ra ngoài với một tốc độ đều đặn không đổi (để đem đi xử lý). Nếu user đổ nước vào quá nhanh, thùng đầy thì nước tràn ra ngoài (Request bị từ chối).

• Ưu điểm: Giúp hệ thống luôn xử lý công việc với một tốc độ ổn định tăm tắp, không sợ bị sốc phản vệ khi traffic tăng đột biến.

3. Fixed Window Counter (Đếm theo cửa sổ cố định):

• Chia thời gian thành từng khúc cố định (ví dụ từ 1h00 đến 1h01). Trong khúc này chỉ cho phép 100 requests. Qua phút mới, reset bộ đếm về 0.

• Điểm yếu chết người: Lỗi "bão traffic ở biên". Nếu từ 2:00:59 có 100 ông vào, rồi sang 2:01:01 lại có thêm 100 ông nữa vào $\rightarrow$ Hệ thống phải gánh 200 requests chỉ trong vòng 1 giây ở khoảng giữa, vượt quá giới hạn thiết kế và có thể gây sập tiệm.

💃 Less 5: Vòng tròn ma thuật – Consistent Hashing

Bài toán đặt ra: Anh em có 4 máy chủ Cache (ký hiệu là Node 0, 1, 2, 3). Khi user lưu dữ liệu, thông thường anh em sẽ dùng hàm băm dạng: $\text{Server} = \text{hash(key)} \% 4$. Nếu kết quả ra 0 thì vào Node 1, ra 1 vào Node 2...

Cách này chạy rất ngon cho đến một ngày... Node 3 bị chập nguồn sập (chỉ còn 3 máy), hoặc anh em mua thêm Node X (thành 5 máy). Lúc này, phép chia lấy dư $\%$ kia sẽ đổi từ $\% 4$ sang $\% 3$ hoặc $\% 5$. Kết quả tính toán đảo lộn toàn bộ! Hầu hết dữ liệu cũ tìm trên Cache sẽ bị sai vị trí (Cache Miss), hệ thống cuống cuồng chạy xuống Database quét lại từ đầu $\rightarrow$ Database cháy luôn.

Để giải quyết thảm họa này, tiền bối Alex Xu đưa ra phương pháp Consistent Hashing (Băm nhất quán):

• Cách chơi: Chúng ta không dùng phép chia lấy dư nữa. Hãy tưởng tượng toàn bộ dải giá trị băm được uốn cong lại thành một vòng tròn (từ hòn số 0 đến $2^{32}-1$).
• Chúng ta băm IP của các máy chủ và xếp chúng lên các vị trí trên vòng tròn đó.
• Khi có một dữ liệu (Key) cần lưu, chúng ta cũng băm cái Key đó rồi đặt lên vòng tròn. Sau đó, đi xuôi theo chiều kim đồng hồ xem gặp cái máy chủ nào đầu tiên thì nhét dữ liệu vào máy chủ đó.
• Cái hay ở đây là gì? Nếu một máy chủ bị sập, hệ thống chỉ phải phân bổ lại một phần nhỏ dữ liệu nằm ngay trước máy chủ đó sang máy kế tiếp, các máy chủ khác hoàn toàn không bị ảnh hưởng. Dữ liệu được bảo toàn đến 90%!
• Mẹo Senior: Để tránh tình trạng các máy chủ phân bố không đều trên vòng tròn (chỗ thì thưa quá, chỗ thì dày quá gây lệch tải), người ta dùng thêm chiêu Virtual Nodes (Máy chủ ảo). Nghĩa là một máy chủ vật lý sẽ được băm thành nhiều điểm "bù nhìn" rải rác khắp vòng tròn để chia đều tải tăm tắp.

💃 Less 6: Thiết kế két sắt phân tán – Key-Value Store

Thiết kế một kho lưu trữ dữ liệu dạng Key-Value (như kiểu tự chế một con Redis thu nhỏ) mà chạy trên nhiều máy chủ phân tán là một trong những chương "hại não" nhất cuốn sách. Tiền bối Alex lôi ra một định lý mà bất kỳ ông Senior nào cũng phải thuộc nằm lòng: Định lý CAP.

Định lý này bảo rằng, trong một hệ thống phân tán, ông chỉ được chọn tối đa 2 trong 3 thứ sau chứ không bao giờ có cả 3:

• Consistency (C): Tính nhất quán. Đọc ở máy chủ nào thì dữ liệu cũng phải giống hệt nhau.
• Availability (A): Tính sẵn sàng. Máy chủ nào cũng phải trả lời được requests của user, kể cả khi hệ thống đang có lỗi ngầm.
• Partition Tolerance (P): Tính chịu lỗi đường truyền. Mạng mẽo giữa các máy chủ có bị đứt (Partition) thì hệ thống tổng vẫn phải sống.

Vì trong thực tế, dây mạng kiểu gì cũng có ngày bị chuột cắn (luôn luôn có P), nên anh em chỉ có thể chọn CP (Ưu tiên dữ liệu chính xác, nếu mạng lỗi thì từ chối phục vụ để tránh sai lệch) hoặc AP (Ưu tiên mở cửa bán hàng 24/7, mạng lỗi thì cứ cho ghi dữ liệu bừa đi, sau này mạng kết nối lại thì sửa sai sau).

Làm sao để các máy chủ "đồng lòng" cập nhật dữ liệu?

Trước hết, bạn phải nắm được 2 khái niệm kho phân phối dữ liệu (Data Partitioning) và sao lưu dữ liệu (Data Replication)

• Data Partitioning: Làm thế nào để chia đều dữ liệu khổng lồ sang nhiều máy chủ?
  • Sử dụng kỹ thuật Consistent Hashing (đã nêu ở less 5).
  • Các máy chủ và các key được băm và đặt lên một vòng tròn băm (Hash Ring).
  • Kỹ thuật này giúp phân bổ tải đều nhờ các Nút ảo (Virtual Nodes) và giảm thiểu di chuyển dữ liệu khi thay đổi hạ tầng
• Data Replication: Để đảm bảo độ sẵn sàng cao, dữ liệu phải được sao lưu sang nhiều máy chủ khác nhau.
  • Khi một key được băm vào một vị trí trên vòng tròn băm
  • Hệ thống sẽ đi theo chiều kim đồng hồ và lưu bản sao của key đó lên N máy chủ thực tế đầu tiên gặp được trên vòng tròn (với N là hệ số sao lưu được cấu hình trước).

Để điều khiển tính nhất quán giữa các nút đọc và ghi, tiền bối Alex chỉ ra mô hình Quorum thông qua 3 tham số:

• $N$: Số lượng máy chủ sao lưu.
• $W$: Số lượng máy chủ cần xác nhận (ACK) ghi thành công thì thao tác ghi mới coi là hoàn tất.
• $R$: Số lượng máy chủ cần phản hồi dữ liệu giống nhau thì thao tác đọc mới coi là hoàn tất.
• Nếu $W + R > N$: Hệ thống đảm bảo tính Nhất quán mạnh (Strong Consistency) vì chắc chắn tập máy chủ đọc và tập máy chủ ghi sẽ có ít nhất một máy chủ trùng nhau (luôn đọc được dữ liệu mới nhất).
• Nếu $W + R \le N$: Hệ thống ưu tiên tốc độ, chấp nhận Nhất quán sau cùng (Eventual Consistency). Tức là chấp nhận dữ liệu có thể “chưa đồng bộ ngay lập tức” ở mọi nơi, miễn là hệ thống phản hồi nhanh hơn.

💃 Less 7: Unique ID Generator

Chương cuối của phần này giải quyết một bài toán nghe thì rất nhỏ nhưng lại cực kỳ nhức nhối: Làm sao để tạo ra một cái ID (ví dụ số hóa đơn, số định danh user) tăng dần theo thời gian, duy nhất trên đời, trong một hệ thống có cả ngàn máy chủ chạy đồng thời?

Dùng hàm UUID sinh ra chuỗi kiểu de305d54-75b4-431b-adb2-eb6b9e546013?

• Chê: Chuỗi này dài quá, tốn bộ nhớ lưu trữ, index dưới DB rất chậm, và quan trọng là nó không có tính chất tăng dần theo thời gian (nhìn vào ID không biết cái nào tạo trước, cái nào tạo sau).

Giải pháp tối ưu nhất được tiền bối Alex "mượn" từ thuật toán Snowflake của Twitter. Cắt nhỏ một chuỗi số 64-bit ra thành từng khúc như khúc giò:

+--------+------------------------+------------------+------------------+
| 1 bit  |        41 bits         |     10 bits      |     12 bits      |
| Unused |       Timestamp        |  Datacenter &    | Sequence Number  |
|        | (Thời gian mili-giây)  |    Machine ID    |  (Số thứ tự tự   |
|        |                        | (Định danh máy)  |   tăng trong 1ms)|
+--------+------------------------+------------------+------------------+

• 1 bit đầu: Để trống cho vui (giữ số dương).
• 41 bits tiếp theo: Dùng để lưu thời gian (Timestamp) dạng mili-giây. Nhờ khúc này mà ID sinh ra tự động tăng dần theo thời gian!
• 10 bits ở giữa: Định danh xem cái ID này được sinh ra từ Máy chủ số mấy, nằm ở Trung tâm dữ liệu (Datacenter) nào. Đảm bảo không ông máy chủ nào sinh trùng với ông nào.
• 12 bits cuối cùng: Là số thứ tự tự tăng trong cùng một mili-giây (tối đa $4096$ số). Nếu sang mili-giây mới, số này lại reset về 0.

Kết quả: Anh em có một cái ID dạng số nguyên (BigInt) siêu gọn nhẹ, không bao giờ trùng, index chạy tít mù, lại còn biết luôn thời gian tạo đơn hàng mà không cần thêm cột created_at!

📚 Góc từ điển – Thuật ngữ & Từ viết tắt

🍻 Lời kết cho Gay 2

Thế là anh em mình đã đi qua những cánh rừng rậm rạp nhất của hạ tầng phân tán. Nhờ có Rate Limiter chặn phá hoại, Consistent Hashing chia đều tải Cache, Định lý CAP định hướng lưu trữ, và Snowflake in số thứ tự, hệ thống của chúng ta giờ đây đã vững như bàn thạch, sẵn sàng gánh những dự án khổng lồ.

🚀 GAY kế nói gì :> ???

🏳️‍🌈 GAY 3: NHỮNG "KẺ GÁC CỔNG" VÀ HẠ TẦNG PHÂN TÁN

Ở GAY 3 tiếp theo, tôi và anh em sẽ chính thức đem đao kiếm ra thực chiến: Thiết kế những hệ thống đời thực siêu khủng như TinyURL, News Feed Facebook, Hệ thống Chat và YouTube.

Chúc anh em cuối tuần không phải nhận cảnh báo sập server nhé =))) 🍻