뉴스 피드 수정 감지 로직관해서

[Atriel1999]

현재 구현과 토의방향은
수집서비스는 말그대로 실시간으로 들어오는 rss 피드에 대해서 카테고리별로
중복데이터만 없게 처리해서 받아옴

저번에 토의했을땐
별도의 스케쥴러를 지금 작업중인 talkpick-batch가 아닌 별도의 서버에서 처리한다고 토의했던걸로 기억하는데

같은 프로젝트 내에서 처리해도 되지않을까 생각이들어 discussions 발의했습니다

의견1: 저장로직 및 데이터 처리

1. 객체에 hash값을 넣는 column을 추가 (글 + 내용을 해시값으로 변환함)
2. 데이터 수집후 Quartz스케쥴러로 MySQL에 넣는과정에서
   Redis에 필요한데이터(링크, hash)를 가공(해쉬값 변환)해서 저장 (Bloom Filter 고려)
3. redis 정보 TTL을 30일 정도로 제한해서 오래된 데이터에 대해서는 업데이트 제외 (실제로 최근 기사에 대해서만 업데이트가 일어날테니)
4. redis 저장은 mysql정보가 Spring batch로 저장될때 통합처리

까지만 생각했는데 어디까지나 개인적인 생각이고
batch를 실제로 써본적이없어서 이게맞는지 모르겠는데

의견2: 스크래핑 관련 로직

1. 카테고리별 중요성 별로 데이터 처리 전략 고려
   • 자주나오는 정치카테고리 뉴스들은 더 오랜기간확인
   • 스포츠 뉴스등은 스크래핑 빈도나, 날짜 제한 줄이기 (최근 10일 데이터만 업데이트 등)
2. 서버에서 비동기처리 @async등으로 처리
   • 만약 운영중 부하가 심하면, 메세지큐(Kafka, rabbitMQ)로 시간당 처리 속도 제한 <- 인프라비용 엄음엄

관련 모르는거 공부or 조사해야하는것

 - 만약 사용한다면 Kafka와 rabbitMQ중 프로젝트에 더 적합한게 뭔지
 - redis Bloom filter (빠른 데이터 조회)
 - Spring Retry 라이브러리 (스크래핑 실패시 재시도 라이브러리, 필수아님)

원래하려던 방향이 이 방향이 맞는지? (토의에서 애기를 하긴했는데)
실제로 데이터양이 얼마나 될지 아직 모르겠기는한데 이런 기술까지 필요한가? 조사하다가 생각이들기도 했습니다
검토하고 지적해주셨으면합니다

[thelightway24]

다른 서버라고 생각할 수 있었다고 생각합니다.
제가 주장했던 것 같은데, 주요 요지는

데이터를 rss에서 가져오는 로직과
변경사항을 추적 관리 하는 로직을 분리하자는 것입니다.

RSS 수집은 newsId 등을 기준으로 일정 수준의 중복 확인이나 체크가 가능하지만,
변경사항 추적은 비교 로직, 히스토리 저장 등 부가적인 기능이 많아
유지보수 측면에서 RSS 수집기와 통합해서 처리하기엔 부담이 크다고 판단했습니다.

스크래핑과 관련해서는,
Spring Batch를 활용해 비동기까지는 아니더라도 멀티스레드 기반 병렬 처리가 적절해 보입니다.
또, 언급해주신 Retry 관련 라이브러리도 좋지만,
Spring Batch 자체에서도 retry와 skip 기능을 제공하므로 충분히 활용할 수 있습니다.

한편, 채팅 서비스를 개발할 경우에는 비동기 처리 방식이 적합하다고 생각합니다.
실시간성과 다중 사용자 대응이 필요하기 때문입니다.

또한, 이벤트 기반으로 처리한다면 강의에서 사용해봤던 RabbitMQ를 활용하는 것도 좋은 선택이라고 생각합니다.