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