处理海量并发，本质上的难题是什么？
处理超大并发的根本问题在于“如何在海量并发item中找到特定的那一个。”，本质上是查找问题。
写在后面
服务器的网卡带宽是恒定的，CPU，内存资源也是恒定的。
如果只有一个连接，所有从网卡进入的数据包都发给这个连接，这唯一的连接就独享所有的网卡，CPU，内存资源。
假设有1000个连接，有数据包从网卡进入时，所有要做的事就是“确定这个包是发给这1000个连接中哪一个”，只要完成这件事，在接下来一段时间，资源就分配给这个连接。
假设最理想情况，这个查找时间为0，资源总量为m，并发量为N时，每个连接所获取的资源就是m/N，这是个上界，不可逾越。
So，问题就是，如何用最快的速度找到这个数据包是发给谁的。这显然是个查找问题，这就是问题之“道”。
无论是epoll还是IO完成端口，都是在干这件事。
不要心存幻想去突破上界！优化目标是如何让结果无限接近m/N。遗憾的是程序员们并不信这个。
至于锁，调度，它们是实现确定目标的路上遇到的捣蛋鬼。属逼近m/N之“术”。
“术”向“法”，“法”趋于“道”，何为“法”？
加超大内存，索引而非查找，空间换时间，设计最最牛逼的查找算法榨干CPU，时间换空间，但突破不了对数时间复杂度，没有无限内存，hash离 O ( 1 ) O(1) O(1)还是很远，根本就没有 O ( 1 ) O(1) O(1)。
So，如何权衡内存和CPU的使用，最优化空间和时间的综合效益，需要设计好的数据结构和算法。数据结构决定空间效益，算法决定时间效益，这便是优化之“法”。
还有些时间，写些不仅关乎并发的废话。
即便你有海量内存，问题还是会一步步沉淀到“哪一个连接有权使用现在的CPU或网卡”的问题，总之还是查找问题。或者更广泛地说，是个“匹配”问题，“映射”问题。
除非你的内存，CPU，网卡容量都是无限的。但如果这些都是无限的，要程序员干什么？
我曾经以为当代青年有个误区，以为上硬件就能吊打一切，这是一种懒惰的做法，且非常不经济，毕竟要购买硬件。硬件不应该和软件去比拼实现收益，而是合作关系，问题是设计一个算法在有限的硬件资源下让性能最佳。
但礼崩乐坏。如今的工人倾向于用硬件方案替换软实现，如果你竟然使用软实现，就会有人给你洗脑，让你抛弃软实现，上硬件方案。
礼崩乐坏来自于硬件成本的降低，而成本的降低又因需求太大而使然。二者相拥滚动，早就没极致优化什么事了。
但这样真的不好吗？
反过来想，真的需要极致优化吗？把所有事情整体来看，综合效益最佳的方案是“刚刚够用”而不是极致优化，如果用便宜的新硬件替换软件就能瞬间达到效果，那么偏执的程序员在旧硬件上花时间做软件优化就是一种不经济的自嗨行为了。
So，最经济的方案也许就是“等”，时间总会带来更快的硬件。老板支付你花一年薪资聘你做极致优化可能不如一分钱不花等明年的新硬件。
无论是老板的思路还是工人的思路，都没法制造我们现实的世界，若工人不做，何来新硬件，若工人做了，先做的老板必定血亏。
然而，老板并不管理工人，老板管经理，经理管工人。经理的核心并非“道”，“法”，“术”，经理在乎的是一个“势”字。若工人没活干，经理也就不存在了。若要“势”，必先“卷”。然后各种事情就做起来了，也就有了我们现在的世界。
经理的思路既不是等，也不是极致优化，而是两者都要一点。这是一种伟大而美妙的平衡。
So，现实世界是经理创造的，经理才是真正的造物主。不信你看，人类文明之始，仅靠酋长和野人们是没法拓展文明的，社会分工必然会出现经理。
扯远了，但这也许就是“道”之“道”吧。
浙江温州皮鞋湿，下雨进水不会胖。