如何获得高并发的经验？

如何获得高并发的经验？要获得高并发经验要去大公司，然后大公司招聘要求高并发经验，感觉这是个死循环，没有高并发经验的人如何才能获取高并发方面的经验呢？从知乎看到几个大神说的特别好，所以给大家看下。

作者：北南

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

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

然后是分布式系统设计，这是经验和知识的结合，或者说就是用前面提到的基础来搭积木。这里最常用的就是如何分片sharding和负载均衡load balancer， 大家都知道更大的并发需要更多的服务器，但是你的分布式系统很可能加不了那么多服务器，这就是所谓的scalability.

http://highscalability.com/all-time-favorites/
https://www.mullie.eu/why-your-code-doesnt-scale/

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

还不能离开高可用，你搞5w台服务器，但只要坏一台全部服务完蛋肯定是不行的，如果有些服务坏掉或者重启，你需要能有一些应对和调整的策略。这有还很多细节，比如说id怎么生成，你用一个mysql自增长的整数就会影响并发的能力，uuid生成也没那么简单，也要根据实际情况调整。比如说你的数据怎么sharding，以后怎么扩容，可以看看一致性哈希，再结合前面id算法，可以给你带来很多思考。然后跨多个数据中心怎么办，如果是一个可写其他只读，那我怎么知道去哪个数据中心写，其实还是可以做在那个id算法里。
这些我觉得也可以自学，网上公开的资料很多。关于ID的算法，我也是最近玩go，仿制twitter的snowflake id做了一个用乐观锁的分布式ID算法。beinan/fastidwww.github.com现在的高并发服务不单单是线上的服务，还包括很多线下的服务，比如说大数据，这个也是不能忽视的部分。最后才是实操经验，其实这主要让猎头和hr觉得你行，因为你干过。
但你具体行不行技术面试一聊就知道了，再好的公司也不是各个都行。国内做得好的可以多看看阿里，但我不知道他们具体并发多少。如果你前面那些基础好，去阿里不会太难，去一个核心点的组，就接触到了。或者可以看看twitter的技术博客也有帮助(要翻墙)。

作者：冰封

自己在高并发设计方面折腾了好几年了。最重要是有高并发场景（大公司未必有这种场景），在这种场景下，如何提高吞吐量？如何降低响应时间？从这两个指标开始折腾到底。所以要获得高并发的经验：首先要有场景，有了场景，需要自己去了解方方面面相关的知识，在架构调优的同时，自己也能跟着成长了。但是因人而异，就算高并发场景给你了，也许只是遇到一个hbase读超时问题，就把你打倒了，排查了几周无果就轻易放弃了，退缩了。

动不动就怪服务器配置不行，晕。遇到问题至少你要知道，瓶颈是在哪里？而不是猜测！！在庞大的架构体系中，涉及那么多架构组件，影响性能的到底是谁？你必须把瓶颈定位出来，就是所谓的“对症下药”。例如你虽然开发过几十万行代码，Mysql新增改查无压力，但是你对sql语句性能、索引、行锁等不是很了解，高并发下一条update的sql语句就够致命了，锁住整张表，所有update都在等待，吞吐量死都上不去。所以要搞好高并发，在条件允许下，对技术要有很大的热度，从下到上涉及到的方方面面，从业务逻辑，从各个组件，从系统方面去做各种优化，各种突破，迫使你去了解更多底层的知识，不退缩中前进。

作者：朱元

不同公司嘴上的高并发不是一个概念。。前几天还遇到一位朋友不停的问如何实现高并发短信网关，结果居然设计目标也就单机单核500多qps…我目前只能说，机器撑不住了就算高并发了。。。其实这东西有几个点，0 怎么模拟高并发。你别说，很多人甚至写不出来高并发的客户端单元测试程序。

1. 达到机器撑不住的时候是什么场景，有什么症状，你有没有处理经验，可以是运维经验也可以是开发经验，甚至可以只是压测经验。

2. 撑不住之后是怎么去扩容或者削峰的，这个是否已经形成了可复用的方法论。

3. 撑不住了之后是否有“熔断机制”，避免流量扩散，影响到其实不该影响的业务。

4. 上述3点在你的知识体系中是否已经成为了一个完整的可重用架构？现在有一个新的save and forward and echo系统等待你去设计，你能基于上述3点获得的知识去设计出一个所gou谓pi的高并发系统吗？

作者：find goo

高并发不是难题，如nginx这样服务器软件可以在一台电脑上实现很高并发，再加个路由选择多台服务器反向代理，用redis建立缓存命中，处理高并发本身不是问题。类似微博的无事务高并发可以用这种框架。

但高并发+事务处理的确是世界难题，12306这种事务处理系统维护这么多年，在高并发事务处理时压力很大，事务处理需要是原子操作，要不完成，要不不完成，不能有中间状态，这就决定了事务处理时需要建立类似操作系统的临界区一样的机制来保护，在掉电等异常时有日志系统可以回退到初始状态，一但有了硬盘IO操作，事务处理就变得很慢，整条河流的瓶颈就卡在事务处理卡在IO速度这个闸门上。这时依赖通用系统来解决高并发时就力不从心，就需要根据业务模式来分析优化方向，如查询建立在缓存中，通过散列来进行路由选择，使用自定义快速算法代替数据管理系统的一些操作，修改操作系统数据库系统虚拟机系统参数，使用硬件加速，把运算展开成内存存储等。

商业公司如银行保险之类不差钱，可以用IBM,Oracle的解决方案，比较贵。互联网公司一般根据自身的业务特点，自行定制裁剪通用开源软件来完成，如memsql就是这种修改软件发展的，memsql以前靠租用亚马逊云系统来测试高并发，云端系统可以按小时租比较经济。

一般像nginx,redis,memcache,mongodb等开源软件多是高并发框架下的选择，可以看它们的源代码，工作机制，这类软件多为c/c++写的，近几年出现的node.js/go语言也是高发并的代表语言，node.js主要是面向事件模型在大规模应用上有一定的缺陷，go语言近年多用于开发云计算系统如docker,云盘软件,github可以找到相关源码，go语言相对比较底层，稳定性因为较新很多未知，适合开发基础框架。