V 友们有处理过交易相关的场景么?如何保证一个交易能够正常的完成,或者是出现异常的时候进行及时的补救?
JoeJoeJoe ·PRO
场景就是电商购物的时候, 或者积分充值和提现之类的, 如果是峰值的话怎么规避呢? 仅仅靠队列削峰么? 或者说怎么规避一些恶意的攻击呢?
之前做 2b 比较多, 很少接触到这一块, 感谢大佬们拨冗回答. 先磕为敬 orz.
 |
1
JShen 3 小时 11 分钟前
说白了都是分而治之。不管流量多大，一个机器能处理的事务就这么多，多了搞不定，就这个思路去玩就行了。
从入口到底层存储都是这个思路。前端的负载均衡，后端的服务拆分（扩容，限流，降级），底层的分库分表。全部都是这个思路的应用，另外采用空间换时间，优化一些查询效率。 |
|
2
JShen 3 小时 9 分钟前
出现异常的情况，快速失败就行。 峰值采用分而治之的思想。恶意攻击这个需要安全部门一起配合，接口签名，验签常规手段。
|
 |
3
Croow 3 小时 4 分钟前
收藏下，下下版本我们也有类似需求，蹲大佬解答
|
 |
4
JYii 2 小时 50 分钟前
支付服务永远只处理支付、退款等金融操作，与业务相关全部异步处理，最多关心一下最终一致即可。
异步就需要消息中间件，其他业务异常都可以补救，因为订单数据就在那。 不明白你说的异常是什么，支付服务是不允许出现异常，除非银联或第三方支付出问题。 从请求进来要严格按照订单状态流程扭转，例如不允许出现支付成功->支付进行中、支付失败，写个状态机就可以了。 恶意攻击 Ddos 放在任一服务前面都是需要的，通常在 gateway 层挡住处理，不然所有服务都要考虑这种问题。如果只有你一个人，几个钱啊啥都管。如果有团队，那就听 leader 的，你还是不用关心。 |
 |
5
guiyumin 2 小时 43 分钟前
据说，当人数太多的时候，直接随机杀死一些请求
|
 |
6
leoding 2 小时 17 分钟前
最终事务一致性，出账的只做出账同时设置中间状态，入账只做入账，入账成功后回更出账中间状态到最终状态。可能还需要一个补偿机制，对一定时间后（ 5 分或 10 分）处于中间状态的数据进行补偿入账操作。
|
 |
7
chutianyao 2 小时 5 分钟前
事务+限流啊
如果真的有泼天的流量需要承接, 扩容呗 |
Select Language