FULLTEXT 검색 방식

• 자연어 검색(natural search)
  검색 문자열을 단어 단위로 분리한 후, 해당 단어 중 하나라도 포함되는 행을 찾는다.
• 불린 모드 검색(boolean mode search)
  검색 문자열을 단어 단위로 분리한 후, 해당 단어가 포함되는 행을 찾는 규칙을 추가적으로 적용하여 해당 규칙에 매칭되는 행을 찾는다.
• 쿼리 확장 검색(query extension search)
  2단계에 걸쳐서 검색을 수행한다. 첫 단계에서는 자연어 검색을 수행한 후, 첫 번째 검색의 결과에 매칭된 행을 기반으로 검색 문자열을 재구성하여 두 번째 검색을 수행한다. 이는 1단계 검색에서 사용한 단어와 연관성이 있는 단어가 1단계 검색에 매칭된 결과에 나타난다는 가정을 전제로 한다.

풀 텍스트 인덱스 생성

1. CREATE FULLTEXT INDEX unique_code_idx ON lotto(unique_code);

2. alter table lotto add FULLTEXT(unique_code);

FULLTEXT 검색 엔진 설정하기

검색어가 너무 짧은 경우 아무런 검색결과도 나오지 않는다. 이때 짧다는 기준은 4글자 이하다. 만약 2글자의 검색어를 지원하려면 최소 검색어 길이 값을 2로 수정해야 한다. my.cnf 설정파일을 열어서 ft_min_word_len 변수 값을 기본값인 4에서 2로 변경한다

적용 되었는지 확인

풀텍스트 쿼리 문

1. 자연어

자연어 검색 시 관련이 낮은 것도 같이 검색이 된다.

select * FROM lotto WHERE MATCH(unique_code) AGAINST("d4b42907b15d43cfb0b1e635aeff4a00" );

2. 불린 모드

• 검색의 정확도에 따라 결과가 정렬되지 않는다.
• 구문 검색이 가능하다
• 필수(+), 예외(-), 부분(*) 연산자를 사용할 수 있다

d4b42907b15d43cfb0이 포함된 구문만 검색 된다.

select * FROM lotto WHERE MATCH(unique_code) AGAINST("+d4b42907b15d43cfb0*" IN BOOLEAN MODE);

3.인덱스 타는 지 확인.

describe select * FROM lotto WHERE MATCH(unique_code) AGAINST("d4b42907b15d43cfb0b1e635aeff4a00" IN BOOLEAN MODE);

요번주는 모의 기술면접을 봤다.....

코딩공부를 하면서 이분야에서 처음 보는 면접이였고 긴장되어서 질문을 받았을 때 잘 생각이 나지않았다 ㅠㅠ

면접을 보면서 cs지식도 많이 필요하다고 느꼈다.

면접 질문 중 db에 대해 많이물어보셨다.

그중 가장 기억나는 거는 트랜젝션이였다.

서비스 코드에서 @Transactional 을 많이 쓴다.

그런데 사실 뜻도 잘 모르고 좋다고 쓴거라... 정확히 설명하기가 어려웠다.

트랜잭션이란?

데이터베이스 트랜잭션은 데이터베이스 관리 시스템 또는 유사한 시스템에서 상호작용의 단위이다.

여기서 단위라는 말을 사용했는데, 쉽게 말하면 더 이상 쪼개질 수 없는 최소의 연산이라는 의미가 된다.

1. 트랜잭션은 데이터베이스 시스템에서 병행 제어 및 회복 작업 시 처리되는 작업의 논리적 단위이다.

2. 사용자가 시스템에 대한 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업단위이다.

3. 하나의 트랜잭션은 Commit되거나 Rollback된다.

Atomicity(원자성)

1. 트랜잭션의 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다.

2. 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.

Consistency(일관성)

1. 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환한다.

2. 시스템이 가지고 있는 고정요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 한다.

Isolation(독립성,격리성)

1. 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행중에 다른 트랜잭션의 연산이 끼어들 수 없다.

2. 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.

Durablility(영속성,지속성)

1. 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다.

Commit연산

