Thiết kế một hệ thống hỗ trợ hàng triệu người dùng là một thách thức lớn, đòi hỏi sự tinh chỉnh liên tục và cải tiến không ngừng. Trong bài viết này, chúng ta sẽ bắt đầu với hệ thống hỗ trợ một người dùng và dần dần mở rộng để phục vụ hàng triệu người dùng. Sau khi đọc, bạn sẽ nắm vững một số kỹ thuật giúp bạn thiết kế hệ thống với hàng triệu người dùng truy cập.
Thiết lập máy chủ đơn
Một hành trình dài bắt đầu từ một bước đi nhỏ, và việc xây dựng một hệ thống phức tạp cũng không khác gì. Để bắt đầu, mọi thứ đều chạy trên một máy chủ đơn. Người dùng truy cập website qua tên miền và gửi yêu cầu HTTP tới máy chủ web, máy chủ này sẽ trả về trang HTML hoặc phản hồi JSON.
Để hiểu cấu hình này, chúng ta nên xem xét luồng yêu cầu và nguồn lưu lượng truy cập.
- Người dùng truy cập website qua tên miền, chẳng hạn như api.mysite.com. Thông thường, Hệ thống Tên miền (DNS) là một dịch vụ trả phí được cung cấp bởi bên thứ ba và không được lưu trữ trên các máy chủ của chúng ta.
- Địa chỉ Giao thức Internet (IP) được trả về cho trình duyệt hoặc ứng dụng di động. Trong ví dụ này, địa chỉ IP 15.125.23.214 được trả về.
- Khi đã có địa chỉ IP, các yêu cầu Giao thức Truyền Siêu văn bản (HTTP) được gửi trực tiếp đến máy chủ web của bạn.
- Máy chủ web trả về các trang HTML hoặc phản hồi JSON để hiển thị.
Tiếp theo, hãy xem xét nguồn lưu lượng truy cập. Lưu lượng truy cập đến máy chủ web của bạn xuất phát từ hai nguồn: ứng dụng web và ứng dụng di động.
- Ứng dụng web: Sử dụng kết hợp các ngôn ngữ phía máy chủ (Java, Python, v.v.) để xử lý logic kinh doanh, lưu trữ, v.v. và các ngôn ngữ phía khách (HTML và JavaScript) để hiển thị.
- Ứng dụng di động: Giao thức HTTP là giao thức truyền thông giữa ứng dụng di động và máy chủ web. JSON thường được sử dụng làm định dạng phản hồi API để truyền dữ liệu do tính đơn giản của nó.
Cơ sở dữ liệu
Khi số lượng người dùng tăng lên, một máy chủ sẽ không đủ và chúng ta cần nhiều máy chủ: một máy chủ cho lưu lượng web/di động và một máy chủ cho cơ sở dữ liệu. Việc tách biệt lưu lượng web/di động (web tier) và máy chủ cơ sở dữ liệu (data tier) cho phép chúng được mở rộng một cách độc lập.
Nên sử dụng cơ sở dữ liệu nào?
Bạn có thể chọn giữa cơ sở dữ liệu quan hệ truyền thống và cơ sở dữ liệu phi quan hệ. Hãy cùng xem xét sự khác biệt của chúng.
- Cơ sở dữ liệu quan hệ còn được gọi là hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) hoặc cơ sở dữ liệu SQL. Các cơ sở dữ liệu phổ biến nhất là MySQL, Oracle Database, PostgreSQL, v.v. Cơ sở dữ liệu quan hệ biểu diễn và lưu trữ dữ liệu trong các bảng và hàng. Bạn có thể thực hiện các phép nối (join) bằng SQL giữa các bảng cơ sở dữ liệu khác nhau.
- Cơ sở dữ liệu phi quan hệ còn được gọi là cơ sở dữ liệu NoSQL. Các cơ sở dữ liệu phổ biến là CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB, v.v. Những cơ sở dữ liệu này được chia thành bốn loại: kho khóa-giá trị, kho đồ thị, kho cột, và kho tài liệu. Các phép nối thường không được hỗ trợ trong cơ sở dữ liệu phi quan hệ. Bạn có nên vượt ra ngoài cơ sở dữ liệu quan hệ?
Đối với hầu hết các nhà phát triển, cơ sở dữ liệu quan hệ là lựa chọn tốt nhất vì chúng đã tồn tại hơn 40 năm và lịch sử đã chứng minh hiệu quả của chúng. Tuy nhiên, nếu cơ sở dữ liệu quan hệ không phù hợp với các trường hợp sử dụng cụ thể của bạn, việc khám phá các cơ sở dữ liệu phi quan hệ là điều cần thiết.
Cơ sở dữ liệu phi quan hệ có thể là lựa chọn đúng đắn nếu:
- Ứng dụng của bạn yêu cầu độ trễ siêu thấp.
- Dữ liệu của bạn không có cấu trúc hoặc bạn không có dữ liệu quan hệ.
- Bạn chỉ cần tuần tự hóa và giải tuần tự hóa dữ liệu (JSON, XML, YAML, v.v.).
- Bạn cần lưu trữ một lượng dữ liệu khổng lồ.
Mở rộng theo chiều dọc và chiều ngang
- Mở rộng theo chiều dọc, còn gọi là "scale up", nghĩa là quá trình thêm nhiều sức mạnh (CPU, RAM, v.v.) cho các máy chủ của bạn.
- Mở rộng theo chiều ngang, còn gọi là "scale-out", cho phép bạn mở rộng bằng cách thêm nhiều máy chủ vào nhóm tài nguyên của mình.
Khi lưu lượng truy cập thấp, mở rộng theo chiều dọc là một lựa chọn tuyệt vời và sự đơn giản của mở rộng theo chiều dọc là lợi thế chính của nó. Tuy nhiên, nó đi kèm với những hạn chế nghiêm trọng:
- Mở rộng theo chiều dọc có giới hạn cứng. Không thể thêm CPU và bộ nhớ không giới hạn vào một máy chủ duy nhất.
- Mở rộng theo chiều dọc không có khả năng chuyển đổi dự phòng và dự phòng. Nếu một máy chủ gặp sự cố, trang web/ứng dụng sẽ ngừng hoạt động hoàn toàn.
Mở rộng theo chiều ngang được ưa chuộng hơn cho các ứng dụng quy mô lớn do những hạn chế của mở rộng theo chiều dọc.
Trong thiết kế trước đó, người dùng kết nối trực tiếp với máy chủ web. Người dùng sẽ không thể truy cập vào trang web nếu máy chủ web ngừng hoạt động. Trong một kịch bản khác, nếu nhiều người dùng truy cập máy chủ web đồng thời và máy chủ web đạt đến giới hạn tải, người dùng thường sẽ trải nghiệm phản hồi chậm hơn hoặc không thể kết nối với máy chủ. Bộ cân bằng tải là kỹ thuật tốt nhất để giải quyết những vấn đề này.
Bộ cân bằng tải
Bộ cân bằng tải phân phối đều lưu lượng truy cập đến các máy chủ web được xác định trong một tập hợp cân bằng tải.
Như minh họa, người dùng kết nối trực tiếp đến IP công khai của bộ cân bằng tải. Với thiết lập này, máy chủ web không còn truy cập trực tiếp bởi các khách hàng nữa. Để bảo mật tốt hơn, các IP riêng được sử dụng để giao tiếp giữa các máy chủ. IP riêng là một địa chỉ IP chỉ có thể truy cập giữa các máy chủ trong cùng một mạng. Tuy nhiên, nó không thể truy cập qua internet. Bộ cân bằng tải giao tiếp với các máy chủ web thông qua các IP riêng.
Trong hình trên, sau khi thêm bộ cân bằng tải và máy chủ web thứ hai, chúng ta đã giải quyết thành công vấn đề không có khả năng chuyển đổi dự phòng và cải thiện tính khả dụng của tầng web. Các chi tiết được giải thích dưới đây:
- Nếu máy chủ 1 ngừng hoạt động, tất cả lưu lượng sẽ được chuyển hướng đến máy chủ 2. Điều này ngăn chặn trang web bị ngừng hoạt động. Chúng ta cũng sẽ thêm một máy chủ web mới và khỏe mạnh vào nhóm máy chủ để cân bằng tải.
- Nếu lưu lượng truy cập trang web tăng nhanh, và hai máy chủ không đủ để xử lý lưu lượng, bộ cân bằng tải có thể giải quyết vấn đề này một cách linh hoạt. Bạn chỉ cần thêm nhiều máy chủ vào nhóm máy chủ web, và bộ cân bằng tải sẽ tự động bắt đầu gửi các yêu cầu đến chúng.
Hiện tại tầng web đã ổn, còn tầng dữ liệu thì sao? Thiết kế hiện tại chỉ có một cơ sở dữ liệu, vì vậy nó không hỗ trợ chuyển đổi dự phòng và dự phòng. Sao chép cơ sở dữ liệu là một kỹ thuật phổ biến để giải quyết những vấn đề này. Hãy cùng xem xét.
Sao chép cơ sở dữ liệu
Theo Wikipedia: “Sao chép cơ sở dữ liệu có thể được sử dụng trong nhiều hệ thống quản lý cơ sở dữ liệu, thường với mối quan hệ chính/phụ giữa cơ sở dữ liệu gốc (chính) và các bản sao (phụ)”.
Một cơ sở dữ liệu chính thường chỉ hỗ trợ các thao tác ghi. Một cơ sở dữ liệu phụ nhận bản sao dữ liệu từ cơ sở dữ liệu chính và chỉ hỗ trợ các thao tác đọc. Tất cả các lệnh thay đổi dữ liệu như chèn, xóa hoặc cập nhật phải được gửi đến cơ sở dữ liệu chính. Hầu hết các ứng dụng yêu cầu tỷ lệ đọc cao hơn nhiều so với ghi. Do đó, số lượng cơ sở dữ liệu phụ trong hệ thống thường nhiều hơn số lượng cơ sở dữ liệu chính.
Lợi ích của việc sao chép cơ sở dữ liệu:
- Hiệu suất tốt hơn: Trong mô hình chính-phụ, tất cả các thao tác ghi và cập nhật xảy ra trên các nút chính trong khi các thao tác đọc được phân phối trên các nút phụ. Mô hình này cải thiện hiệu suất vì nó cho phép xử lý nhiều truy vấn đồng thời.
- Độ tin cậy: Nếu một trong các máy chủ cơ sở dữ liệu bị phá hủy bởi thiên tai, chẳng hạn như bão hay động đất, dữ liệu vẫn được bảo toàn. Bạn không cần phải lo lắng về việc mất dữ liệu vì dữ liệu được sao chép ở nhiều địa điểm khác nhau.
- Tính khả dụng cao: Bằng cách sao chép dữ liệu qua các địa điểm khác nhau, trang web của bạn vẫn hoạt động ngay cả khi một cơ sở dữ liệu ngoại tuyến vì bạn có thể truy cập dữ liệu lưu trữ trên máy chủ cơ sở dữ liệu khác.
Xử lý khi cơ sở dữ liệu bị ngoại tuyến:
- Nếu chỉ có một cơ sở dữ liệu phụ và nó ngừng hoạt động, các thao tác đọc sẽ được chuyển hướng tạm thời đến cơ sở dữ liệu chính. Khi sự cố được phát hiện, một cơ sở dữ liệu phụ mới sẽ thay thế cơ sở dữ liệu cũ. Trong trường hợp có nhiều cơ sở dữ liệu phụ, các thao tác đọc sẽ được chuyển hướng đến các cơ sở dữ liệu phụ khỏe mạnh khác. Một máy chủ cơ sở dữ liệu mới sẽ thay thế máy chủ cũ.
- Nếu cơ sở dữ liệu chính ngừng hoạt động, một cơ sở dữ liệu phụ sẽ được nâng cấp thành cơ sở dữ liệu chính mới. Tất cả các thao tác cơ sở dữ liệu sẽ tạm thời được thực hiện trên cơ sở dữ liệu chính mới. Một cơ sở dữ liệu phụ mới sẽ thay thế cơ sở dữ liệu cũ để sao chép dữ liệu ngay lập tức. Trong các hệ thống sản xuất, việc nâng cấp một cơ sở dữ liệu chính mới phức tạp hơn vì dữ liệu trong cơ sở dữ liệu phụ có thể không được cập nhật. Dữ liệu thiếu cần được cập nhật bằng cách chạy các kịch bản phục hồi dữ liệu. Mặc dù một số phương pháp sao chép khác như nhiều cơ sở dữ liệu chính và sao chép vòng có thể hữu ích, nhưng các thiết lập đó phức tạp hơn.
Thiết kế hệ thống bao gồm:
- Người dùng nhận địa chỉ IP của bộ cân bằng tải từ DNS.
- Người dùng kết nối bộ cân bằng tải với địa chỉ IP này.
- Yêu cầu HTTP được chuyển hướng đến Server 1 hoặc Server 2.
- Máy chủ web đọc dữ liệu người dùng từ cơ sở dữ liệu phụ.
- Máy chủ web chuyển hướng bất kỳ thao tác thay đổi dữ liệu nào đến cơ sở dữ liệu chính. Điều này bao gồm các thao tác ghi, cập nhật và xóa.
Giờ đây, bạn đã hiểu rõ về các tầng web và dữ liệu, đã đến lúc cải thiện thời gian tải/phản hồi. Điều này có thể được thực hiện bằng cách thêm một lớp bộ nhớ đệm và chuyển các nội dung tĩnh (tệp JavaScript/CSS/hình ảnh/video) sang mạng phân phối nội dung (CDN).Tầng cache
Bộ nhớ đệm (Cache)
Bộ nhớ đệm là khu vực lưu trữ tạm thời lưu trữ kết quả của các phản hồi tốn kém hoặc dữ liệu thường xuyên được truy cập trong bộ nhớ để các yêu cầu tiếp theo được phục vụ nhanh hơn. Như hình minh họa "Thiết kế hệ thống sau khi thêm bộ cân bằng tải và sao chép cơ sở dữ liệu" phía trên, mỗi khi một trang web mới được tải, một hoặc nhiều lần gọi cơ sở dữ liệu được thực hiện để lấy dữ liệu. Hiệu suất ứng dụng bị ảnh hưởng lớn khi gọi cơ sở dữ liệu liên tục. Bộ nhớ đệm có thể giảm thiểu vấn đề này.
Tầng bộ nhớ đệm
Tầng bộ nhớ đệm là lớp lưu trữ dữ liệu tạm thời, nhanh hơn nhiều so với cơ sở dữ liệu. Lợi ích của việc có một tầng bộ nhớ đệm riêng bao gồm hiệu suất hệ thống tốt hơn, khả năng giảm tải cho cơ sở dữ liệu và khả năng mở rộng tầng bộ nhớ đệm độc lập.
Sau khi nhận yêu cầu, máy chủ web sẽ kiểm tra xem bộ nhớ đệm có sẵn phản hồi hay không. Nếu có, nó gửi dữ liệu lại cho khách hàng. Nếu không, nó truy vấn cơ sở dữ liệu, lưu phản hồi vào bộ nhớ đệm và gửi lại cho khách hàng. Chiến lược bộ nhớ đệm này gọi là bộ nhớ đệm đọc (read-through cache). Các chiến lược bộ nhớ đệm khác có thể được áp dụng tùy thuộc vào loại dữ liệu, kích thước và mô hình truy cập.
Những điều cần cân nhắc khi sử dụng bộ nhớ đệm
- Quyết định khi nào sử dụng bộ nhớ đệm: Sử dụng bộ nhớ đệm khi dữ liệu được đọc thường xuyên nhưng ít khi được thay đổi. Vì dữ liệu bộ nhớ đệm được lưu trữ trong bộ nhớ tạm, máy chủ bộ nhớ đệm không lý tưởng cho việc lưu trữ dữ liệu lâu dài. Nếu máy chủ bộ nhớ đệm khởi động lại, tất cả dữ liệu trong bộ nhớ sẽ bị mất. Do đó, dữ liệu quan trọng nên được lưu trữ trong các kho lưu trữ dữ liệu bền vững.
- Chính sách hết hạn: Thực hiện chính sách hết hạn là một thực hành tốt. Khi dữ liệu bộ nhớ đệm hết hạn, nó sẽ bị loại bỏ khỏi bộ nhớ đệm. Không nên đặt ngày hết hạn quá ngắn vì sẽ gây ra việc hệ thống tải lại dữ liệu từ cơ sở dữ liệu quá thường xuyên. Đồng thời, cũng không nên đặt ngày hết hạn quá dài vì dữ liệu có thể trở nên lỗi thời.
- Tính nhất quán: Giữ cho kho dữ liệu và bộ nhớ đệm đồng bộ. Sự không nhất quán có thể xảy ra vì các thao tác thay đổi dữ liệu trên kho dữ liệu và bộ nhớ đệm không nằm trong cùng một giao dịch. Khi mở rộng qua nhiều khu vực, việc duy trì tính nhất quán giữa kho dữ liệu và bộ nhớ đệm là một thách thức. Để biết thêm chi tiết, hãy tham khảo tài liệu “Scaling Memcache at Facebook” được xuất bản bởi Facebook.
- Giảm thiểu lỗi: Một máy chủ bộ nhớ đệm đơn lẻ có thể trở thành điểm thất bại duy nhất (SPOF), được định nghĩa trên Wikipedia như sau: “Một điểm thất bại duy nhất (SPOF) là một phần của hệ thống, nếu nó bị lỗi, sẽ làm ngừng hoạt động toàn bộ hệ thống”. Do đó, nên sử dụng nhiều máy chủ bộ nhớ đệm ở các trung tâm dữ liệu khác nhau để tránh SPOF. Một phương pháp được khuyến nghị khác là cung cấp dư thừa bộ nhớ cần thiết bằng một tỷ lệ phần trăm nhất định. Điều này cung cấp một bộ đệm khi mức sử dụng bộ nhớ tăng.
- Chính sách loại bỏ: Khi bộ nhớ đệm đầy, bất kỳ yêu cầu nào để thêm các mục vào bộ nhớ đệm có thể dẫn đến việc loại bỏ các mục hiện có. Đây gọi là loại bỏ bộ nhớ đệm. Chính sách loại bỏ ít sử dụng gần đây (LRU) là chính sách phổ biến nhất. Các chính sách loại bỏ khác, như ít sử dụng nhất (LFU) hoặc FIFO (First in First Out), có thể được áp dụng để phù hợp với các trường hợp sử dụng khác nhau.
Mạng phân phối nội dung (CDN)
CDN là một mạng lưới các máy chủ phân bố địa lý được sử dụng để phân phối nội dung tĩnh. Các máy chủ CDN lưu trữ các nội dung tĩnh như hình ảnh, video, tệp CSS, JavaScript, v.v.
Bộ nhớ đệm nội dung động là một khái niệm tương đối mới. Nó cho phép bộ nhớ đệm các trang HTML dựa trên đường dẫn yêu cầu, chuỗi truy vấn, cookie và tiêu đề yêu cầu. Bài viết này tập trung vào cách sử dụng CDN để bộ nhớ đệm nội dung tĩnh.
Cách hoạt động của CDN
- Người dùng A cố gắng lấy image.png bằng cách sử dụng URL hình ảnh. Tên miền của URL được cung cấp bởi nhà cung cấp CDN. Đây là hai ví dụ URL hình ảnh được sử dụng để minh họa hình dạng của URL hình ảnh trên các CDN Amazon và Akamai: https://mysite.cloudfront.net/logo.jpg - https://mysite.akamai.com/image-manager/img/logo.jpg
- Nếu máy chủ CDN không có image.png trong bộ nhớ đệm, máy chủ CDN yêu cầu tệp từ nguồn gốc, có thể là máy chủ web hoặc lưu trữ trực tuyến như Amazon S3.
- Nguồn gốc trả về image.png cho máy chủ CDN, kèm theo tiêu đề HTTP tùy chọn Time-to-Live (TTL) mô tả thời gian hình ảnh được lưu trữ trong bộ nhớ đệm.
- CDN lưu trữ hình ảnh và trả về cho Người dùng A. Hình ảnh vẫn được lưu trong bộ nhớ đệm của CDN cho đến khi TTL hết hạn.
- Người dùng B gửi yêu cầu để lấy cùng một hình ảnh.
- Hình ảnh được trả về từ bộ nhớ đệm miễn là TTL chưa hết hạn.
Những điều cần cân nhắc khi sử dụng CDN
- Chi phí: Các CDN được vận hành bởi các nhà cung cấp bên thứ ba và bạn sẽ bị tính phí cho việc chuyển dữ liệu vào và ra khỏi CDN. Lưu trữ các tài sản ít sử dụng không mang lại lợi ích đáng kể, vì vậy bạn nên cân nhắc chuyển chúng ra khỏi CDN.
- Thiết lập thời gian hết hạn của bộ nhớ đệm: Đối với nội dung nhạy cảm về thời gian, việc thiết lập thời gian hết hạn bộ nhớ đệm là quan trọng. Thời gian hết hạn không nên quá dài hoặc quá ngắn. Nếu quá dài, nội dung có thể không còn mới. Nếu quá ngắn, có thể dẫn đến việc tải lại nội dung từ máy chủ gốc quá thường xuyên.
- Dự phòng CDN: Bạn nên cân nhắc cách trang web hoặc ứng dụng của bạn đối phó với sự cố CDN. Nếu xảy ra sự cố CDN tạm thời, khách hàng nên có khả năng phát hiện vấn đề và yêu cầu tài nguyên từ nguồn gốc.
- Vô hiệu hóa tệp: Bạn có thể loại bỏ một tệp khỏi CDN trước khi hết hạn bằng cách thực hiện một trong các thao tác sau: Vô hiệu hóa đối tượng CDN bằng cách sử dụng các API do các nhà cung cấp CDN cung cấp. Sử dụng phiên bản đối tượng để phục vụ phiên bản khác của đối tượng. Để phiên bản hóa đối tượng, bạn có thể thêm một tham số vào URL, chẳng hạn như số phiên bản. Ví dụ, số phiên bản 2 được thêm vào chuỗi truy vấn: image.png?v=2.
Thiết kế sau khi thêm CDN và bộ nhớ đệm
- Các tài sản tĩnh (JS, CSS, hình ảnh, v.v.) không còn được phục vụ bởi các máy chủ web nữa. Chúng được lấy từ CDN để cải thiện hiệu suất.
- Tải cơ sở dữ liệu được giảm bớt nhờ vào việc lưu trữ dữ liệu trong bộ nhớ đệm. Tầng web không trạng thái (stateless web tier)
Web Tier Không Lưu Trữ Trạng Thái
Khi mở rộng web tier theo chiều ngang, cần chuyển trạng thái (như dữ liệu phiên người dùng) ra khỏi web tier. Thực hành tốt là lưu trữ dữ liệu phiên trong lưu trữ bền vững như cơ sở dữ liệu quan hệ hoặc NoSQL. Mỗi máy chủ web trong cụm có thể truy cập dữ liệu trạng thái từ cơ sở dữ liệu. Đây là kiến trúc web không lưu trữ trạng thái.
Kiến trúc Lưu Trữ Trạng Thái
- Máy chủ lưu trữ trạng thái ghi nhớ dữ liệu của khách hàng từ yêu cầu này đến yêu cầu tiếp theo.
- Máy chủ không lưu trữ trạng thái không lưu giữ thông tin trạng thái.
- Ví dụ về kiến trúc lưu trữ trạng thái: Nếu dữ liệu phiên của người dùng A và hình ảnh hồ sơ được lưu trữ trên Máy chủ 1, các yêu cầu HTTP phải được định tuyến đến Máy chủ 1 để xác thực. Yêu cầu gửi đến các máy chủ khác như Máy chủ 2 sẽ không thành công vì Máy chủ 2 không có dữ liệu phiên của người dùng A. Điều này yêu cầu mọi yêu cầu từ cùng một khách hàng phải được gửi đến cùng một máy chủ, gây khó khăn trong việc mở rộng và xử lý sự cố máy chủ.
Kiến trúc Không Lưu Trữ Trạng Thái
Trong kiến trúc không lưu trữ trạng thái, các yêu cầu HTTP từ người dùng có thể được gửi đến bất kỳ máy chủ web nào, và dữ liệu trạng thái được lấy từ lưu trữ dữ liệu chia sẻ. Dữ liệu trạng thái được lưu trong lưu trữ dữ liệu chia sẻ và không nằm trong các máy chủ web. Hệ thống không lưu trữ trạng thái đơn giản hơn, đáng tin cậy hơn và có khả năng mở rộng tốt hơn.
Trong hình trên, dữ liệu phiên được chuyển ra khỏi web tier và lưu trữ trong lưu trữ dữ liệu bền vững. Lưu trữ dữ liệu chia sẻ có thể là cơ sở dữ liệu quan hệ, Memcached/Redis, NoSQL, v.v. Lưu trữ NoSQL được chọn vì dễ mở rộng. Tự động mở rộng có nghĩa là thêm hoặc loại bỏ máy chủ web tự động dựa trên tải trọng lưu lượng truy cập. Sau khi dữ liệu trạng thái được loại bỏ khỏi các máy chủ web, việc tự động mở rộng web tier dễ dàng hơn bằng cách thêm hoặc loại bỏ máy chủ dựa trên tải trọng lưu lượng truy cập.
Trang web của bạn phát triển nhanh chóng và thu hút số lượng lớn người dùng quốc tế. Để cải thiện khả năng sẵn có và cung cấp trải nghiệm người dùng tốt hơn trên các khu vực địa lý rộng hơn, hỗ trợ nhiều trung tâm dữ liệu là rất quan trọng.
Trung Tâm Dữ Liệu
Cài đặt Trung Tâm Dữ Liệu
Trong hình trên, có hai trung tâm dữ liệu. Người dùng được định tuyến theo geoDNS (định tuyến theo vị trí địa lý) đến trung tâm dữ liệu gần nhất, với lưu lượng phân bổ x% ở US-East và (100 - x)% ở US-West. GeoDNS là dịch vụ DNS cho phép tên miền được phân giải thành địa chỉ IP dựa trên vị trí của người dùng.
Nếu có sự cố lớn ở một trung tâm dữ liệu, toàn bộ lưu lượng được chuyển hướng đến trung tâm dữ liệu còn lại. Ví dụ trong hình bên dưới, nếu trung tâm dữ liệu 2 (US-West) bị ngừng hoạt động, 100% lưu lượng sẽ được chuyển hướng đến trung tâm dữ liệu 1 (US-East).
Thách Thức Kỹ Thuật trong Cài Đặt Nhiều Trung Tâm Dữ Liệu
- Chuyển Hướng Lưu Lượng: Cần các công cụ hiệu quả để chuyển hướng lưu lượng đến trung tâm dữ liệu đúng. GeoDNS có thể được sử dụng để chuyển hướng lưu lượng đến trung tâm dữ liệu gần nhất dựa trên vị trí của người dùng.
- Đồng Bộ Dữ Liệu: Người dùng từ các khu vực khác nhau có thể sử dụng cơ sở dữ liệu hoặc bộ nhớ đệm địa phương khác nhau. Trong các tình huống chuyển đổi dự phòng, lưu lượng có thể được chuyển hướng đến trung tâm dữ liệu nơi dữ liệu không có sẵn. Một chiến lược phổ biến là sao chép dữ liệu giữa nhiều trung tâm dữ liệu. Tìm hiểu thêm cách Netflix thực hiện sao chép không đồng bộ giữa các trung tâm dữ liệu.
- Kiểm Tra và Triển Khai: Với cấu hình nhiều trung tâm dữ liệu, việc kiểm tra trang web/ứng dụng ở các vị trí khác nhau là quan trọng. Các công cụ triển khai tự động là cần thiết để duy trì sự nhất quán của dịch vụ qua tất cả các trung tâm dữ liệu.
Để mở rộng hệ thống hơn nữa, cần phân tách các thành phần khác nhau của hệ thống để chúng có thể được mở rộng độc lập. Hàng đợi tin nhắn là một chiến lược quan trọng được nhiều hệ thống phân tán thực tế sử dụng để giải quyết vấn đề này.
Hàng Đợi Tin Nhắn (Message queue)
Hàng đợi tin nhắn là một thành phần bền bỉ, lưu trữ trong bộ nhớ, hỗ trợ giao tiếp bất đồng bộ. Nó hoạt động như một bộ đệm và phân phối các yêu cầu bất đồng bộ. Cấu trúc cơ bản của hàng đợi tin nhắn bao gồm các dịch vụ đầu vào (nhà sản xuất/phát hành), tạo và xuất bản tin nhắn vào hàng đợi, và các dịch vụ khác (người tiêu dùng/đăng ký), kết nối với hàng đợi để thực hiện các hành động được xác định bởi tin nhắn.
Ưu điểm: Việc phân tách các thành phần làm cho hàng đợi tin nhắn trở thành kiến trúc ưa chuộng cho việc xây dựng ứng dụng mở rộng và đáng tin cậy. Nhà sản xuất có thể gửi tin nhắn vào hàng đợi ngay cả khi người tiêu dùng không có sẵn để xử lý. Người tiêu dùng có thể đọc tin nhắn từ hàng đợi ngay cả khi nhà sản xuất không có sẵn.
Trường Hợp Sử Dụng: Ví dụ, ứng dụng của bạn hỗ trợ tùy chỉnh ảnh như cắt, làm sắc nét, làm mờ, v.v. Những công việc này cần thời gian để hoàn thành. Các máy chủ web xuất bản các nhiệm vụ xử lý ảnh vào hàng đợi tin nhắn. Các công nhân xử lý ảnh lấy nhiệm vụ từ hàng đợi và thực hiện các công việc tùy chỉnh ảnh một cách bất đồng bộ. Nhà sản xuất và người tiêu dùng có thể được mở rộng độc lập. Khi kích thước hàng đợi lớn, số lượng công nhân được tăng cường để giảm thời gian xử lý. Nếu hàng đợi thường xuyên trống, số lượng công nhân có thể được giảm bớt.
Logging, Metrics và Automation
Logging
Giám sát các nhật ký lỗi là rất quan trọng vì nó giúp nhận diện lỗi và vấn đề trong hệ thống. Có thể giám sát các nhật ký lỗi theo từng máy chủ hoặc sử dụng công cụ để tập hợp chúng vào một dịch vụ trung tâm để dễ dàng tìm kiếm và xem.
Metrics
Thu thập các loại chỉ số khác nhau giúp hiểu rõ tình trạng sức khỏe của hệ thống và có cái nhìn sâu sắc về kinh doanh. Một số chỉ số hữu ích bao gồm:
- Chỉ số cấp máy chủ: CPU, bộ nhớ, I/O đĩa, v.v.
- Chỉ số tổng hợp: Hiệu suất của toàn bộ tầng cơ sở dữ liệu, tầng bộ nhớ đệm, v.v.
- Chỉ số kinh doanh quan trọng: Người dùng hoạt động hàng ngày, tỷ lệ giữ chân, doanh thu, v.v.
Automation
Khi hệ thống trở nên lớn và phức tạp, việc xây dựng hoặc sử dụng công cụ tự động hóa là cần thiết để cải thiện năng suất. Continuous integration (CI) là một thực hành tốt, trong đó mỗi lần kiểm tra mã được xác thực qua tự động hóa, giúp các nhóm phát hiện vấn đề sớm. Tự động hóa quy trình xây dựng, kiểm thử, triển khai, v.v. có thể cải thiện đáng kể năng suất của các nhà phát triển.
Thêm Hàng Đợi Tin Nhắn và Các Công Cụ
- Thiết kế Cập nhật: Thêm hàng đợi tin nhắn vào thiết kế giúp hệ thống trở nên linh hoạt hơn và có khả năng chịu lỗi tốt hơn. Công cụ logging, monitoring, metrics và automation cũng được tích hợp.
- Quản lý Tăng Trưởng Dữ Liệu: Khi dữ liệu ngày càng nhiều, cơ sở dữ liệu của bạn trở nên quá tải. Đã đến lúc mở rộng tầng dữ liệu.
Quy mô cơ sở dữ liệu (Database scaling)
Có hai cách tiếp cận chung để quy mô cơ sở dữ liệu: quy mô theo chiều dọc và quy mô theo chiều ngang.
Quy mô theo chiều dọc
Quy mô theo chiều dọc, còn được gọi là mở rộng quy mô, là quy mô bằng cách thêm nhiều năng lượng hơn (CPU, RAM, DISK, v.v.) vào một máy hiện có. Có một số máy chủ cơ sở dữ liệu mạnh mẽ.
Theo Amazon Relational Database Service (RDS), bạn có thể có một máy chủ cơ sở dữ liệu với 24 TB RAM. Loại máy chủ cơ sở dữ liệu mạnh mẽ này có thể lưu trữ và xử lý nhiều dữ liệu. Ví dụ: stackoverflow.com vào năm 2013 có hơn 10 triệu lượt truy cập duy nhất hàng tháng, nhưng chỉ có 1 cơ sở dữ liệu chính. Tuy nhiên, quy mô theo chiều dọc đi kèm với một số nhược điểm nghiêm trọng:
• Bạn có thể thêm nhiều CPU, RAM, v.v. vào máy chủ cơ sở dữ liệu của mình, nhưng có giới hạn về phần cứng. Nếu bạn có lượng người dùng lớn, thì một máy chủ duy nhất là không đủ.
• Nguy cơ xảy ra lỗi điểm đơn cao hơn.
• Tổng chi phí cho quy mô theo chiều dọc cao. Máy chủ mạnh mẽ đắt hơn nhiều.
Chia tỷ lệ theo chiều ngang
Chia tỷ lệ theo chiều ngang, còn được gọi là phân mảnh, là phương pháp thêm nhiều máy chủ hơn.
Chia mảnh chia tách các cơ sở dữ liệu lớn thành các phần nhỏ hơn, dễ quản lý hơn được gọi là phân mảnh. Mỗi phân mảnh chia sẻ cùng một lược đồ, mặc dù dữ liệu thực tế trên mỗi phân mảnh là duy nhất đối với phân mảnh đó.
Dữ liệu người dùng được phân bổ cho máy chủ cơ sở dữ liệu dựa trên ID người dùng. Bất cứ khi nào bạn truy cập dữ liệu, một hàm băm được sử dụng để tìm phân mảnh tương ứng. Trong ví dụ trên của chúng tôi, user_id % 4 được sử dụng làm hàm băm. Nếu kết quả bằng 0, phân mảnh 0 được sử dụng để lưu trữ và truy xuất dữ liệu. Nếu kết quả bằng 1, phân mảnh 1 được sử dụng. Logic tương tự áp dụng cho các phân mảnh khác.
Yếu tố quan trọng nhất cần cân nhắc khi triển khai chiến lược chia mảnh là lựa chọn khóa chia mảnh. Khóa phân mảnh (được gọi là khóa phân vùng) bao gồm một hoặc nhiều cột xác định cách dữ liệu được phân phối.
Như thể hiện trong trên, “user_id” là khóa phân mảnh. Khóa phân mảnh cho phép bạn truy xuất và sửa đổi dữ liệu hiệu quả bằng cách định tuyến các truy vấn cơ sở dữ liệu đến đúng cơ sở dữ liệu. Khi chọn khóa phân mảnh, một trong những tiêu chí quan trọng nhất là chọn khóa có thể phân phối dữ liệu đồng đều.
Phân mảnh là một kỹ thuật tuyệt vời để mở rộng cơ sở dữ liệu nhưng nó không phải là giải pháp hoàn hảo. Nó gây ra sự phức tạp và những thách thức mới cho hệ thống:
Phân mảnh lại dữ liệu: Phân mảnh lại dữ liệu là cần thiết khi 1) một phân mảnh duy nhất không còn có thể chứa nhiều dữ liệu hơn do tăng trưởng nhanh. 2) Một số phân mảnh nhất định có thể bị cạn kiệt phân mảnh nhanh hơn những phân mảnh khác do phân phối dữ liệu không đồng đều. Khi xảy ra tình trạng cạn kiệt phân mảnh, cần phải cập nhật hàm phân mảnh và di chuyển dữ liệu xung quanh. Băm nhất quán là một kỹ thuật thường được sử dụng để giải quyết vấn đề này.
Bài toán người nổi tiếng: Đây cũng được gọi là bài toán khóa điểm nóng. Truy cập quá mức vào một phân đoạn cụ thể có thể gây quá tải cho máy chủ. Hãy tưởng tượng dữ liệu của Katy Perry, Justin Bieber và Lady Gaga đều nằm trên cùng một phân đoạn. Đối với các ứng dụng xã hội, phân đoạn đó sẽ bị quá tải với các hoạt động đọc. Để giải quyết vấn đề này, chúng ta có thể cần phân bổ một phân đoạn cho mỗi người nổi tiếng. Mỗi phân đoạn thậm chí có thể yêu cầu phân vùng thêm.
Tham gia và phi chuẩn hóa: Sau khi cơ sở dữ liệu được phân đoạn trên nhiều máy chủ, sẽ khó thực hiện các hoạt động tham gia trên các phân đoạn cơ sở dữ liệu. Một giải pháp thay thế phổ biến là phi chuẩn hóa cơ sở dữ liệu để có thể thực hiện các truy vấn trong một bảng duy nhất.
Trong hình trên, phân đoạn cơ sở dữ liệu để hỗ trợ lưu lượng dữ liệu tăng nhanh. Đồng thời, một số chức năng không quan hệ được chuyển đến kho dữ liệu NoSQL để giảm tải cơ sở dữ liệu.
Kết luận, bạn có thể thiết kế hệ thống cho hàng triệu người dùng và hơn thế nữa
Việc mở rộng quy mô hệ thống là một quá trình lặp đi lặp lại. Lặp lại những gì chúng ta đã học được trong bài viết này có thể giúp chúng ta tiến xa hơn. Cần phải tinh chỉnh nhiều hơn và có các chiến lược mới để mở rộng quy mô vượt ra ngoài hàng triệu người dùng.
Ví dụ: bạn có thể cần tối ưu hóa hệ thống của mình và tách hệ thống thành các dịch vụ thậm chí còn nhỏ hơn. Tất cả các kỹ thuật được học trong bài viết này sẽ cung cấp nền tảng tốt để giải quyết các thách thức mới. Để kết thúc bài viết này, tôi cung cấp bản tóm tắt về cách mở rộng quy mô hệ thống của mình để hỗ trợ hàng triệu người dùng:
• Giữ nguyên trạng thái của tầng web
• Xây dựng dự phòng ở mọi tầng
• Lưu trữ dữ liệu đệm nhiều nhất có thể
• Hỗ trợ nhiều trung tâm dữ liệu
• Lưu trữ các tài sản tĩnh trong CDN
• Mở rộng tầng dữ liệu của bạn bằng cách phân mảnh
• Chia các tầng thành các dịch vụ riêng lẻ
• Giám sát hệ thống của bạn và sử dụng các công cụ tự động hóa
Cảm ơn bạn đã theo dõi bài viết. Hãy để lại bình luận và theo dõi các chủ đề tiếp theo của mình nhé!
Website không chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn không muốn bị AI thay thế và tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp hay làm chủ Database thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ bí kíp thực chiến, thủ tục, quy trình của gần 20 năm kinh nghiệm (mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google) từ đó giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
cơ sở dữ liệu, cơ sở dữ liệu quốc gia, database, AI, trí tuệ nhân tạo, artificial intelligence, machine learning, deep learning, LLM, ChatGPT, DeepSeek, Grok, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c/21c/23c/23ai, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, docker, k8s, micro service, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
