Trong bài viết về "LUỒNG HOẠT ĐỘNG CỦA MỘT ỨNG DỤNG WEB CƠ BẢN", mình đã chia sẻ cho các bạn thấy một sơ đồ cơ bản bao gồm 1 Web Server và 1 Database để giúp các bạn dễ hiểu và tiếp cận.
Tuy nhiên, trong thực tế mọi chuyện sẽ không đơn giản như vậy. Giả sử trường hợp Database duy nhất đó bị sập thì sao?
Lúc ấy chúng ta sẽ không thể kết nối tới Database để thêm, sửa, xóa và lấy dữ liệu nữa. Mà các thao tác với dữ liệu lại là phần QUAN TRỌNG BẬC NHẤT trong 1 ứng dụng. Như vậy thì coi như người dùng cũng không sử dụng được ứng dụng để thực hiện những chức năng mong muốn nữa, và đương nhiên họ sẽ rất dễ có những đánh giá tiêu cực về phần mềm mà chúng ta tạo ra.
Một trong những cách giải quyết thường được áp dụng nhất đó là Database Replication.
🔑 ĐỊNH NGHĨA
Database Replication có thể được sử dụng trong nhiều hệ quản lý cơ sở dữ liệu, thường có mối quan hệ Master - Slave (Chủ nhân - Nô lệ)
-
Master database thường chỉ hỗ trợ các thao tác ghi dữ liệu. Tức là, tất cả các câu lệnh như
INSERT,UPDATE,DELETEsẽ thực hiện trên master database. -
Còn các Slave database sẽ copy dữ liệu từ master database và chỉ hỗ trợ các thao tác đọc dữ liệu.
Việc phân chia nhiệm vụ rõ ràng này sẽ giúp cho quá trình đồng bộ dữ liệu không bị nhập nhằng giữa master và slave.
Hầu hết các ứng dụng sẽ thực hiện ĐỌC dữ liệu NHIỀU HƠN là ghi dữ liệu. Do đó, số lượng Slave database trong một hệ thống thường sẽ nhiều hơn số lượng Master database.
✅ NHỜ VIỆC ÁP DỤNG DATABASE REPLICATION MÀ HỆ THỐNG CỦA CHÚNG TA SẼ CÓ:
-
Hiệu suất tốt hơn (Performance): Vì các thao tác đọc ghi được xử lý riêng ở Master và Slave, nên chúng ta có thể tận dụng để cho phép xử lý song song nhiều truy vấn hơn.
-
Độ tin cậy (Reliability): Nếu một trong những Database Server bị sập, dữ liệu vẫn sẽ được bảo toàn, vì dữ liệu đã được copy trên nhiều Database khác nhau.
-
Tính khả dụng (High Availability): Trong bài viết về Load Balancer mình cũng đã chia sẻ với các bạn về thuật ngữ này, và nó ảnh hưởng đến uy tín của dự án, công ty như thế nào. Cũng nhờ việc copy dữ liệu trên nhiều Database khác nhau, trang web của bạn vẫn đảm bảo hoạt động bình thường. Ví dụ: Khi một Slave Database có vấn đề, thì dữ liệu sẽ được đọc từ một Slave Database khác.
🤓 NGOÀI LỀ
Có một sự kiện khá thú vị gần đây đó là: GitHub thay đổi nhánh mặc định từ "master" thành "main".
Lý do được đưa ra là vì việc sử dụng các từ khóa nhạy cảm như:
-
Master - Slave (Chủ nhân - Nô lệ)
-
Whilelist - Blacklist (Liên tưởng đến vấn đề màu da, sắc tộc)
-
...
Nên rất nhiều dự án mã nguồn mở đã cố gắng đề giải quyết vấn đề này:
-
Linus Torvalds thông qua đề xuất loại bỏ các từ khóa Master, Slave, Blacklist trong Linux.
-
Database MySQL, ngôn ngữ lập trình Python cũng thực hiện các hành động tương tự như vậy.
-
Redis thậm chí phải sửa đổi cả kiến trúc Master - Slave của mình.
-
...
Vậy nên có thể thấy, để thay đổi dù chỉ là những điều tưởng như rất vậy, nhưng cũng phải mất rất nhiều thời gian. Bởi, đây không chỉ là thay đổi về mặt kỹ thuật, mà là cả thói quen của người dùng khi đã quá quen với những thuật ngữ, tính năng này từ nhiều năm trước đó.
Đây chính là tầm quan trọng của việc viết code làm sao cho dễ đọc, dễ hiểu và quan trọng là dễ bảo trì, cập nhật, sửa đổi ở trong tương lai.
LỜI NHẮN
Hi vọng kiến thức này hữu ích với bạn.
Follow mình trên Facebook "CLB Lập trình - THPT Ngọc Tảo" hoặc kênh Youtube "Tờ Mờ Sáng học Lập trình" để cùng nhau học tập, chia sẻ những kiến thức công nghệ và lập trình hoàn toàn miễn phí nhé!
Facebook CLB Lập trình - THPT Ngọc Tảo: https://www.facebook.com/clb.it.ngoctao/
Youtube Tờ Mờ Sáng học Lập trình: https://www.youtube.com/@tmsangdev
Hẹn gặp lại 👋
BẠN CÓ THỂ ĐỌC THÊM
Clean Architecture: A Craftsman’s Guide to Software Structure and Design - Robert C. Martin
Designing Data – Insensitive applications - Martin Kleppmann
System Analysis and Design - Alan Dennis, Barbara Haley Wixom, Roberta M. Roth
System Design Interview - Alex Xu
Modern Systems Analysis and Design - Joseph Valacich, Joey George
Head First Design Patterns - Eric Freeman, Elisabeth Robson