| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
Tags
- rdb
- 임베딩
- redissearch
- redis
- 메시지브로커
- god object
- 레디스
- retry
- 백엔드
- 객체지향적사고
- 데이터유실방지
- 마케팅 #퍼플카우 #새스고딘 #혁신 #독서 #이북
- 배치처리
- SaaS
- redisstreams
- jedis
- springboot
- 장애복구
- 코사인
- DLT
- 시맨틱캐싱
- 메세지브로커
- 비동기처리
- 테스트코드
- aof
- OOP
- blockingqueue
- 자연어캐싱
- Kafka
- 레디스스트림
Archives
- Today
- Total
목록aof (1)
pandaterry's 개발로그
이전 글(https://pandaterry.tistory.com/9)에서는 Redis Pub/Sub과 Kafka를 비교하며 메시지 유실·재처리 이슈를 검증했습니다. 이번 글에서는 “Redis만으로도 신뢰형 메시지 큐를 구현할 수 있지 않을까?”라는 의문으로 다음 방식으로 직접 비교·실험해보겠습니다. 왜 Pub/Sub만으로는 부족했을까?현재 개발중인 SaaS 서비스는 “사용자의 Saas 기능 사용 -> 사용량 측정”이라는 흐름을 비동기로 처리합니다. 이 구조에서 가장 먼저 선택한 메시지 브로커는 Redis Pub/Sub이었습니다. 설정이 간단하고, 즉각적인 전달이 가능했기 때문입니다.하지만 곧 문제를 마주하게 됩니다."만약 메시지를 구독 중이던 서버가 죽는다면?""그 사이에 발행된 메시지는 어떻게 되는가..
개발/Saas 개발로그
2025. 6. 12. 11:13