昨天，讯飞开放平台第三期的技术沙龙如期进行，作为这次分享的组员之一，前期在确定主题为“高并发”后，也是花费了许多时间收集和整理资料。由于上一期的技术沙龙准备不是很充分，所以导师也是相当重视这次的分享，期望能拿出干货，让听者学有所成，要不然这沙龙就办不下了呀。毕竟与会者都是程序猿，自然Show me the code便是一条金科玉律，甭管那么多花里胡哨的，除了有理论，这次还必须言之有物，即有具体的代码和实例作支撑。
最开始导师用思维导图雕琢了雏形和逻辑的骨架，之后不断收集资料增添血肉，最后补充代码和实例，润色和排版，足足花费了近三个星期的时间，这期间大伙儿一起讨论，也提出了新的问题，为了构建有血有肉的材料，也是花了许多心思。这最终的目的其实就是只有一个，希望在一个小时的时间里面，真正让大家听到想听到的东西，能学到有意义的东西，而非浪费时间，然后沙龙也能够继续办下去，让越来越多的人能够参与进来，一起进步，共同学习，一同进步。
我们准备将内容分为五部分进行讲解：
高并发是一个出现在移动终端数量暴增和用户数日益膨胀的年代的一个概念。为了说明它，我们首先引入一个楼盘买房的场景，大家都一拥而上抢夺房源，势必会出现买不到心仪的房子的情况，这就是挤和抢。接着我们在现场展示了三个实例，用以说明高并发的会造成的危害：
- 用Jmeter模拟大量的用户并发访问未设防的服务器，压垮服务器的数据库服务，用以说明拒绝服务
- 多进程易出现死锁
- 多线程下的数据不一致问题
我们接着在第二章里揭示了高并发难以解决的原因，最本质的原因就是我们比较难做到一心二用，即用大脑模拟计算机的多线程，所以在编写高并发场景下的代码，天生地容易出错。再加上大流量的情况具有时效性，测试时的模拟很难复刻实际情况的流量冲击，所以往往许多问题测试时发现不了，却在实际高并发的冲击下暴露了出来。
然后我们详细地讨论了C10K问题的四个模型，并且抛出了分布式系统下经典的CAP问题。
CAP问题揭示了一致性、分区容错性和可用性，这三个我们都追求的性质，只能取其中两者，一旦满足了其中两个性质，那么第三个性质一定会满足不了。换句话来说，在分布式系统中绝对的完美是不存在的。
在第三章节中我们解析了天猫双一背后的技术，面对滔天巨浪般的购物狂们的狂轰滥炸，仍能维持正常的服务，这是怎么做到的？阿里官方尽是铺天盖地的宣传，对外宣称自己又完美地服务了一次双十一，但是在文案君们华丽的词藻下，技术的细节都被封装成宣传的代名词，而技术细节都被隐藏起来了。只摸到一点点门道，就是阿里自行开发的消息中间件RocketMQ、资源自动调度系统和TimeTunnel。
比较有意思的是阿里云实现了一个资源自动调度（扩容）的算法，使用机器依照情况，根据模型自动分配计算和存储资源。下图是算法的核心计算式，但是对于其中参数的计算方法并未找到，还有一张是双十一当日采用资源调度系统的资源分配情况。
第四章讲解了讯飞开放平台曾经遇到过的高并发的问题，在最后的第五章则给出一套完整的解决思路，算是一个方法论吧。个人觉得整理的还是蛮清晰的，分了三个层次来讲，一是工具层面，使用一些工具来进行压力测试、监测等工作；二是应对高并发的手段和思路；三是从事前、事中和事后三个维度来阐明需要做什么。
最后着重讲解诸如“压力测试怎么做”、“代码审查如何做”、“系统水位如何预估”等问题，抛出银弹和短板的总结。
何为银弹，我从百度百科上摘取了如下的讲解：
在欧洲中世纪的传说中，有一种叫“人狼”的妖怪，就是人面狼身。它们会讲人话，专在月圆之夜去袭击人类。而且传说中对“人狼”用一般的枪弹是不起作用的，普通子弹都伤不到也打不死它，只有一种用银子作成的特殊子弹才能把它杀死。Brooks在他最著名的随笔文章《No Silver Bullet》里引用了这个典故 ，说明在软件开发过程里是没有万能的终杀性武器的，只有各种方法综合运用，才是解决之道。而各种声称如何如何神奇的理论或方法，都不是能杀死“软件危机”这头人狼的银弹。他当时大胆声称并预言方法学家们10年之内绝找不到什么好的的神奇银弹。他的文章发表后，被广泛引用，后来他的随笔结集成书，《人月神话》。从此，在软件界，银弹（Silver Bullet）成了一个通用的比拟流行开来。1975年所出版的《人月神话》—被称为软件工程圣经。
写的真好，