1. Commit 연산은 한개의 논리적 단위(트랜잭션)에 대한 작업이 성공적으로 끝났고 데이터베이스가 다시 일관된 상태에 있을 때, 이 트랜잭션이 행한 갱신 연산이 완료된 것을 트랜잭션 관리자에게 알려주는 연산이다.

Rollback연산

1. Rollback 연산은 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 이 트랜잭션의 일부가 정상적으로 처리되었더라도 트랜잭션의 원자성을 구현하기 위해 이 트랜잭션이 행한 모든 연산을 취소(Undo)하는 연산이다.

2. Rollback시에는 해당 트랜잭션을 재시작하거나 폐기한다.

@Transactional의 작동 원리와 흐름

그렇다면 @Transactional이 붙은 메서드를 호출할 경우, 우리 코드에는 어떤 일이 벌어질까?

@Transactional이 클래스 내지 메서드게 붙을 때, Spring은 해당 메서드에 대한 프록시를 만든다.

프록시 패턴은 디자인 패턴 중 하나로, 어떤 코드를 감싸면서 추가적인 연산을 수행하도록 강제하는 방법이다.

--프록시란 실제 엔티티 객체 대신에 사용되는 객체로서 실제 엔티티 클래스와 상속 관계 및 위임 관계에 있습니다.

프록시 객체는 실제 엔티티 클래스를 상속 받아서 만들어지므로 실제 엔티티와 겉모습이 같습니다.

트랜잭션의 경우, 트랜잭션의 시작과 연산 종료시의 커밋 과정이 필요하므로, 프록시를 생성해 해당 메서드의 앞뒤에 트랜잭션의 시작과 끝을 추가하는 것이다.

서비스 클래스에서 @Transactional을 사용할 경우, 해당 코드 내의 메서드를 호출할 때 영속성 컨텍스트가 생긴다는 뜻이다. 영속성 컨텍스트는 트랜잭션을 시작할 때 생겨나고, 메서드가 종료되어  트랜잭션을 커밋할 경우 영속성 컨텍스트가 flush되면서 해당 내용이 반영된다. 이후 영속성 컨텍스트 역시 종료되는 것이다.

isolation

트랜잭션에서 일관성없는 데이터 허용 수준을 설정한다

propagation

트랜잭션 동작 도중 다른 트랜잭션을 호출할 때, 어떻게 할 것인지 지정하는 옵션이다

noRollbackFor

특정 예외 발생 시 rollback하지 않는다.

rollbackFor

특정 예외 발생 시 rollback한다.

timeout

지정한 시간 내에 메소드 수행이 완료되지 않으면 rollback 한다. (-1일 경우 timeout을 사용하지 않는다)

readOnly

트랜잭션을 읽기 전용으로 설정한다.

DB의 꽃 옵티마이저의 실행 계획 수립

RDBMS에서 가장 복잡하면서 가장 중요한 것은 옵티마이저(Optimizer)가 쿼리를 어떻게 실행할지 실행 계획을 결정하는 부분이다.

똑같은 쿼리라 할지라도 다양한 방법과 순서로 실행 될 수 있다.

어떤 실행 계획이 좋고 어떤 실행 계획이 안 좋은지 판단하는 건 온전히 옵티마이저의 몫이지만 개발자 역시도 어떤 실행 계획으로 수행되어야 좋은지를 알아야 최적의 실행 계획을 사용할 수 있도록 옵티마이저에게 힌트를 줄 수 있기 때문에 중요하고 반드시 학습해야하는 부분이다.

사전 지식

실행 계획에 대해 자세히 살펴보기 전에 아래의 사전 지식이 있어야 한다.

• 쿼리 실행 절차
  1. SQL을 SQL 파서가 파싱하여 파서 트리(parser tree)를 만든다.
  2. 파서 트리를 기준으로 옵티마이저가 분석하여 실행 계획을 만든다.
• 옵티마이저의 종류
  1. 규칙 기반 옵티마이저 : 이제는 안 쓰임
  2. 비용 기반 옵티마이저 : 쿼리 대상 테이블의 레코드 수, 선택도 등 통계 정보를 바탕으로 비용이 가장 적을 것 같은 방향으로 실행 계획 생성 → 대부분 이 방식 옵티마이저 사용(MySQL포함)
