MyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。

下面先让我们回答一些问题：

• 你的数据库有外键吗？
• 你需要事务支持吗？
• 你需要全文索引吗？
• 你经常使用什么样的查询模式？
• 你的数据有多大？

思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从InnoDB中获得全文索引。

数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB只需要几分钟。

您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts 语句在MyISAM下会快一些，但是updates 在InnoDB 下会更快一些——尤其在并发量大的时候。

所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM 也许会更适合。当然，在大型的环境下使用MyISAM 也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方式。但需要记住InnoDB 的表需要更多的内存和存储，转换100GB 的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。

原文：https://coolshell.cn/articles/652.html

1、主键
主键ID，可以一列或多列，主键既是约束也是索引且是唯一索引，同时也用于对象缓存的键值。

2、索引
组合或者引用关系的子表（数据量较大的时候），需要在关联主表的列上建立非聚集索引（如订单明细表中的产品ID字段、订单明细表中关联的订单ID字段）

索引键的大小不能超过900个字节，当列表的大小超过900个字节或者若干列的和超过900个字节时，数据库将报错。

表中如果建有大量索引将会影响INSERT、UPDATET、DELETE语句的性能，因为在表中的数据更改时，所有的索引都将必须进行适当的调整。需要避免对经常更新的表进行过多的索引，并且索引应保持较窄，列要尽可能的少。

为经常用于查询的谓词创建索引，如用于下拉参照快速查找的code、name等。在平台现有下拉参照的查询sql语句中的like条件语句要改成不带前置通配符。还有需要关注Order By和Group By谓词的索引设计，Order By和Group By的谓词是需要排序的，某些情况下为Order By和Group By的谓词建立索引，会避免查询时的排序动作。

对于内容基本重复的列，比如只有1和0，禁止建立索引，因为该索引选择性极差，在特定的情况下会误导优化器做出错误的选择，导致查询速度极大下降。

当一个索引有多个列构成时，应注意将选择性强的列放在前面。仅仅前后次序的不同，性能上就可能出现数量级的差异。

对小表进行索引可能不能产生优化效果，因为查询优化器在遍历用于搜索数据的索引时，花费的时间可能比执行简单的表扫描还长，设计索引时需要考虑表的大小。记录数不大于100的表不要建立索引。频繁操作的小数量表不建议建立索引，例如记录数不大于5000条。

索引与排序
指定列的索引就相当于对指定的列进行排序，为什么要排序呢？

因为排序有利于对该列的查询，可以大大增加查询效率。那么可能有人认为应该对所有的列排序，这样就可以增加整个数据库的查询效率。这样的想法是错误的，原因是建立索引也是要消耗系统资源的，给每个表里的每个列都建立索引那么将对系统造成极大的负担，那就更别提效率了！简单的说建立一个列的索引，就相当与建立一个列的排序。

主键其实就是一个索引（特殊的唯一索引），但是这个索引跟一般的索引有所不同。主键所在的列里的每一个的记录都是唯一的，也可以说不能在主键里出现相同的记录，在同一个表里只能有一个主键。

主键等于索引，索引不一定等于主键，简单的说主键就是所在列不能出现相同记录的特殊索引，而且这个索引只能在表里出现一次。

唯一索引与主键索引的比较
唯一索引
唯一索引不允许两行具有相同的索引值。
如果现有数据中存在重复的键值，则大多数数据库都不允许将新创建的唯一索引与表一起保存。当新数据将使表中的键值重复时，数据库也拒绝接受此数据。例如，如果在 employee 表中的职员姓氏(lname) 列上创建了唯一索引，则所有职员不能同姓。

主键索引
主键索引是唯一索引的特殊类型，其唯一索引名为primary。
表的主键，数据库表通常有一列或多列组合，其值用来唯一标识表中的每一行。
在数据库关系图中为表定义一个主键将自动创建主键索引，主键索引是唯一索引的特殊类型。主键索引要求主键中的每个值是唯一的。当在查询中使用主键索引时，它还允许快速访问数据。

二者比较：
主键创建后一定包含一个唯一性索引，唯一性索引并不一定就是主键

(1) 对于主健/unique constraint ， oracle/sql server/mysql等都会自动建立唯一索引；
(2) 主键不一定只包含一个字段，所以在主键的其中一个字段建唯一索引还是必要的；
(3) 主健可作外健，唯一索引不可；
(4) 主健不可为空，唯一索引可；
(5) 主健也可是多个字段的组合；
(6) 在 RBO 模式下，主键的执行计划优先级要高于唯一索引；

主键严格于唯一索引体现：
a. 主键有not null属性
b. 主键在每个表只能有一个

主键与唯一索引的区别
主键是一种约束，唯一索引是一种索引，两者在本质上是不同的

1. 主键一定是唯一性索引，其索引名为 primary，唯一性索引并不一定是主键
2. 一个表中可以有多个唯一性索引，但只能有一个主键
3. 主键列不允许空值，而唯一性索引列允许空值

原文：https://blog.mimvp.com/article/7462.html

Node.js 开发一般不容易遇到真正的模块循环依赖的情况，可是当你的项目开始达到一定的复杂度之后，你很有可能在你的 Node.js 编码生涯中遇到几次。而且如果你之前没有关于这方面的意识，Debug 可能会花费不少的时间。

我在最近的项目中就遇到了这种情况，而且不能轻易通过项目架构的重构来解决。具体来说，A 文件中需要用 B 文件中某些函数，B 文件又需要用到 A 文件中的某些函数。

定义问题

实际上，Node.js 官网上就有关于模块循环 require() 的说明。

在官网给出的例子中，有 3 个模块：main.js、a.js、b.js。其中 main.js 有对 a.js 和 b.js 的引用，而 a.js 和 b.js 又是相互引用的关系（详细情况请参阅上段末的超链接）。

官网上点出了这种模块循环的情况，并且解释清楚了原因（但并没有给出具体可行的解决方案）：

When main.js loads a.js, then a.js in turn loads b.js. At that point, b.js tries to load a.js. In order to prevent an infinite loop, an unfinished copy of the a.jsexports object is returned to the b.js module. b.js then finishes loading, and its exports object is provided to the a.js module.

简单说就是，为了防止模块载入的死循环，Node.js 在模块第一次载入后会把它的结果进行缓存，下一次再对它进行载入的时候会直接从缓存中取出结果。所以在这种循环依赖情形下，不会有死循环，但是却会因为缓存造成模块没有按照我们预想的那样被导出（export，详细的案例分析见下文）。

官网给出了三个模块还不是循环依赖最简单的情形。实际上，两个模块就可以很清楚的表达出这种情况。根据递归的思想，解决了最简单的情形，这一类任意大小规模的问题也就解决了一半（另一半还需要探明随着问题规模增长，问题的解将会如何变化）。

下面是一个两个模块循环依赖的问题最简情形：

A.js:

1
2
3
4
5
6
7
8
9

let b = require('./B');

console.log('A: before logging b');
console.log(b);
console.log('A: after logging b');

module.exports = {
    A: 'this is a Object'
};

B.js:

1
2
3
4
5
6
7
8
9

let a = require('./A');

console.log('B: before logging a');
console.log(a);
console.log('B: after logging a');

module.exports = {
    B: 'this is b Object'
};

运行 A.js，将会看到如下输出：

1
2
3
4
5
6

B: before logging a
{}
B: after logging a
A: before logging b
{ B: 'this is b Object' }
A: after logging b

JavaScript 作为一门解释型的语言，上面的打印输出清晰的展示出了程序运行的轨迹。在这个例子中，A.js 首先 require 了 B.js, 程序进入 B.js，在 B.js 中第一行又 require 了 A.js。

如前文所述，为了避免无限循环的模块依赖，在 Node.js 运行 A.js 之后，它就被缓存了，但需要注意的是，此时缓存的仅仅是一个未完工的 A.js（an unfinished copy of the a.js）。所以在 B.js require A.js 时，得到的仅仅是缓存中一个未完工的 A.js，具体来说，它并没有明确被导出的具体内容（A.js 尾端）。所以 B.js 中输出的 a 是一个空对象。

之后，B.js 顺利执行完，回到 A.js 的 require 语句之后，继续执行完成。

解决问题

想要解决这个问题有一个很简明的方法，那就是在循环依赖的每个模块中先导出自身，然后再导入其他模块（对于本文的举例来说，实际只需改动 A.js 就可以达到效果）。

话不多说，放码过来：

A.js:

1
2
3
4
5
6
7
8
9

module.exports = {
    A: 'this is a Object'
};

let b = require('./B');

console.log('A: before log b');
console.log(b);
console.log('A: after log b');

B.js:

1
2
3
4
5
6
7
8
9

module.exports = {
    B: 'this is b Object'
};

let a = require('./A');

console.log('B: before log a');
console.log(a);
console.log('B: after log a');

此时，在 A 和 B 中，都在 require 之前就导出了自身需要导出的模块，此时输出则是这样：

1
2
3
4
5
6

B: before log a
{ A: 'this is a Object' }
B: after log a
A: before log b
{ B: 'this is b Object' }
A: after log b

可以看到 B 中按我们的预期输出了 A 中导出的值。

这种解决办法可行的原因也很简单，还是因为 JavaScript 是一门解释型的语言，在 require 其他模块之前，已经把自身需要导出的部分都导出了，所以即便有模块载入缓存，也不影响最终结果按预期进行。

