Redis basicandroadmap
- 1. Redis Basic and RoadMap Clark.kang
- 2. Redis Basic
- 6. Collections
- 7. Collections - String - list - Set - Sorted Set - Hash
- 8. Dict #1
- 9. Dict #2
- 13. SkipList
- 14. Single Thread
- 15. Single Thread - 한번에 하나의 명령만 처리된다.
- 16. Single Thread - 한번에 하나의 명령만 처리된다. - 즉 한번에 오래도는 명령은 쓰면 안됨
- 17. Single Thread - 한번에 하나의 명령만 처리된다. - 즉 한번에 오래도는 명령은 쓰면 안됨 - O(n) 계열(keys, flushall, del)
- 18. Keys - 현재 DB의 모든 키를 가져온다. - 우리 서버에서 쓰면 바로 Timeout
- 19. Scan - 2.8 부터 가능 - 일정 양만 fetch 하는 걸로 전체를 스 캔 가능
- 20. Scan
- 21. Del - 일반 Key는 별 문제 없음 - 꽤 많은 개수가 들어있는 Collection 을 지우면… 역시 일정시간 Hang - 백만개 지우면 1초 정도 멈춤
- 22. RDB/AOF - persist - 두 개가 서로 관련은 없음 - RDB 생성을 위해서 무조건 Fork() 이 때, 메모리를 추가로 많이 쓸 수 있음
- 23. RDB/AOF - RDB는 현 시점의 메모리 덤프 - AOF는 매 틱마다 디스크에 수행한 명령을 기록함.
- 24. Replication - 슬레이브 접속시 무조건 Master는 RDB 생성 - 그 뒤에 차이 나는 부분을 보냄 - 슬레이브가 계속 붙었다 떨어지면 Master의 로드가 높아짐.
- 25. Memory Issues - 메모리 관리가 Jemalloc에 의존적 - 그래서 Jemalloc 최신 버전 3.6.0 을 쓰 는 2.8.13 이후를 사용하는게 좋음.
- 26. Memory Issues - Jemalloc에 의존적이라 메모리 파편화 의 문제가 심각할 수 있음.
- 29. Partial Sync - 아주 잠시 마스터와 접속이 끊겼는 데도, 새로 받으면 비효율적임. - 지정된 버퍼 사이즈 이하로 변경이 있으면, 변경분만 받음.
- 30. Partial Sync - 그런데, Redis Replication 버 퍼에 PING/PONG 등이 쌓여서, 결 국 시간만 지나면 변화가 없어도 버 퍼가 꽉참.
- 32. Diskless Replication - 매 슬레이브 접속시 RDB를 만들어 서 디스크로 덤프함… 디스크 쓰기가 생기니… 이걸 그냥 스트리밍 상태로 만들어서 전송
- 33. Cluster #1 - Redis Cluster - 최소 3대 이상의 마스터가 필요하 지만, 제대로는 3M – 3S가 필요함.
- 34. Cluster #2 - 16384의 내부 슬롯이 존재 - Sentinel 없이 마스터 노드끼리 통 신해서 Master 장애시 자동으로 Slave를 Master로 승격시킴
- 35. Cluster #3 - Library 에 크게 의존함 - Java/Ruby/Python 등의 클러스 터 지원 라이브러리가 존재(Jedis)
- 36. Cluster #4
- 37. Cluster #5
- 38. Cluster #6
- 39. Cluster #7
- 40. Cluster #8
- 41. Cluster #9 - Library에서 해당 슬롯의 위치를 캐시해야 효율적임.
- 42. Cluster #10 - 클러스터의 부하 분산은 slot 단위로 migration 명령을 이용함. - 자동이 아니라 매뉴얼임.
- 43. Cluster #11 - 아직 큰곳에서 쓰는 레퍼런스가 없음
- 44. Redis 3.2 - GEO(구현 완료) - 기타 등등?(여기에 큰 이슈가…)
- 45. GEO - GEO 커맨드 지원
- 46. 기타 등등 -BloomFilter -sds 메모리 줄이는 것이 있음. sds header 사이즈가 가변으로… -Multi DC Supporting?
- 47. Thank you.