서비스 중심 kafka와 redis pub/sub

redis pub/sub?

*레디스 펍섭은 다수의 퍼블리셔가 하나의 채널에 데이터를 전송하고 다수의 섭스크라이브에게 전파되는 기능

*메세지 발행시 채널에 섭스크라이브가 없어도 발행되며 즉시 사라짐

*퍼블리셔는 섭스크라이브가 메시지를 수신 했는지 모름

*섭스크라이브는 메세지를 가져가는 방식이 아니라 채널로 부터 수신 받는방식

*휘발성데이터다

 

채팅서비스에서 사용하였는데 실시간으로 채팅과 관련된 이벤트를 전파하기 위해 사용하였음

1. 여러개의 퍼블리시가 채팅관련 이벤트 상수를 포함한 특정 패턴의 데이터를 채널에 pub

2. 다수의 subscribe에 전파하는 방식

 

kafka?

kafka란 redis pubsub과 다르게 여러 프로듀서가 각기 다른 이벤트를 토픽에 저장하고 컨슈머가 각 하나씩 가져가 처리함 대용량 데이터 처리를 빠르게 하며 히스토리나 추적에 용이하게 됩니다.

*컨슈머는 주기적으로 토픽에 있는 메시지를 가져온다

*컨슈머는 메시지를 가져와도 토픽의 메시지는 바로 사라지지않는다

*컨슈머는 메시지를 읽고 확인할 수 있으므로 처리상태를 추적 할 수있다.

*컨슈머는 각각 offset을 갖고 있어 offset으로 메세지를 어디까지 읽었는지 기록한다.

 

각 서비스 별 대용량 로그 데이터를 적재해야 하는 경우 사용하였음

1. log적재가 필요한 서비스에서 tos-producer로 http 요청을 한다.

2. tos프로듀서 서비스에서 받아서 kafka로 pub하게 되고 topic에 메세지가 적재된다.

3. consumer서비스에서 해당 메세지을 빼서 로그 DB에 로그 적재한다.

 

redis queue?

채팅 서비스 내 랜덤 보상발생시 rpush로 보상내용을 오른쪽부터 메모리에 저장시키고 blpop으로 왼족부터꺼내서 보상순서를 보장시켜 한 유저의 재화 연산을 보장하고 별도로 kafka를 사용해 mq방식으로 재화 수정 히스토리를 남김

 

 

redis로 nft 메타데이터를 저장한 이유?

nft를 상세값을 레디스에 저장한 이유는 nft상세보기 시 매번 메타보라에 요청하는 것은 비효율적이고 느림, 또한 메타데이터는 한번 발행하면 잘 변경될일이 없어서 레디스에서 불러오도록 사용