看看大神的指点

1. 程序的运行和加载，推荐程序员的自我修养一书。

2. 内存分配，推荐阅读Ptmalloc源码分析，无论是C还是C++程序员，这一部分是最容易踩雷的，多读一点基础的东西，会在解决实际问题的时候，不至于手足无措。以这些为基础，再结合Valgrind或Purify，相信效果会更好。

3. 多读一点C和C++开发的成功产品，如Apache Http Server和Nginx，这样就容易搞清楚在设计一个系统的时候需要有哪些关注点。 

• 是单进程还是多进程，是单进程多线程还是多线程单进程
• 进程间通信采用什么方式
• 消息的encoding/decoding以及message passing，每次都要自己写一次，不累吗，有没有好的开源实现，如Protobuffer、Thrift
• 对于一个Network Server来说，基本构架大体上还是相同的，acceptor→dispatcher→worker

4. 《深入理解计算机系统》真的是一本非常不错的书，为什么要这么说，软件的设计还是要以物理设备支持的特性为基础的，这本书让我们在CPU的级别来进一步思考程序设计。

若干年前，金庸群侠传这个游戏很流行，里头有一种武功初练稀松平常，但只要练到第10级，那就比降龙十八掌还厉害。学用C和C++也是如此吧，无它，唯勤而已。

CSDN： 您谈到了因为产品迁移到Linux Cluster所以深入的研究了IP Load Balance及OpenSAF，在这两个方面有可分享给读者的么？ 

许鹏： IP Load Balance这一块主要是对ipvs和nat的升级协议rsip作了一些研究。有关这方面的资料网上很多，也不敢乱加评论，如果想作细致深入学习的话，以lvs ipvs作为关键字搜一下就可以了。熟悉ipvs最好的方式还是试验加源码阅读，其源码已经在Linux内核之中，在network目录下。

OpenSAF是SAF的开源实现，主要目的是为了解决HA和Scalability的问题，对于电信产品来说，高可靠性始终是一个硬性的指标。SAF制定了一套齐备的标准，在开源实现方面情况变得有意思起来。OpenSAF基本上跟随了SAF标准，而其它一些则认为标准过于庞杂，而只选取其中一部分加以深化实施，如corosync和pacemaker。

CSDN：您花了大量的时间阅读Spark和Storm源码，并进行测试，对这两个计算框架您有做过比较吗？有什么结论可以为大家分享？

许鹏： 这是一个经常会被提及的问题，之所以如此就是因为两个产品都很优秀。Storm是专注于实时流计算的框架，在Twitter有大量成功的应用，其整体架构是非常易于理解的。Spark则更为通用一些，不仅支持实时流计算，也支持批处理，图及机器学习方面的应用。所以要对两者进行比较的话，我们还是将目标缩小到流处理这一块。

1. 从应用的广泛程度上来说，Storm可能拥有更多的用户基础。
2. 从处理速度上而言，似乎Spark更胜一筹。
3. 从当前整个项目的活跃度而言，Spark更为活跃。
4. Spark可以与Hadoop的新一代资源管理框架Yarn更为紧密的结合。
5. Spark有Cloudera的大力支撑，而Hortonwork则是Storm的最大推手，两家都是大数据处理领域的翘楚，一场龙争虎斗很值得期待。
6. Spark目前还缺少Storm所支持rebalance功能，不能动态利用新增加的节点。
7. Spark和Storm在支持“exactly-once”的处理上，有不同的实现，Spark是依赖于Spark，而Storm则是利用Trident来解决，TridentTopology对storm中基础的bolt和spout做了封装，让上层应用的开发更加关注于业务本身。
8. 二者有一个共同的缺点或毛病，就是对资源在较细粒度的调配方面，支持得还不够

CSDN：大量开源项目使用和学习经验，您对开源运动怎么看？如何才能更好的学习一个开源项目？开源项目使用时又该注意些什么？

许鹏： 开源项目离不开大家的广泛参与和支持，要让一个开源项目取得成功，有多个方面的因素。

• 产品本身的创新功能
• 在实际项目中的应用和推广，业界大佬企业的积极参与
• 教育培训市场的积极跟进，也是一个开源项目最终能够长久生存下来的必备因素

CSDN：能否分享一些您对当下大数据的看法？

许鹏： 大数据要解决的两大基本问题是“数据存储”和“数据分析”，在数据存储领域，开源实现方面似乎大家都已经首肯HDFS的方式，不再怀疑。

