Thư Viện Câu Hỏi Phỏng Vấn

Để giải quyết vấn đề nhất quán dữ liệu giữa Local Cache và Distributed Cache, chúng ta thường áp dụng mô hình Pub/Sub hoặc Event Bus. Khi dữ liệu tại Redis thay đổi, một sự kiện (Invalidation Event) sẽ được phát đi. Các ứng dụng đang giữ Local Cache sẽ lắng nghe sự kiện này và xóa bỏ hoặc cập nhật giá trị tương ứng. Một kỹ thuật khác là sử dụng TTL (Time To Live) ngắn cho Local Cache để giảm thiểu rủi ro dữ liệu cũ (stale data), kết hợp với cơ chế Versioning để kiểm tra tính hợp lệ của dữ liệu.

Cache Stampede xảy ra khi một key phổ biến hết hạn (expire) cùng lúc, dẫn đến hàng ngàn request đồng thời đổ dồn về Database vì cache miss. Cách giải quyết tối ưu bao gồm: 1. Sử dụng Mutex Lock (Distributed Lock) để chỉ cho phép một request duy nhất truy vấn Database và cập nhật cache. 2. Sử dụng chiến thuật Probabilistic Early Recomputation (tự động làm mới cache trước khi hết hạn). 3. Sử dụng cơ chế Background Refresh để cập nhật cache định kỳ mà không làm gián đoạn luồng đọc của người dùng.

Redis Cluster sử dụng khái niệm Hash Slots để phân phối dữ liệu. Tổng cộng có 16384 slots. Mỗi key được map vào một slot thông qua công thức CRC16(key) mod 16384. Việc hiểu rõ cơ chế này giúp tránh tình trạng Hot Key, nơi một node phải chịu tải quá lớn do dữ liệu tập trung vào các slot trên node đó. Khi thiết kế, cần đảm bảo phân bổ key đồng đều để tránh tình trạng lệch tải giữa các node trong cluster.

Write-Through: Dữ liệu được ghi vào Cache và Database đồng thời. Đảm bảo tính nhất quán cao nhưng độ trễ (latency) ghi cao hơn. Phù hợp với hệ thống yêu cầu tính toàn vẹn dữ liệu nghiêm ngặt. Write-Behind (Write-Back): Dữ liệu ghi vào Cache trước, sau đó hệ thống sẽ ghi vào Database một cách bất đồng bộ. Tốc độ ghi cực nhanh, giảm tải cho Database nhưng rủi ro mất dữ liệu nếu Cache bị lỗi trước khi kịp đồng bộ xuống Database.

Để xử lý Hot Key, chúng ta có thể áp dụng các giải pháp: 1. Phân tán key: Thêm hậu tố ngẫu nhiên vào key để chia nhỏ dữ liệu ra nhiều node. 2. Sử dụng Local Cache tại tầng ứng dụng cho các key cực hot để giảm tải truy vấn xuống Redis. 3. Sử dụng Redis Read Replicas để phân tán lưu lượng đọc. 4. Sử dụng cơ chế LFU (Least Frequently Used) để ưu tiên giữ các key này trong bộ nhớ.

Sử dụng Redis làm lock đơn lẻ có rủi ro mất lock khi node Redis bị crash trước khi kịp replicate. Redlock là thuật toán được thiết kế để giải quyết vấn đề này bằng cách yêu cầu client lấy lock từ đa số (quorum) các node Redis độc lập. Nếu client lấy được lock từ quá bán số node trong một khoảng thời gian nhất định, lock mới được coi là thành công. Điều này đảm bảo tính an toàn ngay cả khi một vài node trong cluster gặp sự cố.

Redis có thể trở thành bottleneck nếu tất cả các service cùng truy vấn vào một cluster duy nhất với lưu lượng quá lớn. Cách khắc phục: 1. Chia nhỏ Redis Cluster theo từng domain hoặc service (Service-specific Cache). 2. Sử dụng Multi-tier Caching (Local Cache cho các dữ liệu ít thay đổi và Redis cho dữ liệu dùng chung). 3. Tối ưu hóa serialization (sử dụng Protobuf thay vì JSON để giảm kích thước payload và tăng tốc độ xử lý).

Đối với hệ thống có lưu lượng ghi lớn, chính sách 'volatile-lru' hoặc 'allkeys-lru' thường được ưu tiên. Nếu dữ liệu có tính chất tạm thời và cần ưu tiên giải phóng bộ nhớ, 'volatile-ttl' là lựa chọn tốt nhất vì nó sẽ xóa các key có thời gian sống ngắn nhất trước. Việc chọn đúng chính sách giúp tối ưu hóa hiệu năng bộ nhớ và tránh tình trạng OOM (Out Of Memory) trong Redis.

Cache Penetration xảy ra khi attacker liên tục gửi request cho các key không tồn tại trong Cache và Database. Giải pháp hiệu quả nhất là sử dụng Bloom Filter. Bloom Filter là cấu trúc dữ liệu xác suất giúp kiểm tra nhanh xem một key có khả năng tồn tại hay không. Nếu Bloom Filter khẳng định key không tồn tại, hệ thống sẽ từ chối request ngay lập tức mà không cần truy vấn Database, giúp bảo vệ hệ thống khỏi các cuộc tấn công.

Redis Cluster sử dụng cơ chế Sentinel hoặc Cluster Bus để giám sát trạng thái các node. Khi một Master node bị lỗi, các Slave node sẽ thực hiện bầu chọn (election) để chọn ra một Master mới. Để đảm bảo tính sẵn sàng cao, cần cấu hình replication factor ít nhất là 1 (mỗi Master có ít nhất 1 Slave) và đặt các node trên các Availability Zone khác nhau để tránh rủi ro hạ tầng vật lý.

Tham khảo tài liệu về phân phối nội dung phân tán toàn cầu (Globally Distributed Content Delivery): https://kilthub.cmu.edu/articles/journal_contribution/Globally_distributed_content_delivery/6605972

Tham khảo mã nguồn Google Mobwrite (https://code.google.com/p/google-mobwrite/) và tài liệu về Đồng bộ hóa vi sai - Differential Synchronization (https://neil.fraser.name/writing/sync/)

Tham khảo tài liệu Giới thiệu về Redis: http://www.slideshare.net/dvirsky/introduction-to-redis

BGP (Border Gateway Protocol) là một giao thức cổng ngoài tiêu chuẩn được sử dụng để trao đổi thông tin định tuyến và khả năng kết nối giữa các hệ thống tự trị trên internet. Trong OpenStack, BGP có thể được sử dụng để quảng bá động các địa chỉ IP nổi (floating IP) và mạng dự án tới các bộ định tuyến vật lý, loại bỏ sự cần thiết của các tuyến tĩnh và cho phép các kiến trúc mạng có khả năng mở rộng và chịu lỗi tốt hơn.

Network namespaces là một tính năng của nhân Linux cung cấp các ngăn xếp mạng cô lập cho các tiến trình khác nhau. Trong OpenStack, network namespaces được sử dụng để cô lập tài nguyên mạng của các virtual router khác nhau và các dịch vụ mạng khác. Điều này đảm bảo rằng mỗi router có tập hợp giao diện, bảng định tuyến và quy tắc tường lửa riêng, ngăn ngừa xung đột và cung cấp một môi trường đa khách thuê (multi-tenant) bảo mật.