DB 앞에 cache-aside 계층(Redis/Memcached)을 두어 read가 메모리를 치게 하고, 항목에 TTL을 주고 write 시 무효화하며, cold key가 DB에 thundering herd를 풀어놓지 못하도록 stampede 보호를 추가하고, 하나의 인기 key가 단일 노드를 녹이지 않도록 hot key를 replica에 분산하십시오.
┌── hit ──▶ return value
request ──▶ cache│
└── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
│
(only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
cache-aside에서는 앱이 캐시를 확인하고, miss 시 DB를 읽어 캐시를 스스로 채웁니다. read-through에서는 캐시 라이브러리가 이를 대신 해줍니다. 어느 쪽이든 목표는 같습니다: 5ms DB 쿼리를 0.2ms 메모리 조회로 바꾸는 것 — 그래서 95% hit rate 캐시는 DB read 트래픽을 20배 줄입니다. 분당 수백만 요청에서 DB는 단순히 모든 read를 감당할 수 없습니다 — 캐시가 그 숫자를 성립시킵니다.
캐시를 신선하게 유지하는 두 가지 방법이며, 보통 둘 다 필요합니다. TTL은 staleness를 제한합니다 — 항목이 N초 후 만료되어 잘못된 데이터가 스스로 치유됩니다. 명시적 무효화는 TTL을 기다릴 수 없는 정확성을 위해 write 시 key를 삭제/업데이트합니다. 전형적인 버그는 무효화 없이 캐시하여 몇 분간 stale 데이터를 제공하는 것이고, 더 미묘한 것은 같은 write에서 무효화 와 설정을 함께 하여 race가 나는 것입니다.
면접관은 당신이 "Redis 추가"를 넘어 사고하는지 보고 싶어 합니다. 좋은 답변: TTL을 갖춘 cache-aside. 훌륭한 답변: stampede 보호, 무효화 전략, hot-key 처리, 그리고 캐시 장애 시 무슨 일이 일어나는지를 짚습니다. 함정은 캐시가 항상 살아 있다고 가정하는 것 — Redis가 죽고 모든 miss가 DB로 흘러내리면, DB까지 무너뜨리는 cache-avalanche가 발생합니다.
주니어부터 시니어까지 상세한 답변이 포함된 IT 면접 질문 라이브러리.
후원하기