这是一个创建于 1230 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如，下单后，前端重新调用请求获取购物车数量，但购物车数量是通过 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
xmumiffy 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