http请求大数据量耗时较长如何解决

Question

有一个业务场景，要在两个系统中同步一个大容量的Map数据（在内存中），大约100兆+，A系统请求B系统使用FeignClient请求，但是耗时有点长，会影响用户体验，另外耗时长在系统上会有什么不好的影响吗，有什么其他方式来应对这种大数据量传输的场景呢？

暂时能想到的办法是将map分成n片小map，然后A系统需要同步时开启n个线程去访问系统B，不过map分片好像不太好分，而且B系统的map数据是在实时变化的，分片再传输有可能造成数据丢失。

有没有一种类似数据库的游标的实现方式，得到一点数据就处理一点数据？

请大佬赐教。

Answer 1

提供一个思路：

1. 这里不用 feign client，因为要手动解析流（我不太熟悉feign，如果可以返回流，不让feign解析的话也可以）
2. 如果数据简单，考虑分块（比如换行符分割），然后以文本的格式返回
3. 服务端返回时使用“增量”模式，每次只输出一块数据，借助于 jackson 的 SequenceWriter，可以增量的将数据写入到ServletOutputStream
4. 客户端也自己解析，直接解析 ServletInputStream ，手动读流，按服务端分块规则拆分，每次只读一块，边读边处理。

这一套操作，虽然比较麻烦，但内存占用低，也实现了增量处理

Answer 2

公司请教了大佬，最后使用grpc解决，底层是http2协议++protobuf数据传输格式

不仅支持大数据量传输，数据量减小，解析也比json快，而且还可以支持全双工，也就是双端都能发送请求，就是说不需要A去定时请求B了，而是B的数据发生改变时主动推送给A。支持stream，支持异步处理

目前来说很完美，我再测试下性能，晚点补充～

Answer 3

你这数据同步是要做实时响应？如果不是，
最简单的就做个异步处理就ojbk了，
如果可以使用mq就mq发消息，如果能使用redis的消息订阅模式，也是可以的，将数据由块拆分成了条，这样就少了很多事情
实在不行，双方也可以约定给返回特殊格式的文件，自己去解析即可