而在数据分析的计算框架方面，目前还有大量的竞争或博弈出现。Spark就是一例，分析领域除了基于传统关系型数据库的分析方式，还有图计算相关和机器学习为代表的数据挖掘。显然机器学习是一个大热门，这一方面个人所知甚少，不敢胡说八道，但门槛似乎很高，数学底子一定要好，决不是简简单单的调用几个API就完事了的。

云计算是大数据的支撑，虽然脱胎于虚拟化，不乏商业宣传的味道，但是大量机器的安装部署，如果全部使用物理机一台台去装，肯定会让人发疯，云计算让大规模部署和产品迁移变的更为简单。

CSDN：对于阅读源码您有着丰富的经验，对想阅读源码又不知道如何下手的同学可否做一些分享？

许鹏： 源码阅读其实是一个逆向的工程，这期间必须会遇到种种问题。一般来说，我会遵循这样一个思维范式——Problem domain→model→architecture&implementation→improvement→best practice。

1. 首先搞清楚要分析的产品解决的问题是什么，这个问题在哪个大的范畴里，也就是要搞清楚problem domain。一个著名的开源产品必定在Wikipedia上有相应的条目，所以一开始去看wikipedia是破题的一种极好方式。

2. 清楚要分析产品的大体框架和关键性的概念，也就是理解清楚architecture和key concept。

3. 将分析的产品实实在在的运行起来，我一般选择debian或archlinux作为工作平台，它们提供了丰富的软件包，可以很快的将东西安装并运行。熟悉Linux本身对于开源项目的源码阅读还是大有裨益的。

4. 修改日志级别，得到丰富的日志信息。有了这个为基础，再来开始真正的源码阅读和分析。

5. 源码分析的时候，要始终问这几个问题。

• 进程以及线程的启动顺序
• 搞清楚调用关系call flow

• 这一部分代码是在同一个进程中么，同一个线程中么，运行在同一台机器中么
• 每一个线程都要问清楚，什么时候启动的，什么时候停止的

• 消息传递的路径，针对每一个函数，搞清楚，input是谁传给我的，output要传给谁，由哪个来传
• 搞清楚上述的问题之后，就将最开始提到的对architecture的了解做到具体而微了。有了这个基础之后，再继续往下问

• 当前实现的性能如何，比如i/o, cpu, network 这个需要做相应的测试方面的试验
• 当前的解决方案还有优化空间吗，比如针对spark中的scheduling问题，就有sparrow的优化机制提出

6. 碰到具体的问题一时解决不了怎么办

• 用好google，用好stackoverflow
• 将碰到的问题模型化，写一些验证性的代码，或者是写一个小的demo来验证，我在解决许多很妖的bug，也是采用类似的思路
• 找到相应的用户论坛，发帖虚心请教
• 如果还是不行，就先搁一搁，去看能看懂的地方

7. 编程语言选择

• 源码阅读中可能遇到的一个问题就是这个语言是新近出来的，我根本没学过，我需要系统去掌握该语言之后，才能来看源码么。我的看法是可以边看边学，在掌握语言的过程中，牢牢把握住这几个问题

• 基本语法：数据类型、控制语句、函数定义
• 是否支持FP
• 多态和继承

• 现代编程语言基本上都混合了面向过程，面向对象和函数式编程的特点，即便是C++或新近的java8都如此。
• Storm用Clojure来编写，而Spark使用Scala，就语言的偏好来说，我更喜欢Clojure一些。 
  

稍微总结一下，我想源码分析心中要有两幅大图，将整体与局部很好的结合起来思考

• 一是太极图，要有整体性的思维，要对architecture有掌握，对其在整个生态系统中的定位要清楚，东方式的思维强调整体性
• 二是数学中常见的笛卡尔坐标体系，将大的问题拆分之后一一研究，做到具体而微，西方式的思维强调个性

CSDN：有什么可以补充给读者的？

许鹏： 选择自己感兴趣的东西，坚持做下去，一定会有回报，诚如《一代宗师》中所说的那样，“念念不忘，必有回响”。 

编码到底是一件技术活，还是一项艺术活，这是一个令人纠结的话题。 

最后，感谢CSDN的采访，谢谢那些为开源项目耗费大量精力的开发者。由于本人代码阅读时间比较仓促，错误在所难免，有不对的地方，敬请指出，学无先后，能者为师。

Storm&Spark源码走读

读源码是开源项目最好的学习方式，然而当项目规模达到一定程度时，就像许鹏所说，源码阅读其实是一个逆向的工程，这期间必须会遇到种种问题。这里我们为大家分享许鹏的Spark和Storm源码走读，方便大家学习。