阿里之路（二）

从今年7月到现在转眼间转岗到淘宝部门已经有小半年了，最近刚刚经历人生中第一次双11实战，体验了一把系统经受高并发高流量的冲击的感觉，一个字爽，作为小白，在这小半年里面收获颇多，一个感悟是实战是提高一个人能力的唯一真理，只有真的动手去做了，才会知道会遇到什么问题。日常做项目时候不怕遇到问题如何解决，最怕有些情景考虑不到，而后者是需要经验累积起来的，一方面是试错的累积，一方面是通过书本或者思考源码得来的。来淘宝这半年来为了能够学到更多，从来不敢浪费时间，一边欣赏这人家如何用代码解决高并发高流量问题，一边学着人家如何用工具快速高效的查询系统瓶颈与查找线上问题。

来淘宝后接受的是一个消息中间件系统，这个系统刚上线1年，而开发者也在我来之前的1个月转岗去了其他部门。还好有一些设计架构图可以参考，不得不说和看开源代码类似，有了设计图看代码是很爽的。由于之前有看源码的经验，在加上这个是中间件，涉及的业务场景很少，所以研究起来并不费劲。看了人家的代码才知道,哦，原来FutureTask是这样使用异步解决耗时比较大的操作从而减少rt的，原来多线程中有些方法参数必须深拷贝才能避免线程安全问题，原来服务端可以通过线程池来减少客户端远程调用的rt,原来线程池队列要设置大小为了避免内存爆掉，原来线程池队列满了后调用抛弃策略执行时候用的是业务线程（这个影响业务线程rt）,哦，原来缓存作用那么大，guava缓存那么吊.....

对于如何用代码解决高并发问题感悟是掌握并发编程基础尤为重要，比如并发包下的队列了，Map了的使用与原理了解，再比如并发队列的put和offer方法有啥区别那，使用时如何选择。还好在转岗前苦心研究了一把并发编程，为欣赏人家的代码奠定了基础，另外由理论到实践中间还是会采坑的，这里说的采坑是说由于经验不足造成写代码时候由于没有意识到所造成的并发安全问题，有些并发问题很微妙，不细细品味是很难避免的。

说起双11，历经2周几乎每天搞到凌晨3，4点的双11前压测不得不说下，由于这个系统才上线1年，经历过一次双11，今年流量是那次的5倍，再加上期间应该被改造过一些东西，压测时候还是压出来了一些问题。现在回头看来压测是模拟预估的流量(当然目前还是比较粗浅的认识)，比如预估直播同时在线为200W，那么压测时候就模拟出200W在线的用户，然后看集群系统的性能如何，具体比如cpu使用量，内存使用量，系统load情况，接口调用的QPS，rt等是否正常,说实话来淘宝前基本这些指标对我就是纸上谈兵。我们第一次压测时候出现了一些机器cpu和load非常高，通过dump线程堆栈分析发现是卡到了hashmap的put方法上，大家应该都知道hashmap在多线程下是线程不安全的，查看代码原来是4月份新增的一个功能竟然没有使用ConcurrentHashMap，这个是一个低级的错误，拉分支修改为ConcurrentHashMap问题解决。还有一个是服务端线程池满了，线程满一般是因为服务器执行过慢，通过查看cpu占用量top10的线程，发现都卡到了打日志的地方，而日志打印明明是异步的了，在一看原来是卡到了异步日志队列的put方法了，异步日志队列是一个阻塞有界队列，默认如果队列满会调用put方法 ，而这货是阻塞的，由于日志并不涉及统计信息使用，通过配置一个参数可以使用offer方法，offer方法是非阻塞，队列满则丢弃....

两周的压测没有白压，从11月10号到11月11的0点，系统没有出现问题，顺利的度过了高峰，不过挑战才刚刚开始...

最后打一个广告，努力很重要，环境更重要。来吧，淘宝欢迎你的加入，拿简历来砸晕我吧，邮箱1064454834@qq.com。