修复过的一个bug

有些业务是有实时性要求,实时性的概念可能是产品设计的必须性,也可以是非必需的,当然谁都希望做到又快又好.

调用云服务的时候有些产品是有qps要求的,所以导致有些数据创建不成功或是违规的创建

当时为了考虑到用户少、这个功能的并发数不会多、节省成本的角度,所以就没有进一步做处理.

就是这么巧,某天的并发数真的超过了设置数量,导致有些数据录入不成功,用户反馈过来说体验感不好.

处理措施有两种方案:

对于实时性要求不高的功能:改成非实时性的用户可之后查看,后台用消息队列处理

就要求实时性的:升级云产品qps,消息队列 redis等等待,并发量大了用户可能等待的时间过长导致,当然针对于某些业务比如秒杀抢购类似的业务用户是愿意等待的