随机数应用场景

2019独角兽企业重金招聘Python工程师标准>>>

随机数应用场景


最近工作中使用随机数解决了一些实际的问题，再结合些其他经典案例，做一次梳理。


场景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;
}

转载于:https://my.oschina.net/heguangdong/blog/140688