Redis – 3 vấn đề LỚN có thể mất việc khi sử dụng cache

Nội dung bài viết

Video học lập trình mỗi ngày

Để hiểu về 3 sự cố khi sử dụng cache đó là sự cố tuyết lở trong Cache (cache avalanche), sự cố sụp đổ (cache breakdown), sự cố thâm nhập cache (cache penetration). À trước khi vào tình huống thực tế này, thì tôi có nhận một số phản hồi của các bạn là "Anh viết ngắn gọn được không? Chứ dài quá em đọc lan man. kakak"

Có thể góp ý này đúng thật, nhiều lúc mình muốn ngắn, nhưng có những vấn đề nói ngắn thì lại không hiểu? Vì vậy thử thay dổi phong cách viết lại một thời gian xem. Ngắn gọn xúc tích. Vậy thì tình huống thế này, nhưng hơn hết bạn phải biết vì sao lại có chủ để này, đó là tôi đã viết một series về phát triển một sàn thương mại điện tử, tuy nó chưa có code, nhưng tất cả lý thuyết đó đều có giá trị, tin tôi đi. Hãy xem lại nếu bạn cảm thấy hứng thú.


Tình huống mất việc khi sử dụng cache


Đây là câu chuyện giữa người phỏng vấn (pv) và người tìm việc back-end (be). 


PV : Xin chào! Anh nói là anh có kinh nghiệm trong vị trí back-end. Vậy anh đã sử dụng cache rồi đúng không? 

BE: Vâng! 

PV: Anh dùng gì để cache dữ liệu, và khi nào anh sử dụng cache? 

BE: Tôi dùng redis để cache dữ liệu, và sử dụng khi "dữ liệu được sử dụng nhiều nhưng sửa đổi ít". 

PV :Tốt, vậy anh biết khi sử dụng cache thì có một số vấn đề lớn hay gặp phải, anh có thể cho chúng tôi biết được chứ? 

BE: Vâng! Đó 3 sự cố khi sử dụng cache đó là sự cố tuyết lở trong Cache (cache avalanche), sự cố sụp đổ (cache breakdown), sự cố thâm nhập cache (cache penetration). 

PV :Tốt lắm! Vậy giả sử tình huống đầu tiên là cache avalanche thì nguyên nhân là gì? 

BE:: Có 2 nguyên nhân gây nên tình trạng trên đó là "Số lượng lớn dữ liệu hết hạn cùng một lúc", và "redis đột ngột chết". 

PV :Tốt lắm anh bạn? Nếu vậy anh xử lý thế nào? 

BE:: Dạ!!! ???? Dạ. Thì mình sẽ nên tránh đặt một lượng lớn dữ liệu vào cùng một thời gian hết hạn. Tôi có thể thêm một số ngẫu nhiên vào thời gian hết hạn của dữ liệu đã lưu trong bộ nhớ cache khi đặt thời gian hết hạn , để đảm bảo rằng dữ liệu sẽ không hết hạn cùng một lúc. 

PV : Còn gì nữa không? Chứ từng đó con gái tôi nó cũng biết. 

BE: Dạ ???? 


Thế đấy câu chuyện tôi nghe lỏm được là vậy? Theo bạn, nếu như là bạn thì bạn sẽ giải quyết sao ngoài cách trên.

Cache avalanche - Khắc phục sự cố


Với sự cố này theo kinh nghiệm của tôi khi triển khai hệ thống lớn thì đa số là bị một dữ liệu lớn đồng thời bị hết hạn thời gian đặt cache. Từ đó sinh ra hiện tượng tuyết lở trong cache. Hình dung sự việc như thế này. Ở đây tôi sẽ hướng dẫn 4 cách để tránh tình trạng này, lưu ý là hãy làm thật sớm. Chứ để redis chết rồi thì xin nghỉ việc đi, chứ sửa chữa gì nữa. Nói đùa thôi, hãy tham khảo 4 cách khắc phục phổ biến dưới đây. 

  • Đặt thời gian hết hạn đồng đều 
  • Khóa Mutex 
  • Chiến lược cache kép 
  • Cập nhật bộ nhớ cache trong background.

Redis set expire nodejs


