多线程写入同一个文件的时候，会存现“线程安全”的问题(多个线程同时运行同一段代码，如果每次运行结果和单线程运行的结果是一样的，结果和预期相同，就是线程安全的)。如果是MySQL数据库，可以使用它自带的锁机制很好的解决问题，但是在大规模并发的场景中，是不推荐使用MySQL的。秒杀和抢购的场景中，还有另外一个问题，就是“超发”，如果在这方面控制不慎，会产生发送过多的情况，比如某些电商搞抢购活动，买家成功拍下后，商家却不承认订单有效，拒绝发货。问题也许并不一定是商家奸诈，而是系统技术层面存在超发风险导致的。

 

3.1、超发的原因

 

假设某个抢购场景中，一共只有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。这就导致了并发用户B也“抢购成功”，多让一个人获得了商品。这种场景在高并发的情况下非常容易出现。

 

3.2、悲观锁思路

 

悲观锁也就是在修改数据的时候，采用锁定状态，排斥外部请求的修改，遇到加锁的状态，就必须等待，虽然上述的方案的确解决了线程安全的问题，但是我们的场景是“高并发”，也就是说会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。

 

3.3、FIFO队列思路

 

直接将请求放入队列中的，采用FIFO(First Input First Output，先进先出)，这样的话就不会导致某些请求永远获取不到锁。看到这里是不是有点强行将多线程变成单线程的感觉哈，现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。

 

3.4、乐观锁思路

 

乐观锁是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号(Version)更新。这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话我们就不需要考虑队列的问题，不过它会增大CPU的计算开销。但是综合来说，这是一个比较好的解决方案。有很多软件和服务都“乐观锁”功能的支持，通过这个功能可以保证数据的安全。

 

4、随着互联网的用户越来越多，高并发的场景也变得越来越多，电商秒杀和抢购是两个比较典型的高并发场景，虽然遇到的挑战多，但是我们不怕，因为我们一直在努力。

 

以上就是我们关于什么是服务器高并发的介绍，希望对大家有所帮助。