PHP 가짜 위 챗 보너스 수령 효과

최근 프로젝트 는 채 팅 을 바탕 으로 보너스 기능 을 추가 해 야 합 니 다.수요:위 챗(댓 글 포함 하지 않 음)을 모방 하지만 잔액 으로 만 보 너 스 를 보 낼 수 있 습 니 다.그래서 여러 번 위 챗 보 너 스 를 사용 하여 각종 상호작용 인터페이스 와 업무 수 요 를 파악 했다.예 를 들 어 전시 정보,분류(개인,군 일반,군 합작),개수 제한(100),금액 제한(200),기한 이 지난 시간(24 시간)등 이다.그리고 개발 에 착수 했다.아래 에 언급 된 기본 은 모두 app 엔 드 에 제공 하 는 인터페이스 이다.왜냐하면 나 는 phoper 이기 때문이다.
1.디자인 데이터 시트 는 다음 과 같다.

CREATE TABLE `red_packet` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`user_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '  id',
`for_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '    （    id）',
`pay_status` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '    ：0   ，1   ',
`type` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '  ：1、  ，2、   ，3、    ',
`intro` varchar(255) NOT NULL DEFAULT '' COMMENT '  ',
`number` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '  ',
`total_money` decimal(10,2) unsigned NOT NULL DEFAULT '0.0' COMMENT '   ',
`single_money` decimal(10,2) unsigned NOT NULL DEFAULT '0.0' COMMENT '      （      0）',
`return_money` decimal(10,2) unsigned NOT NULL DEFAULT '0.0' COMMENT '    ',
`is_cli_handle` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '    cli    ：0 ，1 ',
`expend_time` mediumint(1) unsigned NOT NULL DEFAULT '0' COMMENT '      ',
`add_time` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '    ',
`pay_time` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '    ',
PRIMARY KEY (`id`),
KEY `user_id` (`user_id`),
KEY `pay_status` (`pay_status`),
KEY `pay_time` (`pay_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='     ';
CREATE TABLE `red_packet_log` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`rp_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '  id',
`user_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '   id',
`money` decimal(10,2) unsigned NOT NULL DEFAULT '0.0' COMMENT '    ',
`is_good` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '      ：0 ，1 ',
`add_time` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '    ',
`update_time` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '    ',
PRIMARY KEY (`id`),
KEY `rp_id` (`rp_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='       ';

보너스

지불 이 성공 한 후,보 너 스 는 바로 채 팅 창 에 발송 되 었 기 때문에,왼쪽 그림 에서"보 너 스 를 넣 기"를 찍 을 때,보 너 스 를 red 에 삽입 합 니 다.패 킷 시트(지불 상태 미 지급),금액 분배,계산 운 이 흐 트 러 진 후 red 삽입packet_log 표(수령 자 와 수령 시간 이 비어 있 음),오른쪽 그림"결제 확인"성공 후 red 업데이트패 킷 시트 의 지불 상태 에서 보 너 스 를 보 냅 니 다.
3.보너스 수령(여 기 는 단체 보너스 만 분석)


보 너 스 를 받 는 각종 전제 검 사 는 자신의 뇌 보 를 하 세 요.여기 서 보 너 스 를 빼 앗 는 병발 문제(군 안의 몇 십 명 이 보 너 스 를 빼 앗 는 것)를 말 하고 MQ 를 도입 하여 해결 합 니 다.보 너 스 를 보 낼 때 먼저 보 너 스 를 순서대로 MQ 에 기록 합 니 다.예 를 들 어 보 너 스 를 3 개 보 내 면 1,2,3 을 순서대로 기록 합 니 다.보 너 스 를 뺏 을 때 MQ 에서 값 을 얻 으 면 숫자 는 당신 이 몇 번 째 로 보 너 스 를 뺏 었 는 지 설명 합 니 다.red 에 대응 합 니 다.packet_로그 표 의 몇 번 째 보너스,다음은 레 드 업데이트packet_로그 표 의 수령 자 와 수령 시간,그리고 잔액 에 돈 을 더 하고 흐 르 는 물 등 업 무 를 처리 한 다음 에 수령 결 과 를 되 돌려 줍 니 다.숫자 를 얻 지 못 한 것 은 당연히 보 너 스 를 빼 앗 지 못 하고 바로'손 이 느 려 졌 다'는 화면 을 내 는 것 을 의미한다.초기 에 레 드 를...packet_log 표 의 메 인 키 를 MQ 에 기록 하면 정렬 을 줄 이 고 몇 번 째 log 기록 을 가 져 올 수 있 지만'수령 소모 시간'이라는 필드 의 업 데 이 트 를 더욱 번 거 롭 게 할 수 있 습 니 다.MQ 메모리 숫자 를 사용 하면 마지막 보너스 인지(받 은 숫자 등 보너스 개수)를 직접 비교 한 다음 에 업데이트 하 는 데 걸 리 는 시간 을 업데이트 할 수 있 습 니 다.
위 챗 보너스 수령 결과 페이지(즉,핸드폰 페이지 를 보 는 것)에는 여러 가지 가 있 습 니 다.단체 와 단체 결과 가 다 르 고 보 너 스 를 보 낸 사람과 보 너 스 를 받 은 사람 이 보 는 것 도 다 릅 니 다.단체 보 너 스 는 기한 이 지나 면 알림 이 다 릅 니 다.여 기 는 일일이 열거 하지 않 고 대체적으로 경계 에 따라 데이터 베 이 스 를 검사 할 뿐 입 니 다.
4.수요 변경,제3자 지불 추가
제3자 지불 하면 동기 화 와 비동기 리 셋,그리고 리 셋 시간 차 를 언급 해 야 한다.app 엔 드 는 동기 리 셋 에 성공 할 때 보 너 스 를 보 냅 니 다.(app 엔 드 의 지불 동기 리 셋 은 callback 을 직접 호출 합 니 다)이때 비동기 리 셋 이 1,2 초 느 려 지면 사용 자 는 이 지불 상태 가 0 인 보 너 스 를 빼 앗 을 것 입 니 다.만약 에 app 측 에 긴 연결 인 터 페 이 스 를 호출 하여 비동기 반전 이 성공 적 인지 확인 하고 보 너 스 를 보 내 면 사용자 체험 이 비교적 좋 지 않 습 니 다.

#       
ALTER TABLE `red_packet`
MODIFY COLUMN `pay_status` tinyint(1) UNSIGNED NOT NULL DEFAULT 0 COMMENT '    ：0   ，1   ，2    ' AFTER `for_id`,
ADD COLUMN `pay_type` tinyint(1) NOT NULL DEFAULT 0 COMMENT '    ：0  ，1   ，2  ，3  ' AFTER `pay_status`,
ADD COLUMN `trade_no` varchar(30) NOT NULL DEFAULT '' COMMENT '        ' AFTER `pay_type`;
ALTER TABLE `red_packet_log`
ADD COLUMN `is_into_account` tinyint(1) UNSIGNED NOT NULL DEFAULT 0 COMMENT '    ：0 ，1 ' AFTER `is_good`;

사용자 가 보 너 스 를 빼 앗 았 을 때 pay 에 따라status 로 is 결정into_account 의 값;
app 엔 드 로 동기 화 할 때 인터페이스 로 결제 상 태 를 paystatus 가 2 로 변 함;
비동기 로 서버 로 되 돌 릴 때 지불 상태 paystatus 가 1 로 변 하고 isinto_account=1 의 redpacket_로그 기록 처리.
하지만 위의 세 단 계 는 모두 redpacket 조 회 는 FOR UPDATE 작업 을 진행 합 니 다.그렇지 않 으 면 실행 시간 과 순서 문제 가 발생 하여 일부 redpacket_로그 기록 미 입금 isinto_account=0；또한 자물쇠 메커니즘 은 사용자 가 보 너 스 를 빼 앗 을 때 매우 느 려 지게 할 수 있다.왜냐하면 자물쇠 가 풀 릴 때 까지 기 다 려 야 하기 때문이다.
개선 사항 은 다음 과 같 습 니 다.(전 과정 은 업 데 이 트 를 위 한 것 이 아 닙 니 다)
사용자 가 보 너 스 를 빼 앗 았 을 때 pay 에 따라status 로 is 결정into_account 의 값;
app 엔 드 로 동기 화 할 때 인터페이스 로 결제 상 태 를 paystatus 가 2 로 변 함;
비동기 로 서버 로 되 돌 릴 때 지불 상태 paystatus 를 1 로 바 꾸 고 보너스 id(redpacket 메 인 키)MQ 넣 기;
백 스테이지 자동 스 크 립 트,MQ 에서 보너스 id 를 받 은 후 이 보너스 isinto_account=0 의 기록 을 처리 한 후 5 초 지연 하여 보너스 id 를 다시 MQ 에 기록 하고 2 차 처 리 를 하여 데이터 가 모두 장부 에 들 어 갈 수 있 도록 합 니 다.
5.보너스 기한 이 지나 면 환불
여기 자동 스 크 립 트 하나 있 습 니 다.redpacket 표 의 paytime 은 24 시간 이 넘 고 다 받 지 못 한 돈 을 판단 하여 사용자 잔액 을 돌려 줍 니 다.