WW38 ~ WW40

240919

- 코드리뷰 받은 것 수정 후 머지 
- 레디스 적용 


https://hstory0208.tistory.com/entry/Spring-Redis-Redis-cache%EB%A5%BC-%EC%A0%81%EC%9A%A9%ED%95%B4-%EC%A1%B0%ED%9A%8C-%EC%84%B1%EB%8A%A5-%EA%B0%9C%EC%84%A0-%EB%B0%A9%EB%B2%95



- docker exec -it 레디스이미지명 redis-cli

 

 

240920

- Redis는 싱글 스레드고, 'keys *' 는 시간 복잡도가 O(N)이기에 지양하자

 

 

 

240923

- 레디스 poc는 다 했고 직접 적용하다보니 직렬화, 역직렬화 문제와 dateTime 문제가 발생한다.


*** Redis가 메인 DB의 역할을 하기에 적절하지 이유는 무엇일까? 

-> In-Memory DB의 저장 용량은 기본적으로 RAM의 저장 공간을 따르게 된다. 그렇기 때문에 메인 DB의 역할을 하기에는 부족한 저장 공간을 가지고 있는 것이다.

또한 대용량의 데이터가 한번에 들어올 경우, 메모리 공간의 부족 때문에 메모리 스왑이 일어나게 되는데 이 경우 성능의 저하가 발생하게 된다.

현실적인 이유에서는 고성능인 만큼, 고비용이 따른다는 단점이 있다.

그리고 마지막으로 디스크에 데이터를 저장하여 영속성을 유지하는 방법을 사용하는데, 이 경우 사실상 Disk-based DB를 사용하는 것과 다름이 없기 때문에 굳이 비싼 비용을 지불하며 Redis를 사용하는 메리트가 없기 때문이다.

이러한 이유 때문에 메인 DB보다는 다른 메인 DB의 데이터를 캐시시키는 목적으로 사용되는것이 일반적이다.

 

240924

- DLQ(Dead Letter Queue) : 소프트웨어 시스템에서 오류로 인해 처리할 수 없는 메시지를 임시로 저장하는 특수한 유형의 메시지 대기열


< Redis >
- feign Client 쓸때 레디스에 저장해두면 레디스에 있는 경우 외부서비스 타지 않아서 좋음
단, 외부서비스를 타는 경우에는 그 서비스에 레디스를 적용해서 DB 앞단에 캐시에서 가져올 수 있게 

- 레디스는 글로벌로 최소 3개 replica로 사용하는 것을 추천 

- Hyperloglog라는 자료형이 있음 -> 중복제거된 값을 매우 적은비용과 매우 빠른 속도로 계산하는데 사용하는 확률적 자료구조. 카운팅하기 좋음.

- redis를 DB와 함께 캐시로 쓰는 것이 아니라 TTL을 적용하는 DB 용도로만 쓴다면 AOF를 사용해서 영속성에 주의해야 한다!
- redis에 객체 저장할때 serializer 통해 직렬화! GenericJackson2JsonRedisSerializer
- redis에 Geospatial라는 자료구조를 이용해서 좌표계산 편리하게 할 수 있음

<rabbitMQ, Redis, Kafka>
- rabbitMQ : 큐이기 때문에 사용하면 사라짐. ack 처리를 해서 래빗엠큐가 직접 주는 형식 
- Redis : 인메로리 데이터로 이벤트버스 방식으로 진행됨
- Kafka : ack 없고 잘 갔는지 확인 안함. ack가 producer은 있는데 consume엔 없어서 빠름.
          데이터 다 갖고 있고, offset을 사용함. 컨슈머에 있는 그룹아이디가 offset을 관리.
          주키퍼가 ISR(In Sync Replication)을 관리 <- 정상적으로 복제를 보장하는 replication group 
  

*** 현재 컨슈머 이슈 ***
offset에 exception으로 문제 있는 경우
1. 커밋 시키기 (글로벌 카프카 코드 수정 필요)
2. 핸들러 만들기
3. retry를 1로 만들기 


<카프카 at least once 기본 정책>
정확히 한번의 메세지 처리를 위해 
1. 카프카 트랜잭션 걸기
2. 아웃박스 패턴 
3. config(TID:transaction ID) : 송수신 느려짐(header에 추가해서). 제일 쉬운 방법 


