亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

PHP仿微信發(fā)紅包領(lǐng)紅包效果

 更新時間:2016年10月30日 16:20:45   作者:andyChan  
最近項目開發(fā)要求實現(xiàn)紅包功能,仿微信(不含留言),但只能使用余額發(fā)紅包。下面小編給大家分享PHP仿微信發(fā)紅包領(lǐng)紅包效果,感興趣的朋友一起看看吧

近期項目需要在聊天的基礎(chǔ)上新增紅包功能,需求:仿微信(不含留言),但只能使用余額發(fā)紅包。于是多次使用微信紅包,了解各種交互界面及業(yè)務(wù)需求,如展示信息、分類(個人,群普通,群拼手氣)、個數(shù)限制(100)、金額限制(200)、過期時間(24小時)等等,然后著手開發(fā),下面提及的基本全是提供給app端的接口,畢竟我是phper。

一、設(shè)計數(shù)據(jù)表如下

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 '發(fā)放對象(用戶或群id)',
`pay_status` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '支付狀態(tài):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 '個數(shù)',
`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 '是否經(jīng)過cli退款處理:0否,1是',
`expend_time` mediumint(1) unsigned NOT NULL DEFAULT '0' COMMENT '領(lǐng)取消耗時間',
`add_time` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '創(chuàng)建時間',
`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='紅包發(fā)放表';
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 '領(lǐng)取人id',
`money` decimal(10,2) unsigned NOT NULL DEFAULT '0.0' COMMENT '領(lǐng)取金額',
`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 '領(lǐng)取時間',
PRIMARY KEY (`id`),
KEY `rp_id` (`rp_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='紅包領(lǐng)取日志表';

二、發(fā)紅包

由于支付成功之后,紅包就馬上發(fā)到聊天界面了,所以在左圖“塞錢進紅包”時,就把紅包信息插入 red_packet 表(支付狀態(tài)未支付),并分配好金額、計算手氣打亂后插入 red_packet_log 表(領(lǐng)取人和領(lǐng)取時間為空),右圖“確認支付”成功之后,更新 red_packet 表的支付狀態(tài),然后發(fā)出紅包。

三、領(lǐng)紅包(這里只針對群紅包進行分析)

領(lǐng)紅包的各種前提校驗請自己腦補,這里說一個搶群紅包的并發(fā)問題(群里的幾十個人搶幾個紅包),引入MQ來解決。在發(fā)紅包的時候,先把紅包個數(shù)依次寫入MQ,比如發(fā)3個紅包,就依次寫入1、2、3。搶紅包的時候從MQ取值,取得到數(shù)字說明你是第幾個搶到紅包,對應(yīng) red_packet_log 表里的第幾個紅包,接下來的就是更新 red_packet_log 表的領(lǐng)取人和領(lǐng)取時間,以及余額加錢以及記流水等業(yè)務(wù)處理了,然后返回領(lǐng)取結(jié)果;取不到數(shù)字的當(dāng)然就說明沒有搶到紅包,直接出“手慢了”的界面。前期有考慮把 red_packet_log 表的主鍵寫入MQ,可以省去排序拿第幾條log記錄,但這樣會讓“領(lǐng)取消耗時間”這個字段的更新更加麻煩;采用MQ存數(shù)字,則可以直接比對是否是最后一個紅包(取到的數(shù)字等與紅包個數(shù)),然后更新消耗時間。

微信紅包的領(lǐng)取結(jié)果頁(即查看手氣頁)有很多種:單個和群結(jié)果不一樣,發(fā)紅包的人和領(lǐng)紅包的人看到的也不一樣,單個和群紅包過期之后提示不一樣等等,這里不一一列舉,基本都是根據(jù)界面查數(shù)據(jù)庫而已。

四、需求變更,新增第三方支付

說到第三方支付,就要提及同步和異步回調(diào),還有回調(diào)時間差。app端在同步回調(diào)成功的時候,就會把紅包發(fā)出去了(app端的支付同步回調(diào)是直接調(diào)用callback的),如果此時異步回調(diào)慢了一兩秒,那么用戶就會搶到這個支付狀態(tài)為0的紅包。如果說讓app端調(diào)用長連接接口去查異步回調(diào)是否已經(jīng)成功,再發(fā)出紅包,則用戶體驗比較差。

# 引入中間狀態(tài)
ALTER TABLE `red_packet`
MODIFY COLUMN `pay_status` tinyint(1) UNSIGNED NOT NULL DEFAULT 0 COMMENT '支付狀態(tài):0未支付,1已支付,2等待到賬' AFTER `for_id`,
ADD COLUMN `pay_type` tinyint(1) NOT NULL DEFAULT 0 COMMENT '支付方式:0未知,1支付寶,2微信,3銀聯(lián)' 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`;

用戶搶到紅包的時候,根據(jù) pay_status 來決定 is_into_account 的值;

同步回調(diào)到app端時,調(diào)用接口把支付狀態(tài) pay_status 變?yōu)?;

異步回調(diào)到服務(wù)端時,則把支付狀態(tài) pay_status 變?yōu)?,并查出 is_into_account=1 的 red_packet_log 記錄進行處理。

但是上面這三步都要對 red_packet 的查詢進行 FOR UPDATE 操作,不然會有執(zhí)行時間和順序問題,導(dǎo)致部分 red_packet_log 記錄未到賬 is_into_account=0;另外鎖機制還會使得用戶搶紅包時變得很慢,因為要等鎖釋放。


改進如下:(全程不 FOR UPDATE)

用戶搶到紅包的時候,根據(jù) pay_status 來決定 is_into_account 的值;

同步回調(diào)到app端時,調(diào)用接口把支付狀態(tài) pay_status 變?yōu)?;

異步回調(diào)到服務(wù)端時,則把支付狀態(tài) pay_status 變?yōu)?,并把紅包id(red_packet主鍵)放入MQ;

后臺自動腳本,從MQ拿到紅包id之后,把該紅包 is_into_account=0 的記錄進行處理,然后再延遲5秒把紅包id再次寫入MQ,進行二次處理,確保數(shù)據(jù)全部到賬。

五、紅包過期退還

這里就一個自動腳本,根據(jù) red_packet 表的 pay_time 判斷是否超過24小時且沒領(lǐng)完的錢,退回用戶余額。

相關(guān)文章

最新評論