redis+mysql+quartz 일종 의 보너스 발송 기능 의 실현

개요:
이 글 은 주로 반년 전에 개 발 된 보너스 모듈 을 정리 하고 그 중의 주요 한 디자인 사상 과 구체 적 인 실현 방안 을 소개 하 는 것 입 니 다.만약 에 디자인 과 실현 상의 결함 이 있 거나 구멍 이 있 으 면 비판 하고 지적 해 주 십시오!
보너스 기능 은 모두 가 잘 알 고 있 습 니 다.그러면 여기 서 간단하게 보너스 기능 에 대해 설명 하 겠 습 니 다. 
기능 설명:보너스 업무 의 주요 기능 은 네 부분 을 포함 하 는데 그것 이 바로 보너스 발송,보너스 수신,보너스 회수,그리고 보너스 기록 조회 이다.
1)보너스 발송:발송 자 계좌->보너스 중간 층
2)보너스 수령:보너스 중간 층->수령 자 계 정
3)보너스 회수:보너스 중간 층 에 보너스 가 24 시간 이상 남아 있 으 면 회수,보너스 중간 층->발송 자 계 정
기능 설명 을 대충 알 고 나 면 그 다음은 실현 방안 입 니 다. 
먼저 디자인 절 차 를 제시 하고 이 부분 은 보너스 발송,보너스 수신,보너스 회수 절 차 를 순서대로 분석 할 것 이다.
1.설계 절차
먼저 보너스 발송 기능 입 니 다.단체 보 너 스 를 예 로 들 면 그 절차 도 는 다음 과 같 습 니 다.

그림 1 보너스 발송 절차 도
먼저,고 스 분 포 를 바탕 으로 금액 100 을 무 작위 로 8 부 로 분배 한 다음 에 이 8 개의 데 이 터 를 redis 캐 시 대기 열(list)에 저장 하고 대기 열의 만 료 시간 을 24h 로 설정 합 니 다.보 너 스 를 뺏 을 때 중복 뺏 기 문제 가 발생 하 는 것 을 감안 하여 중복 제거 방안 은 redis 캐 시 에서 분 배 된 집합(set)을 유지 하 는 것 입 니 다.집합 에는 보 너 스 를 받 은 사용자 ID 가 저 장 됩 니 다.또한 대량의 사용자 가 동시에 보 너 스 를 빼 앗 는 상황 에서 최적화 측면 에서 볼 때 일정한 제한 역할 을 하기 위해 데이터 베이스 에 대한 방문 압력 을 줄인다(이런 상황 을 고려 하면 한 시간 동안 대량의 사용자 가 보 너 스 를 빼 앗 고 보 너 스 를 이미 분배 한 시간 후에 오 는 요 구 는 데이터 베이스 에 일정한 방문 압력 을 가 져 올 것 이다).그 방법 은 redis 캐 시 에서 보너스 가 분 배 된 태그(key-value)를 유지 하고 0(분 배 된 것)/1(분 배 된 것)두 가지 상 태 를 유지 하여 일정한 흐름 제한 역할 을 합 니 다.
캐 시 차원 에 이 어 데이터베이스 차원 입 니 다.MySQL 에 있 는 보너스 발송 표(accountcoin_records_user_coin_package_send)에서 기록 을 만 드 는 동시에 위 에서 고 스 분포 방법 으로 얻 은 8 개의 금액 을 보너스 분배 표(accountcoin_records_user_coin_package_assign)에서 분배 표 시 를 0(미분 배)으로 초기 화하 면 보너스 발송 의 전체 절차 가 완 료 됩 니 다.
그 다음 에 보너스 수신 기능 입 니 다.그 절차 도 는 다음 과 같 습 니 다.

그림 2 보너스 수신 절차 도
보 너 스 를 받 는 사람 이 보 너 스 를 빼 앗 으 려 면 먼저 일련의 검증 이 필요 합 니 다.이 검증 작업 은 redis 캐 시 와 MySQL 데이터베이스 에 있 는 데 이 터 를 바탕 으로 검증 해 야 합 니 다.주로 보 너 스 ID 에 대응 하 는 보 너 스 는 존재 하 는 지,보 너 스 는 이미 분배 되 었 는 지,보 너 스 는 기한 이 지 났 는 지,보너스 수신 자 는 보너스 등 을 중복 수령 할 지 여부 다.인증 이 통과 되면 이 사용 자 는 보 너 스 를 받 을 수 있 습 니 다.그 다음은 계 정 동기 화(보 너 스 중간 층->사용자 계 정,사무 처리)입 니 다.데이터 베 이 스 를 성공 적 으로 작 동 하면 보 너 스 를 받 을 수 있 습 니 다.그렇지 않 으 면 실패 합 니 다.이로써 보 너 스 는 전체 절 차 를 받 을 수 있 습 니 다.
마지막 으로 보너스 회수 기능 입 니 다.그 절차 도 는 다음 과 같 습 니 다.