这种办法几乎没什么副作用，唯一稍令强迫症感到不快就是这种顺序与我们通常的书写顺序不符。一般我们都会先把 require 写在源文件开头，exports 放到后面的位置。唯一需要祈祷的是，之后接手项目的代码猴儿不会因为觉得这个顺序看着碍眼又把它改回去。鉴于此点，在导入导出语句上添加合理的解释性注释变得很重要。

其他相关问题

实际上，我还自己实验并查阅了一些资料来探索是否有其他的解决办法，但那些办法要么是适用于特定的情形和设计模式之下，要么就没有上述方法简洁，本文就不赘述了。如果有兴趣，可以参看本文末尾的 References 链接。如果你发现有更好的解决办法，欢迎在评论区留言。

要想彻底弄明白 Node.js 模块加载的相关问题，一定得去读读 Node.js 相关部分的源码。其次，推荐阅读《深入浅出 Node.js》第二章与阮一峰的这篇日志。

有趣的是，ES6 特性中已经有了更优秀的 import/export 模块加载机制，就不会存在这样的问题（原因参考 References 第5条），然而 Node.js 还并不支持。Github 上有人提出过这个问题，Node.js 基金会成员 @bnoordhuis 对此的回复是：

In a nutshell, require() is not going anywhere - removing it would break too much for too little gain - but we’ll almost certainly end up supporting ES6 import/export somehow, details TBD.

Support for ES6 modules first needs to land in V8.

详细的讨论可以到这里查看。

虽然因为 V8 的原因 Node.js 官方还不能支持 import/export，不过我们依然可以借助 Babel 来提前在 Node.js 使用这个特性，感兴趣的同学可以参考这里。

References

1. Modules | Node.js Documentation
2. Circular dependencies in node.js
3. node.js的循环依赖 - cnode
4. Node.js 中的循环依赖 - sf
5. JavaScript 模块的循环加载 - 阮一峰
6. nodejs中模块循环依赖的解决方案 #65

原文

http://maples7.com/2016/08/17/cyclic-dependencies-in-node-and-its-solution/

前言

区块链是加密货币背后的技术，是当下与VR等比肩的热门技术之一。最初接触区块链的小伙伴，感觉非常茫然，无从下手，原因是区块链本身不是什么新技术，类似于Ajax，说它是一种技术架构，或许更加确切。所以，这篇文章我们就从架构设计的角度，谈谈区块链的技术实现，无论你擅长什么编程语言，都能够参考这种设计去实现一款区块链产品。当然，具体到产品，架构设计有很多种，不同的人、不同的产品，架构设计也不尽相同，我们这里仅仅提供一种参考，让读者能够直观的感受区块链的技术实现，并顺便梳理与之相关的知识体系，帮助大家更进一步去学习研究。

基本概念

区块链的概念最近很火，它来自于比特币等加密货币的实现，但是目前，这项技术已经逐步运用在各个领域。什么是区块链技术？为了感性认识这个问题，我们可以使用谷歌地球的例子做类比，ajax不是什么新技术，但组合在一起就成就了产品谷歌地球，与之类似，区块链也不是什么新技术，但与加密解密技术、P2P网络等组合在一起，就诞生了比特币。技术人员，特别是Web开发工程师，学习了解ajax技术最早是被谷歌地球酷炫的效果所吸引。而现在，历史再一次重演，很多人被比特币的疯狂发展所吸引，进而开始研究其背后的技术——区块链。

区块链作为比特币背后的技术，无需中心服务器，可实现各类存储数据公开、透明、可追溯。原本是比特币等加密货币存储数据的一种独特方式，是一种自引用的数据结构，用来存储大量交易信息，每条记录从后向前有序链接起来，具备公开透明、无法篡改、方便追溯的特点。实际上，这种特性也直接体现了整个比特币的特点，因此使用区块链来概括加密货币背后的技术实现是非常直观和恰当的。区块链是一项技术，加密货币是其开发实现的一类产品（含有代币，也有不含代币的区块链产品），不能等同或混淆。与加密货币相比，区块链这个名字抛开了代币的概念，更加形象化、技术化、去政治化，更适合作为一门技术去研究、去推广。

所以，目前当大家单独说到区块链的时候，就是指的区块链技术，是实现了数据公开、透明、可追溯的产品的架构设计方法，算作广义的区块链。而当在具体产品中谈到区块链的时候，可以指类似比特币的数据存储方式，或许是数据库设计，或许是文件形式的设计，这算作狭义的区块链。广义的区块链技术，必须包含点对点网络设计、加密技术应用、分布式算法的实现、数据存储技术的使用等4个方面，其他的可能涉及到分布式存储、机器学习、VR、物联网、大数据等。狭义的区块链仅仅涉及到数据存储技术，数据库或文件操作等。本文的区块链，指的是广义的区块链。

架构图

从架构设计上来说，区块链可以简单的分为三个层次，协议层、扩展层和应用层。其中，协议层又可以分为存储层和网络层，它们相互独立但又不可分割。如图：

协议层

所谓的协议层，就是指代最底层的技术。这个层次通常是一个完整的区块链产品，类似于我们电脑的操作系统，它维护着网络节点，仅提供Api供调用。通常官方会提供简单的客户端（通称为钱包），这个客户端钱包功能也很简单，只能建立地址、验证签名、转账支付、查看余额等。这个层次是一切的基础，构建了网络环境、搭建了交易通道、制定了节点奖励规则，至于你要交易什么，想干什么，它一概不过问，也过问不了。典型的例子，自然是比特币，还有各种二代币，比如莱特币等，本书介绍的亿书币也是。这个层次，是现阶段开发者聚集的地方，这说明加密货币仍在起步当中。

从用到的技术来说，协议层主要包括网络编程、分布式算法、加密签名、数据存储技术等4个方面，其中网络编程能力是大家选择编程语言的主要考虑因素，因为分布式算法基本上属于业务逻辑上的实现，什么语言都可以做到，加密签名技术是直接简单的使用（请看书中相关的加密解密文章，不建议自由发挥，没有过多的编码逻辑），数据库技术也主要在使用层面，只有点对点网络的实现和并发处理才是开发的难点，所以对于那些网络编程能力强，对并发处理简单的语言，人们就特别偏爱。也因此，Nodejs开发区块链应用，逐渐变得更加流行，Go语言也在逐渐兴起。

上面的架构设计图里，我把这个层面进一步分成了存储层和网络层。数据存储可以相对独立，选择自由度大一些，可以单独来讨论。选择的原则无非是性能和易用性。我们知道，系统的整体性能，主要取决于网络或数据存储的I/O性能，网络I/O优化空间不大，但是本地数据存储的I/O是可以优化的。比如，比特币选择的是谷歌的LevelDB，据说这个数据库读写性能很好，但是很多功能需要开发者自己实现。目前，困扰业界的一个重大问题是，加密货币交易处理量远不如现在中心化的支付系统（银行等），除了I/O，需要全方位的突破。

分布式算法、加密签名等都要在实现点对点网络的过程中加以使用，所以自然是网络层的事情，也是编码的重点和难点，《Nodejs开发加密货币》全书分享的基本上就是这部分的内容。当然，也有把点对点网络的实现单独分开的，把节点查找、数据传输和验证等逻辑独立出来，而把共识算法、加密签名、数据存储等操作放在一起组成核心层。无论怎么组合，这两个部分都是最核心、最底层的部分，都是协议层的内容。

扩展层

这个层面类似于电脑的驱动程序，是为了让区块链产品更加实用。目前有两类，一是各类交易市场，是法币兑换加密货币的重要渠道，实现简单，来钱快，成本低，但风险也大。二是针对某个方向的扩展实现，比如基于亿书侧链，可为第三方出版机构、论坛网站等内容生产商提供定制服务等。特别值得一提的就是大家听得最多的“智能合约”的概念，这是典型的扩展层面的应用开发。所谓“智能合约”就是“可编程合约”，或者叫做“合约智能化”，其中的“智能”是执行上的智能，也就是说达到某个条件，合约自动执行，比如自动转移证券、自动付款等，目前还没有比较成型的产品，但不可否认，这将是区块链技术重要的发展方向。

扩展层使用的技术就没有什么限制了，可以包括很多，上面提到的分布式存储、机器学习、VR、物联网、大数据等等，都可以使用。编程语言的选择上，可以更加自由，因为可以与协议层完全分离，编程语言也可以与协议层使用的开发语言不相同。在开发上，除了在交易时与协议层进行交互之外，其他时候尽量不要与协议层的开发混在一起。这个层面与应用层更加接近，也可以理解为B/S架构的产品中的服务端（Server）。这样不仅在架构设计上更加科学，让区块链数据更小，网络更独立，同时也可以保证扩展层开发不受约束。

从这个层面来看，区块链可以架构开发任何类型的产品，不仅仅是用在金融行业。在未来，随着底层协议的更加完善，任何需要第三方支付的产品都可以方便的使用区块链技术；任何需要确权、征信和追溯的信息，都可以借助区块链来实现。我个人觉得，这个目标应该很快就能实现。

应用层

这个层面类似于电脑中的各种软件程序，是普通人可以真正直接使用的产品，也可以理解为B/S架构的产品中的浏览器端（Browser）。这个层面的应用，目前几乎是空白。市场亟待出现这样的应用，引爆市场，形成真正的扩张之势，让区块链技术快速走进寻常百姓，服务于大众。大家使用的各类轻钱包（客户端），应该算作应用层最简单、最典型的应用。很快，亿书将基于亿书网络推出文档协作工具，这个就是典型的应用层的产品。

