这是一个创建于 1278 天前的主题，其中的信息可能已经有所发展或是发生改变。
说明一下：
- 用户会按时间顺序请求 A 接口 和 B 接口
- 目前 B 接口需要请求第三方 api ，比较慢（ 10 秒）
- 现在想提前到 A 接口去请求，B 接口使用
- 但是有一个问题就是不能保证 B 接口被访问的时候第三方 api 已经返回
- 我的想法就是 A 接口 share 一个 promise ，让 B 接口可以拿到并等到数据返回
但是目前并没有这样一个解决方案（因为 A 和 B 可能发生在不同服务器，所以无法直接共享文件或者内存）
所以看看大家有没有什么比较好的解决方案
（之前得到过一个方法：可以用 redis pubsub ）
- 用户会按时间顺序请求 A 接口 和 B 接口
- 目前 B 接口需要请求第三方 api ，比较慢（ 10 秒）
- 现在想提前到 A 接口去请求，B 接口使用
- 但是有一个问题就是不能保证 B 接口被访问的时候第三方 api 已经返回
- 我的想法就是 A 接口 share 一个 promise ，让 B 接口可以拿到并等到数据返回
但是目前并没有这样一个解决方案（因为 A 和 B 可能发生在不同服务器，所以无法直接共享文件或者内存）
所以看看大家有没有什么比较好的解决方案
（之前得到过一个方法：可以用 redis pubsub ）
 | 1 IvanLi127 2022 年 8 月 15 日 via Android 这。。。大概可以理解成: 在 A 时预加载 B 的数据，并在 B 被调用时使用这个数据。 你可以让客户端或者 A 所在服务调用 B 所在服务，或者通过消息队列通知给 B 所在的服务。 然后，你只要在 B 服务实现预加载或者是缓存功能就好了。 |
 | 3 maxthon OP 可以认为 A 和 B 在同一个 web service 中，但是这个 service 会有很多 server （或者 instance ） |
 | 4 libook 2022 年 8 月 15 日  1 既然已经跨实例了，就已经脱离语言本身的范畴了，需要使用系统架构来满足需求。 你得到了 redis pub/sub 的方法，就直接用这个方法呗。 |
 | 5 lmshl 2022 年 8 月 15 日 1 建议负载均衡层面根据 token 做 sticky session ，这样就能保证客户端短时间请求始终转发到同一个 instance 中去了。 内存里用 Map 简单缓存一下这个 Promise ，记得把时间也记录下来，定期清理掉过期的 Promise 防止泄漏 |
 | 6 lmshl 2022 年 8 月 15 日 在这个基础上再实现一个 fallback 机制，极端情况下，前一个 instance 凑巧被杀死了，后一个缓存里读不到 Promise 的时候还是需要走全流程 |
Select Language