• 통계 정보가 정확할 수록 좋은 실행 계획을 만들 확률이 높다.
  • 통계 정보는 서비스중에도 수집되고 수정된다. innodb_stats_sample_pages 설정값은 통계 정보를 위해 분석할 인덱스 페이지의 개수(기본값:8)를 지정하는 것인데, 분석할 페이지 개수를 늘려서 더 정확한 통계 정보를 수집할 수 있지만, 수집 중에 테이블의 읽기/쓰기가 되지 않으므로 문제될 수 있다. 따라서 최대 16~24까지만 설정해야한다.
  • MySQL 8.0 부터는 인덱스 말고 일반 컬럼에도 통계 정보(Histogram)를 수집하기 때문에 더 정확한 통계를 토대로 실행 계획을 수립할 수 있다.
  • ANALYZE 키워드를 이용해 테이블의 통계 정보를 다시 수집할 수 있다.
• EXPLAIN 키워드를 SELECT 쿼리 앞에 붙여서 실행 계획을 살펴볼 수 있다.
  • INSERT, UPDATE, DELETE 쿼리는 실행 계획을 알 수 없다.

인덱스 사용중인 지 확인을 위함.

클라우드 사용시 대량의 데이터 트래픽을 기본 프리티어로 견디지 못해 서버거 자꾸 내려감.

클라우드 티어 업그레이드 할 시 비용 문제로 인한 개인 서버 사용.

온프레미스

집을 짓는다고 할 때 집을 짓기 위한 자제 구매부터 건물 도면을 그리는 작업, 시공, 건축 그리고 인테리어까지 모든 과정을 도움없이 집을 필요로 하는 사람이 혼자서 다 처리하는 방법

즉, 온프레미스란 필요한 시스템을 구축하기 위해서 하드웨어와 소프트웨어를 구입하여, 시스템 구성 상황에 맞게 환경을 구성하는 것을 말합니다. 즉 서버실과 혹은 데이터 센터와 같이 특정 공간에 IT 인프라를 구축하여 소프트웨어를 사용하는 방식입니다. 이러한 방법은 인프라를 구축하기 위한 기간이 필요하며, 상황에 따라서는 몇 개월 이상이 걸리기도 합니다. 또한 시스템을 구축하기 위한 물리적인 하드웨어 장비를 구매하는 비용이 들어가며, 부차적으로는 이를 관리 및 운용을 위한 유지보수 비용을 필요로 합니다.

클라우드 시스템

온프레미스처럼 집을 짓는다고 가정하면, 집을 만드는 과정에서 자내나 도구 혹은 전문가의 도움을 필요에 따라 제공받는 방법.
그렇기 때문에 온프레미스는 서비스를 만들기 위해 하나부터 열까지 다 알아야 하지만, 클라우드 시스템은 하나부터 다섯까지 정도만 알아도 ok

즉, 온프레미스와 클라우드 시스템의 가장 큰 차이는

서비스를 제공함에 있어 사용하는 IT 자원을 누가 관리하느냐임
온프레미스: 서비스를 공급하는 서비스 제공자가 직접적으로 IT 자원을 관리하는 주체
클라우드 시스템: 서비스를 공급하는 서비스 제공자는 IT 자원을 사용할 뿐, 대부분의 IT 자원 관리는 클라우드 서비스 제공자에게 제공받음

어떻게 보면 클라우드 시스템은

서비스에 필요한 인프라를 직접 보유하지 않고 필요할 때만 사용할 수 없을까?라는 질문에 답을 하기 위해 나온 기술

이라고 봐도 좋다.

차이점

1. 비용

클라우드 서비스가 제공되지 이전에는 IT 프로젝트를 구성하기 위해서는 온프레미스 시스템을 먼저 도입하고 프로젝트를 진행함.

일반적으로 예측된 데이터를 기준으로 인프라 지식을 갖춘 기술자가 물리적인 구성을 설계함

이때 물리적인 구성은 최대 사양을 기준으로 구성되기 때문에 실제 프로젝트 오픈 시 예측과 다른 경우가 많음 => 이로인해 불필요한 비용이 사용되는 경우가 많음

