为什么说是现阶段的我，因为任何事务的认识都有局限性，不管是历史上的还是技术上的，比如地心与日心，比如光的波粒二象性。因此，我也只能在自身目前的认知水平来聊相关的话题。
不管网络上还是技术书籍上，关于高并发的内容不胜枚举，当然也有对高并发本质的论述。今天突发奇想要写的肯定也跳不出上述资料，但我并不想将那些资料罗列到一起来聊这个话题，我更想结合经验来谈谈个人的认识。
当我们查看招聘网上的职位时，几乎所有的职位都有一个关键词--高并发。。。从网络大规模普及后，这个词也就成了程序员的标配。那么，一个职位要求的高并发究竟是个什么东西。用大白话说，就是有一大堆请求在短时间内发送给我们，然后我们用手中所掌握的资源来处理掉它们。一大堆是多大？短时间有多短？这两个问题其实跟“高并发”中的“高”字一样，高有多高？有这么一句话，凡是我们到达不了的地方都叫远方。我觉得把这句话修改一下来形容高并发也挺合适，凡是现有资源在指定时间内处理不了的并发都叫高并发。从这句话中我仿佛窥探到了高并发的本质，那就是任务与其处理资源之间的博弈。换种说法，如果我资源充足（成百上千台刀片机组成的集群），十亿百亿的并发量也称不上高并发，如果只有一台90年代的笔记本电脑，那么估计千位级别的请求就可以叫高并发了。
上述探讨了高并发的本质，接下来就是如何应对高并发，也就是在限定时间内将之前提到的那一大堆请求处理完毕。至于具体的应对措施，其实还是之前提到的，网上和各种技术书籍随处可见，在这就不班门弄斧了。曾几何时，当一听到高并发三个字，我就会想到多线程，其实呢，格局小了。这只是在代码级别的一种应对方法而已。处理高并发是个系统工程，从产品设计到架构再到代码，从业务策略到用户体验等等，都会影响到所采取的应对措施。我认为根据业务的不同，应对高并发总体上有两种策略，1.利用一切手段处理全部请求，不管是真处理还是假处理（降级--就像用七伤拳，无论是打人的还是被打的，外表都要装着跟没事儿一样）。比如商业搜索引擎。2.只处理一部分有效请求。比如电商下单，当库存没有了，自然后续的下单请求也就不用处理了（这里之所以具体到下单，是因为电商的商品展示和查询仍像搜索引擎一样需要尽可能的处理全部请求）。
针对上述两种策略，就有了不同的处理方式，通过增加资源来实现第一种策略，当然最好是横向的。这自然就引入了分布式概念。通过各种手段过滤掉绝大多数请求来实现第二种策略。至于为什么不纵向增加资源以及过滤请求的具体方法就不在这详述了。
不断思考去认清事务的本质可以指导我们采取更为有效的行动，居然不知不觉中还跟第一性原理扯上了关系。