Để tránh việc cache hết hạn đồng thời thì biện pháp khắc phục như bạn phỏng vấn trên kia. Đó là nếu bạn muốn đặt thời gian hết hạn cho dữ liệu đã lưu trong bộ nhớ cache, bạn nên tránh đặt một lượng lớn dữ liệu vào cùng một thời gian hết hạn. Chúng tôi có thể thêm một số ngẫu nhiên vào thời gian hết hạn của dữ liệu đã lưu trong bộ nhớ cache khi đặt thời gian hết hạn , để đảm bảo rằng dữ liệu sẽ không hết hạn cùng một lúc. Rất hay, hãy theo mẹo này.


Mutex


Mutex là gì? Cái này có thể những bạn mới sẽ không hiểu. Nhưng tôi đã có nhắc đến trong bài viết "process và thread" . Khi một người dùng truy cập vào dữ liệu nhưng mà không có trong redis thì nhiêm vụ của mutex sẽ đảm bảo rằng chỉ có một yêu cầu sẽ (đọc dữ liệu từ cơ sở dữ liệu, sau đó cập nhật dữ liệu lên Redis). Nói không dễ hình dung, nhưng hãy xem tôi mô tả thực tế như thế này. 

Mutex là gì?

Ví dụ trong nhà trọ chỉ có một phòng tắm. Thì những ai tắm trước thì khoá cửa, và treo ngoài cửa tấm biển là "Có người đang tắm", thì mấy người đến sau xếp hàng để vào. Đây được gọi là "Mutex" (Mutual Exclusive, viết tắt là Mutex), ngăn không cho nhiều luồng đọc và ghi một vùng nhớ nhất định cùng một lúc.


Chiến lược cache kép


Chúng ta có thể sử dụng hai khóa cho dữ liệu đã lưu trong bộ nhớ cache, một là khóa chính sẽ đặt thời gian hết hạn và khóa còn lại là khóa dự phòng, sẽ không đặt thời gian. Chúng chỉ là các khóa khác nhau, nhưng giá trị giá trị là tương tự, tương đương với thực hiện Sao chép dữ liệu bộ nhớ cache. Khi luồng nghiệp vụ không thể truy cập dữ liệu đã lưu trong bộ nhớ cache của "khóa chính", nó sẽ trực tiếp trả về dữ liệu đã lưu trong bộ nhớ đệm của "khóa dự phòng", sau đó cập nhật dữ liệu của "khóa chính" và "khóa dự phòng" cùng một lúc khi cập nhật bộ nhớ đệm .


Cập nhật bộ nhớ cache trong background


Việc này thì các lập trình viên của Việt Nam là hay sử dụng nhất đó là cứ 12h đêm mấy ông tính toán xem dữ liệu có được người dùng sử dụng nhiều hay không? Đa số thời gian đó là ít người Online cho nên mấy ông cho chạy update lại cache. Hay cụ thể là thường xuyên kiểm tra xem cache có hợp lệ hay không, nếu bộ đệm được phát hiện là không hợp lệ, nguyên nhân có thể là do hệ thống bị căng và bị loại bỏ, vì vậy dữ liệu phải được đọc từ cơ sở dữ liệu ngay lập tức và cập nhật vào bộ nhớ cache. Khoảng thời gian của phương pháp này không được quá dài. Quá dài cũng sẽ khiến dữ liệu mà người dùng thu được là giá trị rỗng thay vì dữ liệu thực. Do đó, khoảng thời gian phát hiện tốt nhất là mili giây, hay nói cách khác là càng nhanh càng chậm :D.


Tóm lại

Bài học này không dễ gì mà các anh chị giang hồ viết ra đâu. Vì đó chính là bí kíp tăng lương của họ, làm cho họ nổi trội so với đám đông. Chính vì bởi thế, họ càng giấu càng tốt. Chỉ có một số báo cáo hay số liệu làm đồ án thì khả năng là có nhiều. Thôi như vậy cũng đủ cho các bạn có thêm những kiến thức mới trong việc phát triển series về phát triển một sàn thương mại điện tử,. Chúc các bạn thành công, và đừng quên like page tipjs để ủng hộ cũng như theo dõi những bài viết mới nhất nhé.

Có thể bạn đã bị missing