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