반면 클라우드 시스템의 경우 서비스에서 제공되는 옵션을 통해 시스템 사양을 실시간으로 수정해 사용이 가능

즉, 불필요한 비용이 들지 않음!

온프레미스는 한번 확정이 된 시스템 사양을 바꾸기가 어렵기 때문에 불필요한 비용이 지속적으로 낭비되지만, 클라우드 시스템은 상황에 따라 적절한 비용으로 시스템을 운용할 수 있도록 도와줌

또한 온프레미스는 물리적인 구성에 필요한 절차 및 시간을 필요로 하는데 클라우드 시스템은 가상에서 시스템을 구성할 수 있어 불필요한 절차를 없애고 쉽게 프로젝트를 구성할 수 있도록 함 => 프로젝트 초기 구성시 드는 비용을 줄여주는 효과

2. 시스템 유지 보수

일반적으로 서버 인프라는 기본 지식으로만 응대하기 어려운 부분이라 인프라에 관한 전문가가 필요함

인프라는 단순히 서버 물리적인 위치 구성 뿐만 아니라 서버 간의 흐름, 역할에 맞는 서버 배치 및 보안 관리 이슈등 여러가지 관점에서 관리되어야 하는 분야이기 때문에 한 명의 전문가가 모든 일들을 처리할 수 없음

이러한 관점에서 프로젝트는 시작부터 유지보수 단계까지 지속적으로 인프라 전문가 인원을 운용해야
또한 온프레미스는 인프라를 직접 운영하고 관리하기 때문에, 현대와 같이 IT 인프라가 점차 복잡해지는 환경에서는 유지보수가 용이하지 못합니다. 직접 인프라를 운용하는 기업들은 날이 갈수록 발전하고 복잡해지는 IT 환경 속에서 지속적으로 발생하는 인프라의 확충과 컴퓨팅 파워 및 저장능력 향상에 대한 끊임없는 책임을 지녀야 하고, 기업이 가진 자산 혹은 개인정보를 지키기 위해서 많은 노력과 비용을 투자해야 하기 때문입니다.

이때, 온프레미스는 모든 관리를 직접적으로 하기 때문에 인프라 전문들을 지속적으로 유지해야 하고 섭외하지 않은 분야의 문제가 생기는 경우 빠른 대처가 어려움. 특히 성능 이슈로 인해 서버의 증설 문제가 발생하는 경우 물리적인 시간 필요

반면 클라우드 시스템은 말 그대로 인프라에 관련된 전문가들이 항시 문제를 해결할 수 있도록 대기중이며, 어떤 이슈가 발생하더라도 응대할 수 있는 인원 및 체계가 갖춰져 있음.
또한 성능 이슈로 인한 서버 증설 문제의 경우 단 한번의 클릭으로 몇분, 몇 시간 내 해결 가능

4조 실전 프로젝트 팀 노션 (notion.site)

실전프로젝트 시작

주제 : 로또 시뮬레이션

목적 : 대용량의 클라이언트 로또 번호 더미데이터를 생성하고 그것을 로직화하여 당첨번호와 비교하여 등수 가려내는 로직 목적

ERD

레이아웃

회차별 당첨번호 < 로또6/45 < 당첨결과 | 동행복권 (dhlottery.co.kr)

느낀점

매일 회의를 하며 일일 회고를 노션을 통해 쓰기 시작했고 자신이했던 일들을 기록하면서 서로 회의를 하며 프로젝트를 진행하고 있다. 백엔드 적인 기능 구현을 중점으로 만들어진 백엔드 반이라 처음에는 어떤것을 해야하는지를 모르기떄문에 많은 생각을 하게되었고 서로 의견이 맞지않아 트러블도 생겼다 . 나는 새로운 기술 스텍을 사용하여 그것을 파고 들고 그그 기술을 잘 활용하면 될것 같다 생각을 했지만 토요일에 피드백을 받고 우선 항해에서 원하는 것은 느리더라도 기본을 우선 파고들고 기본 스프링에서 여러가지를 해본 후 더 이상  해결 할 수 없을 것 같을 경우에 나중에서야 그 기술 스텍을 사용하라고 하는 것 같았다.  배우는 입장이기 때문에 우선 이렇게 진행하기로 헀다.

