互联网中常见的随机数+分布式中常见的防止重复处理的方式
统计学意义上的随机数
1.完全随机性，也就是各个数值的概率分布是均匀的
2.不可预测性，也就是不能通过之前的随机数预测下一个随机数的值
3.不可重复性，也就是不能出现重复的数列
java中的随机数实现：
- java中常见的Random实现是一个伪随机数，如果设置相同的种子值(默认为System.currentTimeStamp)，那么得到的是完全一样的预测值序列，当然这样一个功能也有利于我们和其他比如前端的数据同步方式，比如后端在初始化的时候返回给app应用一个种子值，随后app应用通过使用该种子值生成各种随机数，来计算比如每次切中水果的概率，当app应用最后统计所有已经切中的水果来计算得分时，把这个最终的结果发送给后端记录分数，后端当然要验证这个计算结果的准确性，所以也会用之前的种子值来生成各个随机数来验证前端结果的准确性，达到验证数据准确性的目的,不过由此也可知肉眼可见的安全风险：一旦黑客能猜出Random的初始种子(相对容易，因为默认是System.currentTimeStamp)，那么他就可以破解由此产生的所有随机数
- java中的SecureRandom实现是可以达到安全要求的，其实不论是Random还是SecureRandom在确定了初始种子之后，他们的随机数序列都是可以预测的，那SecureRandom为何是可以达到安全要求呢，要点就在于SecureRandom生成种子值的方式，他不像Random那样默认使用System.currentTimeStamp作为种子值，他是使用计算机的环境噪声比如当前cpu的使用率，当前内存的使用率，当前时钟，当前按键的值等等组合生成一个种子值，这个种子值就几乎完全是不可预测了，这样就达到了生成随机数的目的
分布式系统最普遍存在而又最难处理的一件事情就是当客户单调用服务器的写接口超时的状态不确定性
情况一：服务端收到了请求后网络超时了，这个请求服务端已经处理过了
情况二：服务端压根没有收到请求，网络超时了
由于是写接口，比如是增加某个用户的账号游戏币的数值的，重复调用会导致极大的问题，所以这种情况下服务端一般都要实现幂等的操作，所谓的幂等是指重复的请求多次调用服务端的接口的效果和只成功调用一次服务端接口的结果是相同的，而这里其实又引申出另外一个问题，如果定义重复的请求，所以这里问题的关键变成了服务端怎么知道请求是重复的？
答案就是调用方要根据业务的含义定义出对应某个请求的特定参数，比如对于抽奖接口来说，我们可以定义这样的一个参数:用户id+抽奖次数，这样当服务器收到两次一样的这个参数的请求时，他就能判断出来第二次请求时重复的请求，简单的过滤掉即可**.所以问题的关键是调用方定义一个业务含义上的重复的定义**