背景

在面试过程中，常常会遇到对高并发场景进行提问的情况。请问，这样的提问旨在了解哪些方面的信息呢？

gbf

  1. 技术功底：高并发确实涉及到一些底层原理和技术架构设计，有经验者可结合实际情况作答，无经验者则需考察其背诵能力。

  2. 团队协作能力：高并发往往需要多个技术人员协同工作，包括架构、运维、测试等方面，因此需要考察应聘者的团队协作能力。

  3. 应变和解决问题能力：高并发并非长期稳定的状态，可能会因受到攻击而突然增加，因此需要考察应聘者的应变和解决问题能力。

  4. 是否有离职意向：从并发量角度考虑公司盈利，如果面试公司正处于业务扩张期，访问量激增，所以才来招聘有高并发经验的人才，如果公司业务不行，面试官可以从面试者中筛选高并发经验的公司，可以跑路。这个就是我瞎说，请勿当真！！！

问答

以下是一则可能的面试问答：

您能详细阐述一下什么是高并发吗？其主要特性和衡量指标是什么？

演唱会门票、商品秒杀等场景，大家都在同一时间疯狂点击“购买”按钮，这些都可以理解为“高并发”。高并发的特点是大家同时进行相同操作，访问量迅速增加，系统需快速响应。

衡量并发的一些关键指标包括

  1. QPS（Queries Per Second）: 每秒请求数，QPS值越大，说明系统处理能力越强、性能越好。
  2. **TPS（Transactions Per Second）**是每秒事务数。TPS值越大，说明系统处理能力越强、性能越好。
  3. RT（Response Time）: 响应时间，表示服务器从接收到请求到返回结果所消耗的时间。
  4. 并发用户数：同一时刻，系统能够接待多少用户。通过全链路压测来评估系统能够承受的最大并发用户数。
  5. CPU/内存/IO: 这几个硬件指标应该保持在一个合理的范围。

对于一个高并发系统，您认为可能存在哪些瓶颈或挑战？

常见的瓶颈或挑战包括：硬件条件限制，数据库瓶颈，代码性能，缓存问题

比如数据库并发高时候容易出现：

  1. 连接过多：数据库的连接数达到上限，新的请求就无法获取到数据库连接，导致请求失败。
  2. 数据库查询慢：某些查询语句问题，导致数据库响应速度慢。
  3. 数据库锁冲突：高并发下，事务并发操作锁冲突的概率会增高。

如何解决

  1. 优化连接池：监控连接池，根据并发情况调整参数，持续监控

  2. SQL优化：查找出长SQL，根据SQL业务场景和SQL执行计划进行优化。

  3. 数据库读写分离：分离查询和更新操作，这个需要借助中间件的支持，比如：Java 使用 Sharding-JDBC。

  4. 数据库分表分库：根据业务场景，比如搞个活动，预计的数据表量会比较大，进行水平拆分，这个也是需要借助中间件支持，如：Mycat

对于缓存，请问在应对高并发请求时，您有哪些需要特别关注的问题呢？

要防止缓存穿透问题：若缓存逻辑出现漏洞，攻击者可伪造大量Key查询不存在的数据，直接访问数据库，可能迅速占据缓存导致服务崩溃。

  1. 参数KEY过滤：在接口层添加过滤规则，对于明显异常的参数直接返回错误，比如一个正常用户的ID一般会是一个正整数，我们可以在接口层验证，如果用户ID为非正常范围内的数直接返回错误，不进行查询。
  2. 缓存空对象：对于查询不到数据的请求，也将其结果进行缓存，但是这种方案需要小心，大量的空结果可能会挤占了我们的缓存空间，导致有效缓存的命中率降低，因此这些空结果的缓存时间需要设置得较短。
  3. 使用布隆过滤器：布隆过滤器是一种多哈希函数映射的位数组结构，它能判断一个元素是否在一个集合里面，而且不会返回误判。

您是否考虑过将部分任务异步处理，如何合理运用线程池？

我会根据不同的业务场景去创建不同的线程池

  1. 未支付订单超时自动取消，我使用ScheduledThreadPool 来处理。
  2. 实时顺序写入日志，我使用SingleThreadExecutor 来处理。
  3. 订单状态变化推送通知和数据同步，我使用 CachedThreadPool 来处理，不过我们也需要控制线程数量，避免大量任务导致系统资源耗尽。

您是否了解过负载均衡策略，以及它们在何种场景下适用？

  1. 轮询（Round Robin）：这是最简单的负载均衡策略，就是按顺序把请求分配到服务器列表中的每一台服务器，然后再回到列表的开头重新开始这个过程。这种策略适用于所有服务器的硬件配置都相同，处理能力差异较小的场景。
  2. 随机（Random）：随机策略就是完全随机地选择一个服务器进行处理。这个策略适用于服务器群里每台服务器的性能都相当，且服务器数量相对较多的情况。
  3. 最少连接（Least Connections）：此策略会把请求分配给当前连接数最少的服务器。适用于每个请求处理时间较长，或者处理时间差异较大的场景。
  4. IP Hash：根据请求的IP地址进行哈希计算，然后根据计算结果把请求分配给固定的一台服务器，保证同一IP的客户端请求总是访问同一台服务器。这个策略适用于需要会话保持的场景，例如电商网站的购物车功能。
  5. 权重（Weighted）：权重策略允许我们根据服务器的处理能力，指定请求分配的比例。比如某台服务器性能是其他服务器的两倍，那就可以设置其处理请求的权重也是其他的两倍。
  6. 资源使用率（Resource Utilization）：根据服务器当前的资源使用情况，如CPU、内存或磁盘等，将请求分发到资源利用率最低的服务器。这个策略适用于服务器硬件配置差异较大，或者处理请求的资源消耗率差异较大的场景。

总结

高并发场景系统设计主要结合以下方法进行，但是什么万能方案可以解决所有的高并发问题，基本都要结合业务场景和公司当前系统的架构硬件基础展开设计。

  1. 横向扩展：也就是增加更多的服务器节点，来分摊这个突增的流量。
  2. 使用负载均衡：通过负载均衡策略，将流量合理地分配到各个服务器上，防止某一台服务器压力过大而崩溃。
  3. 使用CDN加速：通过CDN加速静态内容的访问，减轻源站的压力。
  4. 数据库分库分表：对数据库进行优化，分库分表，提高数据库查询的效率，降低单一库表的读写压力。
  5. 使用缓存：使用Redis或Memcached这样的缓存技术，将经常访问的数据（如首页热销商品）缓存在内存中，加快访问速度。