为什么要结构化
笔者在学习知识时常常感觉知识碎片化不成体系，这种碎片化的学习方式有几个问题。
- 其一， 盲人摸象而产生的错误认识。举个例子来说rabbitmq的持久化其实需要消息、队列和exchange全部持久化，重启时exchange和queue重建并从磁盘读取消息；然而笔者在工作中常常有同事看到上述其中有一项是persistent的，并不追求rabbitmq的整体各个结构的关联就认为系统可靠，从而为项目埋下隐患。
- 其二，遇到问题时没有思考的章法。比如当 思考innodb持久型机制时，没有一个思维的顺序和架构，乱撒网式思考一会想到double write，一会想到redo log，很难定位问题也很难和别人沟通。一种比较好的方式是从一条sql执行的顺序，按核心环节串联所有innodb的知识点。
结构化的层次
与碎片化混乱化相反的是结构化和系统化，这种认知模型有两个层次：
- 第一个层次是具体性的针对问题的，比如TCP协议的整体架构，消息中间件的可靠性问题，这种结构化是和知识内容深度绑定的结构适配内容，内容在结构中展开；
- 第二个层次是一般性的，是一种面对位置问题组织思维的方式，通用也更抽象；这种一般性的系统框架可以非常简单，也可以非常复杂，举个例子来说：按照timeline分析就是一种非常常见的一般性思考方式；
具体性和一般性的有自己的粒度，和相对性；比如网络reliable的机制一般意义而言十分具体，可以从（1）信息是否可靠；（2）效率是否可靠；（3）两端重启时是否可靠；等角度结解构这个问题。但放到具体的某个协议中，比如TCP协议，用这个框架去思考TCP的具体机制时，这个结构就十分一般性，TCP保证消息可靠的方式和innodb保证数据可靠的方式不同有自己更具体更细粒度的实现方式。
如何结构化
那么如何建立结构化的认知呢？这里有3个建议：先粗后细，先小后大，总结提炼。
什么叫做先粗后细？拿rabbitmq为例子，可以先理解rabbitmq的核心模块的含义（exchange，producer，consumer等），了解他们之间的关系如何串联起来的就可以了。这样在很粗的粒度上，了解了整个rabbitmq的样貌，之后再每个环节去了解：比如关系可能展开成了各种routing模式等等。
这里注意这个例子里用了另一种一般性的结构框架：核心对象和关系分析的思维方式。
什么叫做先小后大？举个例子，当我们了解了rabbitmq的框架之后不要铺开学习也不要一上来就研究很全面很大的问题，这样往往会陷入认知混乱。这里的好的办法叫做从小处入手：按照结构可以先展开了解producer发消息的整个细节流程，再了解exchange内部做了什么工作等等。当一个个小问题击破后，就可以从整体二次串联研究比较大的问题：比如rabbitmq消息丢失的原因和措施，比如rabbitmq push和pull方案的对比选择。
最后一个要求叫总结提炼，一般性的结构往往是在多种学习研究中发现和总结出来的规律，常常梳理自己的认知框架有助于产生新的抽象和认识。同时，学习过程中往往不可避免有一定的碎片化的过程，很难一开始就把一个新问题结构化，所以如果在一个固定的问题上出现碎片化也不用着急，可以围绕这个问题梳理自己的认知，提炼结构。