• 기간 10월 28일(금)~11월 4일(목)
• 프론트&백엔드 협업 클론 코딩(KAKAOTALK)

Redis

1. Redis & Cache

• Cache : 나중에 요청할 결과를 미리 저장해둔 후 빠르게 서비스 해주는 것. 미리 결과를 저장하고 나중에 요청이 오면 그 요청에 대해서 DB 또는 API를 참조하지 않고 Cache에 접근해서 요청을 처리한다.

1) Client로부터 요청을 받는다.

2) Cache에서 이미 들어왔던 작업인지 확인한 후 만약 참이면 Cache 내용을 리턴한다.

3) 거짓이라면 DB or Server에 접근해서 작업한다.

4) DB를 접근했기 때문에 한번 들어온 내용은 Cache에 저장이 되고 따라서 다시 Cache와 작업한다.

WebSocket

웹소켓(WebSocket)은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. 웹소켓 프로토콜은 2011년 IETF에 의해 RFC 6455로 표준화되었으며 웹 IDL의 웹소켓 API는 W3C에 의해 표준화되고 있다.

웹소켓은 HTTP와 구별된다. 두 프로토콜 모두 OSI 모델의 제7계층에 위치해 있으며 제4계층의 TCP에 의존한다. 이들에 차이가 있으나 "RFC 6455"에 따르면 웹소켓은 HTTP 포트 80과 443 위에 동작하도록 설계되었으며 HTTP 프록시 및 중간 층을 지원하도록 설계되었으므로 HTTP 프로토콜과 호환이 된다. 호환을 달성하기 위해 웹소켓 핸드셰이크는 HTTP 업그레이드 헤더를 사용하여[1] HTTP 프로토콜에서 웹소켓 프로토콜로 변경한다.

웹소켓 프로토콜은 HTTP 폴링과 같은 반이중방식에 비해 더 낮은 부하를 사용하여 웹 브라우저(또는 다른 클라이언트 애플리케이션)과 웹 서버 간의 통신을 가능케 하며, 서버와의 실시간 데이터 전송을 용이케 한다. 이는 먼저 클라이언트에 의해 요청을 받는 방식이 아닌, 서버가 내용을 클라이언트에 보내는 표준화된 방식을 제공함으로써, 또 연결이 유지된 상태에서 메시지들을 오갈 수 있게 허용함으로써 가능하게 되었다. 이러한 방식으로 양방향 대화 방식은 클라이언트와 서버 간에 발생할 수 있다. 통신은 TCP 포트 80(TLS 암호화 연결의 경우 443)를 통해 수행되며 방화벽을 통해 웹이 아닌 인터넷 연결을 차단하는 일부 환경에 도움이 된다. 단순 양방향 브라우저-서버 통신은 코멧 등의 스톱갭(stopgap) 기술을 사용하는 비표준 방식으로 수행된다.

구글 크롬, 마이크로소프트 에지, 인터넷 익스플로러, 파이어폭스, 사파리, 오페라 등 대부분의 브라우저가 이 프로토콜을 지원한다.

웹소켓 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

STOMP

STOMP는 Simple/Stream Text Oriented Messaging Protocol 약자다.

말 그대로 간단한 문자 기반 메세징 프로토콜이다.

프로토콜이란 원거리에서 메세지를 서로 주고 받을때 정의된 양식 규칙 체계이다.

다시말해 STOMP는 웹 상에서 텍스트 송,수신을 위해 미리 정의된 특정한 규칙이다.

STOMP에 정의한 규칙만 잘 지키면 여러 언어, 여러 플랫폼간에서 메세지를 상호 운영할 수 있다.

STOMP는 기존 AMQP 나 MQTT 와 같은 메세지 전송을 위한 다른 프로토콜들과 다르게 binary 기반이 아닌 텍스트 기반 프로토콜이다.

그렇기 때문에 개발자가 읽기 쉽고 사용하기에 좋다.

STOMP는 HTTP와 마찬가지로 프레임(frame)을 사용해 전송하는 프로토콜이다.
프레임이란 주소와 명령, 명령 수행을 위한 데이터가 모두 포함된 데이터를 의미한다.

