PHP 결제 시스템 설계 및 대표적인 사례(권장)
- 墨辰丷원래의
- 2018-06-01 15:56:021966검색
이 글에서는 주로 PHP 결제 시스템의 설계와 일반적인 사례를 자세히 소개합니다. 이는 소규모 결제 시스템으로 사용될 수도 있고, 타사 애플리케이션이 개방형 플랫폼에 연결될 때 결제 흐름 시스템으로 사용될 수도 있습니다. 친구들이 참고하면 됩니다
회사의 업무상 소액 결제 시스템을 구현하는 데 2주가 걸렸습니다. 비록 작은 규모이지만 계정 잠금, 거래 보장, 결제 등 필요한 모든 모듈을 갖추고 있습니다. 실행 화해 등 모두 완벽하게 구현되어 있고, 개발 과정 전반에 걸쳐 많은 경험이 축적되어 있습니다. 또한, 인터넷으로 검색해본 결과 대부분 실용성이 거의 없는 연구 논문이라 특별히 가져왔습니다. 이번에는 모두와 공유해 보세요.
본 시스템은 소액 결제 시스템으로 활용이 가능하며, 오픈 플랫폼에 타사 애플리케이션이 연결될 경우 결제 흐름 시스템으로 활용될 수 있습니다.
원래 수요는 더 책임이 있으므로 조금 단순화하겠습니다.
각 애플리케이션에 대해 잔액 확보, 결제 장비, 재충전 등과 같은 외부 인터페이스
백그라운드에 프로그램 및 청산이 있습니다. 매월 1일에 진행됩니다
계정이 동결될 수 있습니다
각 작업의 흐름을 기록해야 하며, 일일 흐름은 개시자와 조정되어야 합니다
위 요구 사항에 대응하여 우리는 다음을 설정합니다. 다음 데이터베이스를 올려보세요.
CREATE TABLE `app_margin`.`tb_status` ( `appid` int(10) UNSIGNED NOT NULL, `freeze` int(10) NOT NULL DEFAULT 0, `create_time` datetime NOT NULL, `change_time` datetime NOT NULL, PRIMARY KEY (`appid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_account_earn` ( `appid` int(10) UNSIGNED NOT NULL, `create_time` datetime NOT NULL, `balance` bigint(20) NOT NULL, `change_time` datetime NOT NULL, `seqid` int(10) NOT NULL DEFAULT 500000000, PRIMARY KEY (`appid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_bill` ( `id` int AUTO_INCREMENT NOT NULL, `bill_id` int(10) NOT NULL, `amt` bigint(20) NOT NULL, `bill_info` text, `bill_user` char(128), `bill_time` datetime NOT NULL, `bill_type` int(10) NOT NULL, `bill_channel` int(10) NOT NULL, `bill_ret` int(10) NOT NULL, `appid` int(10) UNSIGNED NOT NULL, `old_balance` bigint(20) NOT NULL, `price_info` text, `src_ip` char(128), PRIMARY KEY (`id`), UNIQUE KEY `unique_bill` (`bill_id`,`bill_channel`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_assign` ( `id` int AUTO_INCREMENT NOT NULL, `assign_time` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_price` ( `name` char(128) NOT NULL, `price` int(10) NOT NULL, `info` text NOT NULL, PRIMARY KEY (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_applock` ( `appid` int(10) UNSIGNED NOT NULL, `lock_mode` int(10) NOT NULL DEFAULT 0, `change_time` datetime NOT NULL, PRIMARY KEY (`appid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT `app_margin`.`tb_assign` (`id`,`assign_time`) VALUES (100000000,now());
자세한 설명은 다음과 같습니다.
tb_status 신청 현황 테이블입니다. 계정 동결 여부와 어떤 유형의 계정인지에 대한 책임(실제 요구 사항은 애플리케이션에 두 개의 계정이 있을 수 있으므로 단순화를 위해 여기에 나열하지 않음)
appid 애플리케이션 ID
동결 여부
create_time 생성 시간
change_time 마지막 수정 시간
tb_account_earn 애플리케이션 계정 잔액 테이블
appid 애플리케이션 ID
잔액 잔액(단위는 센트입니다. 소수점 자체가 정확하지 않으므로 소수점을 사용하여 저장하지 마세요. 또한 지원하려면 PHP가 64비트 시스템에 있어야 합니다. bigint)
create_time 생성 시간
change_time 마지막 수정 시간
seqid 작업 시퀀스 번호(동시성을 방지하기 위해 업데이트할 때마다 +1됨)
tb_sign 파이프라인 ID를 할당하는 테이블 tb_bill의 bill_id는 tb_sign
id로 할당되어야 합니다. increment id
create_time 생성 시간
tb_bill 파이프라인 테이블입니다. 각 작업 흐름을 기록하는 역할을 합니다. 동일한 bill_id에 결제 및 롤백이라는 두 가지 흐름이 있을 수 있기 때문입니다.
bill_id는 일련번호입니다. 작업량(양수와 음수를 구분해야 함), 주로 모두 선택 시 특정 기간 동안의 금액 변화를 직접 계산합니다.
bill_info 웹서버 3개, dbs 2개 등 작업에 대한 세부 정보
bill_user 작업 사용자
bill_time 청구 시간
bill_type 청구 유형, 차이점은 돈이 추가되거나 손실이 발생함
bill_channel 재충전, 결제, 롤백, 정산 등 거래 소스
bill_ret 다음을 포함한 거래의 반환 코드 미처리, 성공, 실패 로직은 나중에 설명하겠습니다
appid 애플리케이션 ID
old_balance 작업 발생 이전 계정 잔액
price_info 기록 작업 발생 시 유료 아이템의 단가를 기록
src_ip 클라이언트 ip
tb_price 단가 테이블 , 기계의 단가를 기록합니다
이름 기계 고유 식별자
가격 가격
정보 설명
tb_applock 잠금 테이블입니다. 이는 애플리케이션에 대한 동시 쓰기 작업을 방지하도록 설계되었으며 특정 코드는 나중에 표시됩니다.
appid 애플리케이션 ID
lock_mode 잠금 상태. 0이면 잠김, 1이면 잠김
change_time 마지막 수정 시간
자, 라이브러리 테이블이 디자인되면 가장 일반적인 동작을 살펴보겠습니다.
여기 있습니다. 현재 구현하는 방식만 나열했습니다. 최고는 아닐 수도 있지만 가장 경제적이고 요구 사항을 충족해야 합니다.
먼저 호출자에 대해 이야기해 보겠습니다. 로직은 다음과 같습니다.
그러면 해당 결제 시스템의 내부 로직은 다음과 같습니다. (결제 작업만 나열되며 롤백 로직은 유사하며 흐름 확인은 다음과 같습니다. 해당 결제 흐름이 있는지 확인):
일반적으로 사용되는 오류 반환 코드는 다음과 같이 충분할 수 있습니다.
$g_site_error = array( -1 => '服务器繁忙', -2 => '数据库读取错误', -3 => '数据库写入错误', 0 => '成功', 1 => '没有数据', 2 => '没有权限', 3 => '余额不足', 4 => '账户被冻结', 5 => '账户被锁定', 6 => '参数错误', );
对于大于0的错误都算是逻辑错误，执行支付操作，调用方是不用记录流水的。因为账户并没有发生任何改变。
对于小于0的错误是系统内部错误，因为不知道是否发生了数据更改，所以调用方和支付系统都要记录流水。
对于等于0的返回，代表成功，两边也肯定要记录流水。
而在支付系统内部，之所以采用先写入流水，再进行账户更新的方式也是有原因的，简单来说就是尽量避免丢失流水。
最后总结一下，这种先扣钱，再发货，出问题再回滚的方式是一种模式；还有一种是先预扣，后发货，没有出问题则调用支付确认来扣款，出了问题就调用支付回滚来取消，如果预扣之后很长时间不做任何确认，那么金额会自动回滚。
二. 账户锁定的实现
这里利用了数据库的加锁机制，具体逻辑就不说了，代码如下:
class AppLock
{
function __construct($appid)
{
$this->m_appid = $appid;
//初始化数据
$this->get();
}
function __destruct()
{
$this->free();
}
public function alloc()
{
if ($this->m_bGot == true)
{
return true;
}
$this->repairData();
$appid = $this->m_appid;
$ret = $this->update($appid,APPLOCK_MODE_FREE,APPLOCK_MODE_ALLOC);
if ($ret === false)
{
app_error_log("applock alloc fail");
return false;
}
if ($ret <= 0)
{
app_error_log("applock alloc fail,affected_rows:$ret");
return false;
}
$this->m_bGot = true;
return true;
}
public function free()
{
if ($this->m_bGot != true)
{
return true;
}
$appid = $this->m_appid;
$ret = $this->update($appid,APPLOCK_MODE_ALLOC,APPLOCK_MODE_FREE);
if ($ret === false)
{
app_error_log("applock free fail");
return false;
}
if ($ret <= 0)
{
app_error_log("applock free fail,affected_rows:$ret");
return false;
}
$this->m_bGot = false;
return true;
}
function repairData()
{
$db = APP_DB();
$appid = $this->m_appid;
$now = time();
$need_time = $now - APPLOCK_REPAIR_SECS;
$str_need_time = date("Y-m-d H:i:s", $need_time);
$db->where("appid",$appid);
$db->where("lock_mode",APPLOCK_MODE_ALLOC);
$db->where("change_time <=",$str_need_time);
$db->set("lock_mode",APPLOCK_MODE_FREE);
$db->set("change_time","NOW()",false);
$ret = $db->update(TB_APPLOCK);
if ($ret === false)
{
app_error_log("repair applock error,appid:$appid");
return false;
}
return true;
}
private function get()
{
$db = APP_DB();
$appid = $this->m_appid;
$db->where('appid', $appid);
$query = $db->get(TB_APPLOCK);
if ($query === false)
{
app_error_log("AppLock get fail.appid:$appid");
return false;
}
if (count($query->result_array()) <= 0)
{
$applock_data = array(
'appid'=>$appid,
'lock_mode'=>APPLOCK_MODE_FREE,
);
$db->set('change_time','NOW()',false);
$ret = $db->insert(TB_APPLOCK, $applock_data);
if ($ret === false)
{
app_error_log("applock insert fail:$appid");
return false;
}
//重新获取数据
$db->where('appid', $appid);
$query = $db->get(TB_APPLOCK);
if ($query === false)
{
app_error_log("AppLock get fail.appid:$appid");
return false;
}
if (count($query->result_array()) <= 0)
{
app_error_log("AppLock not data,appid:$appid");
return false;
}
}
$applock_data = $query->row_array();
return $applock_data;
}
private function update($appid,$old_lock_mode,$new_lock_mode)
{
$db = APP_DB();
$db->where('appid',$appid);
$db->where('lock_mode',$old_lock_mode);
$db->set('lock_mode',$new_lock_mode);
$db->set('change_time','NOW()',false);
$ret = $db->update(TB_APPLOCK);
if ($ret === false)
{
app_error_log("update applock error,appid:$appid,old_lock_mode:$old_lock_mode,new_lock_mode:$new_lock_mode");
return false;
}
return $db->affected_rows();
}
//是否获取到了锁
public $m_bGot = false;
public $m_appid;
}
为了防止死锁的问题，获取锁的逻辑中加入了超时时间的判断，大家看代码应该就能看懂
三. 对帐逻辑
如果按照上面的系统来设计，那么对帐的时候，只要对一下两边成功（即bill_ret=0）的流水即可，如果完全一致那么账户应该是没有问题的，如果不一致，那就要去查问题了。
关于保证账户正确性这里，也有同事跟我说，之前在公司做的时候，是采取只要有任何写操作之前，都先取一下流水表中所有的流水记录，将amt的值累加起来，看得到的结果是否和余额相同。如果不相同应该就是出问题了。
select sum(amt) from tb_bill where appid=1;
所以这也是为什么我在流水表中，amt字段是要区分正负的原因。
总结：以上就是本篇文的全部内容，希望能对大家的学习有所帮助。
相关推荐：
위 내용은 PHP 결제 시스템 설계 및 대표적인 사례(권장)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!