PHP che imita l'effetto di invio e ricezione delle buste di denaro di WeChat

Il progetto recente richiede la funzione dei pacchetti rossi basata sulla chat, esigenza: imitazione di WeChat (senza messaggi), ma solo può utilizzare il saldo per inviare pacchetti rossi. Quindi è stato utilizzato più volte il pacchetto rosso di WeChat, per comprendere vari interfacce di interazione e esigenze aziendali, come la visualizzazione delle informazioni, la classificazione (individuale, gruppo comune, gruppo a sorte), il limite di numero (100), il limite di importo (200), il tempo di scadenza (24 ore) ecc., poi ha iniziato a sviluppare, il che viene menzionato di seguito è tutto l'interfaccia fornita all'app, perché sono un phper.

Primo, il progettazione del database come segue

CREATE TABLE `red_packet` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`user_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'ID utente'
`for_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Oggetto di emissione (ID utente o gruppo)'
`pay_status` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT 'Stato di pagamento: 0 non pagato, 1 pagato'
`type` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT 'Tipo: 1, individuale, 2, gruppo comune, 3, gruppo a sorte'
`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 '支付时间',

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',

Le precondizioni di verifica per prelevare il pacchetto di denaro devono essere pensate autonomamente, qui si introduce un problema di concorrenza per prelevare il pacchetto di denaro di gruppo (decine di persone nel gruppo prelevano diversi pacchetti di denaro), si introduce l'MQ per risolvere. Quando si invia il pacchetto di denaro, inserisci prima il numero di pacchetti di denaro in sequenza nell'MQ, ad esempio, se si inviano 3 pacchetti di denaro, si inseriscono 1, 2, 3 in sequenza. Quando si preleva il pacchetto di denaro, si preleva il valore dall'MQ, se si ottiene un numero, significa che sei il numero X a prelevare il pacchetto di denaro, corrispondente al numero X del pacchetto di denaro nel red_packet_log tabella, poi aggiornare la tabella red_packet_log per l'utente che preleva e l'ora di prelievo, e aggiungere denaro e registrare il flusso di denaro ecc., poi restituire il risultato di prelievo; se non si ottiene un numero, naturalmente, significa che non si è prelevato il pacchetto di denaro, esce direttamente l'interfaccia

La pagina di risultato della raccolta di pacchetti di denaro WeChat (cioè la pagina di visualizzazione del sorteggio) ha molte varietà: i risultati individuali e di gruppo sono diversi, chi invia il pacchetto di denaro e chi lo raccoglie vedono cose diverse, i messaggi di scadenza dei pacchetti di denaro individuali e di gruppo sono diversi, ecc., non elenco uno per uno, di solito è sufficiente consultare il database in base all'interfaccia.

Quarto, cambiamento di esigenze, aggiunta del pagamento tramite terzi

Quando si parla di pagamento tramite terzi, si deve menzionare le callback同步 e asincrone, nonché il differenza di tempo delle callback. Quando l'app同步amente richiama con successo la callback, l'app invia il pacchetto dell'aria (la callback di pagamento同步 dell'app è una chiamata diretta a callback), se in questo momento la callback asincrona è lenta di un paio di secondi, allora l'utente può prendere questo pacchetto dell'aria con lo stato di pagamento 0. Se si dice che l'app richiami l'interfaccia di connessione a lungo termine per verificare se la callback asincrona è stata eseguita con successo prima di inviare il pacchetto dell'aria, l'esperienza utente è piuttosto scarsa.

# Introduzione a uno stato intermedio
MODIFICA TABELLA `red_packet`
MODIFICA COLONNA `pay_status` tinyint(1) UNSIGNED NOT NULL DEFAULT 0 COMMENT 'Stato di pagamento: 0 Non pagato, 1 Pagato, 2 In attesa di contabilizzazione' DOPPIA `for_id`,
MODIFICA COLONNA `pay_type` tinyint(1) NOT NULL DEFAULT 0 COMMENT 'Metodo di pagamento: 0 Sconosciuto, 1 Alipay, 2 WeChat, 3 UnionPay' DOPPIA `pay_status`,
AGGIUNGI COLONNA `trade_no` varchar(30) NOT NULL DEFAULT '' COMMENT 'Numero di transazione del terzo pagamento' DOPPIA `pay_type`;
MODIFICA TABELLA `red_packet_log`
AGGIUNGI COLONNA `is_into_account` tinyint(1) UNSIGNED NOT NULL DEFAULT 0 COMMENT 'Se è stato contabilizzato: 0 No, 1 Sì' DOPPIA `is_good`;

Quando l'utente ruba il pacchetto di denaro, la valore di is_into_account viene determinato in base al pay_status;

Quando la callback sincrona viene inviata all'app, viene chiamata l'interfaccia per cambiare lo stato di pagamento pay_status in 2;

Quando la callback asincrona viene inviata al server, viene cambiato lo stato di pagamento pay_status in 1 e vengono elaborati i record di red_packet_log con is_into_account=1.

Ma questi tre passaggi devono eseguire l'operazione di query FOR UPDATE su red_packet, altrimenti ci saranno problemi di tempo di esecuzione e ordine, causando che alcuni record di red_packet_log non siano accreditati is_into_account=0; Inoltre, il meccanismo di locking rende l'azione di rubare il pacchetto di denaro dell'utente molto lenta, perché deve aspettare che il lock venga rilasciato.

Miglioramenti come segue: (nessun FOR UPDATE in tutto il processo)

Quando l'utente ruba il pacchetto di denaro, la valore di is_into_account viene determinato in base al pay_status;

Quando la callback sincrona viene inviata all'app, viene chiamata l'interfaccia per cambiare lo stato di pagamento pay_status in 2;

Quando la callback asincrona viene inviata al server, viene cambiato lo stato di pagamento pay_status in 1 e l'id del pacchetto di denaro (prima chiave di red_packet) viene messo nel MQ;

Script automatico nel backend che, dopo aver ricevuto l'id del pacchetto di denaro dal MQ, elabora i record con is_into_account=0 del pacchetto di denaro e poi scrive di nuovo l'id del pacchetto di denaro nel MQ dopo 5 secondi per una seconda elaborazione, assicurando che tutti i dati siano accreditati.

V. Rimborsabilità dei pacchetti di denaro

Qui c'è uno script automatico che, in base al campo pay_time della tabella red_packet, determina se il denaro non ancora riscosso è superiore a 24 ore e lo restituisce al saldo dell'utente.

Dichiarazione: il contenuto di questo articolo è stato prelevato da Internet, il diritto d'autore è della proprietà del rispettivo autore, il contenuto è stato contribuito autonomamente dagli utenti di Internet e caricato autonomamente, il sito web non detiene i diritti di proprietà, non è stato elaborato manualmente e non assume responsabilità legali correlate. Se trovi contenuti sospetti di violazione del copyright, ti preghiamo di inviare una e-mail a: notice#oldtoolbag.com (al momento dell'invio dell'e-mail, sostituisci # con @) per segnalare il problema e fornire prove pertinenti. Una volta verificata, il sito eliminerà immediatamente i contenuti sospetti di violazione del copyright.