그림 3 보너스 회수 절차 도
보너스 회 수 는 정기 적 인 스케줄 링 전략 으로 시 작 된 것 으로 시간 간격 이 5min 인 끊 임 없 는 폴 링 으로 MySQL 데이터 베 이 스 를 방문 하여 회수 해 야 할 보너스(보너스 가 보너스 중간 층 에 24h 를 초과 하고 보너스 가 분배 되 지 않 았 음)를 조회 합 니 다.회수 해 야 할 보너스 가 있 으 면 효율 적 인 고려 를 바탕 으로 다 중 스 레 드 방안 으로 회수 작업 을 합 니 다.모든 보너스 가 하나의 스 레 드 에 대해 정책 은 하나의 스 레 드,하나의 요청,하나의 사무(이 방안 은 회수 할 보너스 개수 가 많 지 않 은 경우 에 만 적 용 됩 니 다)입 니 다.(주의:회수 해 야 할 보너스 가 많 으 면 신청 라인 이 끊 이지 않 으 면 메모리 넘 침 문제 가 발생 할 수 있 습 니 다.이때 구체 적 인 문 제 를 구체 적 으로 분석 하면 생산자-소비자 모델 을 고려 할 수 있 습 니 다).분포 식 구조,원 격 호출,그 다음 에 보너스 회수 서버 가 보너스 회수 요청 을 받 은 후에 계 정 동기 화 와 보너스 상태 표시(회수 한 것 으로 표시)를 합 니 다.만약 에 데이터 베이스 업무 에 이상 이 생기 면 트 랜 잭 션 이 다시 굴 러 갑 니 다.이때 이 보 너 스 는 회수 에 성공 하지 못 하고 다음 5min 을 기 다 렸 다가 다시 회수 할 수 밖 에 없습니다.
여기까지 절 차 를 거의 소 개 했 습 니 다.그럼 데이터 모델 을 소개 하 겠 습 니 다.
2.데이터 모델
데이터 베 이 스 는 MySQL 을 사용 합 니 다.보너스 기록 을 지속 적 으로 저장 하여 보너스 분배 기록 과 후기 기록 조회 에 사용 합 니 다.보너스 분배 데이터 모델 은 다음 그림 과 같다.

그림 4 보너스 분배 데이터 모델
그림 4 에서 일부 중요 한 데이터 정 보 를 보 여 주 었 다.표 간 의 관 계 는 보너스 ID 로 이 루어 진 것 이 고 보너스 기록 과 상태 표지 그림 에 표 시 된 것 이 므 로 일일이 소개 하지 않 는 다.
데이터 베이스 차원 에서 보 너 스 를 받 는 기능 에 높 은 병발 문제 가 존재 합 니 다.다음은 병발 을 어떻게 처리 하 는 지 간단하게 소개 하 겠 습 니 다.
3.동시 처리
높 은 병발 문 제 를 어떻게 처리 합 니까?
분석:
우선,보너스 금액 은 redis 캐 시 대기 열 에 저장 되 어 있 기 때문에 redis 는 단일 스 레 드 이기 때문에 보 너 스 를 받 는 단계 에서 병발 문제 가 존재 하지 않 습 니 다.
그리고 다음 단 계 는 MySQL 데이터베이스 의 일련의 update 작업 입 니 다.높 은 병발 문제 가 존재 합 니 다.
마지막 으로 기록 저장 입 니 다.insert 작업 도 병행 문제 가 없습니다.
데이터베이스 에서 update 작업 은 주로 낙관적 인 자물쇠 와 X 자물쇠 두 가지 방식 으로 데이터 의 일치 성 을 확보한다.
4.동시 테스트
한 동안 의 동시 다발 테스트 에서 테스트 를 통과 하면 데이터 가 일치 하지 않 는 문제 가 발생 하지 않 고 보너스 회수 기능 도 정상적으로 진행 할 수 있다.
현재 병발 에 있어 서 는 적어도 같은 시각 병발 량 이 3000 인 보너스 쟁탈 작업 을 지원 하 는 데 문제 가 없 을 것 이다.
결론 적 으로 능력 과 기술 이 유한 하기 때문에 현재 의 방안 은 기본적으로 사용 자 량 이 큰 응용 장면 이 아니 라 후기 에 사용자 의 양 이 증가 함 에 따라 더욱 최 적 화 될 것 이다.
읽 어 주 셔 서 감사합니다. 여러분 에 게 도움 이 되 기 를 바 랍 니 다.본 사이트 에 대한 여러분 의 지지 에 감 사 드 립 니 다!