개발자취

Pub / Sub 패턴 메시징 모델 중의 하나로 발생(publish)과 구독(Subscribe) 로 개념화한 형태 발행자와 구독자는 서로에 대한 정보 없이 특정 주제(토픽 or 채널)를 매개로 송수신 graph LR subgraph Messaging Middleware Topic end Publisher --메시지 발행--> Topic --메시지 구독--> Subscriber 메시지 미들웨어 사용의 장점 비동기: 통신의 비동기 처리 낮은 결합도: 송신자와 수신자가 직접 서로 의존하지 않고 공통 미들웨어에 의존 탄력성: 구성원들간에 느슨한 연결로 인해 일부 장애가 생겨도 영향이 최소화 됨 메지싱 미들웨어 제품들: kafka, RabbitMQ, ActiveMQ 등등 Redis Pub/Sub 특징 메시지가 큐..

캐시 적중(Cache Hit): 캐시에 접근해 데이터를 발견 캐시 미스(Cache Miss): 캐시에 접근했으나 데이터를 발견하지 못함 캐시 삭제 정책(Eviction Policy): 캐시의 데이터 공간 확보를 위해 저장된 데이터를 삭제 캐시 전략: 환경에 따라 적합한 캐시 운영 방식을 선택할 수 있음 캐시 전략 Cache-Aside(Lazy Loading) 항상 캐시를 먼저 체크하고, 없으면 원본(ex: DB)에서 읽어온 후에 캐시에 저장 장점: 필요한 데이터만 캐시에 저장되고, Cache Miss가 있어도 치명적이지 않음 단점: 최초 접근이 느림. 업데이트 주기가 일정하지 않기 때문에 캐시가 최신 데이터가 아닐 수 있음. graph LR Application --1. 읽기 시도--> Cache App..

두 WAS를 띄었을때 JSESSIONID의 값이 다를것인데 graph LR 브라우저 --> 로드발란서 --> 서버1 로드발란서 --> 서버2 @GetMapping("/login") public String login(HttpSession session){ return session.getId(); }세션 아이디를 리턴하게 코드를 짜고 포트 8080과 8081로 따로 WAS를 띄워봤다. 다른 세션ID를 가지고 있다. 세션공유가 안되고있다. Redis사용하기 이런 분산환경에서 redis를 사용한다면? graph LR 브라우저 --> 로드발란서 --> 서버1 --> Redis 로드발란서 --> 서버2 --> Redis 아니 근데 RDB를 사용안하는 이유는? 과연 관계형 데이터 모델이 필요할까? 영속성이 필요한..

Strings 가장 기본적인 데이터 타입 바이트 배열을 저장 바이너리로 변관할 수 있는 모든 데이터를 저장 가능 최대크기 = 512MB 명령어 기능 예제 SET 특정 키에 문자열 값을 저장 SET say hello GET 특정 키에 문자열 값을 부름 GET say INCR 특정 키에 값을 Integer로 취급하며 1증가 INCR mycount DECR 특정 키에 값을 Integer로 취급하며 1증가 DECR mycount MSET 여러 키에 대한 값을 한번에 저장 MSET key1 value1 key2 value2 MGET 여러 키에 대한 값을 한번에 부름 MGET key1 key2 Lists Linked-list 형태의 자료구조 Queue와 Stack으로 사용할수있음 명령어 기능 예제 LPUSH 리스트..

Redis 사용하는 이유 손쉽게 사용할수있는 In-memory 저장소 높은 성능 다양한 활용성 세션 관리나 캐시 정의 Storage: 데이터 저장소 (데이터 관점) DataBase: 전통적인 DBMS의 역할을 수행한다. NoSQL Middleware: 어플리케이션이 이용할 수 있는 유용한 기능을 제공하는 소프트웨어 장점 아주 빠른 저장소로 활용 분산된 서버들간의 커뮤니케이션 내장된 자료구조를 활용한 기능 구현 In-Memory DB 란 ? 일반적으로 DB는 디스크에 저장하는데 레디스는 메모리(RAM)에 저장한다. 따라서 아주 빠르다. 대신 비싸다. 메모리는 휘발성인데? 지워져서 안되는 중요데이터가 아닌 지워져도 큰 문제가 없는 로그인 세션데이터나 캐시같은 용도로 사용된다. 데이터 저장 구조 DB관점에서의..