场景是这样的， 公司产品给 app 商品列表页模仿了百度外卖的样子，要做一直向下滑展现商品的效果。我抓包百度外卖 app 发现，它们是一次性吐的全量商品信息，结构是 分类下有个字段数组存的此分类全部商品详情。
我们的底层， 商品库存独立系统， 商品销量（订单）独立系统，商品分类＋app 商品信息是独立系统（信息 cache 进了 redis），api 写出来以后，返回数居前要 http 抓每个商品的 ，库存＋销量进行信息拼凑， 商品越多， 导致接口越慢。。
我的优化方案是， 不时时取了， 回头弄成脚本定时按商品纬度 去各系统抓库存＋销量，存入 redis。
这样 api 只读就好了。
请教下大家百度外卖或糯米这样的对外 api 信息都怎么读取的啊，有其它地方存放还是？？ 来保证 api 性能。 用了什么牛逼东西么？
我们的 api 数据还有个需求按库存排序， 库存为 0 就从结果沉下去，redis 每次都排序对 cpu 占用较高。。 也请教下大家给点思路。。
线下搞活动时候 api qps 比较高，巨卡。。
某些无限下滑的 app 点击进入详情在返回就得再来一次。。
库存、订单、产品是三个独立系统的意思是 microservice？数据库也分开的？
我没有接触过这方面的东西，但是貌似这个应该有专门的组件方法实现的吧？感觉有点类似于分页
这个只是简单读取，还谈不上高并发。数据主要来自商品信息系统，你在那里做一个库存的 cache 就可以了，一个 id 对应一个库存量，没有就先去库存系统拉。失效按照时间或者库存系统的 enqueue 通知。 按库存排序也不复杂，根据上面的数据再做一个简单数组，失效重新排序，都很快的。读取时按已经排好序的数组的分页，再去数据库或 cache 里面拉具体的商品信息就可以了。
@zming619 你没有明白我的意思，商品系统做库存的缓存和服务独立一点关系都没有，这个就存在于商品系统自身。
可以考虑使用 https://github.com/openresty/lua-nginx-module#ngxlocationcapture_multi 减少客户端的请求，然后结合 http 的 cache 来减少 api gateway 对各 microservice 的请求