기본적으로는 텍스트 기반 통신을 사용하지만, 바이너리 기반 통신도 지원한다.

메시지 전송 방식은 TCP 위에서 STOMP에서 정의한 Frame 구조로 Client와 Server 상호간에 메세지를 전달한다.

STOMP는 메시지를 수신 할 대상 집합을 관리하는 일을 한다.

STOMP는 메시지에 대한 스팩만을 정의하고 있기 때문에, 기능 구현은 전적으로 서버에 맡긴다.

Frame 구조

Frame은 명령(Command)과 추가적인 헤더(Header)와 추가적인 바디(Body)로 구성이 된다.

Frame은 몇 개의 텍스트 라인으로 지정된 구조인데 첫번째 라인은 텍스트(Command 명령어)이고 이후 key:value 형태로 header 정보를 포함한다.

header이후에 공백 줄을 하나 더 추가하는 것으로 header의 끝을 설정할 수 있다.

header이후에는 Payload(Body)가 존재한다.
페이로드(Payload)는 전송되는 데이터를 의미.
[EX] JSON에서 DATA 부분.
[EX] 택배 배송을 보내고 받을 때, 택배 물건이 payload.

Payload(데이터)는 Body에 위치하는데, 끝은 NULL 문자로 설정한다.

Redis

1. Redis & Cache

• Cache : 나중에 요청할 결과를 미리 저장해둔 후 빠르게 서비스 해주는 것. 미리 결과를 저장하고 나중에 요청이 오면 그 요청에 대해서 DB 또는 API를 참조하지 않고 Cache에 접근해서 요청을 처리한다.

[progress]

1) Client로부터 요청을 받는다.

2) Cache에서 이미 들어왔던 작업인지 확인한 후 만약 참이면 Cache 내용을 리턴한다.

3) 거짓이라면 DB or Server에 접근해서 작업한다.

4) DB를 접근했기 때문에 한번 들어온 내용은 Cache에 저장이 되고 따라서 다시 Cache와 작업한다.

• Redis(Remote Dictionary[key,value] Server, 원격 사전 서버)

[properties]

1) In-Memory database로 read/write가 빠른 NoSQL이다.

2) Persistence(영속성)를 지원하므로 서버가 꺼지더라도 다시 data를 불러들일 수 있다.

3) key-value 형태로 data를 저장하기 때문에 별도의 쿼리 없이 key로 value를 찾을 수 있다.

4) Data Collection : String, List, Set, Sorted Set, hash

5) Memory 기반의 DB이므로 get, put을 이용해서 데이터를 넣고 빼는 것이 가능하다.

💡 Redis Collection(자료구조)와 명령어

1) String(key-value : One-To-One Mapping)

• get : key에 해당하는 value 리턴
• set : key에 value 저장
• del : key 삭제

2) List(순서가 있는 String 묶음으로 array형식의 데이터 구조이다. 자바의 linked list와 유사하다. 처음과 끝에 데이터를 삽입/삭제는 빠르지만, 중간에 데이터를 삽입하는 것이 어렵다.)

• lpush <key><value> : left, 첫번째(index:0)에 데이터 삽입
• rpush <key><value> : right, 마지막(index:-1)에 데이터 삽입
• lpop <key><value> : left, 첫번째(index:0)에 데이터 삭제
• rpop <key><value> : right, 마지막(index:0)에 데이터 삭제
• lrange <key><s><e> : s부터 e index의 데이터 반환

3) Sorted Set(Set과 마찬가지로 순서가 없는 String의 묶음. 다른점은 score를 통해 순위를 매겨 오름차순으로 정렬이 가능하다. 만약, score값이 같으면 value로 정렬한다. 여기서 set의 value는 member이다. value는 중복이 불가능하지만, score 값은 중복이 가능하다.)

• zadd <key><score><member> : key에 score와 member 추가
• zcard <key> : member count 조회
• zcard <key><s><e> : s부터 e까지 index의 member 반환
• zrangebyscore <key><min><max> : min부터 max까지 해당하는 score 값을 갖는 member 반환
• zrem <key><member> : member 삭제

