Amazon ElastiCache là một dịch vụ của AWS, giúp thiết lập, quản lý và scale in-memory cache trên AWS Cloud, hỗ trợ hai engine phổ biến là Redis và Memcached.
1. Giới thiệu chung
- Một dạng in-memory store caching service
- Hoàn toàn độc lập, không làm ảnh hưởng tới hiệu năng của server
- Sử dụng cấu trúc của NoSQL (key-value)
- Độ trễ cực thấp: từ ms đến microsecond
- Hỗ trợ TTL
- Cải thiện rất nhiều hiệu năng của Database cũng như hệ thống
| Redis | Memcached |
| – Hỗ trợ nhiều dạng data từ nhiều nguồn, với nhiều tính năng: snapshots, replication, encryption, transactions… – Không hỗ trợ đa luồng | – Hỗ trợ caching data đơn giản hơn, không bao gồm tính toán – Có hỗ trợ đa luồng |
Các loại cache thường gặp trong ứng dụng:
2. Cache Strategies
2.1. Lazy loading
Đúng như tên gọi, lazy loading là kỹ thuật caching mà sẽ chỉ cập nhật dữ liệu vào cache khi cần thiết.
Amazon ElastiCache sẽ có vai trò trung gian nằm giữa ứng dụng và cơ sở dữ liệu. Khi ứng dụng cần dữ liệu, nó sẽ gọi đến ElastiCache đầu tiên. Lúc này sẽ có 2 kết quả có thể xảy ra
– Cache hit: Nếu dữ liệu tồn tại trong cache và là dữ liệu mới nhất, ElastiCache sẽ trả dữ liệu về cho ứng dụng.
– Cache miss: Nếu dữ liệu không tồn tại trong cache hoặc đã hết hạn thì khi đó ứng dụng sẽ yêu cầu dữ liệu trực tiếp từ cơ sở dữ liệu. Sau khi cơ sở dữ liệu trả về dữ liệu cho ứng dụng, ứng dụng sẽ ghi lại những dữ liệu nhận được này vào cache.
2.2. Write through
Write through là kỹ thuật mà khi dữ liệu được cập nhật vào cơ sở dữ liệu thì cũng sẽ được thêm hoặc sửa trong cache.
Ưu điểm của kỹ thuật này là khó bị xảy ra tình trạng cache miss hơn do dữ liệu được cập nhật liên tục.
Nhược điểm của kỹ thuật này là lượng dữ liệu được lưu trong cache sẽ rất lớn và có thể sẽ dư thừa rất nhiều, dẫn đến nhiều khả năng sẽ đọc phải dữ liệu cũ.
Lúc này, một thuật ngữ quan trọng được nhắc đến, đó là Time to live (TTL), tạm dịch là “thời gian tồn tại”. Đây là một giá trị được thêm vào để đánh dấu thời gian dữ liệu trong cache bị xoá khỏi cache. Khi ứng dụng đọc những dữ liệu mà đã hết thời gian này thì sẽ coi như là không còn tồn tại, lúc đó ứng dụng sẽ phải gọi trực tiếp đến cơ sở dữ liệu.
2.3. Ví dụ ứng dụng
Lưu session của users
3. Cluster mode architecture
- Cluster mode
disabled- Bao gồm 1 shard duy nhất, 1 primary node và có tối đa 5 replicas
- Hỗ trợ multi-AZs
- Hỗ trợ single reader endpoint
- Cơ chế fail-over tự động: 1 replica sẽ được promote thành primary node
- Dùng endpoint của primary node để ghi và phải TỰ QUẢN LÝ các endpoints của replicas (dùng để đọc)
- Cluster mode
enabled- Có thể có nhiều shard
Datasẽ được phân tán sang các shards- Có thể có max 90 nodes (replica cũng là một node) –
CHÚ Ý: limit có thể bị ảnh hưởng bới các version và instance type ⇒ Tối đa 90 shardsKHÔNGcó replicashoặc15 shards với 5 replicas - Nên có ít nhất 3 shards
- Cơ chế failover tương tự
- Nên sử dụng configuration endpoints ⇒ khi có bất cứ thay đổi nào liên quan đến shard, KHÔNG cần update gì cả
- Một số thông tin chung của 2 loại
- Sẽ có replication lag
- downtime failover sẽ từ 3-6 phút
- Khi đang maintenance, cluster mode disabled sẽ KHÔNG thể ghi thông tin vào được
4. Backup và Restore
- Hỗ trợ thủ công và tự động
- Chỉ có thể backup toàn bộ cluster
- Thường dùng để warm-up (tạo một cluster mới, KHÔNG cần chờ load data từ request)
- Có thể backup từ primary node hoặc replicas (nên sử dụng relicas)
- Backup được store ở S3, CÓ THỂ được copy sang một region khác
