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

Ngoài sức tưởng tượng của tôi khi bài viết "Redis – 3 vấn đề LỚN có thể mất việc khi sử dụng cache" có lượt tương tác hơn tôi nghĩ đến x3 lần. Tôi đã sai, sai cái gì? Và sai từ đâu? Xin mời... Trước khi đi vào 2 vấn đề còn lại mà tôi chưa có thời gian để giải quyết trong bài viết trước thì tôi có một số lời muốn nói đến anh em trong giới showDev. Nếu anh em nào cảm thấy không cần nghe thì có nhảy bước đến phần 2 - cách giải quyết khi sự cố thâm nhập Redis. 

Cùng xem qua một số hình ảnh đại diện:

Một số thành viên quan tâm...

Tôi đã sai

Khi viết bài về Redis, tôi cứ nghĩ nó sẽ kén người đọc, bởi vì những bài viết đó đều đi sâu vào thực tiễn, và chỉ có những người đang gặp phải vấn đề hay trải qua rồi thì mới quan tâm. Nghĩa là nó ở mức độ lớn hơn level 3 hay còn gọi Senior developer đấy. Và điều quan trọng là nếu như những người đều tìm đến và đọc bài viết này thì tôi chắc chắn họ đang làm nhiều về vị trí back-end, và có một trình độ cao. Nhưng nó có kết quả cao hơn tôi nghĩ nhiều, x3 lận đấy. Chính vì vậy, tôi đã có suy nghĩ khác, và tiếp tục viết những bài kiểu như vậy. Cảm ơn anh em đã đồng hành. Còn bây giờ tiếp tục câu chuyện...

Cache breakdown - Khi nào xảy ra hiện tượng này

Nếu như mô hình của bạn hay doanh nghiệp của bạn gặp một tình huống, lượng connect đồng thời cao đều truy cập xuống Database thì lúc đó e rằng sự cố "Cache breakdown" nó đã xảy ra. Chính vì Redis đã gặp phải sự cố đã chết thì tất nhiên là lượng truy cập để lấy tài nguyên 100% là xuống DB rồi. Nếu có người cho rằng đó giống như sự cố tuyết lở (cache avalanche) thì không phải, nếu như ai đã đọc bài viết trước thì sẽ có nhận định khác. 

Vâng, xin hãy hiểu kỹ, trước tiên hãy để tôi nói về Cache breakdown. Cache breakdown là do một khu vực lớn bị lỗi bộ nhớ cache, chú ý chỗ này, là lỗi ở Redis, nó dẫn đến làm hỏng DB.

Cache breakdown - Cách khắc phục

Đối với Cache breakdown bộ nhớ cache do Redis bị lỗi và chết nhanh chóng, thì các phương pháp phổ biến để giải quyết nó như sau: 

• Gạt cầu chì rồi đi ngủ 
• Xây dựng một cụm bộ nhớ cache Redis có độ tin cậy cao.

Cache breakdown - Phương pháp gạt cầu chì

Khi gặp sự cố về Redis gây ra chúng tôi có thể khởi động cơ chế "gạt cầu chì" có nghĩa là giết chết nó luôn. Nghĩa là không cho nó hoạt động nữa mà tạm dừng quyền truy cập của ứng dụng kinh doanh vào dịch vụ bộ nhớ cache, trả lại lỗi trực tiếp và không cần truy cập cơ sở dữ liệu nữa, do đó giảm áp lực cho truy cập cơ sở dữ liệu và đảm bảo hệ thống cơ sở dữ liệu chạy bình thường ở khu vực khác, sau đó đợi cho đến khi Redis khắc phục trở lại bình thường trước khi cho phép các ứng dụng kinh doanh truy cập vào dịch vụ bộ nhớ cache. 

Có nhiều bài viết về Redis, có nên tham quan không? Điều đó tuỳ thuộc vào bạn...

Vậy nếu bạn nào chưa biết về cơ chế gạt cầu chì thì tôi nói thêm cho luôn: Cơ chế cầu chì là một quyền được sử dụng vào mục đích để bảo vệ cơ sở dữ liệu, nhưng quyền truy cập của ứng dụng kinh doanh vào hệ thống máy chủ bộ nhớ cache bị tạm ngưng và tất cả các dịch vụ không thể hoạt động bình thường Để giảm tác động đến hoạt động kinh doanh, chúng tôi có thể bật cơ chế giới hạn luồng yêu cầu và chỉ gửi một phần nhỏ yêu cầu đến cơ sở dữ liệu để xử lý và càng nhiều yêu cầu sẽ bị từ chối trực tiếp ngay từ đầu và sau đó đợi cho đến khi Redis trở lại bình thường và bộ nhớ cache được giải toả được nhiều áp lực. Có ai không hiểu không?

Cache breakdown - Xây dựng một cụm bộ nhớ cache Redis có độ tin cậy cao

Bạn có biết nếu bạn chỉ đọc phía trên mà không đọc tới đây là sai lầm bởi vì phương pháp gạt Cầu chì hiện tại chỉ là giải pháp sau khi tuyết lở bộ nhớ đệm xảy ra. Tốt nhất hay nói chính xác là tốt hơn hết khỏi mất việc là ban phải nhất định xây dựng Cache Cluster có độ tin cậy cao của bộ nhớ cache Redis bằng nhiều khung có sẵn mà các sư phục trên internet đã dạy đó là master-slave + sentinel... Tôi đã có một bài viết về triển khai master-slave trên Mongodb, các bạn hóng thì qua đó. 

Còn phần tiếp theo là: Cache penetration là gì? Và cách khắc phục xin để lần sau có thời gian tiếp nha quý zị...