4) Hash(key내부에 key-value가 존재하는 자료구조이다. key의 Filed는 subkey로 갯수에 제한이 없다. 여러가지 Object type을 저장할 수 있다.)

• hset <key><field><value><field><value>.. : 하나의 key에 여러 field-value 저장
• hget <key><field> : key와 field에 해당하는 value 리턴
• hdel <key><field> : field 삭제
• hlen <key> : field count 리턴
• hgetAll <key> : 모든 field-value 쌍 반환
• hkeys <key> : 모든 field 리턴
• hvals <key> : 모든 value 리턴

[Reference]

2.pub/sub Model

<aside> 💡 Kafka VS Redis Cluster에서 Pub/Sub 동작원리

</aside>

*차이점 요약: pub/sub을 다루는데 있어서 kafka가 훨씬 무겁다.

1) pub/sub 모델에 대한 이해

2) Kafka pub/sub model

kafka 는 producer/consumer(publisher/subscriber)가 있는데 producer가 Topic에 이벤트를 보내고 이 이벤트는 Topic의 각 Partition에 분산되어 저장된다. Topic을 구독하고 있는 Consumer group 내의 Consumer는 각각 1개 이상의 partition으로부터 이벤트를 가져온다. 만약 partition 개수보다 consumer개수가 많다면 아무 일도 하지 않는 consumer가 생기기 때문에 항상 partition의 수를 consumer의 수 이상으로 해주는게 좋다.

3) Redis pub/sub model

Redis의 pubsub은 그룹이라는 개념이 존재하지 않고 각 subscriber가 channel을 구독하고 있다. 여기서 kafka와의 가장 큰 차이점으로 channel은 이벤트를 저장하지 않는다. 이벤트가 도착했을때 채널의 subscriber가 없다면 이벤트는 증발한다. 또한 응답을 받지 못하기 때문에 완벽한 이벤트의 성공을 보장하지는 못한다.

Kafka는 redis보다 더 다양한 기능이 있고 세밀하게 성능 및 기능을 조정할 수 있다. 그러나 Redis도 kafka처럼 사용할 수 있으므로 Event queue가 무겁고 core하게 pub/sub 기능이 필요하다면 kafka를 추천하고 단순한 이벤트큐로 가볍게 사용하려고 한다면 redis를 권장한다.

💡 Back to Redis(Kafka는 이후에 다뤄보도록 하겠다.)

1) server.pubsub_channels → server측에서 channel을 저장하는 구조

pubsub_channel는 채널을 저장하는 dict 구조체를 가리킨다. dict 구조체는 여러개의 dictEntry를 가지고 있고 각 Entry는 key:robj channel, value:list 타입인데 list는 linked list로 이루어져 있다.

public 동작 과정은 다음과 같다. PUBLISH channel_name message → dict(hash table)에서 channel을 찾고 그 value에 있는 linked list를 돌면서 client들에게 메세지를 보낸다.

2) server.pubsub_patterns → server 측에서 pattern을 저장하는 구조

PUBLISH channel_name message → 일단 pubsub_channels 에서 처럼 channel 명으로 클라이언트에 메시지를 보낸 다음  를 돌며 패턴에 맞는 client에게 메시지를 보낸다. (pattern을 보면 robj 라는 단어가 붙어있는데 저건 redis object라고 생각하면 된다. 참고로 redis는 C언어로 개발되어있다.)

1. STOMP & Redis

[INTRO]

💡 Why using Redis?

1) 채팅방의 메인 저장소가 없어 server의 memory에 적재된 채팅방은 server을 재시작 할때마다 초기화된다. 따라서 DB를 이용하거나 저장소가 필요한데 Redis를 저장소로 사용할 수 있다.

2) STOMP에서 지원해주는 pub/sub 기능을 사용하면 pub/sub이 발생한 server 내에서만 메세지를 주고받는 것이 가능하다. 즉, subscribe 대상인 topic(채팅방)이 생성된 server안에서만 유효하므로 다른 서버로 접속한 client는 해당 채팅방이 보이지 않고, 구독도 불가능하다. 이는 Redis에서 지원하는 pub/sub을 이용해서 해결할 수 있다.