Sinatra 电商 API 高并发设计求解

zming619 · 2016年06月08日 · 最后由 vkill 回复于 2016年06月13日 · 6410 次阅读

场景是这样的, 公司产品给 app 商品列表页模仿了百度外卖的样子,要做一直向下滑展现商品的效果。我抓包百度外卖 app 发现,它们是一次性吐的全量商品信息,结构是 分类下有个字段数组存的此分类全部商品详情。

我们的底层, 商品库存独立系统, 商品销量(订单)独立系统,商品分类+app 商品信息是独立系统(信息 cache 进了 redis),api 写出来以后,返回数居前要 http 抓每个商品的 ,库存+销量进行信息拼凑, 商品越多, 导致接口越慢。。

我的优化方案是, 不时时取了, 回头弄成脚本定时按商品纬度 去各系统抓库存+销量,存入 redis。

这样 api 只读就好了。

请教下大家百度外卖或糯米这样的对外 api 信息都怎么读取的啊,有其它地方存放还是?? 来保证 api 性能。 用了什么牛逼东西么?

我们的 api 数据还有个需求按库存排序, 库存为 0 就从结果沉下去,redis 每次都排序对 cpu 占用较高。。 也请教下大家给点思路。。

线下搞活动时候 api qps 比较高,巨卡。。

某些无限下滑的 app 点击进入详情在返回就得再来一次。。

库存、订单、产品是三个独立系统的意思是 microservice?数据库也分开的?

我没有接触过这方面的东西,但是貌似这个应该有专门的组件方法实现的吧?感觉有点类似于分页

这个只是简单读取,还谈不上高并发。数据主要来自商品信息系统,你在那里做一个库存的 cache 就可以了,一个 id 对应一个库存量,没有就先去库存系统拉。失效按照时间或者库存系统的 enqueue 通知。 按库存排序也不复杂,根据上面的数据再做一个简单数组,失效重新排序,都很快的。读取时按已经排好序的数组的分页,再去数据库或 cache 里面拉具体的商品信息就可以了。

#2 楼 @hooopo 是的,数据库是分开的,互相 http 调用的 api

#4 楼 @billy 互相都是独立的,数据库也是分开的, app 显示的商品信息是一套系统一套独立 db,库存一套独立系统独立 db,销量(订单系统统计得来)也是独立的。。 数据互相调用都是通过 http api 的方式, 介于 app 产品要的效果,给 app 的商品 api 需要全量一次行吐所有该小区在售商品,需要遍历商品获取库存,销量。。 哪怕做个缓存,对于 app 触发 cache 过期在 get & cache 也是不小的时间开销。。 。

#1 楼 @pynix app 可以 cache list , list 里返回 detail 用的数据即可节省一次 网络开销

#3 楼 @ws96apt 对于电商类这个案例是个不错的学习经历

@zming619 你没有明白我的意思,商品系统做库存的缓存和服务独立一点关系都没有,这个就存在于商品系统自身。

可以考虑使用 https://github.com/openresty/lua-nginx-module#ngxlocationcapture_multi 减少客户端的请求,然后结合 http 的 cache 来减少 api gateway 对各 microservice 的请求

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册