高并发业务接口开发思路(实战)
- - SFLYQ高并发业务除了需要有支撑高并发的服务器架构,还需要根据业务需求和架构体系,设计出合理的开发方案,
这里根据一个实践过业务场景分析开发思路,罗列出高并发接口需要注意的点,以及设计上的巧思,共勉之,望共鸣. 需求点:(实际业务会复杂些,为了容易理解,这里简化需求点). 提供最新的好货商品信息列表,支持分页.
高并发业务除了需要有支撑高并发的服务器架构,还需要根据业务需求和架构体系,设计出合理的开发方案, 这里根据一个实践过业务场景分析开发思路,罗列出高并发接口需要注意的点,以及设计上的巧思,共勉之,望共鸣
【商品服务API】
:通过商品服务提供的API获取商品数据,当商品有上新、字段更新、排序有更新时,通过API都可以获取到最新的数据(db查询,支持获取未来时间里的商品数据)Redis
【更新时间】
(可空),默认等于当前时间,可以传未来时间【商品缓存Key名】
,将数据存到版本号对应的缓存Key中,所以需要生成一个唯一字符串,这里我们把 【更新时间】
的时间戳作为缓存的Key名,为何这么设计,后面会介绍到【商品服务API】
获取 【更新时间】
对应的商品数据,接着对数据进行字段处理、排序,最后把最终商品数据更新到 【商品缓存Key名】
的Redis SortedSet中【商品缓存Key名】
存到 【版本号集合】
Redis SortedSet中,同时把 【更新时间】
的时间戳作为排序的值【商品缓存Key名】
= 【更新时间】
的时间戳,这个设计的目的是可以支持未来时间版本数据的提前更新,并且可以通过SortedSet排序,过滤出当前时间最新的版本号
【当前最新版本号】
: 【版本号集合】
通过SortedSet机制,获取当前时间能够使用的数据版本号,
如:取[当前时间戳]-[(当前时间-1h)时间戳]区间的版本号,排序后获取离当前时间最近的版本号作为最新版本号 <这里为何取区间,而不是直接取最新版本号,会有个容错处理,后面会说到>【今日好货API】
需要上传版本号和页数,如果是第一次(pageindex=1,首页),会获取 【当前最新版本号】
,然后返回最新商品数据【当前最新版本号】
,就不进行数据缓存查询,直接返回空数据(数据不变),客服端无需重新渲染商品列表,同时可以避免无限下拉刷新带来的服务器压力【当前最新版本号】
和当前最新数据返回,数据版本号参数有上传,就获取对应版本号的分页数据【版本号集合】
随着时间增长,版本号数据会不断累加,需要在每次更新的时候删除掉最近一天的版本,操作 SortedSet 过滤掉比(当前时间-1天)的时间戳小的版本号【当前最新版本号】
的时候,操作 【版本号集合】
集合,获取最近一个小时的,即操作SortedSet[当前时间戳]至[(当前时间-1h)时间戳]范围内的版本号,然后从大到小排序版本号,过滤出版本号,并且有版本号相对于的商品数据,如果不存在商品数据,就往下遍历,直到有符合规则的版本号返回