限于当前区块链技术的发展，亿书只能从协议层出发，把目标指向应用层，同时为第三方开发者提供扩展层的强大支持。这样做既可以避免贪多，又可以避免无法落地，是真正理性的开发路线。因为纯粹的开发协议层或扩展层，无法真正理解和验证应用层，会脱离实际，让第三方开发者很难使用。如果仅仅考虑应用层，市面上又找不到真正牢固、易用的协议层或扩展层的产品。所以，我们只好全面发力，采取完全开源开放的态度，通过社区的力量，共同去做一件有意义的事情，也算为中国区块链技术发展做点技术积累和微薄贡献。

编程实现

很多小伙伴，习惯结合自己的技术背景，来理解上面的架构设计。这里，结合具体的编程语言，简单介绍几款产品，仅供参考。

（1）C/C++

这两个语言是无法逾越的，任何开发遇到瓶颈，基本上都会找到它们，自然应该排在第一位要介绍的。同时，区块链技术的鼻祖，比特币（协议层）就是用C++语言开发的，而且目前为止，没有比比特币更加成功的区块链产品。所以，无论你使用什么语言开发，在正式进入这个行业的过程中，都应该先研究研究比特币。比特币官方客户端钱包用的Qt，第三方钱包有Python语言开发的，特别是第三方整理的开发库（Api包）很多是Nodejs设计的。比特币的架构，与上面的架构设计基本相同，另外，因为共识算法采用的是工作量证明机制（PoW:Proof of work)，还有一些特殊的挖矿的过程。其他竞争币都是直接来自比特币的分支，所以编程语言相同，具体的技术选型和技术实现上可能有所改进，比如：莱特币，使用了其他的加密算法。

官方网站：https://bitcoin.org/

源码库：https://github.com/bitcoin

（2）Nodejs/Javascript

Nodejs平台强大的网络编程能力，以及js脚本语言的简单快捷，在区块链领域自然少不了它的身影。亿书便是这样一个区块链产品，亿书币是它的协议层，使用了著名的express开发框架，基于http协议开发而成。同时，它采用了授权股权证明机制（DPoS），算法上的改进，让它在处理交易时更加轻量，处理能力大大提升。它提供了强大的协作机制，为数字出版、版权保护提供了便利；扩展了侧链功能，可以基于它开发任何去中心化的应用，从而为专业作者、博客爱好者和开发者提供很多方便。《Nodejs开发加密货币》这本书完整分享了它的源码，从区块链基础概念到代码实现，从基本原理到开发设计思路，都做了比较详细的探索，目前为止，从协议层面深入代码讲解区块链技术实现的书籍极少，这算作一本。

官方网站：http://ebookchain.org/

源码库：https://github.com/Ebookcoin

（3）Python

如果是Python语言爱好者，我建议研究研究以太坊（Ethereum）的Python实现。尽管因为The Dao事件闹得沸沸扬扬，但从技术实现的角度来说，仍然值得参考学习。以太坊官方定位为一种开发管理分布式应用的平台，主攻方向就是“智能合约”，并为其定制了一种编程语言Solidity。以太坊的核心是以太坊虚拟机（EVM），允许用户按照自己的意愿创建操作。以太坊给出了Go、Java、Python等多语言的实现。其中以python为基础的实现主要包括三个部分：Pyethapp是客户端部分；pyethereum是核心库，实现了区块链、以太坊模拟机和挖矿等功能；pydevp2p是点对点网络库，实现了节点发现、合约代码传输、加密签名等功能，这三者组合在一起就是完整的区块链实现，后面两个核心库共同组成了协议层。另外，go-ethereum是go语言的完整实现；Ethereum(J) 是纯Java实现，它作为可以嵌入任何Java/Scala项目的库提供。客户端方面，还有Rust、Ruby、Javascript等语言的实现。

官方网站：https://ethereum.org/

源码库：https://github.com/ethereum/pyethapp

（4）Go

在多核时代，Go语言备受喜爱，它可以让你用同步方式轻松实现高并发，特别是在分布式系统、网络编程等领域，应用非常广。所以，在区块链开发领域，也有很多使用Go语言的项目。其中，由linux基金会主导的超级账本（HyperLeger），版本库的名字叫Fabric，就是其中一个。该项目试图为新一代的事务应用创建一种开放的分布式账本标准，支持许可式区块链（这种方式可能无法再现比特币那种强大的网络效应）。Fabric的开发环境建立在VirtualBox虚拟机上，部署环境可以自建网络，也可以直接部署在BlueMix上，部署方式可docker化，支持用Go和JavaScript开发智能合约。它采用PBFT分布式算法，网络编程方面用gRPC来做P2P通讯，使用 Protocol Buffer来序列化要传递的数据结构。在架构设计上，Fabric可能与比特币等区块链产品有所不同，但是上述基本组成部分还是不可或缺的。

官方网站：https://www.hyperledger.org/

源码库：https://github.com/hyperledger

其他编程语言，比如：C#等，也有具体实例，这里就不再列举。总之，针对不同的编程语言，在具体的编码或架构设计上可能有所差别，甚至很大，但是协议层所使用的技术并没有太大的变化。其中，网络编程是重点和难点，多数没有现成的框架可用，都是使用编程语言自身提供的库来设计开发，所以比较底层，非常考验开发者的编码功底。

知识图谱

循着上面的分析，我们已经可以了解区块链是什么，并知道怎么实现了，顺便梳理一下其中的编程技术知识，自然也就清晰多了。

根据个人的理解，我把与区块链相关的知识分为下面5个方面：

（1）基础知识

区块链是新技术，与之相关的是其背后大量的新概念、新理论。这些知识，虽然不直接体现在编码里，但却是理解区块链，掌握区块链技术的基本知识。所以，理当成为区块链技术不可或缺的一部分。这部分从基本概念入手，到工作原理的描述，就能够把区块链基础知识全部覆盖。

（2）技术实现

区块链是一项技术，但从上面的分析可以看出，它应该是一种架构应用，架构的实现理当是我们知识库的核心。正如大家看到的，任何一款区块链产品，协议层必须包括点对点网络、加密签名、数据存储、分布式算法等4个部分，应用层也必然要提供钱包、客户端浏览器等基础应用。所以，把这部分独立出来，也是合情合理。

在扩展层的部分，区块链技术可以对接各种应用，比如：金融、物联网、网络安全、版权保护、电子商务等等，现有的很多技术都可以用在这里。只不过，如何与区块链结合，如何实现跨行业使用，自然是这部分内容研究的课题。所以，这里所罗列或涉及到的技术，理应归为技术实现的一个重要部分。

（3）开发环境

区块链是多项技术的组合，有其自身的复杂性，个别应用对开发环境依赖较大，开发工具与环境搭建，是让开发者快速上手的重要内容。

（4）项目实践

据说，短短数年，全球区块链产品已经有几千个，其中不乏创新应用。有些优秀的开源产品和项目实践，是最好的学习研究资料。

（5）开发文档

这个自然不用说了，每一种产品也都会有自己的开发文档。另一个，就是有心的开发者整理汇总的一些资源，可以帮助我们节省很多查询的时间。

在考虑这个知识体系的过程中，主要思考的是，读者循着这些标签去查阅文章，能否快速掌握区块链技术，并最终上手开发实现一个区块链产品。另外，也刻意规避了与具体编程语言，以及特定领域相关的词汇，唯一可以区分的就是这些节点之下对应的文章标签。所以，这些分类就显得非常中性。也考虑过使用比特币、竞争币、智能合约、数字资产、智能资产等具体领域的实现作为分类方法，但又怕限制了读者的思维，同时随着区块链的发展，新概念将会层出不穷，那样这个图谱就需要不停的修改下去。

总结

这篇文章，我们把区块链技术基础架构描述了一下，需要再次强调的是，这仅仅是一种实现方式，绝非所有的区块链产品都是如此，我们也期待更多创新出现，也相信一定会出现。文章的编程实现部分，罗列了几种编程语言与其实现的典型产品，因为协议层技术较为底层，并没有太多现成的框架需要介绍或讨论，同时，具体的技术细节，也绝非几行字能够罗列清楚，所幸，这些产品都是开源产品，大家可以结合自己的技术背景，进一步查看对应的产品源码，很快就能了解其中的奥妙。

顺便说一下，这篇文章，是应CSDN知识库专家组邀请，为发起并筹建区块链知识库而写的推介文章，目的是帮助更多的程序员小伙伴通俗的感性的认识和了解区块链，权当抛砖引玉。CSDN作为国内著名的技术社区，始终走在技术前沿，该文最先被CSDN发布在主页头条位置，后来被巴比特论坛等多家网络媒体转载。

原文

https://cnodejs.org/topic/58044db0487e1e4578afb57e

2009年，Node.js 项目诞生，所有模块一律为 CommonJS 格式。

时至今日，Node.js 的模块仓库 npmjs.com ，已经存放了几十万个模块，其中绝大部分都是 CommonJS 格式。

这种格式的核心就是 require 语句，模块通过它加载。学习 Node.js ，必学如何使用 require 语句。本文通过源码分析，详细介绍 require 语句的内部运行机制，帮你理解 Node.js 的模块机制。

一、require() 的基本用法

分析源码之前，先介绍 require 语句的内部逻辑。如果你只想了解 require 的用法，只看这一段就够了。

下面的内容翻译自《Node使用手册》。

当 Node 遇到 require(X) 时，按下面的顺序处理。

1. 如果 X 是内置模块（比如 require(‘http’）)
   　　- 1.1. 返回该模块。
   　　- 1.2. 不再继续执行。

