==============================================
스마트포스팅 대량 클릭 처리
==============================================

======= 현 프로세스 및 문제점 =======

현재의 프로세스
 클릭+포스트백 2가지 프로세스
 클릭시에 REQUEST URL 의 _GET, _POST 값을 DB 에 값을 넣고,
   추가된 auto increment 값을 uniq 으로 하여,
     트래킹링크(홍보링크)의 파라미터로 추가하여 리다이렉트 시킴
 추후 포스트백 URL 에서 uniq 값을 이용하여, 클릭될 당시의 _GET, _POST 값을 추출하기 위해 DB 에서 읽어들임

현재의 구성
  CentOS 7.0 + Apache 2.4.6 + PHP 5.6 + MariaDB 5.5.44

문제점
  클릭량이 많을 때, DB 에 실시간으로 넣는 부분에서 DB 문제가 생겼다.

원하는 것
  무한대의 클릭량을 처리 할 수 있는 시스템

======= 스마트포스팅 대량 클릭 처리 =======

클릭서버, 미들웨어, DB 서버, 캐쉬서버, 포스트백서버, 캠페인 참여 및 리포트 서버

으로 분리하면 죽지 않는 서버운영 가능

클릭서버 ( 최소 2대 연결)
  웹서버 데몬만 살려둔다.( httpd daemon 만 살아 있으면 된다. 여러대중에 단 한대만이라도 )
  고유값은 uniqid(SERVER_NO) 로 처리 ( uniqid() 는 100만분의 1초로 for 문돌려도 겹치지 않음.여기에 서버 구분자값 주기)
  DB,Redis 등이 존재하지 않고 access_log 만 고유값과 REQUEST 남기기. (에러 나더라도 로그는 남아야 하니깐 httpd daemon 으로 로그 남기기.)
  웹서버외에 어떠한 컨넥션이 없기에 빠른 처리 (서버 1대당 초당 1,000 쿼리 가능 예상).
  별도의 데문과 연결을 하지 않기에, 문제 발생하지 않고, 트래킹 링크 그대로 이동 가능 (서버 다운되어서 한대만 살아있으면 되는 구조) (UDP 로 패킷을 통한 이벤트를 별도의 서버로 보낼 수 있음 )
  단순 httpd daemon 이 필요한 거라 Nginx 로.

미들웨어 ( 최소 1대 )
  관리를 위한 직접 구현이 좋음.
  데이타는 클릭서버내의 access_log 로부터 가져오기 때문에, 미들웨어 데몬이 죽어도 다시 실행시키면 누락이 없음.
  클릭서버에 저장된 access_log 파일을 읽어들여 캐쉬서버(redis) 와 rdbms(mariadb) 에 저장한다.
  redis 와 mariadb 저장은 각기 다른 프로세스로 작동되게 한다. (2중화하되 서로 간섭없이)
  C > JAVA / Node.JS / Shell / PHP 로 구현 ( 섞어서 사용 가능)
  DB 연결은 DB Pool 이 있으면 좋겠음 ( PHP : SQL Relay )
  버퍼를 활용하여, 멀티쿼리 적용하여 디버세션 수 줄 이기 ( 더욱 빠른 속도가 남)

  (참고. 현시스템을 거의 그대로 쓰기 위한 방법은, 에이전트와 리퍼러 값을 접속자 정보에서 읽어와서 curl 로 다시 요청하기 )

DB ( 최소 2대. 이건 구축 해본 사람만이 )
 DB 서버를 1년내내 끄지 못하고 있는데, DB 서버 한대를 꺼도 되게하기
 자료 백업되고는있으나, 안정성을 위해서 Replication 하여 2대로 운영
 DB 서버가 죽어 있다면 ?
   미들웨어에서의 자료 2중화로, 캐쉬서버로 작동이 가능.

Cache ( 최소 1대 )
  자료 이중화를 위한 것.

포스트백 ( 2대 연결 )
 REQUEST 로그 남기기 ( DB 죽어도 로그 남게 웹서버에서 남기기)
 uniqid 값 온것으로 redis 에서 검색. 없으면 RDBMS 에 검색. 없으면 파일예외 로그남기기
 요청은 있었으나, 완료가 되지 않은 내용에 대해서는 예외 로그 남기고 후처리 ( PHP )

기타 관리
  예외처리된 자료 검토 기능 ( 매일 반수동 )
  access_log 와 캐쉬서버와 RDBMS 서버가 자료가 다른지 분석 ( 매일 반수동 )

이와 같이 클릭과 미들웨어를 따로 분리만 한다면, 어떠한 서버가 다운이 되더라도 운영이 가능하다 판단.
남은 위험은 페이스북 도메인네임 짤리는 것을 대비.