e********3
发帖数: 229 | 1 设计一个itunes/google play购买物品的系统 with high availability. 比如某个游
戏是1刀,你点击之后server会跟银行talk要从你卡里扣除这一刀.还有这charge的一刀
有一部分是要给developer的.这整个过程如何设计
这个是不是应该上kafka.目前能想到的是:
1. front end发送购买event把request经过load balancer发送到application server
preprocess这个request.
2. 然后把提取出来的相关user id, item id等信息作为message发送到kafka.
3. consumer server从kafka里拿出kafka的message,去database 取出相关user的卡信
息,发送给另一个server去Process
4. 这个server跟银行talk,charge了这一刀.然后update database记录下该user相关购
买信息.
5. consumer server commit.继续fetch message from kafka
6. 把这个successful charge的message发给另一个kafka server.另一个consumer
servers负责处理分钱给developer,就是update developer相关的table,给developer
account加钱(不知道还有没有其他)
这过程有很多问题:
1. 跟银行talk的server如果在send charge message给银行后没来得及收到银行
successfully charge的信息就挂了,那这个怎么处理?是不是用two phase commit之类
保证exact once?
2. database用mysql还是nosql.感觉mysql就可以了. nosql没有acid保证是不是不好?
3. 用了2个kafka servers,是不是第二个可以不用啊?
4. 想到其他再update.
不知道这样设计对不对,应该有很多纰漏,大牛们赶紧指点指点. |
T****U
发帖数: 3344 | 2 收钱那一步尽量都用sql, 要保证Atomic操作，其他的用nosql保证性能 |
e********3
发帖数: 229 | 3 对.收钱这个要acid.是指第四步么?
4.这个server跟银行talk,charge了这一刀.然后update database记录下该user相关购
买信息.
那和user 相关的各种Info也是用nosql? |
e********3
发帖数: 229 | |
d*******3
发帖数: 6550 | 5 这种把图画出来，哪里会出问题，怎么解决一目了然。 |
s*****r
发帖数: 43070 | 6 这么critical的系统能用卡夫卡做，俺真服了有了 |
e********3
发帖数: 229 | 7
求大牛指导.我也是自己想了胡说的...大牛给个设计吧
【在 s*****r 的大作中提到】
: 这么critical的系统能用卡夫卡做，俺真服了有了
|
b******7
发帖数: 123 | |
e********3
发帖数: 229 | 9
mysql的话比如各种server挂了怎么办?怎么避免single point of failure?
【在 b******7 的大作中提到】
: 留下1，其他就mysql就可以了吧。
|
d*******3
发帖数: 6550 | 10 galera cluster or mysql cluster
另外你想复杂了，这个考的是系统设计，没必要纠结在用什么数据库，什么软件之类的
。每个环节的server肯定要HA，你要考虑的是request发送中途如果出问题怎么处理，
还有中间某个环节server挂掉，你如何找回并且继续处理这个request。
【在 e********3 的大作中提到】
:
: mysql的话比如各种server挂了怎么办?怎么避免single point of failure?
|
|
|
e********3
发帖数: 229 | 11 对.怎么处理server挂了是重点...我就想到replication, log这些.大牛具体讲讲吧 |
T****U
发帖数: 3344 | 12 如果用信用卡的好，不是当时charge的吧，只要跟银行verify一下就行，收不到确认可
以反复verify,反正不会真正收钱。verify成功或者HOLD CREDIT LINE后就可以发货，
给下载了。具体收钱和银行确认的工作统一由其他专门的机器和软件来处理。
如果是GOOGLE PLAY账户里的钱，就用atomic的数据库处理，性能可能有问题
server
【在 e********3 的大作中提到】
: 设计一个itunes/google play购买物品的系统 with high availability. 比如某个游
: 戏是1刀,你点击之后server会跟银行talk要从你卡里扣除这一刀.还有这charge的一刀
: 有一部分是要给developer的.这整个过程如何设计
: 这个是不是应该上kafka.目前能想到的是:
: 1. front end发送购买event把request经过load balancer发送到application server
: preprocess这个request.
: 2. 然后把提取出来的相关user id, item id等信息作为message发送到kafka.
: 3. consumer server从kafka里拿出kafka的message,去database 取出相关user的卡信
: 息,发送给另一个server去Process
: 4. 这个server跟银行talk,charge了这一刀.然后update database记录下该user相关购
|
g*****g
发帖数: 34805 | 13 交易都是 atomic, 如果数据库负荷过了警戒线可以 queue request, 提交立刻返回，
之后异步处理了邮件短信等通知是否成功。
数据库的 HA用常见的 hot standby即可。 |
e********3
发帖数: 229 | 14
那就是server挂了立刻用另外的server代替.那如果一个server发交易到银行的server
然后没来得及收到对方的message就挂了呢?这怎么办?
【在 g*****g 的大作中提到】
: 交易都是 atomic, 如果数据库负荷过了警戒线可以 queue request, 提交立刻返回，
: 之后异步处理了邮件短信等通知是否成功。
: 数据库的 HA用常见的 hot standby即可。
|
x*******1
发帖数: 28835 | 15 request进来首先要persist（不要立即处理，放到SQS／DDB里面）， 如果server挂了
。 可以返回500 internal error， 用户client收到500 retry。 这时候load balance
就应该mark 那个 down的server，不route request给他。 |
e********3
发帖数: 229 | 16
balance
如果跟面试官说返回error,那这不就不HA了吗?
【在 x*******1 的大作中提到】
: request进来首先要persist（不要立即处理，放到SQS／DDB里面）， 如果server挂了
: 。 可以返回500 internal error， 用户client收到500 retry。 这时候load balance
: 就应该mark 那个 down的server，不route request给他。
|
g*****g
发帖数: 34805 | 17 HA不意味着没error，只不过概率低而已。通常3个9算是底线。
【在 e********3 的大作中提到】
:
: balance
: 如果跟面试官说返回error,那这不就不HA了吗?
|
