在面试中面试官90%以上的几率都会问到高并发相关项目经验。结合我面试候选人的一些经验以及对高并发的理解，给大家一些完整的建议。首先说一下，在我作为面试官问候选人“对高并发的理解”时候，主要是想考察面试者是否有真实项目经历。

如果答的不好，有以下几种情况：

（1）对数据化指标没有概念：完全不清楚什么样的指标来衡量高并发系统，分不清并发量和QPS，不知道自己系统的总用户量、活跃用户量等等。

（2）涉及过一些高并发方案，但不知其所以然。也就是根本说不出当时方案要关注的技术点是什么。

（3）把高并发当成性能优化，大谈特谈并发编程，多级缓存等，不说高可用涉及和服务治理。这种我认为连概念都不清楚。

（4）有方案，没意识。了解垂直分层、水平分区、缓存等大思路。却没有分析数据结构、算法是否合理高效的意识。

基于以上几点，本来想从概念和设计目的给大家介绍，但是思考觉得过于抽象。决定用实际案例给大家详细阐述业务痛点和系统设计的方案，这样不仅梳理了解决问题的思路，也构建了面试的回答思路。

实际案例

互联网分布式系统架构设计必须要考虑高并发，高并发也是大家经常会遇到的技术难题。如何控制库存避免超卖？怎么实现线程间的数据处理同步？以上图红包雨为例详细介绍。

业务要求以及痛点分析

红包雨项目是抽奖类系统的一种，要求在某一段时间内随机发奖品，用户参与活动。这个业务主要是管理后台、用户前台和开发平台构建。

其中后台需要涉及到：用户管理、奖品管理、活动管理、中间统计等功能；

用户前台属于：注册登录、参与抽奖，个人中心查看。

开发平台涉及到的内容：微服务架构体系、注册与服务发现Nacos、部署平台、接口Swagger等。

项目的重点在于高并发情况下及时响应，以及大批用户点击用于，如何保障抽奖的奖品数量，不能出现设置了8个奖品，10个中奖的情况。以及红包出现在什么时候，奖品抽中几率等等。

库存控制以及核心流程

令牌桶算法可以把请求平均分散在时间段内，是使用较为广泛的限流算法。我们可以把令牌桶算法应用到红包雨业务案例中。这时候，令牌相当于奖品票据;令牌桶相当于奖品库存;正常业务相当于中奖;限流相当于未中奖。同时要注意，有多少个奖品，就生成多少个令牌(时间戳)，未中奖返还令牌。假设活动时间间隔太短，奖品太多，极有可能产生的时间戳发生重复。为了解决这个问题，我们需要额外附加一个随机因子，将( 时间戳*1000+3位随机数)作为令牌，抽奖时将抽中的令牌除以1000来还原真实的时间戳。

最后，将拿出令牌、判断时间、放回令牌的操作下沉到Redis服务器端，利用Lua脚本避免出现插队导致的令牌顺序被打乱。通过这些操作和解决方案，相信可以避免打乱奖品令牌造成扎堆出现的问题。

发散思维

使用Lua脚本，将抽奖的逻辑从Java端移入Redis服务器端，作为一个整体函数暴露给Java调用，一方面实现中奖逻辑的原子性，另一方面减少了Java服务器与Redis服务器之间的通信次数，性能会得到提升。要实现活动随时暂停，可以新增一个接口，该接口修改Redis缓存中的活动状态。抽奖接口逻辑中增加暂停状态判断。如果是暂停，返回给前台以提示。要实现多种投放策略，可以修改令牌生成部分代码。按递增、递减、正态分布等多种函数生成时间戳。

知识点总结

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。前者垂直扩展可以通过提升单机硬件性能，或者提升单机架构性能，来提高并发性，但单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是后者：水平扩展。

互联网分层架构中，各层次水平扩展的实践又有所不同：

（1）反向代理层可以通过“DNS轮询”的方式来进行水平扩展；

（2）站点层可以通过nginx来进行水平扩展；

（3）服务层可以通过服务连接池来进行水平扩展；

（4）数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；

各层实施水平扩展后，能够通过增加服务器数量的方式来提升系统的性能，做到理论上的性能无限。