이슈 사항

• 줄서기 테이블의 db변화를 감지하여 db가 변경될때마다 점주 화면으로 socket전송

• 주기적으로 db조회 함수를 실행시켜 emit전송(Polling 방식)

  → 변동 사항이 없을때도 주기적으로 쿼리문이 실행되므로 비효율적이라 판단

• db에 변화를 주는 api가 실행될 때 마다 socket의 emit 실행

   → api마다 socket/express 세팅을 import 해줘야 했는데 하드코딩으로 판단
  

기술 개선을 위해 시도해본 것들

• my sql trigger 세팅

  1. 특정 테이블의 변화를 감지하는 trigger 생성
  2. my sql 트리거에서 select를 통한 db 조회값 반환이 불가
  3. mysql 쿼리로는 직접 http 통신도 불가능

  → 실패

• 프로시저 세팅

  1. trigger가 실행 되었을 때 row값을 저장하고 프로시저를 호출하여 전달
  2. 프로시저는 전달받은 row값과 http통신 로직을 작성하여 외부 함수로 전달
  3. my sql 트리거 에서는 재귀적 호출이 불가능

  → 실패

• my sql의 curl 확장 프로그램 설치

  1. 설치와 세팅 복잡이 복잡하고 사용법에 대한 러닝 커브가 높아보여 해당 프로그램을 BE팀원들의 로컬, 배포 서버에도 적용할 경우 필요 이상으로 리소스가 들 것으로 판단 → 기각

• 파이썬의 mysql connector와 mysql-replication 이용

  1. mysql-replication을 이용하여 바이너리 로그를 실시간으로 읽어와 변경 사항 있을 때 원하는 로직 수행 구상
  2. 레퍼런스가 부족하여 성공여부에 대한 확신이 들지 않았고, my sql curl 확장프로그램 이슈와 동일하다 생각되어 작업 중단

  → 기각

결과

• 대부분의 업체에서는 polling 방법을 사용 중
• 서비스가 커질수록 바이너리 로그나 api를 감지하여 데이터를 전송하는 것보다 polling 방식으로 진행하는 것이 효율적임을 확인(ex → 0.01초마다 변화 감지 진행되는 상황이고, 0.1초마다 갱신을 해도 충분한 경우)
• 현재 서비스에서 5초 단위로 쿼리 select를 전송하고 있는데 서버 모니터링을 통하여 리소스가 크지 않음을 확인하였고, 주기가 짧아지거나 데이터가 커질 경우 쿼리최적화/캐싱 등을 통하여 해결 가능할 것으로 예상
• 위의 결론을 기반으로 최초의 polling방식으로 회귀하여 진행