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