Redis

Master-Replica 전환 후 Client의 인식 문제Client 는 Master에는 Write, Replica에는 Read request를 날림어떤 이유로 Master-Replica 전환Client 는 새로 바뀐 정보가 아닌 예전 Master/Replica 정보

Redis-Streamappend-only log를 구현한 자료 구조하나의 key로 식별되는 하나의 stream에 엔트리가 계속 추가되는 구조하나의 엔트리는 entry ID + (key-value 리스트)로 구성추가된 데이터는 사용자가 삭제하지 않는 한 지워지지 않음명

Redis는 환경에 영향을 많이 받는 시스템이다. 그렇기에 성능과 시스템을 어떻게 신경 써야하는지 검토 해보자Redis 성능 측정redis-benchmark -h host -c clents Redis 성능에 미치는 요소들Network bandwidth & latency

master 3개 replica 3개 총 6개의 클러스터를 구성 한 후 노드를 추가하는 작업을 진행 해보자1\. 포트를 이름으로 디렉토리를 만들고 각각 디렉토리에 conf파일을 설정한다. (clster-enabled 옵션을 yes로 변경하고 port를 7000부터 70

cluster-enabled <yes/no>: 클러스터 모드로 실행할지 여부를 결정cluster-config-file : 해당 노드의 클러스터를 유지하기 위한 설정을 저장하는 파일로 사용하자 수정하지 않음cluster-node-timeout 특정 노드가 정상이

Redis Cluster데이터 분산을 제공일부 노드의 실패나 통신 단절에도 계속 작동하는 가용성고성능을 보장하면서 선형 확장성을 제공Redis Cluster 특징full-mssh 구조(모든 노드가 서로 연결되어 있음)cluster bus라는 추가 채널 사용(16379가

Redis Sentinel Redis에서 고가용성을 위한 장치 master-replica 구조에서 master가 다운 시 repilca를 master로 승격시키는 auto-failover를 수행 특징 몽고디비 RepilcaSet처럼 홀수로 구성된다 SDOWN:

Replication백업만으로는 장애 대비에 부족함(백업 실패 가능성, 복구에 소요되는 시간)Redis도 복제를 통해 가용성을 확보하고 빠른 장애조치가 가능Master가 죽었을 경우에 복제노드중 하나를 Master로 전환해 즉시 서비스 정상화 가능복제본은 Read-On

AOF모든 쓰기 요청에 대한 로그를 저장재시작 시 AOF에 기록된 모든 동작을 재수행해서 데이터를 복구장점모든 변경사항이 기록되므로 RDB 방식 대비 안정적으로 데이터 백업 가능append-only 방식으로 백업 파일이 손상될 위험이 적음실제 수행된 명령어가 저장되어

RDB 방식특정 시점의 스냅샷으로 데이터 저장재시작시 RDB 파일이 있으면 읽어서 복구장점작은 파일 사이즈fork를 이용해 백업하므로 서비스중인 프로세스는 성능에 영향 없음 (자식 프로세스를 만든다)데이터 스냅샷 방식이므로 빠른 복구가 가능단점스냅샷을 저장하는 시점 사

Pub-Sub메시징 모델 중의 하나로 발행과 구독 역할로 개념화 한 형태발행자와 구독자는 서로에 대한 정보 없이 특정 주제(토픽 or 채널)를 매개로 송수신메시징 미들웨어 사용의 장점비동기: 통신의 비동기 처리낮은 결합도: 송신자와 수신자가 직접 서로 의존하지 않고 공

세션을 HashMap에 저장, 저장한 세션을 조회하는 두개의 api를 구현했다.두 개의 터미널을 열어 각각 다른 포트로 자바 서버를 실행시킨다.gradle의 build를 실행시키면 build파일에 SNAPSHOT.jar 파일이 생성된다.해당 경로로 이동하여 각각의 터미