那些共性的技术思想

     从嵌入式，ｌｉｎｕｘ内核－＞机器学习（１个多月）－＞ｇｌｕｓｔｅｒｆｓ－＞ｋｖｍ　，ｏｐｅｎｓｔａｃｋ，网络－＞ｄｏｃｋｅｒ生态，到现在决定以后方向为ｇｏｌａｎｇ后端开发＋机器学习，数据挖掘，　出于各种原因，各种考量，大体方向总是变来变去，真心感叹伤不起，也侧面反映我先前还是属于半迷茫阶段，毕竟选择方向也可以理解为投资未来。

     反省下，方向的频繁转变，那之前学的是否是白学了呢?  去掉那些各个领域的逻辑，到底学了什么了。终结下来，其实还是有很多共性，很多东西底层思想都一样，不管何领域都会使用到。个人觉得，根本原因是　在基础架构没变，都是跑在图灵机机情况下，遇到的问题很多都是共性的，解决的方法思路当然也就相似，这个不会随着开发语言，平台而改变，只不过实现的差异罢了。

　　当然，无论如何，不是往一个领域方向专一研究，总是伤不起的，没有真正的核心竞争力。

高并发： 协程  epoll

     epoll  ：无论golang的sysmon线程监控网络，nodejs的非阻塞式回调机制（观察者模式），还是python的evnetlet ，glusterfs分布式文件系统进程之间的通信，看它们的原理，都会看到epoll的影子，毕竟一切都依赖系统嘛。

     协程：线程切换，是系统的工作，开销比较大， 而协程是用户态，通过栈来实现，不用切换到内核态，按需动态创建资源，可见更加的灵活高效，  如何利用好多核，进一步提高并发，这就看实现了。

 相关链接: goroutine背后的系统知识| sizeof(void)   

 锁问题  

 需要锁的最根本必要条件：（1）资源共享，(2)并发：

 而频繁用锁，锁的范围越大，性能就越影响，不用锁也就需要打破这两条中的一条即可：

     并发条件失效：为啥nodejs没有锁的库，通过非阻塞，单线程方式， 但是缺点 就是不能利用好多核的优点了。

    资源共享条件失效：如果不用锁机制的话，全局表下常见方式就是通过一个线程分配独立的空间。像内核的CPU变量，软中断的tasklet都是通过绑定到独立的cpu上，也算解除了并发的条件。 

 

 缓存，  性能  ，一致性  ，CAP理论

   从应用层到, 基本就是哪有IO，哪有就有缓存。缓存好处不用多说，主要就是提高性能嘛。凡是都有两面，提高性能的对面那就是一致性的问题 ，因此，再加一句，哪有cache，哪就有一致性问题，尤其对于分布式系统来说。对于搞存储的，我想CAP理论就并陌生了，多副本情况下，在性能，可用性面前，也就有强一致性和最终一致性的抉择。

    so 。凡事都是相对的，，当你获得了什么，批判性想想有没牺牲掉什么，最后来个折中。

相关链接：     

CAP理论1  Introduction to Distributed System Design CAP理论2     酷壳 – CoolShell.cn 相关blog

 空间换时间思想

我想这是最常见最常用的重要思想，无论以上的说的缓存，还是以下说的内存管理，hash思想 ，算法中的动态规划 ，都属于这是范围。

 哪有性能要求几乎也都能看到这身影。

内存管理 ：减少系统调用

   那些注重性能的，基本都自己的内存管理机制，多数采用技术也是malloc/map+ hash 。毕竟频繁调用系统接口伤不起，而基础软件很多要求高性能，看golang，redis 都基于tcmalloc，先map大块内存，再自己管理；glusterfs自己的mem_pool；内核的slab机制。。。。

      可以看高性能的基础软件通常通过自己管理内存，最根本原因就是尽量减少系统调用， 这也就很好解释为什么一些软件会消耗那么大内存了，（eg:golang ，redis, mongdb ）

分而治之思想

      化整为零，拷贝网络一段解释：任何一个可以用计算机求解的问题所需的计算时间都与其规模有关。问题规模越小，解题所需的计算时间往往也越少，从而也越容易计算。想解决一个较大的问题， 有时是相当困难的。分治法的思想就是，将一个难以直接解决的大问题，分割成一些规模较小的相同问题，以便各个击破，分而治之。分治的基本思想是将一个规模为n的问题分解为k个规模较小的子问题，这些子问题互相独立且与原问题相同。找出各部分的解，然后把各部分的解组合成整个问题的解。

    　例子：1.对于那些不能一次性载入内存的大文件进行排序，基本思路拆分成小文件快速排序，然后再归并排序了；像现在大数据处理MapReduce ;更广义，数据分片传输，再合并；大文件分片存储在不同节点上，访问时候再从各个节点上获取，　我想在大数据时代下，，分而治之思想也很常见的。

　　相关链接：海量数据处理：十道面试题与十个海量数据处理方法总结

简单唯美  

大道至简，无论解决问题，还是理论。感觉有些只可意会不可言传。

二八定律

       

编程思想

《深入浅出设计模式》就总结的很好了：

   封装变化（抽象！！） 

   多用组合，少用继承。   

   针对接口编程，而不针对实现编程。

    我觉得这本书所说的基本原则中，最基本的就是这3条了，其他原则，设计模式都能看到影子，扩展出来的。 我想只要很好理解，实践这3条，就比较容易写出灵活，扩展性好，维护性好的代码框架来吧。

     并且，就算没见过这本书，也能自然而然的写出能找到对应设计模式名的代码，毕竟设计模式更确切的称呼是常见的“编程经验”。

　　 就好比下象棋久了，然后再给你看给新手的棋谱，估计都有这样的想法：原理我这样的下法还有这么高大上的名字啊。

      现在想想，相对于其他传统的面向对象语言（c++，python等等），golang不就很好的精简的体现了3条，这才是面向对象的最简公式，简单唯美！

ps: 还是强烈推荐 酷壳 – CoolShell.cn  ，每次看，都有不同的感悟，感慨。毕竟是牛人的多年经验，总结。

ps ：哪有理解错误，望指出，谢谢！