1. 캐시 사용 패턴

(1) Look aside cache

리퀘스트가 오면 캐시에 데이터가 존재하는지 여부를 확인 후에 필요하면 DB에 접근

(2) Wribe back

쓰기 리퀘스트인 경우 일단 캐시에 먼저 쓴 후에 나중에 주기적으로 캐시의 내용을 DB에 옮겨 씀

2. 개발 편의성

주요 용도
인증 토큰: Strings 또는 Hash
Ranking 보드: Sorted Set
유저 API Limit
잡 큐: list

Sorted Set 사용

Redis의 경우 자료구조(Collection)이 Atomic하기 때문에 해당 race condition을 피할 수 있음

이러한 Collection을 풍부하게 잘 활용하는 것이 좋음

3. 주의점

• 하나의 컬렉션에 너무 많은 아이템을 넣으면 좋지 않음
• expire는 컬렉션의 item 개별로 걸리지 않고 해당 컬렉션 전체에만 걸림
• O(n) 명령어는 조심해야 함
• 메모리 관리를 잘해야 함
• 스왑(Swap)을 최소화해야함(Redis는 In-memory라 빠른 건데..)
• Maxmemory를 설정하더라도 이보다 더 사용할 가능성이 큼
• 큰 메모리를 쓰는 인스턴스 하나보다는 작은 메모리를 쓰는 인스턴스 여러 개가 나음
• 이미 Swap을 사용 중이라면 프로세스를 재시작해야 함
• 내부적으로 Ziplist를 쓰면 메모리 사용량을 줄일 수 있음(데이터가 적을 때)
• Redis는 Single Threaded이기 때문에 O(n) 명령어는 쓰면 안 된다

KEYS 
FLUSHALL, FLUSHDB
Delete Collections
Get All Collections(=아이템이 몇 만 개 든 hash, sorted set, set에서 모든 데이터를 가져오는 경우)

• KEYS 명령은 SCAN(커서 방식으로 동작)로 대체해서 사용
• Collection의 모든 item을 가져와야할 때는 그 일부만 가져오거나 아니면 큰 컬렉션을 작은 여러 개의 컬렉션으로 나눠서 저장해야 한다
• 모니터링할 때 RSS 지표를 주의해서 봐야 한다