线上限流问题

问题

定向发券时，部分用户发券失败，原因是service-1调用service-2时被ingateway限流(http 596 status)，service-1执行fallback逻辑，抛出异常；活动发券用户1602+394+224*1左右，故批量时qps在 700左右，但是限流配置的是1k，故不应被限制

原因

inrouter的限流是单节点限流，比如配置限流策略是1000，存在17个inrouter节点，即每个节点的限流qps为58，当该节点qps超过58时，即会被限流响应598，上述问题时总qps为722，故单节点平均为 42，当某一节点倾斜量超过16时，超过的请求即会被限流，共限流29个请求

解决方案

• 暂时解决方案
  • 先调整限流策略为1200，降低限流出来的概率（无法根本解决上述问题）
• 根本性解决方案
  • 因为通常配置多个活动时，都会配置一个相同的开始时间，另外稍晚几秒发放优惠券并无影响，故可错开发放，降低并发度
  • 在创建job时，根据活动开始时间+随机秒数，创建job，故即时多个活动开始时间相同，job的schedule time也会错开
  • 在执行某job时，会分成多个unit,限制单次执行unit数量

兑换优惠券报错

问题

在通过积分问的优惠券时，报错，原因是调用券系统因为幂等未返回优惠券信息

原因

兑换优惠券流程

• 冻结积分
• 发送延时1s消息
• 发放优惠券

监听消息流程

• 发放优惠券
• 使用积分

在兑换优惠券发送延时消息时，是通过System.currentTimeMillis()/1000 + second计算出来的延时后的时间，单位为s，当当前时间毫秒为998时，延时消费时间即为下一秒的000，故延时2ms，即两个发放优惠券并行发放，有可能消息的优惠券发放成功，接口调用的发放优惠券被幂等导致发放失败

解决方案

将延时消息从1s调整为3s