如何設計一個 payment processor

14417335 发表于 2019/04/10 22:49:56
查了查：微信支付在2018年的日均总支付交易量超过10亿次

10 0000 0000次
86400秒
11500次/秒

假设银行的API为：
boolean withdraw(acc...

美国公司很少有这个体量的支付需求，面试的时候还是要避免给自己挖坑。面试应该尽量从单机可以处理的数据量开始设计，然后再扩展。不过即使是10k的qps，也不算一个很高频的服务，最大的瓶颈应该是数据库的连接上限，这时候要考虑数据库sharding和读写分离。简单地用用户名sharding，将用户平均分布在不同的数据库里应该就可以了。反正只要知道sharding的策略总是能找回用户订单的。

ericLaw 发表于 2019-4-12 03:10
美国公司很少有这个体量的支付需求，面试的时候还是要避免给自己挖坑。面试应该尽量从单机可以处理的数据 ...

你说的很有道理。有个地方需要往细里走一走。数据库里存什么，是transaction的信息和一系列的状态。
因为wepay不应该是银行。就是一个中间商。而且这银行是多家的。比如A的是连着建行而B是人行。
所以我们的数据库里每个transaction的状态要经历这样一个过程：

initialized   表示我方已经收到A要买B的东西的请求 下一站：要么withdrawn，要么failed

withdrawn     表示钱已经由A的银行账户进入我方（wechat）的银行账号。
              下一站：要么depositfailed要么succeeded

depositfailed 表示钱从我方（wechat）的银行账号没能进入B的账号。
              下一站：要么depositfailed，这时钱从A那里已经进入我方（wechat）
               的银行账号需要继续retry把钱放入B的账号。要么succeeded，要么failed

succeeded     表示A的钱已经进入B的账号。交易成功。通知用户A和B

failed        A的钱没有进入B的账号。交易失败。通知用户A和B

14417335 发表于 2019/04/12 04:35:53


你说的很有道理。有个地方需要往细里走一走。数据库里存什么，是transaction的信息和一系列的状态。
因为wepay不应该是银行。就是一个中间商。而且这银行是多家的。比如A的是连着建行而B是...

银行的结算服务应该是异步的。银行的服务器应该只做一件事，就是把帐记下来，然后再通过异步服务来结算。毕竟对银行来说，不出错才是最重要的。

ericLaw 发表于 2019-4-12 03:10
美国公司很少有这个体量的支付需求，面试的时候还是要避免给自己挖坑。面试应该尽量从单机可以处理的数据 ...

user profile这种东西还是要放在dynamo这样的key value store里面吧

shuyangsheng 发表于 2019/04/12 14:32:05


user profile这种东西还是要放在dynamo这样的key value store里面吧

可以用，但是我认为没有什么特别的好处。用关系型数据库也可以。而且Dynamo是个eventually consistent的系统，一不小心又是给自己挖坑。。。

ericLaw 发表于 2019-4-12 07:27
银行的结算服务应该是异步的。银行的服务器应该只做一件事，就是把帐记下来，然后再通过异步服务来结算。 ...

银行的结算不应该是异步的。而必须是同步的。想象一下A账号没钱，可是B把油条给了他。

另外interview里可能不想，但是生产中，对于交易量的spikes不能轻视。微信支付2018年10亿次，虽然平均11500次/秒，但是早上，中午，下午和晚上应该是高发期。

shuyangsheng 发表于 2019-4-12 14:32
user profile这种东西还是要放在dynamo这样的key value store里面吧

能讲讲为什么你的直觉是应该放在cassandra这类key-value storage里吗？

ericLaw 发表于 2019-4-12 15:25
可以用，但是我认为没有什么特别的好处。用关系型数据库也可以。而且Dynamo是个eventually consistent的 ...

嗯仔细想了一下，我确实想多了，读写的并发要求都不高，没必要上key value store

14417335 发表于 2019/04/12 21:05:36


银行的结算不应该是异步的。而必须是同步的。想象一下A账号没钱，可是B把油条给了他。

另外interview里可能不想，但是生产中，对于交易量的spikes不能轻视。微信支付2018年10亿次...

我们把payment processor这个东西抛开不谈。你如果试过在银行转款，钱也不是马上到对方的账户的，它是有一个时间差的，尤其是跨行操作。但是你的账是不会乱的。所以我认为银行的结算是异步的。异步的原因可能是因为结算涉及大量的锁操作，还涉及到不同银行间的通信，同步的话性能会很差。所以是采取先记账后结算的方法。A的银行系统只要记住A要把钱交出去，至于B的银行晚一点知道B要收钱也是没有影响的。如果中间多了payment processor，好处就是如果双方都是payment的用户，那他们就能知道这笔交易的发生。
还有一个问题就是，虽然payment processor的访问量很高，但是银行不止一家，所以银行的服务器访问量是远低于payment的，很难跟着payment一起讨论。最起码不能把payment的访问量等同于银行服务器的访问量。

ericLaw 发表于 2019-4-13 05:26
我们把payment processor这个东西抛开不谈。你如果试过在银行转款，钱也不是马上到对方的账户的，它是有 ...

現在的銀行結算還不是同步的，所以才有 NSF, pending/withholding funds, 跟 actual balance 這些東西 哈哈哈

我們公司 back office 每天 end of day 都會 sftp 傳 bank file (fixed length file) 給幫我們處理 all EFT transfers 的銀行，裡頭每一行記錄著每一筆 fund transfer，然後有不同客戶不同銀行的 institution number, transit number, account number, amount 等等的資料。要是我們從客戶銀行裡扣錢，但是錢扣不成，他的銀行就會 charge NSF fee，我們這邊也會 mark fund transfer as rejected。