<saga pattern>
- 오케스트레이션 방식과 안무 방식이 있다.
- @카프카리스터네서 받은 코드를 try catch문으로 감싸줘야 한다 (이게 아니면 global에서 exception모두 받아서 if문 타는 방법도)
- catch에서 키값을 보내고, 꼭 마지막에 throw e로 터뜨려줘야함!

240925

- 레디스는 결국 역직렬화시 pageImpl 문제여서 pass...
- 애초에 Page<객체>를 레디스에 넣는 것 자체가 좋지 않았다. 추후에는 저렇게 코드 짜지 않도록!

- feignclient를 3개 받는 서비스가 있어서 처음엔 외부에서 가져오고 추후에는 레디스에서 가져오게 함! 




*** 레디스 Read Through + Write Around

의문1)) @Cacheable은 <Read Through> 
의문2)) 레디스 저장 시마다 @CacheEvict로 저장된 캐시를 제거해줘야 한다!!
      하지만 차라리 @CashPut을 사용해서 갱신시에는 캐시 데이터를 업데이트 해주는 것이 더 좋다!?  (삭제시는 @CacheEvict)
  근데 그럼 그게 Write Around가 과연 맞나..?
  모든 곳에 @CacheEvict가 맞지 않을까..? ㅇㅇㅇ 맞음!

** DB 사용 안하고 레디스만 쓰면 그땐 전략이 없음   
  
  
  

240926

- 쿠버네티스 적용시 saga 패턴 필요 없음 
- kafka streams 적용 시, exactly once 보장되어 outbox pattern 필요 없음 

- 운영관점 로그 찍는법 배워야함

 

< MySQL 스터디 >
- 복제 : 서버끼리 동기화 -> 확장성과 가용성
- 복제 아키텍처 알아두기 
- GTID 

- postgres vs MySQL
ㄴ  현재 postgres 사용하는 이유는 write 작업이 많아서 선택. MVCC가 row단위라 빨라

 

- 클러스터 인덱스(pk..)와 논클러스터 인덱스(유니크키, 인덱스) 차이
클러스터 인덱스는 데이터를 인덱스에 맞게 물리적으로 정렬하여 저장하므로 검색 속도가 빠르지만 테이블당 하나만 만들 수 있습니다. (PK에 주로 사용)
논클러스터 인덱스는 데이터를 참조하는 포인터로 구성된 별도의 인덱스 테이블을 사용하며, 여러 개 생성 가능하지만 클러스터 인덱스보다 조회 속도가 느릴 수 있습니다.


- DB 리밸런싱이란?
DB 리밸런싱(Database Rebalancing)은 데이터베이스 시스템에서 성능을 최적화하고 데이터 분산을 개선하기 위해 데이터 및 트래픽을 균등하게 재분배하는 과정입니다. 리밸런싱이 필요한 상황은 여러 가지가 있지만, 주로 데이터가 특정 서버에 집중되어 부하가 편중되거나, 데이터베이스 클러스터에 새로운 노드를 추가하거나, 기존 노드를 제거하는 경우 발생합니다.

  
 

 

240927

- saga pattern 적용 및 confluence 작성!
(DB가 없으면 saga pattern 적용 필요 없음)

 
- 카프카 exactly once 적용되게 하기...!

카프카관련 
https://baebalja.tistory.com/627

 

240930

* Exactly-Once
메시지가 정확하게 한 번만 전달되는 것을 보장한다. 손실이나 중복 없이, 순서대로 메시지를 전송하는 것은 구현 난이도가 높고 비용이 많이 든다.

Kafka는 at-least-once 방식을 지원했으나, 0.11.0.0 이상부터는 enable.idempotence 옵션과 트랜잭션을 적용하여 exactly-once를 구현할 수 있다.



카프카 offset관련
https://leejaedoo.github.io/kafka-detail_2/

 

241002

- 법정교육듣기
- 신입코드리뷰



*** deleteById는 결국 findById를 한 후 delete를 하는 것을 알 수 있다.

 

 

@Transactional
public void deleteById(ID id) {
    Assert.notNull(id, "The given id must not be null!");
    this.delete(this.findById(id).orElseThrow(() -> {
        return new EmptyResultDataAccessException(String.format("No %s entity with id %s exists!", this.entityInformation.getJavaType(), id), 1);
    }));
}

 

 

 

 

241004

 

- poc로 테스트코드로 카프카 throw로 임의로 던질 경우 transaction 되고 메세지 받지 못하는 것 확인