最近工作中使用随机数解决了一些实际的问题,再结合些其他经典案例,做一次梳理。
场景1
调整输出频率,降低负载。
线上15家商品类媒体API输出是串行的,至于为什么是串行的,这里就不做重点讨论了,串行的结果是生成的时间整体拉长了,
这样不利于媒体的抓取,我们的监控也会频繁报警(运维做了一个多长时间未修改的检测),那么接下来我进行了一个优化,很简单, 也很粗暴,就是14家媒体(第一家媒体做临时缓存)多线程同时执行,这样虽然解决了时间延迟的问题,
但是uptime发现瞬时负载很高,uptime 9:54am up 261 days 11:32, 2 users, load average: 11.81, 10.22, 5.83
大家可以看出1分钟内(当有媒体输出的时候)竟然有11.81,那这高吗?首先这是台4核的机器,一般情况下,单核cpu不超过3,我们就认为不高,所以目前几乎是满负载,这样势必造成其他任务处理的延迟,那么进行优化降负载。
随机数上场:
Random random = new Random();
int delayTime=random.nextInt(20);
try {
Thread.sleep(1000*60*delayTime);
} catch (InterruptedException e) {
log.error("sleep",e);
}
问题得到解决,思路就是线程内随机sleep一段可以容忍的时间,将执行散列到不同的时间段执行。
场景2
缓存批量失效的问题。
当大批量缓存同时建立,又批量失效,导致缓存建立不分散,对服务端瞬时产生压力,那么如何解决批量建立,不批量失效?
spyMemClient.set(key, maxExpireDuration + random.nextInt(600), result);
将缓存失效时间随机+几分钟即可。
场景3
一些抽奖,彩票,生成密钥,建立临时文件夹等本来就是随机的业务,不在细说。
场景4防止浏览器缓存(前提是未设置相关http的head)
url后面增加随机数参数,不过一般前端使用时间戳的较多。
场景5重复提交问题 (只是一个思路,未验证)
每次提交产生一个UUID
将UUID提交到 "提交历史服务" 保存,一个UUID只能提交一次。
每次在服务端通过"提交历史服务"进行校验
大家可以补充一下遇到过的其他场景。
场景6
线上数据的预热问题
当有大量数据不能离线预热,必须要线上预热的时候,势必造成资源的严重紧张,甚至打垮服务器,
所以采用随机预热方式,一定几率的将请求忽略,这样在小的压力下,使数据逐渐预热,预热成功后,
在取消随机预热。
int lucky=goodsRandom.nextInt(4);
if(lucky !=3 ){
return null;
}