做一个支付

这个系统可以用作小型支付系统，也可以用做第三方应用接入开放平台时的支付流水系统。

原来的需求比较负责，我简化一点说:

1.对每个应用，对外需要提供 获取余额，支付设备，充值 等接口

2.后台有程序，每月一号进行清算

3.账户可以被冻结

4.需要记录每一次操作的流水，每天的流水都要和发起方进行对账

针对上面的需求，我们设置如下数据库:

[sql] view plaincopy

  1. CREATE TABLE `app_margin`.`tb_status` (   

  2.    `appid` int(10) UNSIGNED NOT NULL,   

  3.    `freeze` int(10) NOT NULL DEFAULT 0,   

  4.    `create_time` datetime NOT NULL,   

  5.    `change_time` datetime NOT NULL,   

  6.    PRIMARY KEY (`appid`)   

  7. ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

  8. CREATE TABLE `app_margin`.`tb_account_earn` (   

  9.    `appid` int(10) UNSIGNED NOT NULL,   

  10.    `create_time` datetime NOT NULL,   

  11.    `balance` bigint(20) NOT NULL, 

  12.    `change_time` datetime NOT NULL,   

  13.    `seqid` int(10) NOT NULL DEFAULT 500000000,   

  14.    PRIMARY KEY (`appid`)   

  15. ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

  16. CREATE TABLE `app_margin`.`tb_bill` (   

  17.    `id` int AUTO_INCREMENT NOT NULL,   

  18.    `bill_id` int(10) NOT NULL,   

  19.    `amt` bigint(20) NOT NULL,   

  20.    `bill_info` text,   

  21.    `bill_user` char(128),   

  22.    `bill_time` datetime NOT NULL,   

  23.    `bill_type` int(10) NOT NULL,   

  24.    `bill_channel` int(10) NOT NULL, 

  25.    `bill_ret` int(10) NOT NULL,   

  26.    `appid` int(10) UNSIGNED NOT NULL,   

  27.    `old_balance` bigint(20) NOT NULL,   

  28.    `price_info` text,   

  29.    `src_ip` char(128),   

  30.    PRIMARY KEY (`id`),   

  31.    UNIQUE KEY `unique_bill` (`bill_id`,`bill_channel`)   

  32. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;   

  33. CREATE TABLE `app_margin`.`tb_assign` (   

  34.    `id` int AUTO_INCREMENT NOT NULL,   

  35.    `assign_time` datetime NOT NULL,   

  36.    PRIMARY KEY (`id`)   

  37. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;   

  38. CREATE TABLE `app_margin`.`tb_price` (   

  39.    `name` char(128) NOT NULL,   

  40.    `price` int(10) NOT NULL,   

  41.    `info` text NOT NULL,   

  42.    PRIMARY KEY (`name`)   

  43. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;   

  44. CREATE TABLE `app_margin`.`tb_applock` (   

  45.    `appid` int(10) UNSIGNED NOT NULL,   

  46.    `lock_mode` int(10) NOT NULL DEFAULT 0,   

  47.    `change_time` datetime NOT NULL,   

  48.    PRIMARY KEY (`appid`)   

  49. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;   

  50. INSERT `app_margin`.`tb_assign` (`id`,`assign_time`) VALUES (100000000,now());   

  详细解释如下:

  tb_status 应用的状态表。负责账户是否被冻结，账户的类型是什么（真实的需求是应用可能有两种账户，这里为简单所以没有列出）

      appid 应用id

      freeze 是否冻结

      create_time 创建时间

      change_time 最后一次修改时间

  tb_account_earn 应用的账户余额表

      appid 应用id

      balance 余额（单位为分，不要用小数存储，因为小数本身不精确；另外php要在64位机下才能支持bigint）

      create_time 创建时间

      change_time 最后一次修改时间

      seqid 操作序列号（防并发，每次update都会+1）

  tb_assign 分配流水id的表，tb_bill的bill_id必须是有tb_assign分配的

      id 自增id

      create_time 创建时间

  tb_bill 流水表。负责记录每一条操作流水，这里的bill_id不是主键，因为同一个bill_id可能会有支付和回滚两条流水

      id 自增序列号

      bill_id 流水号

      amt 操作的金额（这个是要区别正负的，主要是为了select all的时候可以直接计算出某段时间的金额变化）

      bill_info 操作的详细信息，比如3台webserver，2台db

      bill_user 操作用户

      bill_time 流水时间

      bill_type 流水类型，区分是加钱还是减钱

      bill_channel 流水来源，如充值，支付，回滚，结算还是其他

      bill_ret 流水的返回码，包括未处理、成功、失败，这里的逻辑会在后面讲解

      appid 应用id

      old_balance 操作发生前的账户余额

      price_info 记录操作发生时，记录被支付物品的单价

      src_ip 客户端ip

  tb_price 单价表，记录了机器的单价

      name 机器唯一标识

      price 价格

      info 描述

  tb_applock 锁定表，这是为了避免并发对某一个应用进行写操作设计的，具体的代码会在后面展示

      appid 应用id

      lock_mode 锁定状态。为0则为锁定，为1则为锁定

      change_time 最后一次修改时间

OK，库表设计出来之后，我们就来看一下最典型的几个操作.

一. 支付操作

我这里只列出了我目前实现的方式，可能不是最好的，但应该是最经济又满足需求的。

先说调用方这里，逻辑如下:

然后对应的支付系统内部逻辑如下（只列出支付操作，回滚逻辑差不多，流水检查是要检查对应的支付流水是否存在）:

常用的错误返回码可能如下就足够了:

[php] view plaincopy

  1. $g_site_error = array( 

  2.    -1 => '服务器繁忙', 

  3.    -2 => '数据库读取错误', 

  4.    -3 => '数据库写入错误', 

  5.    0 => '成功', 

  6.    1 => '没有数据', 

  7.    2 => '没有权限', 

  8.    3 => '余额不足', 

  9.    4 => '账户被冻结', 

  10.    5 => '账户被锁定', 

  11.    6 => '参数错误', 

  12. ); 

  1.    对于大于0的错误都算是逻辑错误，执行支付操作，调用方是不用记录流水的。因为账户并没有发生任何改变。

  2. 对于小于0的错误是系统内部错误，因为不知道是否发生了数据更改，所以调用方和支付系统都要记录流水。

  3. 对于等于0的返回，代表成功，两边也肯定要记录流水。

而在支付系统内部，之所以采用先写入流水，再进行账户更新的方式也是有原因的，简单来说就是尽量避免丢失流水。

最后总结一下，这种先扣钱，再发货，出问题再回滚的方式是一种模式；还有一种是先预扣，后发货，没有出问题则调用支付确认来扣款，出了问题就调用支付回滚来取消，如果预扣之后很长时间不做任何确认，那么金额会自动回滚。

二. 账户锁定的实现

这里利用了数据库的加锁机制，具体逻辑就不说了，代码如下:

[php] view plaincopy

  1. class AppLock 

  2. { 

  3.    function __construct($appid) 

  4.    { 

  5.        $this->m_appid = $appid; 

  6.        //初始化数据 

  7.        $this->get(); 

  8.    } 

  9.    function __destruct() 

  10.    { 

  11.        $this->free(); 

  12.    } 

  13.    public function alloc() 

  14.    { 

  15.        if ($this->m_bGot == true) 

  16.        { 

  17.            return true; 

  18.        } 

  19.        $this->repairData(); 

  20.        $appid = $this->m_appid; 

  21.        $ret = $this->update($appid,APPLOCK_MODE_FREE,APPLOCK_MODE_ALLOC); 

  22.        if ($ret === false) 

  23.        { 

  24.            app_error_log("applock alloc fail"); 

  25.            return false; 

  26.        } 

  27.        if ($ret <= 0) 

  28.        { 

  29.            app_error_log("applock alloc fail,affected_rows:$ret"); 

  30.            return false; 

  31.        } 

  32.        $this->m_bGot = true; 

  33.        return true; 

  34.    } 

  35.    public function free() 

  36.    { 

  37.        if ($this->m_bGot != true) 

  38.        { 

  39.            return true; 

  40.        } 

  41.        $appid = $this->m_appid; 

  42.        $ret = $this->update($appid,APPLOCK_MODE_ALLOC,APPLOCK_MODE_FREE); 

  43.        if ($ret === false) 

  44.        { 

  45.            app_error_log("applock free fail"); 

  46.            return false; 

  47.        } 

  48.        if ($ret <= 0) 

  49.        { 

  50.            app_error_log("applock free fail,affected_rows:$ret"); 

  51.            return false; 

  52.        } 

  53.        $this->m_bGot = false; 

  54.        return true; 

  55.    } 

  56.    function repairData() 

  57.    { 

  58.        $db = APP_DB(); 

  59.        $appid = $this->m_appid; 

  60.        $now = time(); 

  61.        $need_time = $now - APPLOCK_REPAIR_SECS; 

  62.        $str_need_time = date("Y-m-d H:i:s", $need_time); 

  63.        $db->where("appid",$appid);

  64.        $db->where("lock_mode",APPLOCK_MODE_ALLOC); 

  65.        $db->where("change_time <=",$str_need_time); 

  66.        $db->set("lock_mode",APPLOCK_MODE_FREE); 

  67.        $db->set("change_time","NOW()",false); 

  68.        $ret = $db->update(TB_APPLOCK); 

  69.        if ($ret === false) 

  70.        { 

  71.            app_error_log("repair applock error,appid:$appid"); 

  72.            return false; 

  73.        } 

  74.        return true; 

  75.    } 

  76.    private function get() 

  77.    { 

  78.        $db = APP_DB(); 

  79.        $appid = $this->m_appid; 

  80.        $db->where('appid', $appid);

  81.        $query = $db->get(TB_APPLOCK); 

  82.        if ($query === false) 

  83.        { 

  84.            app_error_log("AppLock get fail.appid:$appid"); 

  85.            return false; 

  86.        } 

  87.        if (count($query->result_array()) <= 0) 

  88.        { 

  89.            $applock_data = array( 

  90.                'appid'=>$appid, 

  91.                'lock_mode'=>APPLOCK_MODE_FREE, 

  92.            ); 

  93.            $db->set('change_time','NOW()',false); 

  94.            $ret = $db->insert(TB_APPLOCK, $applock_data); 

  95.            if ($ret === false) 

  96.            { 

  97.                app_error_log("applock insert fail:$appid"); 

  98.                return false; 

  99.            } 

  100.            //重新获取数据 

  101.            $db->where('appid', $appid); 

  102.            $query = $db->get(TB_APPLOCK); 

  103.            if ($query === false) 

  104.            { 

  105.                app_error_log("AppLock get fail.appid:$appid"); 

  106.                return false; 

  107.            } 

  108.            if (count($query->result_array()) <= 0) 

  109.            { 

  110.                app_error_log("AppLock not data,appid:$appid"); 

  111.                return false; 

  112.            } 

  113.        } 

  114.        $applock_data = $query->row_array(); 

  115.        return $applock_data; 

  116.    } 

  117.    private function update($appid,$old_lock_mode,$new_lock_mode) 

  118.    { 

  119.        $db = APP_DB(); 

  120.        $db->where('appid',$appid);

  121.        $db->where('lock_mode',$old_lock_mode); 

  122.        $db->set('lock_mode',$new_lock_mode); 

  123.        $db->set('change_time','NOW()',false); 

  124.        $ret = $db->update(TB_APPLOCK); 

  125.        if ($ret === false) 

  126.        { 

  127.            app_error_log("update applock error,appid:$appid,old_lock_mode:$old_lock_mode,new_lock_mode:$new_lock_mode"); 

  128.            return false; 

  129.        } 

  130.        return $db->affected_rows(); 

  131.    } 

  132.    //是否获取到了锁 

  133.    public $m_bGot = false; 

  134.    public $m_appid; 

  135. } 

  为了防止死锁的问题，获取锁的逻辑中加入了超时时间的判断，大家看代码应该就能看懂

三. 对帐逻辑

如果按照上面的系统来设计，那么对帐的时候，只要对一下两边成功（即bill_ret=0）的流水即可，如果完全一致那么账户应该是没有问题的，如果不一致，那就要去查问题了。

关于保证账户正确性这里，也有同事跟我说，之前在公司做的时候，是采取只要有任何写操作之前，都先取一下流水表中所有的流水记录，将amt的值累加起来，看得到的结果是否和余额相同。如果不相同应该就是出问题了。

select sum(amt) from tb_bill where appid=1;

  所以这也是为什么我在流水表中，amt字段是要区分正负的原因。

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 216,039评论 6赞 498
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 92,223评论 3赞 392
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 161,916评论 0赞 351
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 58,009评论 1赞 291
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 67,030评论 6赞 388
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 51,011评论 1赞 295
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,934评论 3赞 416
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,754评论 0赞 271
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 45,202评论 1赞 309
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,433评论 2赞 331
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,590评论 1赞 346
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 35,321评论 5赞 342
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,917评论 3赞 325
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,568评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,738评论 1赞 268
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,583评论 2赞 368
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,482评论 2赞 352

推荐阅读更多精彩内容