作为一个天天和高并发打交道的程序员，我并不觉得这样就能获得高并发的经验，高并发只是一个结果，并不是过程。在来自全人类的高并发访问面前，一切都有可能发生，所以我们经常能看到顶级网站的颤抖。

我觉得基础最重要，这包括算法，操作系统，jvm，数据库，缓存，多线程等等，其实这都是独立而又关联的知识。书本里都有，很多年没新东西了。别只痴迷于框架，框架只会挡住你的眼睛，让你觉得什么都不重要。大并发面前，没一个框架靠得住，靠得住的只有人，是人来根据你具体的应用场景去解决具体的问题。

然后是分布式系统设计，这是经验和知识的结合，或者说就是用前面提到的基础来搭积木。

这里最常用的就是如何分片sharding和负载均衡load balancer， 大家都知道更大的并发需要更多的服务器，但是你的分布式系统很可能加不了那么多服务器，这就是所谓的scalability.

这里并没有一种高并发设计可以打遍天下无敌手，google, twitter, amazon, facebook, linkedin都有自己的应用场景，有自己的实际需要，有自己的权衡。有一得就必有一失。

有兴趣的朋友可以看看

Eventual Consistency vs Strong Consistency

Read Heavy vs Write Heavy

高并发和scalability还不能离开高可用，你搞5w台服务器，但只要坏一台全部服务完蛋肯定是不行的，如果有些服务坏掉或者重启，你需要能有一些应对和调整的策略。

这有还很多细节，比如说id怎么生成，你用一个mysql自增长的整数就会影响并发的能力，uuid生成也没那么简单，也要根据实际情况调整。比如说你的数据怎么sharding，以后怎么扩容，可以看看一致性哈希，再结合前面id算法，可以给你带来很多思考。然后跨多个数据中心怎么办，如果是一个可写其他只读，那我怎么知道去哪个数据中心写，其实还是可以做在那个id算法里。这些我觉得也可以自学，网上公开的资料很多。关于ID的算法，我也是最近玩go，仿制twitter的snowflake id做了一个用乐观锁的分布式ID算法。

现在的高并发服务不单单是线上的服务，还包括很多线下的服务，比如说大数据，这个也是不能忽视的部分。

最后才是实操经验，其实这主要让猎头和hr觉得你行，因为你干过。但你具体行不行技术面试一聊就知道了，再好的公司也不是各个都行。国内做得好的可以多看看阿里，但我不知道他们具体并发多少。如果你前面那些基础好，去阿里不会太难，去一个核心点的组，就接触到了。或者可以看看twitter的技术博客也有帮助(要翻墙)。