多系统数据拼接分页查询

多系统数据拼接分页查询

前段时间遇到了这样一个问题，在订单页面查询时，除了分页查询订单的核心信息之外，还需要去其他系统中调用一些附属信息，此时就涉及到了时效问题，对于如何解决这个问题，我整理了如下的几种方法。

方案一

如图所示，首先在本系统中，将订单信息按照pageRequest请求分页查询后，然后通过rest或者feign，调用下游api接口，获取到数据后，整合到一起后，返回给客户端。
优先：简单明了，不存在数据一致性问题，如果系统QPS不大，且对于响应时长很宽容的情况下，可以采用本方案。
缺点：耗时太长，如果数据结构比较复杂，对接的下游系统较多，每一次的feign调用都会消耗大量的时间，还需要考虑下游系统的负载情况以及网络情况。

方案二

利用Redis同步缓存下游附属数据，这种方案就需要下游系统高度配合，在订单附属数据发生变更时，将数据同步到Redis中，与上游系统统一下key的格式，例如orderId或者OrderCode等，value则存储JSON数据，这样当用户分页查询订单时，仅需要一次JDBC操作，然后根据查询出来的订单信息，提取出来与下游系统约定好的key值，去公用Redis中获取附属信息进行整合，大大提升了时效，当然，也可以依据实际情况考量是否需要给Redis添加过期时间等操作。
优点：这种方案能够大大提升时效性，图示仅展示出了一个下游系统订单附属信息，若存在多个，则需要多次feign调用获取数据，每一次调用都会是一笔不小的开销。而通过Redis同步缓存的方式，不论存在多少下游系统，都可以通过约定好的key去Redis中获取数据，时效会显著提升。
缺点：数据交给下游系统维护，使用Redis缓存数据，可能存在数据一致性问题风险，可以让下游系统使用延时双删策略来确保Redis与数据库的数据一致性，同时，上游系统除了通过redis查询数据之外，当Redis中不存在数据时，也可以通过feign调用api去获取数据，下游接口可以同步缓存数据，这样下次查询时，即可从Redis中获取。

当然，还有很多其他的解决方案，本文只提供了两种常见的简单的方案供大家参考，毕竟涉及到上下游系统对接的时候，不光是技术问题，还会存在很多的问题，大家懂得，所以在思考解决方案的时候，尽可能的想的细一些、全面一些，这样在讨论会上的时候，你才有可能说服下游配合你实现你的方案，话不多说，言尽于此，希望本文对大家有些作用。