在过去的四年工作中，一直对高并发没有一个很好的理解，因为工作中没有人考虑过这个事情，领导觉得指标有点高了就加机器，出问题了就找出报错日志，把锅甩出去，但是并没有考虑兼容这种异常情况。

过去我也一直以为所谓高并发就是需要 QPS 达到某个阈值，但今天突然发现或许并非如此，因为这个阈值对于不同公司不同系统都不是固定值，因此无法简单地使用阈值来判断高并发。个人认为，高并发应该是当用户请求超出了系统正常运行时所能承受的范围，例如，某个系统最多能承受 20QPS，当达到 21QPS 时，对于这个系统就算是高并发了，因为超出了承受能力会带来一些不确定因素，从而导致一系列影响，最终导致系统瘫痪。

在上一家公司，我主要负责 API 开发，这个 API 依赖了大量后端服务，然而会有各种各样的因素导致后端不同服务不稳定，请求处理不过来，导致服务响应变慢，而 API 仍然要接收用户发起的请求，用户请求处理不及时，于是请求大量堆积，导致 TCP 上升，线程频繁切换，导致 CPU 上升，甚至最后会导致系统瘫痪。出现以上情况，往往会有一群不是很懂技术的领导一顿瞎讨论之后，把问题归结为 API 服务请求处理不过来，把后端服务打爆了。

顺带一提，上面说的这种情况再加上在工作中学不到什么知识，于是我辞职了。

其实，这种情况主要是没有对限流、熔断等基础措施导致的(因为上家公司用的系统都是13年开发至今的，从未升级过系统架构)。

说来惭愧，之前有面试官问我高并发如何处理，我的回答是我们机器比较多，没怎么遇到过高并发把系统压爆的情况，然后还说了一点代码上的，其实这部分回答说的是多线程问题。当时的自己确实不懂高并发，工作中学习不到，网上看到的理论对于自己也只是纸上谈兵，并没有真实体会过。

目前个人认为的一些防范措施：

  1. 接口调用指定超时时长
  2. 某个服务多次请求超时，则对该服务所有相关接口进行短时的熔断
  3. 服务提供的接口都需要对外做个限流机制，当请求超过阈值时，就先以队列暂存，但这种机制相对难以实现(个人认为，也许只是个人能力不足)，可以考虑阻塞一小段时间，或是直接拒绝请求
  4. 依赖的服务也需要限流，从而保护依赖服务的稳定，但此处的阈值需要和服务提供者协商
  5. IP 限流
  6. 接入风控系统，风控系统对每一个请求进行识别，判断是否是恶意请求(鉴别黑名单IP、黑名单用户、伪造请求、代理请求等)