Nếu bạn tin vào Ralph Waldo Emerson, một sự nhất quán ngu dốt có thể là quỷ dữ của những tâm trí nhỏ bé, nhưng khi nói đến việc triển khai một chiến lược bộ nhớ đệm doanh nghiệp có khả năng mở rộng và thành công, thì không có gì ngu dốt về sự nhất quán. Trên thực tế, một trong những thách thức lớn nhất trong việc quản lý vận hành cơ sở dữ liệu doanh nghiệp là duy trì sự nhất quán của bộ nhớ đệm.
Tại sao chúng ta lại phiền toái với bộ nhớ đệm? Lợi ích chính của bộ nhớ đệm doanh nghiệp là tốc độ và hiệu quả để truy cập dữ liệu. Mỗi lần gọi đến cơ sở dữ liệu chính có thể tốn kém về cả thời gian và sức mạnh xử lý, trong khi một cuộc gọi đến bộ nhớ đệm có thể nhanh như chớp và không ảnh hưởng đến cơ sở dữ liệu chính.
Ba chướng ngại vật đối với sự nhất quán bộ nhớ đệm
Tất nhiên, những lợi ích này dựa trên giả định cơ bản rằng dữ liệu trong bộ nhớ đệm — hoặc các bộ nhớ đệm — luôn giữ các giá trị giống như dữ liệu nguồn. Mặc dù đây có vẻ như một mục tiêu đơn giản, nhưng dễ dàng trong lý thuyết hơn là thực tế. Trên thực tế, có ba bẫy có thể làm nó đi lệch:
1. Khi thay đổi cơ sở dữ liệu chính không được phản ánh trong bộ nhớ đệm
Vì truy cập dữ liệu qua bộ nhớ đệm, theo định nghĩa, nhanh hơn truy cập qua cơ sở dữ liệu chính, nếu một mục cụ thể được yêu cầu, bộ nhớ đệm sẽ được truy vấn trước. Giả sử mục đó tồn tại trong bộ nhớ đệm, nó sẽ được trả về nhanh hơn nhiều so với từ cơ sở dữ liệu chính. Chiến lược này được gọi là mô hình cache-aside (bộ nhớ đệm bên cạnh). Bộ nhớ đệm được kiểm tra mặc định trước. Nếu dữ liệu không có trong bộ nhớ đệm, ứng dụng truy vấn cơ sở dữ liệu chính và lưu kết quả vào bộ nhớ đệm trên đường trả về cho người dùng.
Vấn đề nảy sinh trong khoảng trống giữa khi dữ liệu trong cơ sở dữ liệu chính thay đổi và khi bộ nhớ đệm được điều chỉnh để phản ánh thay đổi đó. Điều này bị ảnh hưởng bởi tần suất ứng dụng kiểm tra bộ nhớ đệm. Tuy nhiên, mỗi lần kiểm tra tốn tài nguyên bộ xử lý. Cùng một bộ xử lý có thể đồng thời xử lý nhiều chức năng hoặc giao dịch khác, một số quan trọng không kém, thậm chí quan trọng hơn, việc cập nhật bộ nhớ đệm.
Thách thức nằm ở việc tìm "điểm ngọt" (sweet spot), một vùng kiểu Goldilocks nằm giữa việc kiểm tra cập nhật quá thường xuyên hoặc không đủ. Tất nhiên, nếu người dùng cố gắng truy cập dữ liệu lỗi thời trong khoảng trống này, cái cược đó bị mất.
2. Khi có độ trễ trong cập nhật kết quả bộ nhớ đệm
Vấn đề này chồng chéo một chút với vấn đề trước. Mỗi lần một giá trị được cập nhật trong cơ sở dữ liệu chính, một thông điệp được gửi đến bộ nhớ đệm, hướng dẫn nó cập nhật giá trị đã thay đổi hoặc xóa nó hoàn toàn. (Trong trường hợp sau, lần tiếp theo giá trị được yêu cầu, nó sẽ được truy cập từ cơ sở dữ liệu chính và sau đó từ bộ nhớ đệm.) Trong điều kiện bình thường, giao tiếp này diễn ra tương đối nhanh và mục bộ nhớ đệm được cập nhật hoặc xóa để duy trì sự nhất quán bộ nhớ đệm.
Một lần nữa, thay đổi này đòi hỏi sức mạnh xử lý và mất thời gian. Độ trễ có thể bị ảnh hưởng bởi cả tốc độ xử lý khả dụng cũng như thông lượng mạng. Nếu một người dùng có sự xui xẻo truy cập dữ liệu lỗi thời giữa lúc thông điệp được gửi bởi máy chủ để cập nhật bộ nhớ đệm và lúc thông điệp đó được bộ nhớ đệm nhận và xử lý, kết quả có thể là dữ liệu lỗi thời, không chính xác hoặc cả hai.
3. Khi có sự không nhất quán giữa các nút bộ nhớ đệm
Tất nhiên, trang web hoặc ứng dụng càng lớn, bộ nhớ đệm càng có khả năng được lưu trữ trên nhiều nút thay vì chỉ một. Ngoài một nút chính (primary), có thể có bất kỳ số lượng nút bản sao (replica) nào, lý tưởng là lưu trữ dữ liệu giống hệt nhau. Từ quan điểm cân bằng tải và hiệu suất, điều này thường hợp lý.
Nhưng từ góc độ toàn vẹn dữ liệu, nó giới thiệu thêm một nguồn tiềm ẩn của sự không nhất quán bộ nhớ đệm. Mỗi lần dữ liệu được cập nhật trong cơ sở dữ liệu chính, thay đổi này cần được phản ánh trong tất cả các bản sao. Tùy thuộc vào vị trí địa lý của các nút này và số lượng của chúng, quá trình cập nhật có thể mất một lượng thời gian đáng kể. Mặc dù quá trình cập nhật có thể đang diễn ra, nhưng vẫn hoàn toàn có thể một người dùng sẽ truy cập một nút nơi các thay đổi chưa được thực hiện. Kết quả, bạn đã đoán, có thể là sự không nhất quán bộ nhớ đệm.
Chi phí của sự không nhất quán bộ nhớ đệm
Với tất cả lợi ích của cơ sở dữ liệu được bộ nhớ đệm, tiềm năng sự không nhất quán bộ nhớ đệm có lẽ là nhược điểm rõ rệt nhất. Nhưng vấn đề lớn đến đâu? Cuối cùng, chi phí của sự không nhất quán bộ nhớ đệm phụ thuộc vào bối cảnh.
Một số sự không nhất quán bộ nhớ đệm có thể xảy ra mà không gây hậu quả lớn. Ví dụ, nếu tổng "thích" (likes) trong bộ nhớ đệm tạm thời không đồng bộ với tổng thực tế trong cơ sở dữ liệu chính, sự chênh lệch ngắn hạn đó không太可能 gây ra vấn đề hoặc thậm chí bị chú ý.
Mặt khác, nếu bộ nhớ đệm liệt kê một mặt hàng còn lại của một sản phẩm cụ thể vẫn còn hàng, trong khi tồn kho thực tế tại cơ sở dữ liệu chính cho thấy không còn cái nào, xung đột kết quả có thể làm nhầm lẫn và làm mất lòng khách hàng, làm hỏng uy tín độ tin cậy của thương hiệu, gây hỗn loạn cho giao dịch và kế toán của công ty, và trong trường hợp cực đoan, thậm chí đưa bạn vào nguy cơ pháp lý.
Ba cách chống lại sự không nhất quán
May mắn thay, cho từng nguồn tiềm ẩn của sự không nhất quán bộ nhớ đệm trên, có số lượng giải pháp tương ứng.
1. Vô hiệu hóa bộ nhớ đệm (Cache invalidation)
Với vô hiệu hóa bộ nhớ đệm, bất cứ khi nào một giá trị được cập nhật trong cơ sở dữ liệu chính, mỗi mục bộ nhớ đệm với khóa tương ứng sẽ tự động bị xóa khỏi bộ nhớ đệm hoặc các bộ nhớ đệm. Mặc dù vô hiệu hóa bộ nhớ đệm có thể được xem là "phương pháp cưỡng lại" (brute force approach), ưu điểm là nó chỉ yêu cầu một lần ghi tốn kém và thường tốn thời gian — đến chính cơ sở dữ liệu chính — thay vì hai hoặc nhiều hơn.
2. Bộ nhớ đệm ghi xuyên (Write-through caching)
Trong trường hợp này, thay vì cập nhật cơ sở dữ liệu chính và xóa bộ nhớ đệm, với chiến lược ghi xuyên, ứng dụng cập nhật bộ nhớ đệm, sau đó bộ nhớ đệm cập nhật cơ sở dữ liệu chính đồng bộ. Nói cách khác, thay vì dựa vào cơ sở dữ liệu chính để khởi tạo bất kỳ cập nhật nào, bộ nhớ đệm chịu trách nhiệm duy trì sự nhất quán của chính nó và báo lại bất kỳ thay đổi nào nó thực hiện về cơ sở dữ liệu chính.
3. Bộ nhớ đệm ghi sau (Write-behind caching)
Thật không may, đôi khi hai lần ghi thực sự có thể làm sai. Một trong những nhược điểm của chiến lược bộ nhớ đệm ghi xuyên là cập nhật cả bộ nhớ đệm và cơ sở dữ liệu chính đòi hỏi hai lần thay đổi tốn thời gian, tốn tài nguyên bộ xử lý, đầu tiên là bộ nhớ đệm sau đó là cơ sở dữ liệu chính.
Một chiến lược khác, gọi là write-behind (ghi sau), tránh vấn đề này bằng cách ban đầu chỉ cập nhật bộ nhớ đệm và sau đó cập nhật cơ sở dữ liệu chính sau. Tất nhiên, cơ sở dữ liệu chính cũng cần được cập nhật, và càng sớm càng tốt, nhưng trong trường hợp này người dùng không phải trả "chi phí" của hai lần ghi. Lần ghi thứ hai vào cơ sở dữ liệu chính diễn ra bất đồng bộ và phía sau hậu trường (do đó tên là write-behind) vào thời điểm nó ít có khả năng làm suy giảm hiệu suất.
Redis Enterprise đến giải cứu
Ngoài vô hiệu hóa bộ nhớ đệm, bộ nhớ đệm ghi xuyên và ghi sau có thể giải quyết nhiều tình huống giúp bạn đạt được sự nhất quán bộ nhớ đệm. Nhưng tìm ra câu trả lời cho một vấn đề không giống như triển khai nó.
Sao chép địa lý active-active của Redis Enterprise cho phép nhiều nút chính (multiple primaries) và cho phép bạn xử lý khéo léo các tải trọng ngày càng nặng. Tên active-active ám chỉ thực tế rằng mỗi thực thể cơ sở dữ liệu của bạn có thể chấp nhận cả thao tác đọc và ghi trên bất kỳ khóa nào. Mỗi thực thể cơ sở dữ liệu, không quan trọng xa đến đâu, là một đối tác ngang hàng (peer) trên mạng của bạn. Điều đó có nghĩa khi một lần ghi xảy ra trên bất kỳ thực thể nào, nút đó tự động gửi thông điệp đến tất cả các thực thể khác trên mạng của bạn, chỉ ra những gì trong bộ nhớ đệm đã thay đổi và đảm bảo tất cả các thực thể giữ một tập hợp dữ liệu bộ nhớ đệm nhất quán.
Sao chép địa lý active-active độc đáo của Redis Enterprise sử dụng các thuật toán tinh vi được thiết kế để xử lý các xung đột ghi tiềm ẩn có thể dẫn đến sự không nhất quán bộ nhớ đệm. Các thuật toán này dựa trên các kiểu dữ liệu được sao chép không xung đột (CRDTs), đảm bảo rằng các ghi từ nhiều bản sao có thể được hợp nhất theo cách hiệu quả duy trì sự nhất quán.
Hoan hô cho quỷ dữ!
Bởi vì thách thức duy trì sự nhất quán bộ nhớ đệm trở nên phức tạp hơn và hậu quả càng ngày càng nghiêm trọng khi kiến trúc của bạn phát triển, bạn cần một giải pháp bộ nhớ đệm cấp doanh nghiệp để cung cấp tin cậy sự nhất quán mà doanh nghiệp của bạn yêu cầu và khách hàng mong đợi.
Sự nhất quán có thể là một quỷ dữ đối với Emerson, nhưng nó tuyệt đối cần thiết khi nói đến bộ nhớ đệm cơ sở dữ liệu cấp doanh nghiệp. Đó là lý do tại sao việc chọn Redis Enterprise là khôn ngoan. Bạn sẽ ngu dốt nếu không làm vậy.
Nhận toàn bộ câu chuyện về bộ nhớ đệm. Đọc Caching at Scale with Redis, tác giả Lee Atchison.