2. 如果 X 以 “./“ 或者 “/“ 或者 “../“ 开头

   • 2.1. 根据 X 所在的父模块，确定 X 的绝对路径。
   • 2.2. 将 X 当成文件，依次查找下面文件，只要其中有一个存在，就返回该文件，不再继续执行。

     - X                                
     - X.js
     - X.json
     - X.node
     

   • 2.3. 将 X 当成目录，依次查找下面文件，只要其中有一个存在，就返回该文件，不再继续执行。

     - X/package.json（main字段）                                 
     - X/index.js
     - X/index.json
     - X/index.node
     

3. 如果 X 不带路径
   　　- 3.1. 根据 X 所在的父模块，确定 X 可能的安装目录。
   　　- 3.2. 依次在每个目录中，将 X 当成文件名或目录名加载。

4. 抛出 “not found”

请看一个例子。

当前脚本文件 /home/ry/projects/foo.js 执行了 require(‘bar’) ，这属于上面的第三种情况。Node 内部运行过程如下。

首先，确定 x 的绝对路径可能是下面这些位置，依次搜索每一个目录。

1
2
3
4

/home/ry/projects/node_modules/bar
/home/ry/node_modules/bar
/home/node_modules/bar
/node_modules/bar

搜索时，Node 先将 bar 当成文件名，依次尝试加载下面这些文件，只要有一个成功就返回。

1
2
3
4

bar
bar.js
bar.json
bar.node

如果都不成功，说明 bar 可能是目录名，于是依次尝试加载下面这些文件。

1
2
3
4

bar/package.json（main字段）
bar/index.js
bar/index.json
bar/index.node

如果在所有目录中，都无法找到 bar 对应的文件或目录，就抛出一个错误。

二、Module 构造函数

了解内部逻辑以后，下面就来看源码。

require的源码在Node的lib/module.js 文件。为了便于理解，本文引用的源码是简化过的，并且删除了原作者的注释。

1
2
3
4
5
6
7
8
9
10
11
12

function Module(id, parent) {
  this.id = id;
  this.exports = {};
  this.parent = parent;
  this.filename = null;
  this.loaded = false;
  this.children = [];
}

module.exports = Module;

var module = new Module(filename, parent);

上面代码中，Node 定义了一个构造函数 Module，所有的模块都是 Module 的实例。可以看到，当前模块（module.js）也是 Module 的一个实例。

每个实例都有自己的属性。下面通过一个例子，看看这些属性的值是什么。新建一个脚本文件 a.js 。

1
2
3
4
5
6
7
8
9

// a.js

console.log('module.id: ', module.id);
console.log('module.exports: ', module.exports);
console.log('module.parent: ', module.parent);
console.log('module.filename: ', module.filename);
console.log('module.loaded: ', module.loaded);
console.log('module.children: ', module.children);
console.log('module.paths: ', module.paths);

运行这个脚本。

1
2
3
4
5
6
7
8
9
10
11
12

$ node a.js

module.id:  .
module.exports:  {}
module.parent:  null
module.filename:  /home/ruanyf/tmp/a.js
module.loaded:  false
module.children:  []
module.paths:  [ '/home/ruanyf/tmp/node_modules',
  '/home/ruanyf/node_modules',
  '/home/node_modules',
  '/node_modules' ]

可以看到，如果没有父模块，直接调用当前模块，parent 属性就是 null，id 属性就是一个点。filename 属性是模块的绝对路径，path 属性是一个数组，包含了模块可能的位置。另外，输出这些内容时，模块还没有全部加载，所以 loaded 属性为 false 。

新建另一个脚本文件 b.js，让其调用 a.js 。

1
2
3

// b.js

var a = require('./a.js');

运行 b.js 。

1
2
3
4
5
6
7
8
9
10
11
12

$ node b.js

module.id:  /home/ruanyf/tmp/a.js
module.exports:  {}
module.parent:  { object }
module.filename:  /home/ruanyf/tmp/a.js
module.loaded:  false
module.children:  []
module.paths:  [ '/home/ruanyf/tmp/node_modules',
  '/home/ruanyf/node_modules',
  '/home/node_modules',
  '/node_modules' ]

上面代码中，由于 a.js 被 b.js 调用，所以 parent 属性指向 b.js 模块，id 属性和 filename 属性一致，都是模块的绝对路径。

三、模块实例的 require 方法

每个模块实例都有一个 require 方法。

1
2
3

Module.prototype.require = function(path) {
  return Module._load(path, this);
};

由此可知，require 并不是全局性命令，而是每个模块提供的一个内部方法，也就是说，只有在模块内部才能使用 require 命令（唯一的例外是 REPL 环境）。另外，require 其实内部调用 Module._load 方法。

下面来看 Module._load 的源码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

