Đĩ Nghiện Code Thuật Vấn Đáp cách xây dựng một website hàng triệu người dùng P3

MayFest2022 Reconnection

Link bài trước tại đây

Đĩ: Anh nghiện ơi, lại có vấn đề rồi?

Nghiện: Đang ngày nghỉ mà có vấn đề gì thế?

Đĩ: Ơ nay thứ mấy anh nhỉ sao là ngày nghỉ được?

Nghiện: Đối với tao ngày nào cũng là thứ High.

Đĩ: Chả là ngày nghỉ của mọi người (chứ bọn tôi phục vụ mệt chết mẹ nghỉ gì) , anh em đi karaoke, du lịch, đánh golf nhiều quá, vào nhiều sập hệ thống của em.

Nghiện: Hôm trước anh bảo em dí cache vào rồi cơ mà?

Đĩ: Cache hỗ trợ được một phần chứ có nhiều cái vẫn phải vào db mà, chả nhẽ bế cả cái db siêu to khổng lồ hơn hai cái loa của em vào cache to bằng cái núm được à?

Nghiện: Ừ bây giờ phải nghĩ tới giải pháp khác, có lẽ cần một hệ thống replicate, master slave

Đĩ: Cái gì slave hả anh nghe cứ quen quen thế nào ấy nhỉ, để em về lấy dụng cụ sang anh em mình chơi nhé! Em sẽ làm slave cho anh.

Nghiện: Thôi đây là mô hình DB còn slave dụng cụ gì thì tý anh bảo xong rồi mang sang cũng được. Bên hệ thống của em đọc nhiều hay ghi nhiều.

Đĩ: Người ta xem thì nhiều, chứ ghi thì mấy anh.

Nghiện: Vậy thì em phải tách db ra. Một cái master để ghi và nhiều cái slave để đọc.

Đĩ: Kiều như anh là master và có mấy em slave hả, hơi hiểu hiểu rồi.

Nghiện: Mô hình sẽ như thế này.

Đĩ: OK để em thử xem.

Đĩ: Anh ơi cái slave nó vẫn không ổn lắm, vì dữ liệu lớn thì nó vẫn lớn, truy vấn nó vẫn lâu.

Nghiện: Bây giờ phải nghĩ tới Sharding rồi!

Đĩ: Sao anh không nói từ đầu mẹ đi, lúc nào cũng trình bày từ từ mệt vãi, tối tiếp bao nhiêu khách đã mệt rồi, giờ lại phải nghe thằng nghiện liên thuyên mệt mỏi thực sự.

Nghiện: Mày thông cảm tao ngáo tý, lúc nhớ lúc quên.

Đĩ: Thế rốt cuộc cái Sharding nó là cái gì?

Nghiện: Nó đơn giản là chia nhỏ dữ liệu ra thành từng phần rồi lưu ở các DB khác nhau. Rồi có một bảng shard để quyền định cần vào đâu để lấy dữ liệu:

Đĩ: Ví dụ rõ hơn đi anh.

Nghiện: Ví dụ như hệ thống của em có rất nhiều người dùng truy cập, lưu bảng bảng user, em có thể chia ra theo chữ cái đầu của user name. ví dụ A thì lưu vào database A, B thì lưu vào Database B. Lúc đăng nhập em dựa vào tên truy cập để biết nó ở DB nào. Rõ ràng với sharding thế này thì số lượng dữ liệu trên mỗi DB sẽ giảm và truy vấn nhanh hơn.

Đĩ: Nghe cũng hay nhưng mà có một vấn đề nữa là em thấy nhiều người tên bắt đầu vần A, chứ ít người tên bắt đầu bằng vần Ơ, Ư nếu thế sẽ có cái server được chọc nhiều, có cái không được chọc phát nào hả anh?

Nghiện: Đúng là có vấn đề đấy, đó gọi là Celebrity Problem. Trong thực tết sẽ không dựa vào chữ cái đầu như thế kia mà dùng hàm băm để cho cân bằng hơn. Nhưng dù có băm thì thỉnh thoảng vẫn có trường hợp chỗ này nhiều hơn chỗ khác như một số em hot hơn được quan tâm nhiều hơn cái shard đó trở thành hot girl à nhầm hotspot, lúc đó phải sửa hàm, sửa bảng shard, hoặc tăng cấu hình cho con Shard trâu kia.

Đĩ: Anh lưu dữ liệu Shard trong một DB nghĩa là mọi request cần đọc dữ liệu từ đó trước rồi mới qua các DB khác đúng không?

Nghiện: Ừ, Anh đoán em đang sợ nó treo, nhưng vì dữ liệu Shard rất ít thay đổi, lúc này dùng cache rất ngon.

Đĩ: OK em hiểu rồi, nhưng mà em cần join dữ liệu từ nhiều chỗ để lấy, anh cắt nó ra rồi em lấy gì để mà join đây khi dữ liệu nằm trên các server khác nhau?

Nghiện: Vấn đề Shard Join cũng cần cân nhắc, em có thể lưu dư thừa dữ liệu trong các DB shard để đỡ phải join, và cập nhật dữ liệu từ Master DB bằng một worker.

Đĩ: Em cũng đang nghĩ dữ liệu phân tán nhiều mảnh thế làm sao đảm bảo dữ liệu chuẩn, hóa ra cái Shard kia anh chỉ để đọc nhanh thôi đúng không? Còn dữ liệu chuẩn vẫn nằm trên một DB master.

Nghiện: Đúng rồi con master đó là Single Source of Truth (SSOT) đảm bảo cho dữ liệu toàn vẹn còn các dữ liệu Shard kia chủ yếu để đọc.

Đĩ: OK em hiểu rồi.

Nghiện: Cái kia là cho trường hợp của em, còn tùy tình huống cụ thể người ta có thể shading cả phần ghi nữa.

Đĩ: OK khi nào gặp em sẽ làm, hệ thống sẽ như này đúng không anh.