这是一个创建于 1619 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如，下单后，前端重新调用请求获取购物车数量，但购物车数量是通过 mq 减少的，这个时候获取的数据不对，这种要怎么处理呢
- 改成同步：但如果有很多相关业务，不能都改成同步吧
- 前端轮询查询：还是有一段时间显示的数据不对
 | 1 atalia 2021-06-28 15:34:27 +08:00 加入一个 version，前端轮询判断 version |
 | 2 funbox 2021-06-28 15:57:22 +08:00 实时性要求那么高 为啥用异步。。。 要取舍 |
 | 3 WillingXyz OP @atalia 具体怎么加呢 |
 | 4 thet 2021-06-28 16:19:26 +08:00 via iPhone 看 mq 平均消费时间是多少，可以通过一些障眼法等差不多时间再返回购物车页面，或者就不返回到购物车页面 |
 | 5 zhaorunze 2021-06-28 17:28:31 +08:00 mq 本来就是异步，想要同步的效果就改成同步。 如果不想换 api，可以看看 mq 是否可以查询消息的消费状态，查询到被消费后，第一个接口才返回。等于强行把异步该改为同步。 |
 | 6 lasuar 2021-06-28 17:38:53 +08:00 购物车商品数量更新本身应该是同步，其他操作改异步 |
 | 7 hejw19970413 2021-06-28 20:31:03 +08:00 双十一淘宝也不可能做到实时同步啊。所以还得看你们业务接受的延迟和业务场景。不推荐改成同步方式。你可以进行一个粗略的数字这个数字可以做成热点缓存的方式，等到用户在下单动作时进行业务事务的处理。 |
 | 8 akira 2021-06-28 20:37:50 +08:00 接口返回后等一会再查询 |
 | 9 sujin190 2021-06-28 23:01:39 +08:00 对于这种异步任务接口偶尔调用需要返回的，我们都是通过分布式 Event，异步任务加一个 event_id 的参数，传了这个参数，mq 异步任务处理完了如果传了 event_id 的话激活这个分布式 Event 就行，接口这边简单的等待这个分布式 Event 激活就行，这样一个 mq 的异步任务就可以既单纯一个异步任务，也可以支持接口调用了，解耦了 不过估计很多都用过分布式锁，但是估计都没用过分布式 Event 吧，或者用 redis 的 pubsub 回传结果其实也行的吧 |
 | 10 potatowish 2021-06-29 07:54:32 +08:00 via iPhone 流程要进行拆分，购物车数量减少明显是应该做成同步的，消息异步处理更适合状态类或者前台感知不到的业务 |
 | 11 wowbaby 2021-06-29 09:10:31 +08:00 购物车应该是同步操作吧，或者是 MQ 成功后，作标记已入 MQ 的数据，购物车返回的数据再过滤掉作标记的数据， |
 | 12 NUT 2021-06-29 09:36:39 +08:00 @atalia #1 握手，就这么弄。把结果放到 redis 里面。mq 投递前给生成一个 id，然后前端拿着这个 ID 轮训。 HTTP 轮训的方案其实是最实用的。还有有些大哥说同步改造，看到这个有点崩溃。 如果同步返回，在海量秒杀情况下，就连接数就可以来一壶。 |
 | 13 106npo 2021-06-29 09:45:12 +08:00 via Android 淘宝的购物车数量就没正确显示过，你看有用户去找客服说这事么 |
 | 14 Zien 2021-06-29 11:17:36 +08:00 via iPhone 话说美团和淘宝的优惠计算不同步是什么情况 |
 | 15 heheda11 2021-06-29 11:25:15 +08:00 在 mq 队列中的商品加状态 |
 | 16 hhjswf 2021-06-29 11:41:42 +08:00 这个有点离谱吧，你下单完会立马去购物车看一眼吗？就算回，不同步也无关紧要啊 |
 | 17 bsg1992 2021-06-29 17:34:32 +08:00 扣减做成异步，本身就无法实时同步，肯定会有数据对不上的情况。当你选择异步处理业务的时候肯定做做取舍。 一般这种情况，前端请求服务后直接做加减，障眼法。 要不就是轮询，等待异步业务处理完成 |
Select Language