Module._load = function(request, parent, isMain) {

  //  计算绝对路径
  var filename = Module._resolveFilename(request, parent);

  //  第一步：如果有缓存，取出缓存
  var cachedModule = Module._cache[filename];
  if (cachedModule) {
    return cachedModule.exports;

  // 第二步：是否为内置模块
  if (NativeModule.exists(filename)) {
    return NativeModule.require(filename);
  }

  // 第三步：生成模块实例，存入缓存
  var module = new Module(filename, parent);
  Module._cache[filename] = module;

  // 第四步：加载模块
  try {
    module.load(filename);
    hadException = false;
  } finally {
    if (hadException) {
      delete Module._cache[filename];
    }
  }

  // 第五步：输出模块的exports属性
  return module.exports;
};

上面代码中，首先解析出模块的绝对路径（filename），以它作为模块的识别符。然后，如果模块已经在缓存中，就从缓存取出；如果不在缓存中，就加载模块。

因此，Module._load 的关键步骤是两个。

• Module._resolveFilename() ：确定模块的绝对路径
• module.load()：加载模块

四、模块的绝对路径

下面是 Module._resolveFilename 方法的源码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Module._resolveFilename = function(request, parent) {

  // 第一步：如果是内置模块，不含路径返回
  if (NativeModule.exists(request)) {
    return request;
  }

  // 第二步：确定所有可能的路径
  var resolvedModule = Module._resolveLookupPaths(request, parent);
  var id = resolvedModule[0];
  var paths = resolvedModule[1];

  // 第三步：确定哪一个路径为真
  var filename = Module._findPath(request, paths);
  if (!filename) {
    var err = new Error("Cannot find module '" + request + "'");
    err.code = 'MODULE_NOT_FOUND';
    throw err;
  }
  return filename;
};

上面代码中，在 Module.resolveFilename 方法内部，又调用了两个方法 Module.resolveLookupPaths() 和 Module._findPath() ，前者用来列出可能的路径，后者用来确认哪一个路径为真。

为了简洁起见，这里只给出 Module._resolveLookupPaths() 的运行结果。

1
2
3
4
5
6
7

[   '/home/ruanyf/tmp/node_modules',
    '/home/ruanyf/node_modules',
    '/home/node_modules',
    '/node_modules' 
    '/home/ruanyf/.node_modules',
    '/home/ruanyf/.node_libraries'，
     '$Prefix/lib/node' ]

上面的数组，就是模块所有可能的路径。基本上是，从当前路径开始一级级向上寻找 node_modules 子目录。最后那三个路径，主要是为了历史原因保持兼容，实际上已经很少用了。

有了可能的路径以后，下面就是 Module._findPath() 的源码，用来确定到底哪一个是正确路径。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Module._findPath = function(request, paths) {

  // 列出所有可能的后缀名：.js，.json, .node
  var exts = Object.keys(Module._extensions);

  // 如果是绝对路径，就不再搜索
  if (request.charAt(0) === '/') {
    paths = [''];
  }

  // 是否有后缀的目录斜杠
  var trailingSlash = (request.slice(-1) === '/');

  // 第一步：如果当前路径已在缓存中，就直接返回缓存
  var cacheKey = JSON.stringify({request: request, paths: paths});
  if (Module._pathCache[cacheKey]) {
    return Module._pathCache[cacheKey];
  }

  // 第二步：依次遍历所有路径
  for (var i = 0, PL = paths.length; i < PL; i++) {
    var basePath = path.resolve(paths[i], request);
    var filename;

    if (!trailingSlash) {
      // 第三步：是否存在该模块文件
      filename = tryFile(basePath);

      if (!filename && !trailingSlash) {
        // 第四步：该模块文件加上后缀名，是否存在
        filename = tryExtensions(basePath, exts);
      }
    }

    // 第五步：目录中是否存在 package.json 
    if (!filename) {
      filename = tryPackage(basePath, exts);
    }

    if (!filename) {
      // 第六步：是否存在目录名 + index + 后缀名 
      filename = tryExtensions(path.resolve(basePath, 'index'), exts);
    }

    // 第七步：将找到的文件路径存入返回缓存，然后返回
    if (filename) {
      Module._pathCache[cacheKey] = filename;
      return filename;
    }
  }

  // 第八步：没有找到文件，返回false 
  return false;
};

经过上面代码，就可以找到模块的绝对路径了。

有时在项目代码中，需要调用模块的绝对路径，那么除了 module.filename ，Node 还提供一个 require.resolve 方法，供外部调用，用于从模块名取到绝对路径。

1
2
3
4
5
6
7

require.resolve = function(request) {
  return Module._resolveFilename(request, self);
};

// 用法
require.resolve('a.js')
// 返回 /home/ruanyf/tmp/a.js

五、加载模块

有了模块的绝对路径，就可以加载该模块了。下面是 module.load 方法的源码。

1
2
3
4
5
6

Module.prototype.load = function(filename) {
  var extension = path.extname(filename) || '.js';
  if (!Module._extensions[extension]) extension = '.js';
  Module._extensions[extension](this, filename);
  this.loaded = true;
};

上面代码中，首先确定模块的后缀名，不同的后缀名对应不同的加载方法。下面是 .js 和 .json 后缀名对应的处理方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Module._extensions['.js'] = function(module, filename) {
  var content = fs.readFileSync(filename, 'utf8');
  module._compile(stripBOM(content), filename);
};

Module._extensions['.json'] = function(module, filename) {
  var content = fs.readFileSync(filename, 'utf8');
  try {
    module.exports = JSON.parse(stripBOM(content));
  } catch (err) {
    err.message = filename + ': ' + err.message;
    throw err;
  }
};

这里只讨论 js 文件的加载。首先，将模块文件读取成字符串，然后剥离 utf8 编码特有的BOM文件头，最后编译该模块。

module._compile 方法用于模块的编译。

1
2
3
4
5

Module.prototype._compile = function(content, filename) {
  var self = this;
  var args = [self.exports, require, self, filename, dirname];
  return compiledWrapper.apply(self.exports, args);
};

上面的代码基本等同于下面的形式。

1
2
3

(function (exports, require, module, __filename, __dirname) {
  // 模块源码
});

也就是说，模块的加载实质上就是，注入exports、require、module三个全局变量，然后执行模块的源码，然后将模块的 exports 变量的值输出。

原文

http://www.ruanyifeng.com/blog/2015/05/require.html

HTTP 协议入门

HTTP 协议是互联网的基础协议，也是网页开发的必备知识，最新版本 HTTP/2 更是让它成为技术热点。
本文介绍 HTTP 协议的历史演变和设计思路。

一、HTTP/0.9

HTTP 是基于 TCP/IP 协议的应用层协议。它不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口。

最早版本是1991年发布的0.9版。该版本极其简单，只有一个命令GET。

1

GET /index.html

上面命令表示，TCP 连接（connection）建立后，客户端向服务器请求（request）网页index.html。

协议规定，服务器只能回应HTML格式的字符串，不能回应别的格式。

1
2
3

<html>
  <body>Hello World</body>
</html>

服务器发送完毕，就关闭TCP连接。

二、HTTP/1.0

2.1 简介

1996年5月，HTTP/1.0 版本发布，内容大大增加。

首先，任何格式的内容都可以发送。这使得互联网不仅可以传输文字，还能传输图像、视频、二进制文件。这为互联网的大发展奠定了基础。

其次，除了GET命令，还引入了POST命令和HEAD命令，丰富了浏览器与服务器的互动手段。

再次，HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。

其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。

2.2 请求格式

下面是一个1.0版的HTTP请求的例子。

1
2
3

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

可以看到，这个格式与0.9版有很大变化。

第一行是请求命令，必须在尾部添加协议版本（HTTP/1.0）。后面就是多行头信息，描述客户端的情况。

2.3 回应格式

服务器的回应如下。

1
2
3
4
5
6
7
8
9
10

HTTP/1.0 200 OK 
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

<html>
  <body>Hello World</body>
</html>

回应的格式是”头信息 + 一个空行（\r\n） + 数据”。其中，第一行是”协议版本 + 状态码（status code） + 状态描述”。

2.4 Content-Type 字段

关于字符的编码，1.0版规定，头信息必须是 ASCII 码，后面的数据可以是任何格式。因此，服务器回应的时候，必须告诉客户端，数据是什么格式，这就是Content-Type字段的作用。

下面是一些常见的Content-Type字段的值。

• text/plain
• text/html
• text/css
• image/jpeg
• image/png
• image/svg+xml
• audio/mp4
• video/mp4
• application/javascript
• application/pdf
• application/zip
• application/atom+xml

这些数据类型总称为MIME type，每个值包括一级类型和二级类型，之间用斜杠分隔。

除了预定义的类型，厂商也可以自定义类型。

1

application/vnd.debian.binary-package

上面的类型表明，发送的是Debian系统的二进制数据包。

MIME type还可以在尾部使用分号，添加参数。

1

Content-Type: text/html; charset=utf-8

上面的类型表明，发送的是网页，而且编码是UTF-8。

客户端请求的时候，可以使用Accept字段声明自己可以接受哪些数据格式。

1

Accept: */*

上面代码中，客户端声明自己可以接受任何格式的数据。

MIME type不仅用在HTTP协议，还可以用在其他地方，比如HTML网页。

1
2
3

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <!-- 等同于 -->
<meta charset="utf-8" />

2.5 Content-Encoding 字段

由于发送的数据可以是任何格式，因此可以把数据压缩后再发送。Content-Encoding字段说明数据的压缩方法。

1
2
3

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate

客户端在请求时，用Accept-Encoding字段说明自己可以接受哪些压缩方法。

1

Accept-Encoding: gzip, deflate

2.6 缺点

HTTP/1.0 版的主要缺点是，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。所以，HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。

为了解决这个问题，有些浏览器在请求时，用了一个非标准的Connection字段。

1

Connection: keep-alive

这个字段要求服务器不要关闭TCP连接，以便其他请求复用。服务器同样回应这个字段。

1

Connection: keep-alive

一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

三、HTTP/1.1

1997年1月，HTTP/1.1 版本发布，只比 1.0 版本晚了半年。它进一步完善了 HTTP 协议，一直用到了20年后的今天，直到现在还是最流行的版本。

3.1 持久连接

1.1 版的最大变化，就是引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。

客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。

1

Connection: close

目前，对于同一个域名，大多数浏览器允许同时建立6个持久连接。

3.2 管道机制

1.1 版还引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。

举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发出B请求。管道机制则是允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。

3.3 Content-Length 字段

一个TCP连接现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是Content-length字段的作用，声明本次回应的数据长度。

1

Content-Length: 3495

上面代码告诉浏览器，本次回应的长度是3495个字节，后面的字节就属于下一个回应了。

在1.0版中，Content-Length字段不是必需的，因为浏览器发现服务器关闭了TCP连接，就表明收到的数据包已经全了。

3.4 分块传输编码

使用Content-Length字段的前提条件是，服务器发送回应之前，必须知道回应的数据长度。

对于一些很耗时的动态操作来说，这意味着，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。更好的处理方法是，产生一块数据，就发送一块，采用”流模式”（stream）取代”缓存模式”（buffer）。

因此，1.1版规定可以不使用Content-Length字段，而使用“分块传输编码”（chunked transfer encoding）。只要请求或回应的头信息有Transfer-Encoding字段，就表明回应将由数量未定的数据块组成。

1

Transfer-Encoding: chunked

每个非空的数据块之前，会有一个16进制的数值，表示这个块的长度。最后是一个大小为0的块，就表示本次回应的数据发送完了。下面是一个例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

25
This is the data in the first chunk
 
1C
and this is the second one

3
con

8
sequence

0

3.5 其他功能

1.1版还新增了许多动词方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。

另外，客户端请求的头信息新增了Host字段，用来指定服务器的域名。

1

Host: www.example.com

有了Host字段，就可以将请求发往同一台服务器上的不同网站，为虚拟主机的兴起打下了基础。

3.6 缺点

虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为“队头堵塞”（Head-of-line blocking）。

为了避免这个问题，只有两种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。如果HTTP协议设计得更好一些，这些额外的工作是可以避免的。

四、SPDY 协议

2009年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。

这个协议在Chrome浏览器上证明可行以后，就被当作 HTTP/2 的基础，主要特性都在 HTTP/2 之中得到继承。

五、HTTP/2

2015年，HTTP/2 发布。它不叫 HTTP/2.0，是因为标准委员会不打算再发布子版本了，下一个新版本将是 HTTP/3。

5.1 二进制协议

HTTP/1.1 版的头信息肯定是文本（ASCII编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为”帧”（frame）：头信息帧和数据帧。

二进制协议的一个好处是，可以定义额外的帧。HTTP/2 定义了近十种帧，为将来的高级应用打好了基础。如果使用文本实现这种功能，解析数据将会变得非常麻烦，二进制解析则方便得多。

5.2 多工

HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了”队头堵塞”。

举例来说，在一个TCP连接里面，服务器同时收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。

这样双向的、实时的通信，就叫做多工（Multiplexing）。

5.3 数据流

因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

HTTP/2 将每个请求或回应的所有数据包，称为一个数据流（stream）。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流ID，用来区分它属于哪个数据流。另外还规定，客户端发出的数据流，ID一律为奇数，服务器发出的，ID为偶数。

数据流发送到一半的时候，客户端和服务器都可以发送信号（RST_STREAM帧），取消这个数据流。1.1版取消数据流的唯一方法，就是关闭TCP连接。这就是说，HTTP/2 可以取消某一次请求，同时保证TCP连接还打开着，可以被其他请求使用。

客户端还可以指定数据流的优先级。优先级越高，服务器就会越早回应。

5.4 头信息压缩

HTTP 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如Cookie和User Agent，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。

HTTP/2 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息使用gzip或compress压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

5.5 服务器推送

HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。

常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了。

六、参考链接

Journey to HTTP/2, by Kamran Ahmed
HTTP, by Wikipedia
HTTP/1.0 Specification
HTTP/2 Specification

七、原文

http://www.ruanyifeng.com/blog/2016/08/http.html

The Node.js Event Loop, Timers, and process.nextTick()

What is the Event Loop?

The event loop is what allows Node.js to perform non-blocking I/O operations — despite the fact that JavaScript is single-threaded — by offloading operations to the system kernel whenever possible.

Since most modern kernels are multi-threaded, they can handle multiple operations executing in the background. When one of these operations completes, the kernel tells Node.js so that the appropriate callback may be added to the poll queue to eventually be executed. We’ll explain this in further detail later in this topic.

Event Loop Explained

When Node.js starts, it initializes the event loop, processes the provided input script (or drops into the REPL, which is not covered in this document) which may make async API calls, schedule timers, or call process.nextTick(), then begins processing the event loop.

The following diagram shows a simplified overview of the event loop’s order of operations.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

   ┌───────────────────────────┐
┌─>│           timers          │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │
   └───────────────────────────┘

note: each box will be referred to as a “phase” of the event loop.

Each phase has a FIFO queue of callbacks to execute. While each phase is special in its own way, generally, when the event loop enters a given phase, it will perform any operations specific to that phase, then execute callbacks in that phase’s queue until the queue has been exhausted or the maximum number of callbacks has executed. When the queue has been exhausted or the callback limit is reached, the event loop will move to the next phase, and so on.

Since any of these operations may schedule more operations and new events processed in the poll phase are queued by the kernel, poll events can be queued while polling events are being processed. As a result, long running callbacks can allow the poll phase to run much longer than a timer’s threshold. See the timers and poll sections for more details.

*NOTE: There is a slight discrepancy between the Windows and the Unix/Linux implementation, but that’s not important for this demonstration. The most important parts are here. There are actually seven or eight steps, but the ones we care about — ones that Node.js actually uses - are those above.*

Phases Overview

• timers: this phase executes callbacks scheduled by setTimeout() and setInterval().
• pending callbacks: executes I/O callbacks deferred to the next loop iteration.
• idle, prepare: only used internally.
• poll: retrieve new I/O events; execute I/O related callbacks (almost all with the exception of close callbacks, the ones scheduled by timers, and setImmediate()); node will block here when appropriate.
• check: setImmediate() callbacks are invoked here.
• close callbacks: some close callbacks, e.g. socket.on('close', ...).

Between each run of the event loop, Node.js checks if it is waiting for any asynchronous I/O or timers and shuts down cleanly if there are not any.

Phases in Detail

timers

A timer specifies the threshold after which a provided callback may be executed rather than the exact time a person wants it to be executed. Timers callbacks will run as early as they can be scheduled after the specified amount of time has passed; however, Operating System scheduling or the running of other callbacks may delay them.

*Note: Technically, the poll phase controls when timers are executed.*

For example, say you schedule a timeout to execute after a 100 ms threshold, then your script starts asynchronously reading a file which takes 95 ms:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

const fs = require('fs');

function someAsyncOperation(callback) {
  // Assume this takes 95ms to complete
  fs.readFile('/path/to/file', callback);
}

const timeoutScheduled = Date.now();

setTimeout(() => {
  const delay = Date.now() - timeoutScheduled;

  console.log(`${delay}ms have passed since I was scheduled`);
}, 100);


// do someAsyncOperation which takes 95 ms to complete
someAsyncOperation(() => {
  const startCallback = Date.now();

  // do something that will take 10ms...
  while (Date.now() - startCallback < 10) {
    // do nothing
  }
});

When the event loop enters the poll phase, it has an empty queue (fs.readFile() has not completed), so it will wait for the number of ms remaining until the soonest timer’s threshold is reached. While it is waiting 95 ms pass, fs.readFile() finishes reading the file and its callback which takes 10 ms to complete is added to the poll queue and executed. When the callback finishes, there are no more callbacks in the queue, so the event loop will see that the threshold of the soonest timer has been reached then wrap back to the timers phase to execute the timer’s callback. In this example, you will see that the total delay between the timer being scheduled and its callback being executed will be 105ms.

Note: To prevent the poll phase from starving the event loop, libuv (the C library that implements the Node.js event loop and all of the asynchronous behaviors of the platform) also has a hard maximum (system dependent) before it stops polling for more events.

pending callbacks

This phase executes callbacks for some system operations such as types of TCP errors. For example if a TCP socket receives ECONNREFUSED when attempting to connect, some *nix systems want to wait to report the error. This will be queued to execute in the pending callbacks phase.

poll

The poll phase has two main functions:

1. Calculating how long it should block and poll for I/O, then
2. Processing events in the poll queue.

When the event loop enters the poll phase and there are no timers scheduled, one of two things will happen:

• If the **poll queue is not empty**, the event loop will iterate through its queue of callbacks executing them synchronously until either the queue has been exhausted, or the system-dependent hard limit is reached.
• If the **poll queue is empty**, one of two more things will happen:
  • If scripts have been scheduled by setImmediate(), the event loop will end the poll phase and continue to the check phase to execute those scheduled scripts.
  • If scripts have not been scheduled by setImmediate(), the event loop will wait for callbacks to be added to the queue, then execute them immediately.

Once the poll queue is empty the event loop will check for timers whose time thresholds have been reached. If one or more timers are ready, the event loop will wrap back to the timers phase to execute those timers’ callbacks.

check

This phase allows a person to execute callbacks immediately after the poll phase has completed. If the poll phase becomes idle and scripts have been queued with setImmediate(), the event loop may continue to the check phase rather than waiting.

setImmediate() is actually a special timer that runs in a separate phase of the event loop. It uses a libuv API that schedules callbacks to execute after the poll phase has completed.

Generally, as the code is executed, the event loop will eventually hit the poll phase where it will wait for an incoming connection, request, etc. However, if a callback has been scheduled with setImmediate() and the poll phase becomes idle, it will end and continue to the check phase rather than waiting for poll events.

close callbacks

If a socket or handle is closed abruptly (e.g. socket.destroy()), the 'close' event will be emitted in this phase. Otherwise it will be emitted via process.nextTick().

setImmediate() vs setTimeout()

setImmediate and setTimeout() are similar, but behave in different ways depending on when they are called.

• setImmediate() is designed to execute a script once the current poll phase completes.
• setTimeout() schedules a script to be run after a minimum threshold in ms has elapsed.

The order in which the timers are executed will vary depending on the context in which they are called. If both are called from within the main module, then timing will be bound by the performance of the process (which can be impacted by other applications running on the machine).

For example, if we run the following script which is not within an I/O cycle (i.e. the main module), the order in which the two timers are executed is non-deterministic, as it is bound by the performance of the process:

1
2
3
4
5
6
7
8

// timeout_vs_immediate.js
setTimeout(() => {
  console.log('timeout');
}, 0);

setImmediate(() => {
  console.log('immediate');
});

1
2
3
4
5
6
7

$ node timeout_vs_immediate.js
timeout
immediate

$ node timeout_vs_immediate.js
immediate
timeout

However, if you move the two calls within an I/O cycle, the immediate callback is always executed first:

1
2
3
4
5
6
7
8
9
10
11

// timeout_vs_immediate.js
const fs = require('fs');

fs.readFile(__filename, () => {
  setTimeout(() => {
    console.log('timeout');
  }, 0);
  setImmediate(() => {
    console.log('immediate');
  });
});

1
2
3
4
5
6
7

$ node timeout_vs_immediate.js
immediate
timeout

$ node timeout_vs_immediate.js
immediate
timeout

The main advantage to using setImmediate() over setTimeout() is setImmediate()will always be executed before any timers if scheduled within an I/O cycle, independently of how many timers are present.

process.nextTick()

Understanding process.nextTick()

You may have noticed that process.nextTick() was not displayed in the diagram, even though it’s a part of the asynchronous API. This is because process.nextTick() is not technically part of the event loop. Instead, the nextTickQueue will be processed after the current operation completes, regardless of the current phase of the event loop.

Looking back at our diagram, any time you call process.nextTick() in a given phase, all callbacks passed to process.nextTick() will be resolved before the event loop continues. This can create some bad situations because it allows you to “starve” your I/O by making recursive process.nextTick() calls, which prevents the event loop from reaching the poll phase.

Why would that be allowed?

Why would something like this be included in Node.js? Part of it is a design philosophy where an API should always be asynchronous even where it doesn’t have to be. Take this code snippet for example:

1
2
3
4
5

function apiCall(arg, callback) {
  if (typeof arg !== 'string')
    return process.nextTick(callback,
                            new TypeError('argument should be string'));
}

The snippet does an argument check and if it’s not correct, it will pass the error to the callback. The API updated fairly recently to allow passing arguments to process.nextTick() allowing it to take any arguments passed after the callback to be propagated as the arguments to the callback so you don’t have to nest functions.

What we’re doing is passing an error back to the user but only after we have allowed the rest of the user’s code to execute. By using process.nextTick() we guarantee that apiCall() always runs its callback after the rest of the user’s code and before the event loop is allowed to proceed. To achieve this, the JS call stack is allowed to unwind then immediately execute the provided callback which allows a person to make recursive calls to process.nextTick() without reaching a RangeError: Maximum call stack size exceeded from v8.

This philosophy can lead to some potentially problematic situations. Take this snippet for example:

1
2
3
4
5
6
7
8
9
10
11
12

let bar;

// this has an asynchronous signature, but calls callback synchronously
function someAsyncApiCall(callback) { callback(); }

// the callback is called before `someAsyncApiCall` completes.
someAsyncApiCall(() => {
  // since someAsyncApiCall has completed, bar hasn't been assigned any value
  console.log('bar', bar); // undefined
});

bar = 1;

The user defines someAsyncApiCall() to have an asynchronous signature, but it actually operates synchronously. When it is called, the callback provided to someAsyncApiCall()is called in the same phase of the event loop because someAsyncApiCall() doesn’t actually do anything asynchronously. As a result, the callback tries to reference bar even though it may not have that variable in scope yet, because the script has not been able to run to completion.

By placing the callback in a process.nextTick(), the script still has the ability to run to completion, allowing all the variables, functions, etc., to be initialized prior to the callback being called. It also has the advantage of not allowing the event loop to continue. It may be useful for the user to be alerted to an error before the event loop is allowed to continue. Here is the previous example using process.nextTick():

1
2
3
4
5
6
7
8
9
10
11

let bar;

function someAsyncApiCall(callback) {
  process.nextTick(callback);
}

someAsyncApiCall(() => {
  console.log('bar', bar); // 1
});

bar = 1;

Here’s another real world example:

1
2
3

const server = net.createServer(() => {}).listen(8080);

server.on('listening', () => {});

When only a port is passed, the port is bound immediately. So, the 'listening' callback could be called immediately. The problem is that the .on('listening') callback will not have been set by that time.

To get around this, the 'listening' event is queued in a nextTick() to allow the script to run to completion. This allows the user to set any event handlers they want.

process.nextTick() vs setImmediate()

We have two calls that are similar as far as users are concerned, but their names are confusing.

• process.nextTick() fires immediately on the same phase
• setImmediate() fires on the following iteration or ‘tick’ of the event loop

In essence, the names should be swapped. process.nextTick() fires more immediately than setImmediate(), but this is an artifact of the past which is unlikely to change. Making this switch would break a large percentage of the packages on npm. Every day more new modules are being added, which means every day we wait, more potential breakages occur. While they are confusing, the names themselves won’t change.

We recommend developers use setImmediate() in all cases because it’s easier to reason about (and it leads to code that’s compatible with a wider variety of environments, like browser JS.)

Why use process.nextTick()?

There are two main reasons:

1. Allow users to handle errors, cleanup any then unneeded resources, or perhaps try the request again before the event loop continues.
2. At times it’s necessary to allow a callback to run after the call stack has unwound but before the event loop continues.

One example is to match the user’s expectations. Simple example:

1
2
3
4
5

const server = net.createServer();
server.on('connection', (conn) => { });

server.listen(8080);
server.on('listening', () => { });

Say that listen() is run at the beginning of the event loop, but the listening callback is placed in a setImmediate(). Unless a hostname is passed, binding to the port will happen immediately. For the event loop to proceed, it must hit the poll phase, which means there is a non-zero chance that a connection could have been received allowing the connection event to be fired before the listening event.

Another example is running a function constructor that was to, say, inherit from EventEmitter and it wanted to call an event within the constructor:

1
2
3
4
5
6
7
8
9
10
11
12
13

const EventEmitter = require('events');
const util = require('util');

function MyEmitter() {
  EventEmitter.call(this);
  this.emit('event');
}
util.inherits(MyEmitter, EventEmitter);

const myEmitter = new MyEmitter();
myEmitter.on('event', () => {
  console.log('an event occurred!');
});

You can’t emit an event from the constructor immediately because the script will not have processed to the point where the user assigns a callback to that event. So, within the constructor itself, you can use process.nextTick() to set a callback to emit the event after the constructor has finished, which provides the expected results:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

const EventEmitter = require('events');
const util = require('util');

function MyEmitter() {
  EventEmitter.call(this);

  // use nextTick to emit the event once a handler is assigned
  process.nextTick(() => {
    this.emit('event');
  });
}
util.inherits(MyEmitter, EventEmitter);

const myEmitter = new MyEmitter();
myEmitter.on('event', () => {
  console.log('an event occurred!');
});

原文

https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/#the-node-js-event-loop-timers-and-process-nexttick

浅拷贝，比如浅拷贝对象A时，对象B将拷贝A的所有属性，如果属性是引用类型，B将拷贝地址，若果属性是基本类型，B将复制其值。浅拷贝的缺点是如果你修改了对象B中引用类型属性，你同时也会影响到对象A。

深拷贝会完全拷贝所有数据，优点是拷贝双方不会相互依赖，比如修改了一方的引用类型属性，不会影响到另一方。缺点是拷贝的速度更慢，代价更大 （我的理解是耗费了更多内存空间）。

浅拷贝实现

1、使用 ES6 的 Object.assign，其内部实现就是浅拷贝，并剔除了目标对象的原型方法

1
2
3
4
5
6

let a = {
  p: [1, 2]
};

let b = Object.assign({}, a);
console.log(b.p == a.p);

2、遍历对象属性

1
2
3
4
5
6
7
8
9
10
11
12

function shallowClone(obj) {
  if (!obj || typeof obj !== 'object') {
    throw new Error('error arguments');
  }
  let targetObj = obj.constructor === Array ? [] : {};
  for (let key in obj) {
    if (obj.hasOwnProperty(key)) {
      targetObj[key] = obj[key];
    }
  }
  return targetObj;
}

深拷贝实现

1、利用 JSON 序列化实现一个深拷贝，缺点是无法复制函数，并且丢失抛弃对象的 constructor 和原型链

1
2
3
4
5
6
7
8
9
10
11
12
13

function deepClone(obj) {
  return JSON.parse(JSON.stringify(obj));
}

let o1 = {
  arr: [1, 2, 3],
  obj: { key: 'value' },
  func(){
    return 1;
  }
};
let o2 = deepClone(o1);
console.log(o2); // => {arr: [1,2,3], obj: {key: 'value'}}

2、利用递归实现深拷贝，可以复制函数，同样会丢失抛弃对象的 constructor 和原型链，但是对于拷贝 json 对象的话足够了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function deepCopy(src) {
  if(!src || typeof src !== 'object'){
    throw new Error('error arguments');
  }
  let target = src.constructor === Array ? [] : {};
  for (let i in src) {
    if (typeof src[i] === 'object') {
      target[i] = src[i].constructor === Array ? [] : {};
      target[i] = deepCopy(src[i]);
    } else {
      target[i] = src[i];
    }
  }
  return target;
}

原文

http://www.lujianan.com/2016/07/18/deep-shallow/

箭头函数

基本用法

ES6 允许使用“箭头”（=>）定义函数。

1
2
3
4
5
6

var f = v => v;

// 等同于
var f = function (v) {
  return v;
};

如果箭头函数不需要参数或需要多个参数，就使用一个圆括号代表参数部分。

1
2
3
4
5
6
7
8
9

var f = () => 5;
// 等同于
var f = function () { return 5 };

var sum = (num1, num2) => num1 + num2;
// 等同于
var sum = function(num1, num2) {
  return num1 + num2;
};

如果箭头函数的代码块部分多于一条语句，就要使用大括号将它们括起来，并且使用return语句返回。

1

var sum = (num1, num2) => { return num1 + num2; }

由于大括号被解释为代码块，所以如果箭头函数直接返回一个对象，必须在对象外面加上括号，否则会报错。

1
2
3
4
5

// 报错
let getTempItem = id => { id: id, name: "Temp" };

// 不报错
let getTempItem = id => ({ id: id, name: "Temp" });

下面是一种特殊情况，虽然可以运行，但会得到错误的结果。

1
2

let foo = () => { a: 1 };
foo() // undefined

上面代码中，原始意图是返回一个对象{ a: 1 }，但是由于引擎认为大括号是代码块，所以执行了一行语句a: 1。这时，a可以被解释为语句的标签，因此实际执行的语句是1;，然后函数就结束了，没有返回值。

如果箭头函数只有一行语句，且不需要返回值，可以采用下面的写法，就不用写大括号了。

1

let fn = () => void doesNotReturn();

箭头函数可以与变量解构结合使用。

1
2
3
4
5
6

const full = ({ first, last }) => first + ' ' + last;

// 等同于
function full(person) {
  return person.first + ' ' + person.last;
}

箭头函数使得表达更加简洁。

1
2

const isEven = n => n % 2 == 0;
const square = n => n * n;

上面代码只用了两行，就定义了两个简单的工具函数。如果不用箭头函数，可能就要占用多行，而且还不如现在这样写醒目。

箭头函数的一个用处是简化回调函数。

1
2
3
4
5
6
7

// 正常函数写法
[1,2,3].map(function (x) {
  return x * x;
});

// 箭头函数写法
[1,2,3].map(x => x * x);

另一个例子是

1
2
3
4
5
6
7

// 正常函数写法
var result = values.sort(function (a, b) {
  return a - b;
});

// 箭头函数写法
var result = values.sort((a, b) => a - b);

下面是 rest 参数与箭头函数结合的例子。

1
2
3
4
5
6
7
8
9

const numbers = (...nums) => nums;

numbers(1, 2, 3, 4, 5)
// [1,2,3,4,5]

const headAndTail = (head, ...tail) => [head, tail];

headAndTail(1, 2, 3, 4, 5)
// [1,[2,3,4,5]]

使用注意点

箭头函数有几个使用注意点。

（1）函数体内的this对象，就是定义时所在的对象，而不是使用时所在的对象。

（2）不可以当作构造函数，也就是说，不可以使用new命令，否则会抛出一个错误。

（3）不可以使用arguments对象，该对象在函数体内不存在。如果要用，可以用 rest 参数代替。

（4）不可以使用yield命令，因此箭头函数不能用作 Generator 函数。

上面四点中，第一点尤其值得注意。this对象的指向是可变的，但是在箭头函数中，它是固定的。

1
2
3
4
5
6
7
8
9
10

function foo() {
  setTimeout(() => {
    console.log('id:', this.id);
  }, 100);
}

var id = 21;

foo.call({ id: 42 });
// id: 42

上面代码中，setTimeout的参数是一个箭头函数，这个箭头函数的定义生效是在foo函数生成时，而它的真正执行要等到 100 毫秒后。如果是普通函数，执行时this应该指向全局对象window，这时应该输出21。但是，箭头函数导致this总是指向函数定义生效时所在的对象（本例是{id: 42}），所以输出的是42。

箭头函数可以让setTimeout里面的this，绑定定义时所在的作用域，而不是指向运行时所在的作用域。下面是另一个例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

function Timer() {
  this.s1 = 0;
  this.s2 = 0;
  // 箭头函数
  setInterval(() => this.s1++, 1000);
  // 普通函数
  setInterval(function () {
    this.s2++;
  }, 1000);
}

var timer = new Timer();

setTimeout(() => console.log('s1: ', timer.s1), 3100);
setTimeout(() => console.log('s2: ', timer.s2), 3100);
// s1: 3
// s2: 0

上面代码中，Timer函数内部设置了两个定时器，分别使用了箭头函数和普通函数。前者的this绑定定义时所在的作用域（即Timer函数），后者的this指向运行时所在的作用域（即全局对象）。所以，3100 毫秒之后，timer.s1被更新了 3 次，而timer.s2一次都没更新。

箭头函数可以让this指向固定化，这种特性很有利于封装回调函数。下面是一个例子，DOM 事件的回调函数封装在一个对象里面。

1
2
3
4
5
6
7
8
9
10
11
12

var handler = {
  id: '123456',

  init: function() {
    document.addEventListener('click',
      event => this.doSomething(event.type), false);
  },

  doSomething: function(type) {
    console.log('Handling ' + type  + ' for ' + this.id);
  }
};

上面代码的init方法中，使用了箭头函数，这导致这个箭头函数里面的this，总是指向handler对象。否则，回调函数运行时，this.doSomething这一行会报错，因为此时this指向document对象。

this指向的固定化，并不是因为箭头函数内部有绑定this的机制，实际原因是箭头函数根本没有自己的this，导致内部的this就是外层代码块的this。正是因为它没有this，所以也就不能用作构造函数。

所以，箭头函数转成 ES5 的代码如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// ES6
function foo() {
  setTimeout(() => {
    console.log('id:', this.id);
  }, 100);
}

// ES5
function foo() {
  var _this = this;

  setTimeout(function () {
    console.log('id:', _this.id);
  }, 100);
}

上面代码中，转换后的 ES5 版本清楚地说明了，箭头函数里面根本没有自己的this，而是引用外层的this。

请问下面的代码之中有几个this？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function foo() {
  return () => {
    return () => {
      return () => {
        console.log('id:', this.id);
      };
    };
  };
}

var f = foo.call({id: 1});

var t1 = f.call({id: 2})()(); // id: 1
var t2 = f().call({id: 3})(); // id: 1
var t3 = f()().call({id: 4}); // id: 1

上面代码之中，只有一个this，就是函数foo的this，所以t1、t2、t3都输出同样的结果。因为所有的内层函数都是箭头函数，都没有自己的this，它们的this其实都是最外层foo函数的this。

除了this，以下三个变量在箭头函数之中也是不存在的，指向外层函数的对应变量：arguments、super、new.target。

1
2
3
4
5
6
7
8

function foo() {
  setTimeout(() => {
    console.log('args:', arguments);
  }, 100);
}

foo(2, 4, 6, 8)
// args: [2, 4, 6, 8]

上面代码中，箭头函数内部的变量arguments，其实是函数foo的arguments变量。

另外，由于箭头函数没有自己的this，所以当然也就不能用call()、apply()、bind()这些方法去改变this的指向。

1
2
3
4
5
6

(function() {
  return [
    (() => this.x).bind({ x: 'inner' })()
  ];
}).call({ x: 'outer' });
// ['outer']

上面代码中，箭头函数没有自己的this，所以bind方法无效，内部的this指向外部的this。

长期以来，JavaScript 语言的this对象一直是一个令人头痛的问题，在对象方法中使用this，必须非常小心。箭头函数”绑定”this，很大程度上解决了这个困扰。

嵌套的箭头函数

箭头函数内部，还可以再使用箭头函数。下面是一个 ES5 语法的多重嵌套函数。

1
2
3
4
5
6
7
8
9
10

function insert(value) {
  return {into: function (array) {
    return {after: function (afterValue) {
      array.splice(array.indexOf(afterValue) + 1, 0, value);
      return array;
    }};
  }};
}

insert(2).into([1, 3]).after(1); //[1, 2, 3]

上面这个函数，可以使用箭头函数改写。

1
2
3
4
5
6

let insert = (value) => ({into: (array) => ({after: (afterValue) => {
  array.splice(array.indexOf(afterValue) + 1, 0, value);
  return array;
}})});

insert(2).into([1, 3]).after(1); //[1, 2, 3]

下面是一个部署管道机制（pipeline）的例子，即前一个函数的输出是后一个函数的输入。

1
2
3
4
5
6
7
8
9

const pipeline = (...funcs) =>
  val => funcs.reduce((a, b) => b(a), val);

const plus1 = a => a + 1;
const mult2 = a => a * 2;
const addThenMult = pipeline(plus1, mult2);

addThenMult(5)
// 12

如果觉得上面的写法可读性比较差，也可以采用下面的写法。

1
2
3
4
5

const plus1 = a => a + 1;
const mult2 = a => a * 2;

mult2(plus1(5))
// 12

箭头函数还有一个功能，就是可以很方便地改写 λ 演算。

1
2
3
4
5
6

// λ演算的写法
fix = λf.(λx.f(λv.x(x)(v)))(λx.f(λv.x(x)(v)))

// ES6的写法
var fix = f => (x => f(v => x(x)(v)))
               (x => f(v => x(x)(v)));

上面两种写法，几乎是一一对应的。由于 λ 演算对于计算机科学非常重要，这使得我们可以用 ES6 作为替代工具，探索计算机科学。

原文

https://github.com/ruanyf/es6tutorial/blob/gh-pages/docs/function.md

目前Nodejs编写一个守护进程非常简单，在6.3.1版本中已经存在非常方便的API，这些API可以帮助我们更方便的创建一个守护进程。本文仅在描述守护进程的创建方式，而不会对守护进程所要执行的任务做任何描述。

守护进程的启动方式

如果不在Nodejs环境中，我们如何创建守护进程？过程如下：

1. 创建一个进程A。
2. 在进程A中创建进程B，我们可以使用fork方式，或者其他方法。
3. 对进程B执行 setsid 方法。
4. 进程A退出，进程B由init进程接管。此时进程B为守护进程。

Setsid详解

setsid 主要完成三件事：

1. 该进程变成一个新会话的会话领导。
2. 该进程变成一个新进程组的组长。
3. 该进程没有控制终端。

然而，Nodejs中并没有对 setsid 方法的直接封装，翻阅文档发现有一个地方是可以调用该方法的。

Nodejs中启动子进程方法

借助 clild_process 中的 spawn 即可创建子进程，方法如下：

1
2
3
4
5

var spawn = require('child_process').spawn;
var process = require('process');

var p = spawn('node',['b.js']);
console.log(process.pid, p.pid);

注意，这里只打印当前进程的PID和子进程的PID，同时为了观察效果，我并没有将父进程退出。

b.js 中代码很简单，打开一个资源，并不停的写入数据。

1
2
3
4
5
6
7
8
9
10

var fs = require('fs');
var process = require('process');

fs.open("/Users/mebius/Desktop/log.txt",'w',function(err, fd){
	console.log(fd);
	while(true)
	{
		fs.write(fd,process.pid+"\n",function(){});
	}
});

运行后的效果如图：

我们来看以下 top 命令下的进程情况。

看一看到，此时父进程PID为17055，子进程的PPID为17055，PID为17056.

Nodejs中Setsid的调用

到此为止，守护进程已经完成一半，下面要调用setsid方法，并且退出父进程。

代码修改如下：

1
2
3
4
5
6
7
8

var spawn = require('child_process').spawn;
var process = require('process');

var p = spawn('node',['b.js'],{
        detached : true
    });
console.log(process.pid, p.pid);
process.exit(0);

在 spawn 的第三个参数中，可以设置 detached 属性，如果该属性为true，则会调用 setsid 方法。这样就满足我们对守护进程的要求。

在此运行命令。

查看 top 命令

可以看到，当前仅存在一个PID为17062的进程，这个进程就是我们要的守护进程。

由于每次运行PID都不同，所以此次子进程的PID于第一次不同。

总结

守护进程最重要的是稳定，如果守护进程挂掉，那么其管理的子进程都将变为孤儿进程，同时被init进程接管，这是我们不愿意看到的。于此同时，守护进程对于子进程的管理也是有非常多的发挥余地的，例如PM2中，将一个进程同时启动4次，达到CPU多核使用的目的（很有可能你的进程在同一核中运行），进程挂掉后自动重启等等，这些事情等着我们去造轮子。

普通的进程, 在用户退出终端之后就会直接关闭. 通过 & 启动到后台的进程, 之后会由于会（session组）被回收而终止进程. 守护进程是不依赖终端（tty）的进程, 不会因为用户退出终端而停止运行的进程.

总体来说，Nodejs启动守护进程方式比较简单，默认所暴露的API也屏蔽了很多系统级别API，使得大家使用上更加方便，但没有接触过Linux的人在理解上有一些复杂。推荐大家学习Nodejs的同时，多学习Linux系统调用的和系统内核的一些东西。

原文

https://ashan.org/archives/917