前情提要

什么是去重加和

在做数据统计查询时，「去重计数」可能大家并不陌生，也就是 COUNT(DISTINCT x)，访客数、买家数、订单数等都要这么来统计。那「去重加和」是什么？顾名思义就是 SUM(DISTINCT x)，对 x 去重后然后做加和运算，得到加和之后的值。比如一串数字 1, 2, 1, 3, 1，去重计数为 3，去重加和为 6。

为什么要去重加和

了解了「去重加和」是怎么算的，那这个「去重加和」有什么应用场景呢？对事实度量数据进行聚合查询时，指标类型分为可加、半可加、不可加三种，以下拿订单事实表为例。

可加

指的是该度量可以按照和事实表关联的任一维度进行汇总。比如：销售额、售出数，按订单、商品、买家维度统计都可以直接加和。

半可加

指的就是该度量在某些维度下不可进行汇总，或者说汇总起来没有意义。比如：商品库存，只能在商品维度下做加和才有意义，否则库存数会虚高。

不可加

指的是该度量在所有与该事实表关联的维度下都不可进行汇总。比如：客单价，这类比值字段都不可直接累加，需要把分子、分母分别汇总再做计算。

了解了以上几个概念，我们「去重加和」主要就是针对半可加指标的计算。但在实际应用中直接对值做去重然后加和的场景比较少，更多是像上面提到的商品库存，需要按某个维度去重，然后再加和。那这么说直接用 SUM(DISTINCT x) 的方式不行了吗？是又不是，这里先按住不表。

如何做去重加和

假设一个销售场景

• 键鼠套装组合销售，组合了一个键盘两个鼠标，商品 ID 为 123，键盘鼠标分别对应库存系统里的两个 SKU JP1 和 SB1
• 键盘 JP1 也单独销售，商品 ID 为 456，
• 同样鼠标 SB1 也单独销售，商品 ID 为 789

对应的销售记录如下：

• 订单 o1 买了 1 个 123 键鼠套装
• 订单 o2 买了 2 个 456 键盘
• 订单 o3 买了 1 个 789 鼠标

订单事实表如下：

CREATE TABLE f_order
(
    `orderID` String,
    `productID` UInt32,
    `sku` String,
    `orgQuantity` UInt16,
    `realQuantity` UInt16
)
ENGINE = MergeTree
ORDER BY orderID

INSERT INTO f_order VALUES ('o1', 123, 'JP1', 1, 1), ('o1', 123, 'SB1', 1, 2), ('o2', 456, 'JP1', 2, 2), ('o3', 789, 'SB1', 1, 1)

SELECT * 
FROM f_order

┌─orderID─┬─productID─┬─sku─┬─orgQuantity─┬─realQuantity─┐
│ o1      │       123 │ JP1 │           1 │            1 │
│ o1      │       123 │ SB1 │           1 │            2 │
│ o2      │       456 │ JP1 │           2 │            2 │
│ o3      │       789 │ SB1 │           1 │            1 │
└─────────┴───────────┴─────┴─────────────┴──────────────┘

orgQurantity 表示原始销售数量
realQuantity 表示库存实际扣减的数量

需求方期望得到这样的结果

• 统计原始销量汇总为 4（123：1，456：2，789：1）
• 统计商品（productID）维度的原始销量为 123：1，456：2，789：1
• 统计 sku 维度的实际销量为 JP1：3，SB1：3
• 统计 sku 维度的原始销量为 JP1：3，SB1：2
• ...

看上去好像有些绕，其实这里的关键点就是统计原始销量时，需要按订单和商品维度去重后再加和。

常规做法

使用两层聚合的方式，内层按订单和商品维度去重，外层再对去重后的原始销售数量加和。

统计原始销量汇总

SELECT sum(orgQuantity) AS totalOrgQuantity
FROM
(
    SELECT any(orgQuantity) AS orgQuantity
    FROM f_order
    GROUP BY orderID, productID
)

┌─totalOrgQuantity─┐
│                4 │
└──────────────────┘

这种写法优点是很清晰，写法符合 SQL 直觉；缺点是需要多做一层聚合，不一定能跟其他指标同时查询。

ClickHouse 做法

做法一

统计原始销量汇总

SELECT arraySum(x -> (x.3), groupUniqArray((orderID, productID, orgQuantity))) AS totalOrgQuantity
FROM f_order

┌─totalOrgQuantity─┐
│                4 │
└──────────────────┘

将 (orderID, productID, orgQuantity) 作为一个元组 Tuple，然后通过 groupUniqArray 聚合成一个去重后的数组，再用 arraySum 对数组中每一项元组的第 3 项也就是 orgQuantity 进行加和。

这个做法优点是只要一层聚合，跟其他指标一起查询没啥障碍；缺点是如果去重后的数组非常大，将非常影响查询性能。

看下这两条语句的执行耗时就知道了：

SELECT sum(number) AS x
FROM
(
    SELECT number
    FROM numbers(10000000)
)

┌──────────────x─┐
│ 49999995000000 │
└────────────────┘

1 rows in set. Elapsed: 0.012 sec. Processed 10.02 million rows, 80.18 MB (814.14 million rows/s., 6.51 GB/s.)


SELECT arraySum(x -> x, groupUniqArray(number)) AS x
FROM numbers(10000000)

┌──────────────x─┐
│ 49999995000000 │
└────────────────┘

1 rows in set. Elapsed: 1.264 sec. Processed 10.02 million rows, 80.18 MB (7.93 million rows/s., 63.45 MB/s.)

差的不是一点半点，而是 100 倍，这肯定没法接受。

做法二

既然做法一主要性能问题出在去重后数组太大上，那我们就想办法缩小这个数组。回到需求上，我们不难发现只有组合销售的商品才要去重，普通的商品直接加和就行，而正常的销售场景中组合商品占比很少，刚好可以用这个「是否组合商品」的条件来减少需要去重的数量。

不过在查询之前，我们需要对以上 f_order 表改造下

-- 将 orgQuantity 修改为 Tuple(k Nullable(UInt32), q UInt16) 类型
-- 第一位 k 作去重键，取值 NULL 表示非组合商品，有值时为组合商品当前订单的订单号和商品 ID 的 crc32 值
CREATE TABLE f_order_2
(
    `orderID` String,
    `productID` UInt32,
    `sku` String,
    `orgQuantity` Tuple(k Nullable(UInt32), q UInt16),
    `realQuantity` UInt16
)
ENGINE = MergeTree
ORDER BY orderID
SETTINGS index_granularity = 8192

-- 从 f_order 中导入数据，仅 productID 为 123 组合商品时才赋值给 orgQuantity.k
INSERT INTO f_order_2 SELECT
    orderID,
    productID,
    sku,
    (if(productID = 123, crc32(concat(orderID, toString(productID))), NULL), orgQuantity),
    realQuantity
FROM f_order

SELECT *
FROM f_order_2

┌─orderID─┬─productID─┬─sku─┬─orgQuantity────┬─realQuantity─┐
│ o1      │       123 │ JP1 │ (3806212741,1) │            1 │
│ o1      │       123 │ SB1 │ (3806212741,1) │            2 │
│ o2      │       456 │ JP1 │ (NULL,2)       │            2 │
│ o3      │       789 │ SB1 │ (NULL,1)       │            1 │
└─────────┴───────────┴─────┴────────────────┴──────────────┘

查询语句改写

SELECT arraySum(x -> (x.2), groupUniqArrayIf(orgQuantity, isNotNull(orgQuantity.k))) + sumIf(orgQuantity.q, isNull(orgQuantity.k)) AS totalOrgQuantity
FROM f_order_3

┌─totalOrgQuantity─┐
│                4 │
└──────────────────┘

语句分为两部分相加组成，第一部分跟做法一类似，但加入了条件判断，只有组合商品参与去重加和；第二部分也有条件判断，对非组合商品直接累加数量，这样让绝大多数非组合商品直接累加，就大大减少了去重加和的开销。

行文至此，是不是觉得这个问题已经完美解决了，还记得前文那个「是又不是」的回答吗，为什么这么说呢，我们来看看做法三。

做法三

如果你还对 SUM(DISTINCT x) 耿耿于怀，那告诉你念念不忘，必有回响。经过做法二，使用元组保存了「去重键」及「原始数量」，那是不是可以更进一步，拿 UInt64 类型分两段来分别保存「去重键」和「原始数量」，高位 33 ~ 64 用来保存「去重键」，低位 1 ~ 32 用来保存「原始数量」，高位和低位的加和不冲突，查询加和后取低位 1 ~ 32 的值作为结果（见下图），理论可行，实践开始。

改造表

-- 将 orgQuantity 修改为 UInt64 类型
-- 高位 33 ~ 64 用来保存「去重键」, 为 0 表示非组合商品，有值时为组合商品当前订单的订单号和商品 ID 的 crc32 值
CREATE TABLE f_order_3
(
    `orderID` String,
    `productID` UInt32,
    `sku` String,
    `orgQuantity` UInt64,
    `realQuantity` UInt16
)
ENGINE = MergeTree
ORDER BY orderID
SETTINGS index_granularity = 8192

-- 从 f_order 中导入数据，仅 productID 为 123 组合商品时才赋值给 orgQuantity.k
INSERT INTO f_order_3 SELECT
    orderID,
    productID,
    sku,
    bitShiftLeft(toUInt64(if(productID = 123, crc32(concat(orderID, toString(productID))), 0)), 32) + orgQuantity,
    realQuantity
FROM f_order

SELECT *
FROM f_order_3

┌─orderID─┬─productID─┬─sku─┬──────────orgQuantity─┬─realQuantity─┐
│ o1      │       123 │ JP1 │ 16347559244213518337 │            1 │
│ o1      │       123 │ SB1 │ 16347559244213518337 │            2 │
│ o2      │       456 │ JP1 │                    2 │            2 │
│ o3      │       789 │ SB1 │                    1 │            1 │
└─────────┴───────────┴─────┴──────────────────────┴──────────────┘

查询

-- 统计原始销量汇总为 4（123：1，456：2，789：1）
SELECT bitAnd(sumDistinctIf(orgQuantity, orgQuantity >= 4294967296), 4294967295) + sumIf(orgQuantity, orgQuantity < 4294967296) AS totalOrgQuantity
FROM f_order_3

┌─totalOrgQuantity─┐
│                4 │
└──────────────────┘


-- 统计商品（productID）维度的原始销量为 123：1，456：2，789：1
SELECT
    productID,
    bitAnd(sumDistinctIf(orgQuantity, orgQuantity >= 4294967296), 4294967295) + sumIf(orgQuantity, orgQuantity < 4294967296) AS totalOrgQuantity
FROM f_order_3
GROUP BY productID

┌─productID─┬─totalOrgQuantity─┐
│       456 │                2 │
│       789 │                1 │
│       123 │                1 │
└───────────┴──────────────────┘


-- 统计 sku 维度的实际销量为 JP1：3，SB1：3
SELECT
    sku,
    sum(realQuantity) AS totalRealQuantity
FROM f_order_3
GROUP BY sku

┌─sku─┬─totalRealQuantity─┐
│ JP1 │                 3 │
│ SB1 │                 3 │
└─────┴───────────────────┘


-- 统计 sku 维度的原始销量为 JP1：3，SB1：2
SELECT
    sku,
    bitAnd(sumDistinctIf(orgQuantity, orgQuantity >= 4294967296), 4294967295) + sumIf(orgQuantity, orgQuantity < 4294967296) AS totalOrgQuantity
FROM f_order_3
GROUP BY sku

┌─sku─┬─totalOrgQuantity─┐
│ JP1 │                3 │
│ SB1 │                2 │
└─────┴──────────────────┘

语句分同样为两部分组成，第一部分条件 orgQuantity >= 4294967296 表示有去重键是组合商品，需要进行去重加和，直接使用 sumDistinct 做加和，对加和后的结果使用 bitAnd 取出低位 1 ~ 32；第二部分条件 orgQuantity < 4294967296 表示没有去重键是非组合商品，直接累加数量；最后两部分相加得出正确结果。

小结

做法二和做法三看上去都能满足需求，到底应该用哪个呢？先不急着下结论，我们再对比下两者的性能：

模拟做法二

CREATE TABLE x_tuple
(
    `x` Tuple(Nullable(UInt32), UInt16)
)
ENGINE = MergeTree
ORDER BY x

-- 模拟 9 / 10 的数据为非组合商品（没有去重键）
INSERT INTO x_tuple SELECT x
FROM
(
    SELECT
        number % 100000 AS y,
        (if(y > 90000, NULL, y), (number % 4) + 1) AS x
    FROM numbers(10000000)
)

SELECT arraySum(x -> (x.2), groupUniqArrayIf(x, isNotNull(x.1))) + sumIf(x.2, isNull(x.1)) AS x
FROM x_tuple

┌───────x─┐
│ 2724901 │
└─────────┘

1 rows in set. Elapsed: 0.381 sec. Processed 10.00 million rows, 70.00 MB (26.26 million rows/s., 183.81 MB/s.)

模拟做法三

CREATE TABLE x_distinct
(
    `x` UInt64
)
ENGINE = MergeTree
ORDER BY x

-- 模拟 9 / 10 的数据为非组合商品（没有去重键）
INSERT INTO x_distinct SELECT x
FROM
(
    SELECT
        number % 100000 AS y,
        (if(y > 90000, 0, bitShiftLeft(toUInt64(y + 1), 32)) + (number % 4)) + 1 AS x
    FROM numbers(10000000)
)

SELECT bitAnd(sumDistinctIf(x, x >= 4294967296), 4294967295) + sumIf(x, x < 4294967296) AS x
FROM x_distinct

┌───────x─┐
│ 2724901 │
└─────────┘

1 rows in set. Elapsed: 0.170 sec. Processed 10.00 million rows, 80.00 MB (58.71 million rows/s., 469.69 MB/s.)

从上面结果看出，做法三在性能上还是快了一大截。

那么果断使用做法三吗，其实不然，如果经常要查看原始数据，建议还是使用做法二，毕竟做法三像给数量「加密」了，没法肉眼看出原始数量多少，为了一点性能，损失便利性，有点得不偿失；做法三还有一个天生的短板，低位加和超过 4294967295 后数据就开始错乱了，但这个值也足够销量指标用了。

总结

本文通过「去重加和」这个场景，展现出 ClickHouse 查询语法的灵活性，以及存储格式的多样性，抛砖引玉，希望可以拓宽读者使用 ClickHouse 解决查询问题的思路。若「查询组合商品的原始销量汇总」这一特定案例的模拟，能帮助读者解决类似数据查询的问题，倍感荣幸。

注：本文所有语句均运行在 ClickHouse 21.8.4.51 版本上，过低的版本可能无法支持 sumDistinct 函数，请读者自行辨别。

前几天被新浪的一位程序员刷屏了，婚礼现场还要跑去修 bug，这事得赖鹿晗。看到之后想起我的婚礼，那是一年前也是在国庆。距婚礼还有一个月的时候，心想这可是一辈子的大事，在众多亲朋好友面前搞点比较 cool 的事情，这样会不会让大家印象深刻点。

怎样会比较 cool

希望你看到这个标题不要以为是让基友拉着我私奔😱。让现场所有宾客都能参与进来，对，这应该比较 cool。根据以往参加别人婚礼的经验，流程大概是：主持人引导新郎新娘进场，新郎新娘立下海誓山盟，新郎新娘双方父母登台，然后全场一起举杯祝福新人，最后一直吃到婚礼结束。宾客除了那一次举杯，全程都是路人，参与感非常低。有的婚礼会有些互动，这完全看主持人的个人风格了。

要调动现场，站在台上撒红包这种土豪的做法显然不适合木讷的我。眼下几乎人人都有智能机，人人都有微信，于是就想能不能借助微信让大家参与进来。大家可以发祝福上墙，然后现场大屏以弹幕形式将大家祝福展示出来。大家发完祝福可以在大屏上看到自己的头像以及祝福的话，内心是不是有一丝丝的满足。

一开始是想搞一个公众号，大家可以直接在输入框发祝福，后面觉得这样还是太死板，没趣，放弃了。

搞个微信 web 吧，不用关注也能访问，而且把 web 页面做成请柬的形式，还可以提前分享给大家暖暖场。那还等什么，干呀。

撸起袖子就是干

传统请柬三要素：时间地点和人物，我的请柬三要素：签到地图和弹幕。吭哧吭哧，花了两周的业余时间，期间媳妇也帮忙处理了图片，成品长这样：

技术栈

倒是没什么吊炸天的技术，因为开发时间有强制的 deadline，我可不想因为开发这个而错过我的婚礼😂。所以挑的技术都是一些比较熟悉而且开箱即用的。

后台：Mysql、Nodejs、Sails、Sequelize、Bluebird；

前端：WeUI、jQuery、jquery.fullPage、slick、CommentCoreLibrary(CCL弹幕)、高德地图、iconfont。

弹幕数据实时更新是用的最简单的短轮询，没别的，就一个稳字。

如果你有打开体验，看了几张背景照片你会发现，不管照片中人物主体的位置是偏左还是偏右，在你的视觉中一定是居中显示的，这样保证打开后一眼就能看到我们😘。这个也不是什么高大上的技术，就是提前测量好每张照片人物主体中心线的偏移量，然后写在图片标签的属性里。如下图所示，白色代表照片，绿色代表手机屏幕，两个圆圈代表照片上的人物主体。

遇到的一些坑

微信的坑

做好后是部署在我自己的服务器上，域名也没备案，刚分享出去一切都挺顺利。可后面逐渐就有人反馈打不开或打开空白的情况，经过抓包才发现微信会把分享的网址在打开前做拦截，如果域名没有备案那就只能 say goodbye。

微信还会在输入框获取焦点时，提示用户注意安全，谨防泄密。这个也挺烦人的，发个祝福还要注意安全😥。不过这个在公众号可以设置域名白名单，当然前提也是域名要备案。

弹幕的坑

CCL 弹幕库之前默认的渲染方式是 left、top，目的是为了向下兼容。但是在手机端的性能简直不忍直视，当时有个版本 v0.10.0-rc 在测试使用 css3 的渲染方式，切过去效果直逼 PC 端，就马上用上了。现在 CCL 默认的渲染方式就是 css3，不用再踩这个坑了。

输入法的坑

使用中文输入法的时候，输入框底部和键盘顶部无法完美贴合。这个坑到现在也一直没有填，这篇文章《移动端输入框填坑系列（一）》似乎给了解决办法。

干完只是开始

产品开发完成并不是结束，而是开始。怎么引流，生产环境有 bug 等等这些问题接踵而来。

如何让大家现场访问

在入口迎宾处扫码？这样只能一次性加入，退出了就很难再进来。

在现场加群，在群里发链接？这样看似是个好办法，但宾客有绝大多数是年纪比较大，能用微信扫码就了不起，现场加群这种操作还是难为他们了。

二维码投在大屏上？这影响大屏的美感，而且后场扫码几乎是不可能的。

最后想了一个土办法将二维码打在小卡片上，每个桌上发几张。于是随便设计了小卡片的样式，在 TB 上找了家打印店印了 100 多张，成本还是比较低的。

卡片上的二维码现在依然有效，只是现在不抽奖了😂，可以用微信扫一扫体验下。

婚礼结束后统计了下，现场总共有 300 多人，发祝福的有 150 多人，这个转换率还是可以的。

如何搞定现场大屏

上面只讲了微信 web 端，其实完成整个互动，还有一个重要组成部分——现场大屏。酒店的大屏多是 LED 拼接大屏，这可不像电脑的显示器，有明确的分辨率。当时打电话问酒店前台大屏分辨率是多少，他们也是一脸懵逼。后面咨询做大屏的朋友才知道，他们根本不讲分辨率，只讲尺寸，叫我等比例走就行，于是我也一脸懵逼了。不管啦，做了多个响应式尺寸以防万一。

大屏端的交互就没那么多了，都是一些自动播放或静态展示的东西。

如何抽奖

大屏端有个抽奖界面，这个抽奖环节还是需要主持人和幕后人员配合的。主持人发口令，幕后人员根据口令控制抽奖开始与结束。在婚礼前与主持人沟通过程中，主持人表示赞叹：主持了十多年婚礼，第一次见到这么有趣的形式。此时我内心喜悦而又惶恐，担心现场搞砸。

关于抽奖算法，就是简单的完全随机抽取，那句“据说颜值高的和祝福多的都更有机会中奖”，仅仅是促进大家发祝福的小玩笑（好像有点贱，逃~~）。候选人则是所有签到在现场的宾客，扫了上面小卡片上的二维码就可以自动签到在现场，这样也省去宾客需要多余的操作。

其他一些未完成的想法

在微信端完成后，我就分享到朋友圈。一会儿收到了很多祝福，为了感谢大家，就在弹幕里发了一个口令红包，浏览量瞬间爆棚，小水管服务器都有点抗不住了。这给了我一个很好的启发，于是想后台设置个定时任务，在婚礼现场来场震撼的口令红包雨。不过这个想法后来被其他事耽搁了，没有加上，也是有点小遗憾。

One more thing

在本文发布的同时，也打算把这个尘封一年的项目开源出来。祝愿所有的 forker 有情人终成眷属。

项目地址：iammapping/wedding

HTML5中 Web Storage 的出现，主要是为了弥补使用 Cookie 作为本地存储的不足。Cookie 存储的数据量非常小，而且数据会自动携带到请求头里，但服务器端可能并不关心这些数据，所以会造成带宽的浪费。

Web Storage 提供了两个存储对象：localStorage 和 sessionStorage。

sessionStorage 存储的数据仅在本次会话有用，会话结束后会自动失效，而且数据仅在当前窗口有效，同一源下新窗口也访问不到其他窗口基于
sessionStorage 存储的数据。也是由于这些特性，导致 sessionStorage 的使用场景会比较少。

localStorage 可以永久存储，而且同源下数据多窗口也能共享。看起来很美好，但 localStorage 也有短板，绝大多数浏览器有 5M 的大小限制。但是这不足以成为大家使用 localStorage 的障碍，要知道 Cookie 只有 4K 的大小，多了一千多倍，偷着乐吧。

localStorage 的基本使用

讲这个内容的文章网上太多了，现在再来讲有点老套了。这里就不做更多介绍了，不清楚的读者可以看这里。

有两点需要注意一下。在 setItem 时，可能会达到大小限制，最好加上错误捕捉 ¹：

try {
  localStorage.setItem(key, value);
} catch(e) {
  if (isQuotaExceeded(e)) {
    // Storage full, maybe notify user or do some clean-up
  }
}

function isQuotaExceeded(e) {
  var quotaExceeded = false;
  if (e) {
    if (e.code) {
      switch (e.code) {
        case 22:
          quotaExceeded = true;
          break;
        case 1014:
          // Firefox
          if (e.name === 'NS_ERROR_DOM_QUOTA_REACHED') {
            quotaExceeded = true;
          }
          break;
      }
    } else if (e.number === -2147024882) {
      // Internet Explorer 8
      quotaExceeded = true;
    }
  }
  return quotaExceeded;
}

另外在存储容量快满时，会造成 getItem 性能急剧下降 ²。

我们下面看看 localStorage 有哪些脑洞大开的用法。

缓存静态文件

你不禁要问，HTTP 协议不是本来就支持缓存文件吗（之前写过一篇文章《Web缓存之HTTP指南》），为什么还要使用 localStorage 来缓存？为了可编程化，通俗一点说就是把命运握在自己手中。

HTTP 协议的缓存，可以由用户浏览器清除或禁用缓存，也可以由 Web 服务器设置过期时间或不缓存。对于前端工程师，这更像是一个黑盒，想要决定文件是访问缓存还是访问远程显得有些力不从心了。

使用 localStorage 控制文件缓存的方式有两种：

1. 使用 Loader 加载静态文件
2. 借助服务器端将静态文件 inline 化

这两种方式一般都会提前做好缓存过期策略，通常是使用版本号来控制，下面还会细讲。否则文件新版上线，用户客户端还是旧版，这就麻烦大了，而且这类问题，还不好调试不好重现。

使用 Loader 加载静态文件

由于请求都是动态发出的，所以可以对请求拦截处理。大致流程如下：

1. 查看请求的文件 url 是否有缓存到 localStorage
   1. 如果没有，到第 2 大步
   2. 如果有，判断文件是否过期或版本号是否匹配
      1. 过期或不匹配，到第 2 大步
      2. 文件内容有效，到第 4 大步
2. 请求远程文件
3. 缓存最新文件内容
4. 执行文件内容

这个方式有个开源库：basket.js。

借助服务器端将静态文件 inline 化

这个方式比上面那种更进一步，在第一次响应时把需要放入 localStorage 的文件都内联进 html 中，后面每次响应只要文件版本没有变化，都是渲染一段从 localStorage 加载该文件的代码。这样做的好处是可以有效减少请求次数，即使是第一次。

版本号不匹配（版本号可记在 Cookie 中，第一次访问没有版本号），服务端响应内容：

<script>
function script2ls(id) {
  var script = document.getElementById(id);
  if (script) {
    localStorage[id] = script.innerHTML;
  }
}
</script>

<script id="jquery.js">...jquery source code...</script>
<script>script2ls('jquery.js')</script>

版本号匹配，服务端响应内容：

<script>
function ls2script(id) {
  var script = document.createElement('script');
  script.text = localStorage[id];
  document.head.appendChild(script);
}
</script>

<script>ls2script('jquery.js')</script>

不过使用 localStorage 缓存文件会有 XSS 的风险，而且造成的伤害可能是永久的 ³。

同源窗口通信

你可能不禁又要问，不是有 postMessage 吗？没错 postMessage 确实可以用于窗口或 iframe 间通信，但是前提是你必须拿到打开新窗或 iframe 的句柄对象：

var popup = window.open(...popup details...);
popup.postMessage("hello there!", "http://example.com");

这样在新窗中再打开新窗，似乎就不好传递消息了。

你可能还想问，为什么要在窗口间通信？好问题，没有应用场景的技术都是耍流氓。像多窗口共用的一些组件，而且对数据实时同步都有较高要求的都会是这个技术的应用场景。比如通知中心上面的未读数量，两个窗口，A 窗口更新为 8，切到 B 窗口还是 9，这就造成了体验不一致，这个例子可能还觉得无关痛痒；再比如购物车，两个产品窗口，A 窗口添加到购物车，切到 B 窗口添加到购物车，发现没有 A 添加的产品，这样就比较严重了。这当然也可以通过每个窗口都与后台建立连接来更新，但用户如果开十几个窗口就开销大了。

有了同源窗口通信，我们就可以只有一个窗口与后台建立连接，收到更新后，广播给其他窗口就可以。说了这么多，实现原理是怎样的呢？

其实原理也简单，每次 localStorage 中有任何变动都会触发一个 storage 事件，所有窗口都监听这个事件，一旦有窗口更新 localStorage，其他窗口都会收到通知，根据事件中的 key 把不关心的变动过滤掉。原理是很简单，但是要实现一套完整的广播机制还是有些复杂，你需要：

• 管理好每个窗口的唯一 ID
• 防止消息重复
• 防止消息发给不关心的窗口
• 窗口心跳 keep alive
• 主窗口选举
• ...

不用担心，已经有了不错的开源实现：diy/intercom.js、tejacques/crosstab

其他

作为前端 DB 的存储介质

你可能不满足于用键值对保存数据，你还想保存更复杂的数据结构。

灵活存取 json 格式的数据：typicode/lowdb

通过 sql 对数据 CURD 操作：agershun/alasql

表单自动持久化

在填写表单时，遇到浏览器崩溃或者误操作导致填写内容丢失，此刻用户的内心也应该是崩溃的。误操作还可以加一个 beforeunload 事件，在关闭浏览器或跳出当前页前提醒一下用户。那浏览器崩溃呢，将数据变更实时保存到后台，这样似乎开销很大，实时保存到 localStorage 是个不错的解决方案，真巧，也有一个开源实现：simsalabim/sisyphus

总结

文件缓存现在有更好的解决方案，没错，说的就是 Service Worker 的 CacheStorage。

不过多了解一些脑洞大开的想法，有利于拓展解决问题的思路。

Enjoy open source ❤️

参考：

1：Always catch LocalStorage security and quota exceeded errors
2：Measuring localStorage Performance
3：使用 SRI 增强 localStorage 代码安全

匿名函数最早是LISP语言引入，后面发展为不仅是函数式语言所特有，在解释型语言和编译型语言中也越来越多地看到匿名函数的身影，它或许有个更潮的名字叫 lambda 表达式。

闭包多是用匿名函数实现，在匿名函数中引用了外部变量，那这个匿名函数就形成了闭包。由于闭包和匿名函数之间有着千丝万缕的关系，所以经常会把两者搞混淆。其实在 Js 中匿名函数、闭包、自执行函数、回调函数、箭头函数，这些概念似乎相同，却又不同，请读者朋友自行了解。

匿名函数拥有可动态编程的执行过程。巧妙使用可以让你的代码简约而不失优雅，灵活而不失约束。好了，正式切入本文的正题，巧用匿名函数重构代码。按照重构的惯例，先指出代码中的坏味（Bad Smell）：

• 定义冗长的重复配置
• 条件多变的集合过滤
• 说一不二的方法调用

定义冗长的重复配置

在写配置代码时，经常会遇到大量重复的配置，如果要修改一些内容，所有的都要修改，着实很累，而且容易遗漏。比如：

{
  html: `
    <label><input type="checkbox" name="apple" /> Apple</label>
    <label><input type="checkbox" name="banana" /> Banana</label>
    <label><input type="checkbox" name="orange" /> Orange</label>
  `
}

这里面有三个选项，三个选项的结构完全一样，如果要给所有选项加一个 title，那你就要把这件事重复做三遍。

{
  html: `
    <label><input type="checkbox" name="apple" title="Apple" /> Apple</label>
    <label><input type="checkbox" name="banana" title="Banana" /> Banana</label>
    <label><input type="checkbox" name="orange" title="Orange" /> Orange</label>
  `
}

程序猿是个奇怪的群体，他们宁愿做五件不同的事，也不愿重复三次做同一件事。所以这怎么能忍，把配置中不同的内容提取出来：

{
  html: (function(fruits) {
    return fruits.map(it => `<label><input type="checkbox" name="${it.name}" title="${it.title}" /> ${it.title}</label>`).join('');
  }([
    {name: 'apple', title: 'Apple'},
    {name: 'banana', title: 'Banana'},
    {name: 'orange', title: 'Orange'}
  ]))
}

这样的修改对配置的调用方来说是完全透明的，但是对于配置的维护者来说，将结构和数据分离开，要改结构就改自执行方法体，要改数据就改传入自执行方法的参数，可以大大减少犯错的风险，又避免一些无脑的复制粘贴。

虽然在配置中写代码逻辑不是特别推荐的做法，但相对于代码可维护性来说这不算啥了。

条件多变的集合过滤

集合过滤是个非常常见的需求，假设有个学生集合：

let students = [
  {name: 'Lucy', age: 20, sex: 'female'},
  {name: 'LiLei', age: 21, sex: 'male'},
  {name: 'Jim', age: 18, sex: 'male'}
]

现在要过滤出年龄 20 岁的同学：

function filterByAge(list, age) {
  let filtered = [];
  for (let i = 0; i < list.length; i++) {
    if (list[i].age === age) {
      filtered.push(list[i]);
    }
  }
  return filtered;
}

又要过滤出姓名叫 LiLei 的同学：

function filterByName(list, name) {
  let filtered = [];
  for (let i = 0; i < list.length; i++) {
    if (list[i].name === name) {
      filtered.push(list[i]);
    }
  }
  return filtered;
}

还要过滤出性别为男的同学：

function filterBySex(list, sex) {
  let filtered = [];
  for (let i = 0; i < list.length; i++) {
    if (list[i].sex === sex) {
      filtered.push(list[i]);
    }
  }
  return filtered;
}

就在你觉得大功告成，可以站起弯伸腰的时刻，突然被一股强大的力量按回了座椅，帮我找出姓名以 “L” 开头的童鞋。虽然你内心是 mmp~，但还能怎么办，写啊，于是又吭哧吭哧加了如下方法：

function filterByNameStart(list, nameStart) {
  let filtered = [];
  for (let i = 0; i < list.length; i++) {
    if (list[i].name.indexOf(nameStart) === 0) {
      filtered.push(list[i]);
    }
  }
  return filtered;
}

于是乎，这个调用方式：

filterByName(filterBySex(filterByAge(students, 21), 'male'), 'LiLei'); 

就可以理解为找出年龄为 21 岁的男性 LiLei。好吧，可读性还不算太差。

但是，不难看出以上 filterByAge、filterByNameStart 等这一系列方法中，除了过滤条件不同，其他逻辑完全一样，造成了大量代码的重复；并且没有任何灵活性可言，调用方改需求，你就要加方法。

我们现在就使用匿名函数把不同的部分抽出去，让调用方想怎么过滤就过滤。filter 方法的主干逻辑只关心当前的元素是不是要放入结果集合中，其他的判断逻辑都交给匿名函数 fn 去做：

function filter(list, fn) {
  let filtered = [];
  for (let i = 0; i < list.length; i++) {
    if (fn(list[i], i) === true) {
      filtered.push(list[i]);
    }
  }
  return filtered;
}

上面的例子会变成这种写法：

filter(students, function(member) {
  return member.name === 'LiLei' && member.age === 21 && member.sex === 'male';
});

使用箭头方法可以更简洁：

filter(students, member => member.name === 'LiLei' && 
    member.age === 21 && 
    member.sex === 'male');

现在调用方再提一些变态的过滤方式，你可以回一个眼神，自己写去。

说一不二的方法调用

假设有个 Api 接口，将传入的数字翻倍并返回，这个接口支持单个和批量的方式。

传入 5

• 执行成功返回 {status: 'success', data: 10}
• 执行失败返回 {status: 'failed', error: 'xxx'}

传入 [2, 3]

• 执行成功返回 {status: 'success', data: [{status: 'success', data: 4}, {status: 'success', data: 6}]}
• 执行失败返回 {status: 'success', data: [{status: 'failed', error: 'xxx'}, {status: 'failed', error: 'xxx'}]}

也就是单个输入会按单个格式输出，批量输入会按批量格式输出。三下五除二，实现了下面这个版本：

function multiple(inNum) {
  if (Array.isArray(inNum)) {
    // 处理批量情况
    return {
      status: 'success',
      data: inNum.map(it => {
        if (isNaN(parseFloat(it))) {
          return {
            status: 'failed',
            error: 'The input is not a number'
          };
        } 

        return {
          status: 'success',
          data: it * 2
        }
      })
    };
  } else {
    // 处理单个情况
    if (isNaN(parseFloat(inNum))) {
      return {
        status: 'failed',
        error: 'The input is not a number'
      };
    }

    return {
      status: 'success',
      data: inNum * 2
    };
  }
}

这里面单个和批量两种方式除了输入和输出格式不同，其他逻辑完全一样。如果要将乘 2 改成乘 3，两个地方都要改。那看下怎么使用匿名函数来避免两处修改：

function execute(data, fn) {
  // 最小执行单元
  let single = it => {
    try {
      return {
        status: 'success',
        data: fn(it)
      };
    } catch (e) {
      return {
        status: 'failed',
        error: e.toString()
      }
    }
  };

  if (Array.isArray(data)) {
    return {
      status: 'success',
      data: data.map(single)
    }
  } else {
    return single(data);
  }
}

function multiple(inNum) {
  return execute(inNum, it => {
    if (isNaN(parseFloat(it))) {
      throw new Error('The input is not a number');
    }

    return it * 2;
  });
}

现在 execute 方法只管输入输出的格式和错误处理，包揽了所有脏活累活；multiple 方法则只关心业务的具体实现，也不用关心输入的是单个元素还是数组。如果要改乘 3，只要修改 multiple 方法最后一个 return。如此一来，execute 还可以被其他的 Api 方法复用，可谓一举两得。

总结

本文的目的只是抛砖引玉，代码中可利用匿名函数重构的坏味还有很多，这种重构方式不只是适用于 Js 中。大家只要多思考、多动手，代码质量一定会day day up~~

关于重构我还想多说一点，重构的过程应该是渐进的方式，当你改第一次的时候可能觉得还ok，第二次就要想下是不是有更好的方式来实现。如果修改对调用方透明那是最好了，实在不行让调用方配合修改也是值得的，当然这其中还要权衡时间成本。Your boss is watching you 😡

Happy Code 😁

这篇文章作为之前两篇文章的延续，来的稍微有点迟。

• 如何优雅地写js异步代码
• 如何优雅地写js异步代码(2)

时隔一年，以上两篇文章内容或有过时，请读者自行斟酌。好下面正式开始本文内容。

循环的方式

假设我们有个数组，包含 5 个数字：let times = [100, 150, 200, 250, 300]；
还有一个异步的睡觉方法：sleep(time, cb)。

import Promise from 'bluebird';

// 当没有 cb 时，返回一个 Promise 对象
export default function sleep(time, cb) {
    if (cb) {
        setTimeout(cb, time);
    } else {
        return new Promise(resolve => {
            setTimeout(resolve, time);
        });
    }
};

现在要去循环睡这几个数字，问你有哪些睡法？🤔

为了方便交流，我就给这几个睡法起个名字：

1. All in：你如果赶时间又不担心消耗过度，你可以一次性都睡了；
2. One by one：你想细水长流，你可以一个一个睡；
3. With concurrency：你害羞地低下头，说一次能不能睡两个。

作为一段有节操的代码，肯定要告诉其他人你睡完了，也就是必须有全部完成的回调，否则我们接下来的交流会毫无意义。

本文目的是和大家探讨如何写出优雅的异步循环代码，并不是去实现这些循环控制的逻辑；而保持代码优雅，个人以为最好的办法是使用较新的语言特性，其次是使用优秀的开源项目，最后才是自己撸。下面会使用 Async、Promise(bluebird) 和 ES7 中的 async/await 对比下实现这几种循环的区别。

All in

这种方式效率是最高的，耗时取决于循环中最慢的那个异步方法。对资源的消耗也是最大的，如果大量循环请求后端服务，很有可能造成瞬时拥堵的情况。

如果自己实现，这也是最简单的场景，加一个完成计数器，每个异步方法完就给这个完成计数器加 1，然后检查完成数是不是等于数组长度，一旦相等就表示所有的异步方法执行完毕，通知全部完成的回调。

使用 async.each：

import { each } from 'async';
import sleep from './sleep';

let times = [100, 150, 200, 250, 300];

console.log('sleep start');
console.time('async all in');
each(times, sleep, (err) => {
    console.timeEnd('async all in');
    console.log('sleep complete');
});
// sleep start
// async all in: 304.627ms
// sleep complete

使用 Promise.all：

import Promise from 'bluebird';
import sleep from './sleep';

let times = [100, 150, 200, 250, 300];

console.log('sleep start');
console.time('promise all in');
Promise.all(times.map(time => sleep(time))).then(() => {
    console.timeEnd('promise all in');
    console.log('sleep complete');
});
// sleep start
// promise all in: 305.509ms
// sleep complete

使用ES7 async/await：

import sleep from './sleep';

let times = [100, 150, 200, 250, 300];

(async function() {
    console.log('sleep start');
    console.time('es7 all in');
    for await (let i of times.map(time => sleep(time))) {}
    console.timeEnd('es7 all in');
    console.log('sleep complete');
}());
// sleep start
// es7 all in: 305.986ms
// sleep complete

One by one

这种方式效率最低，有点类似于同步语言中的循环，一个接着一个执行，耗时自然也就是所有异步方法耗时的总和。对资源的消耗最小。

这个实现起来也比较简单，把数组看做一个队列，每次从队列shift出一个代入异步方法执行，执行完成就开始递归调用这个过程，当队列长度为空就表示所有的异步方法执行完毕，结束递归，通知全部完成的回调。

使用 async.eachSeries：

import { eachSeries } from 'async';
import sleep from './sleep';

let times = [100, 150, 200, 250, 300];

console.log('sleep start');
console.time('async one by one');
eachSeries(times, sleep, (err) => {
    console.timeEnd('async one by one');
    console.log('sleep complete');
});
// sleep start
// async one by one: 1020.078ms
// sleep complete

使用 Promise.reduce：

import Promise from 'bluebird';
import sleep from './sleep';

let times = [100, 150, 200, 250, 300];

console.log('sleep start');
console.time('promise one by one');
Promise.reduce(times, (last, curr) => {
    return sleep(curr);
}, 0).then(() => {
    console.timeEnd('promise one by one');
    console.log('sleep complete');
});
// sleep start
// promise one by one: 1023.014ms
// sleep complete

使用ES7 async/await：

import sleep from './sleep';

let times = [100, 150, 200, 250, 300];

(async function() {
    console.log('sleep start');
    console.time('es7 one by one');
    for (let time of times) {
        await sleep(time);
    }
    console.timeEnd('es7 one by one');
    console.log('sleep complete');
}());
// sleep start
// es7 one by one: 1025.513ms
// sleep complete

With concurrency

这种方式稍微复杂些，但也是最灵活的方式，可以随心控制并发数。效率和耗时取决于魔法数字 concurrency，当 concurrency 大于或等于数组长度时，它就等同于 All in 方式；当 concurrency 为 1 时，它就等同于 One by one 方式。所以耗时和对资源的消耗都会介于以上两种方式之间。

With concurrency 本身在实现上也会有不同的方式，分别是预分组和任务池。

预分组

顾名思义，就是提前将数组内容按 concurrency 分好组，组内是以 All in 方式执行，组之间则是以 One by one 的方式执行。

就以上文的例子，假如 concurrency 为 2，times 预先分组成：[[100, 150], [200, 250], [300]]，这样耗时会是 700（150 + 250 + 300）。

这个实现方式可以有效地控制并发数，优点就是简单，缺点是并不能达到效率最大化。

任务池

任务池的方式就是设置一个容量为 concurrency 的池子，比如容量为 2，初始化放入两个任务，每当有任务完成，就继续往池子添加新的任务，直到所有任务都完成。上文的例子执行过程大致如下：

1. time = 0; pool = [100, 150]：放入 100 和 150
2. time = 100; pool = [150, 200]：100 结束，放入 200
3. time = 150; pool = [200, 250]：150 结束，放入 250
4. time = 300; pool = [250, 300]：200 结束，放入 300
5. time = 400; pool = [300]：250 结束，没有更多任务
6. time = 600; pool = []：300 结束，循环完毕

得出来的耗时是 600，比预分组的方式效率更高，而且同样能有效控制并发个数。async 和 bluebird 也有相关的方法供直接使用。

使用 async.eachLimit：

import { eachLimit } from 'async';
import sleep from './sleep';

let times = [100, 150, 200, 250, 300];

console.log('sleep start');
console.time('async with concurrency');
eachLimit(times, 2, sleep, (err) => {
    console.timeEnd('async with concurrency');
    console.log('sleep complete');
});
// sleep start
// async with concurrency: 611.498ms
// sleep complete

使用 Promise.map（bluebird 特有 api）：

import Promise from 'bluebird';
import sleep from './sleep';

let times = [100, 150, 200, 250, 300];

console.log('sleep start');
console.time('promise one by one');
Promise.map(times, (time) => {
    return sleep(time);
}, {
    concurrency: 2
}).then(() => {
    console.timeEnd('promise one by one');
    console.log('sleep complete');
});
// sleep start
// promise with concurrency: 616.601ms
// sleep complete

使用ES7 async/await：

pool 方法来自davetemplin/async-parallel

import sleep from './sleep';

let times = [100, 150, 200, 250, 300];

(async function() {
    console.log('sleep start');
    console.time('es7 with concurrency');
    await pool(2, async () => {
        await sleep(times.shift());
        return times.length > 0;
    });
    console.timeEnd('es7 with concurrency');
    console.log('sleep complete');
}());

async function pool(size, task) {
    var active = 0;
    var done = false;
    var errors = [];
    return new Promise((resolve, reject) => {
        next();
        function next() {
            while (active < size && !done) {
                active += 1;
                task()
                    .then(more => {
                        if (--active === 0 && (done || !more))
                            errors.length === 0 ? resolve() : reject(errors);
                        else if (more)
                            next();
                        else
                            done = true;
                    })
                    .catch(err => {
                        errors.push(err);
                        done = true;
                        if (--active === 0)
                            reject(errors);
                    });
            }
        }
    });
}
// sleep start
// es7 with concurrency: 612.197ms
// sleep complete

总结

好了，到这应该可以给这三种循环方式打下分了：

乍一看 With concurrency 是完胜，其实并没有。All in 和 One by one 虽然灵活度低，但是应用的场景还是非常广泛的。要求效率优先就使用 All in；如果有下一次循环依赖上一次循环结果的场景，就必须使用 One by One。

再说下上面 async、bluebird、ES7 对这三种循环方式的实现。需求一直在变，async 需要修改的代码非常少，甚至只要改下方法名就可以，方法定义简单优雅，这可能也是 async 易上手的原因；bluebird 在 Promise 标准基础上添加的方法非常实用，如：map、join...，以至于我几乎是没有使用过原生 Promise 😂；ES7 新增的 async/await 语法特性确实减轻了编写异步代码的痛苦，同时还增强了代码的可读性。

So，你觉得哪种写法更优雅呢？

一般在设计通知中心时，都会在入口处显示一个未读消息数，这样不仅可以醒目地告知用户有未读消息，还能让用户更容易从众多小图标中区分出通知中心的入口。比如 ucloud 控制台的顶栏：

我们网站的通知中心也一样，在入口同样加上了未读消息数的显示。

上线后平稳运行，以为可以就这样一直美下去。程序只要有人用，总会有出 bug 的那一天，最近高峰期经常会出现来自通知表的慢查询语句，仔细一查，原来就是统计未读消息数的语句，而且都是来自几个大用户。我们通知里分了多个组，每个组都有自己的一个未读数，sql 语句差不多是下面这样：

SELECT groupID, count(0) unreadCount FROM notification WHERE userID=xxx AND hasRead=0 GROUP BY groupID;

notification 表中已建立未读索引 unreads： userID + hasRead + groupID 的组合键。

由于我们网站大多是批量异步操作，即使做了消息合并，一天产生几十上百条通知也很正常，而且有的用户就是不喜欢标记通知为已读，这样日积月累，有的用户未读数已经上十万了。假设总记录行有 20 万，如果未读数为 50，建立一个未读的索引，效率会非常显著；但是未读数为 15 万，这时索引的意义也不大了。所以这个性能问题直到现在才暴露出来。

当未读数比较小时：
结果集：

groupID | unreadCount
0 | 23
4 | 16

Explain：

id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
1 | SIMPLE | notification | ref | unreads | unreads | 5 | const,const | 39 | Using where; Using index

耗时：0.4ms（测试数据）

当未读数比较大时：
结果集：

groupID | unreadCount
0 | 23
1 | 103234
3 | 3032
4 | 16

Explain：

id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
1 | SIMPLE | notification | ref | unreads | unreads | 4 | const | 69886 | Using where; Using index

耗时：38.9ms（测试数据）

由上可以看出，未读的记录行数直接影响该语句的性能。

问题出现总归要解决的，如何解决呢？最直接的办法就是看看其他产品是怎么做的。LG 同学提出，可以优化成像 QQ 未读消息数那样显示 99+ 呀。QQ 上有几个群，每天都有人在里面吹水斗表情，消息一会不看就 99+ 了。当初以为这样只是为了排版美观，或者避免特别大的数字给用户造成很大的心理负担，再者也不会有人关心未读的消息是 101 还是 102，所以索性显示 99+。即告诉用户有很多未读消息，又不会因显示一个特别大的数字吓到用户，这样一举两得。但这样似乎只是对用户更友好，对性能然并卵。这时他再次提出可以把 sql 语句拆开来写，一开始我是拒绝的，按照过往经验，多条语句查出结果合并肯定没有单条语句 GROUP BY 来的快。有时经验也会害死人，于是 LG 给出了下面的语句：

SELECT 0 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 0 LIMIT 100) AS a
UNION 
SELECT 1 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 1 LIMIT 100) AS a
UNION 
SELECT 2 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 2 LIMIT 100) AS a
UNION 
SELECT 3 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 3 LIMIT 100) AS a
UNION 
SELECT 4 AS groupID, count(1) AS unreadCount FROM (SELECT 1 FROM notification WHERE userID=xxx AND hasRead='0' AND groupID = 4 LIMIT 100) AS a

这条语句精妙就精妙在 LIMIT 100，使用未读索引并把结果集限定在 100 行以内，这个速度是非常快的。

优化后的时间：
结果集：

groupID | unreadCount
0 | 23
1 | 100
2 | 0
3 | 100
4 | 16

Explain：

id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 23 | NULL
2 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 23 | Using index
3 | UNION | <derived4> | ALL | NULL | NULL | NULL | NULL | 100 | NULL
4 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 73020 | Using index
5 | UNION | <derived6> | ALL | NULL | NULL | NULL | NULL | 2 | NULL
6 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 1 | Using index
7 | UNION | <derived8> | ALL | NULL | NULL | NULL | NULL | 100 | NULL
8 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 3208 | Using index
9 | UNION | <derived10> | ALL | NULL | NULL | NULL | NULL | 16 | NULL
10 | DERIVED | notification | ref | unreads | unreads | 6 | const,const,const | 16 | Using index
NULL | UNION RESULT | <union1,3,5,7,9> | ALL | NULL | NULL | NULL | NULL | NULL | Using temporary

耗时：0.7ms（测试数据）

性能提升了几十倍，堵在胸口的这坨翔终于通了。这条语句的性能会因分组的数量所影响，但分组的数量是有限而且比较固定的，所以这个威胁不成立。

其实到这还没结束，还要结合前台，当 unreadCount 大于 99 时，就要显示 99+，优化后我们的通知中心未读提醒成了这样：

总结

优化不能单靠技术手段，有时产品上做下折中，优化的方法会简单很多。如果这次仅凭技术手段来优化，可能要引入缓存，或者冗余一个未读数，每次更新维护这个数字，这可能需要 2 ~ 3 天的工作量，而且还容易出 bug；而使用 99+ 的做法只花了不到 2 小时。另外也不能一直相信经验，经验有时也会犯错，而且会固化思维。

在文章开始前，先介绍一个背景。著名的异步框架 async 中有一个 waterfall 方法（官方示例），该方法用于控制异步的流程非常直观而且方便，就像下面这样：

async.waterfall([
    function Task1(callback) {
        callback(null, 'a');
    },
    function Task2(last, callback) {
        // last now equals 'a'
        callback(null, 'b');
    },
    function Task3(last, callback) {
        // last now equals 'b'
        callback(null, 'done');
    }
], function (err, result) {
    // result now equals 'done'
});

整个过程写下来就像瀑布一样，参数逐步传递，从上而下，行云流水。如果使用 Promise 实现，可以消除掉丑陋的 callback，伟大的 Github 上也有现成的实现。本文可不是为了介绍这两个库，而是要在这基础上更进一步。

上面的流程，大致可以用如下示意图表示：

可是如果要实现下图的流程：

1. Task1 执行返回 a；
2. Task2_1、Task2_2、Task2_3 并行执行;
3. Task2_1 收到 a 返回 b1;
4. Task2_2 收到 a 执行返回 b2；
   1. Task3 在 Task2_2 执行结束后收到 b2 执行返回 c；
5. Task2_3 收到 a 返回 b3;
6. Task4 收到上一步的 [b1, c, b3] 执行。

是不是感觉有点力不从心了，没事，async.waterfall 结合 async.parallel 一起还是能达到目的：

async.waterfall([
    function Task1(callback) {
        callback(null, 'a');
    },
    function(last, callback) {
        // last equals 'a'
        async.parallel([
            function Task2_1(callback) {
                // last equals 'a'
                callback(null, 'b1');
            },
            function(callback) {
                async.waterfall([
                    function Task2_2(callback) {
                        // last equals 'a'
                        callback(null, 'b2');
                    },
                    function Task3(last, callback) {
                        // last equals 'b2'
                        callback(null, 'c');
                    }
                ], callback);
            },
            function Task2_3(callback) {
                // last equals 'a'
                callback(null, 'b3');
            }
        ], callback);
    },
    function Task4(last, callback) {
        // last equals ['b1', 'c', 'b3']
        callback(null, 'd');
    }
], function(err, result) {
    // result equals 'd'
});

简直叹为观止，但愿这段代码的嵌套以及各种 last 和 callback 没有让你眩晕。如果有一个简单的流程控制框架可以像下面这样简便地实现这个流程：

new Flow([
    function Task1() {
        return 'a';
    },
    [
        function Task2_1(last) {
        	// last equals 'a'
            return 'b1';
        },
        new Flow([
            function Taks2_2(last) {
            	// last equals 'a'
                return 'b2';
            },
            function Task3(last) {
            	// last equals 'b2'
                return 'c';
            }
        ]),
        function Task2_3(last) {
        	// last equals 'a'
            return 'b3';
        }
    ],
    function Task4(last) {
    	// last equals ['b1', 'c', 'b3']
        console.log(last);
    }
]).start();

这样看上去是不是舒服多啦。不过非常遗憾，在写这篇文章前还没有出现这样的一个框架。感觉被耍，别着急，我们自己撸一个便是。

Talk is cheap, Let's 撸.

以下代码自豪地使用 TypeScript 编写（ps: 使用 vscode 写 typescript，真的爽到不要不要的）。

为简单起见，使用 bluebird，而不是原生的 Promise；

import * as Promise from 'bluebird';

定义 Task 的类型，支持普通 Function 对象，Flow 对象和数组；

type Task = Function | Flow | Array<Function | Flow>;

定义 Flow 类；

export class Flow {
    // 保存上一个 Task 的返回值
    private lastValue: any;
    
    // 指向子 Flow 的父 Flow
    public parent: Flow = null;

    // Flow 的构造方法，接收 Tasks
    constructor(protected tasks: Array<Task> = []) {
        if (!(this instanceof Flow)) {
            return new Flow(tasks);
        }
    }

    // 开始 Flow 中的 tasks
    start(initValue: any = Promise.resolve()) : Promise<any> {
        // 逐个执行每一个任务
        return Promise.reduce(this.tasks, (last, curr) => {
            return this.exec(curr, last);
        }, initValue);
    }
}

Flow 中的 exec 方法；

    protected exec(task: Task, last: any) {
        this.lastValue = last;

        // 执行每个单一 task
        let single = (t) => {
            if (t instanceof Flow) {
                // task 为 Flow 对象，既是一个子 Flow
                // 指定 parent 为当前 Flow
                t.parent = this;

                // 开始子 Flow
                return t.start(last);
            } else {
                // task 为普通方法
                return t.call(this, last);
            }
        }

        if (Array.isArray(task)) {
            // task 是数组
            // 并行执行每一个 task
            return Promise.map(task, function(it) {
                return single(it);
            });
        } else {
            return single(task);
        }
    }

到此为止，我们的 Flow 框架已经完成了。另外可以添加两个方法，用于外部向 flow 实例中添加新的 task；

    // 往后追加 task
    append(...tasks: Array<Task>) {
        this.tasks = this.tasks.concat(tasks);

        return this;
    }

    // 往前添加 task
    prepend(...tasks: Array<Task>) {
        this.tasks = tasks.concat(this.tasks);

        return this;
    }

完整代码可查看👉 https://github.com/iammapping/flow。

框架完成了，现在看看实际的应用吧，就来写一个前阵子很火的面试题 LazyMan：

import * as Promise from 'bluebird';
import {Flow} from '../flow';

class LazyMan extends Flow {
    constructor(name: string) {
        super([function() {
            console.log('Hi, I am %s', name);
        }]);
        
        process.nextTick(() => this.start());
    }

    sleep(second: number) {
        return this.append(function() {
            return new Promise((resolve, reject) => {
                setTimeout(() => {
                    console.log('Wake up after %ds!', second);
                    resolve();
                }, second * 1000);
            });
        });
    }

    sleepFirst(second: number) {
        return this.prepend(function() {
            return new Promise((resolve, reject) => {
                setTimeout(() => {
                    console.log('Wake up after %ds!', second);
                    resolve();
                }, second * 1000);
            });
        });
    }

    eat(food: string) {
        return this.append(function() {
            console.log('Eat %s~', food);
        });
    }
}

new LazyMan('mapping').sleep(2).eat('apple').sleepFirst(5);
// Wake up after 5s!
// Hi, I am mapping
// Wake up after 2s!
// Eat apple~

这只是抛砖引玉，小框架也能发挥大威力。

Happy coding~~

代理 ip 因为配置简单而且廉价，经常用来作为反反爬虫的手段，但是稳定性一直是其诟病。筛选出优质的代理 ip 并不简单，即使付费购买的代理 ip 源，卖家也不敢保证 100% 可用；另外代理 ip 的生命周期也无法预知，可能上一秒能用，下一秒就扑街了。基于这些原因，会给使用代理 ip 的爬虫程序带来很多不稳定的因素。要排除代理 ip 的影响，通常的做法是建一个代理 ip 池，每次请求前来池子取一个 ip，用完之后归还，保证池子里的 ip 都是可用的。本文接下来就探讨一下，如何使用 Redis 构建代理 ip 池，实现自动更新，自动择优。

整体流程

由上图所示，左侧是形成了整个流程的闭环，从爬虫程序以独占的方式拿到一个代理 ip 到爬取完成归还 ip。这个流程其实是不太严谨的，如果爬虫程序异常中断，就会导致 ip 无法归还，就会导致这个 ip 无法循环利用。但是由于代理 ip 本身的特点，量多而且循环利用的价值并不大，所以这种情况就let it go。

上面也提到 ip 是以独占的方式获取，如果是去爬两个毫不相关的网站，本来一个 ip 就可以，可现在需要两个。为了资源最大化使用，这里引入了频道 ip 池和总代理 ip 池。两个网站就当做两个频道，各自独占，互不相关；总池子就是保存所有的 ip，每个频道都共享。假设只有一个 ip：1.1.1.1 在总池子，爬 A 网站会把它从总池子取到 A 频道的 ip 池，然后 A 爬虫程序从 A 频道 ip 池取出 1.1.1.1 进行使用，这时 1.1.1.1 依然在总池子里，但 A 频道的 ip 池已经不包含 1.1.1.1 了；爬 B 网站也是一样的流程拿到 1.1.1.1，只是从 B 自己的频道池获取。下面就详细说说总池子和频道池子。

总代理 ip 池

总池子的作用就是共享所有可用的 ip，但是仅作为存储 ip 的池子并不能实现自动择优啊，这里的择优通常是希望延迟低速度快的 ip 更容易被筛选出，所以我们希望池子中的 ip 是根据它们的延时升序排列，借助 Redis 的 Sorted Sets 数据结构即可实现，用延时表示 score，ip 表示 member。

使用 ZADD 添加新 ip 或更新 ip 的延迟：

> ZADD proxy_global_ips 200 1.1.1.1:8080 100 2.2.2.2:80 300 3.3.3.3:8888
(integer) 3

使用 ZRANGE 获取 ip，可以指定获取的个数，比如取两个：

> ZRANGE proxy_global_ips 0 1 WITHSCORES
1) "2.2.2.2:80"
2) "100"
3) "1.1.1.1:8080"
4) "200"

频道 ip 池

频道 ip 池的作用是为了最大化使用总池子中的 ip，并且隔离其他频道的 ip 池。由于一个 ip 使用次数过多是有很大的概率被目标网站屏蔽掉，所以这里也需要进行择优，应该优先筛选出使用次数少的 ip，同理也是使用 Sorted Sets，使用次数表示 score，ip 表示 member，这里与总池子明显的不同之处是 key 不是固定的，需要把频道名称组合进去，这样保证频道之间的隔离，如频道 abc 的 key：proxy_channel_abc_ips。

由于频道池子中的 ip 是要以独占的方式取出，我们需要一个 ZPOP 的方法，奈何 Redis 本身没有，还好可以通过 Lua 模拟，在一个原子操作下取出 ip，然后删除：

> eval "local el = redis.call('zrange', KEYS[1], 0, 0, 'WITHSCORES'); redis.call('zrem', KEYS[1], el[1]); return el;" 1 proxy_channel_abc_ips

往频道 ip 池添加 ip：

> ZADD proxy_channel_abc_ips INCR 0 1.1.1.1:8080

这里与总池子不同的是多了一个 INCR 选项，这是 Redis 3.0.2 版本后才支持的新特性，即指定在 ZADD 时发生 member 冲突采取的处理方式，INCR 顾名思义是冲突后累加 score 的方式，为什么要用这个选项，看看下面这个流程：

1. 在频道池子中只有 1.1.1.1，使用次数为 10；总池子也有 1.1.1.1，而且排在第一个
2. 线程 A 取出 1.1.1.1
3. 线程 B 从频道池子取 ip，没取到，从总池子补充 ip 到频道池子：ZADD proxy_channel_abc_ips 0 1.1.1.1；取出 1.1.1.1
4. 线程 A 归还 1.1.1.1：ZADD proxy_channel_abc_ips 11 1.1.1.1
5. 线程 B 归还 1.1.1.1：ZADD proxy_channel_abc_ips 1 1.1.1.1

第 5 步结束后，ip 1.1.1.1 的计数被错误地重置为 1，而不是我们预期的 12。使用 INCR 选项就可以避免这个尴尬，其实这也只能保证最终计数正确，中途还是会有些非预期的情况，如：

1. 在频道池子中有 1.1.1.1，使用次数为 10，还有 2.2.2.2，使用次数为 2；总池子也有 1.1.1.1，而且排在第一个
2. 线程 A 取出 1.1.1.1
3. 线程 B 取出 2.2.2.2
4. 线程 C 从频道池子取 ip，没取到，从总池子补充 ip 到频道池子：ZADD proxy_channel_abc_ips 0 1.1.1.1；取出 1.1.1.1
5. 线程 C 归还 1.1.1.1：ZADD proxy_channel_abc_ips INCR 1 1.1.1.1
6. 线程 B 归还 2.2.2.2：ZADD proxy_channel_abc_ips INCR 3 2.2.2.2
7. 线程 D 来池子取 ip，按使用次数少的被分配了 1.1.1.1，这就不是我们期望的，1.1.1.1 实际已经用了 12 次，我们更希望 2.2.2.2 被取出

如果要避免这个问题，一个简单粗暴的办法就是增加频道池子的容量，让 ip 数永远大于并发的线程数。

更新

与 ip 有关的两个属性：延时（爬取页面所花的时间）和使用次数。上面只讲到了根据它们自动择优，这里的就来说下它们是如何更新的。延时和使用次数的更新需要爬虫程序的配合，程序中要记录时间和递增使用次数，在归还 ip 时要将最新值带回给总池子和频道池子。上面频道 ip 池的例子也有提及，每次归还 ip 都要将最新的使用次数带上，其次还要将 ip 的延时更新到总池子里面。如果归还 ip 时出现使用失败的情况，就要将该 ip 从总池子里删除掉，保证该 ip 不会再被使用，至于当前的频道池不用归还就行了。其他频道池不作任何处理，因为 ip 在当前频道不可用，一般都是因为被屏蔽，其他频道依然可以使用，即使确实都不能使用，也会在其他频道归还 ip 时被删除。

这两个属性其实也可以都在 Redis 中更新，在获取 ip 时，使用 Hashs 保存 ip 对应的获取时间和使用次数；在归还时从 Hashs 中取出时间计算出延时，取出使用次数并加 1，再分别更新到总池子和频道池子中。而且这还能避免上面提到的获取 ip 不符合预期的问题。

总结

放在 Redis 中更新的方法也有弊端，延时会包含获取和归还的传输时间，如果爬虫程序获取一个 ip 多次使用，会造成使用次数统计偏少。当然也可以通过在程序中多次调用 Redis 更新 ip 的属性来解决，这样增加了整个流程的复杂性，需要自己权衡。

个人还是倾向在程序中记录，最后更新到 Redis 中。这个方案逻辑确实不够严谨，但是出现问题也不会导致严重后果。程序的健壮性也不是不允许出现 bug，而是出现 bug 有很好的容错性。

Markdown is a great language to write a document, and generate a good looking. But it is unpleasant when you insert a local image into your document. If I share the document including some local images with others, the images will be lost. So I should upload the images to a cloud storage provider at first, and copy back the access url into my document. It's so complicated and repetitive. The real terrible thing is to write a document, I want to insert a image, after I finished these fucking steps, back to the document, I have forgotten what to write.

Alfred is a efficient tool for Mac. There is a great feature call Workflows, we can create a workflow to do the complicated and repetitive work. I'm a heavy user of Alfred, I use it to find files, open apps, translate, calculate and so on. Only you can not think, no you can not do.

I can not stand to spend a lot of time waiting for the upload and copy again and again. So I create a workflow called Uploader to connect file input, image processing and url output.

With Uploader, if I want to insert a image while writing, use hotkey to open alfred, input "upload" keyword, select the image to upload, continue writing, just keep an eye on the upload success notification, paste the access url, that's all. My focus was always on the document I'm writing, alfred only disturbed for 1 to 3 seconds.

The all images in this document was uploaded by Uploader proudly. Now let me introduce Uploader to you, you can get it from alfred-uploader.

alfred-uploader

An Alfred workflow to help you upload local images to cloud storage provider (just support upyun now), and get back the public access url.

Setup

Download the latest release and double-click the workflow file (with a .alfredworkflow extension). Alfred will install it automatically.

After installed, you can find it in Alfred Preferences -> Workflows list.

Before we get started, we have to set some variables, click the "[x]" icon button specified with red arrow below.

Fill the variables into the right list on the pop-up modal, then save.

Variables

• UPLOAD_PROVIDER
  • Required
  • The cloud storage provider, such as: S3, Upyun, Qiniu...
  • Just support upyun now, all provider name shoud be lower case
• UPLOAD_HISTORY_COUNT
  • Optional, Default is 50
  • The maximum number of records to save
• The provider specific variables
  • UPYUN_BUCKET
    • Required
    • The service name created at Upyun Console
  • UPYUN_USER
    • Required
    • The operator name
    • Make sure you have granted the operator reading and writing
  • UPYUN_PWD
    • Required
    • The operator password
    • Be careful, it saved as plain
  • UPYUN_USE_STREAM
    • Optional, Default is false
    • Whether enable stream mode
    • Upload with stream mode will save memory
  • UPYUN_USE_RAW_FILENAME
    • Optional, Default is fasle
    • Whether use the original filename
    • The image uploaded will be given a random numeric filename, looks like 147963249017197318.png.
    • If true, the image upload with the original filename, but some special chars (space and ?#%:) will replace with "_"
  • UPYUN_BASEURL
    • Optinal, Default is http://{UPYUN_BUCKET}.b0.upaiyun.com
    • The base url of the access url
    • You can change to the domain of yourself, only when you have config the CNAME redirector

Attention: Don't export your secret variables, unless you want to share your storage.

Usage

Everything is ready. Let's upload.

Upload

There are three ways to upload:

1. Input "upload" keyword, pick a file. You can also filter the files with query.
   

2. locate a file in Alfred, select "Uploader" operation
   
   ​

3. select files in Finder, press hotkey "cmd+shift+s". I highly recommend this way, because it support multi files once.
   

Once you receive a notification said "😀Image upload success", it means the local image has been uploaded to remote, and the access url is ready in your clipboard, you can paste it directly.

Tips: The first way, if you select a file with "alt (option)" key pressing, the result url will wrap a markdown img tag ()

Uploaded

Use "uploaded" keyword to lookup the uploaded images, keeping 50 records by default, query filter alse support.

As shown above, you can see the access url, the original file path and the upload time. Once you select a image, the access url copied, then paste it to anywhere you want. From last tips learned, the "alt" key also works here.

Contribute

Send me a pull request, or commit an issue.

👉 alfred-uploader

好像在我们团队建立的初期，那还是两年多前，就有了打枪的传统。噢，这里要解释一下，这个打枪是指在手机上的FPS(第一人称射击)游戏，不是那个意思啦。那时还是玩BIA2(兄弟连)，这个游戏太老了，以至于后面IOS升级后没法玩，官方也出了BIA3，但是联机不是这个游戏的特长，所以有很长的一段时间，打枪文化逐渐消退了。直到最近两个月，发现CFM(穿越火线手游版)可以联机实时PK，我们的这个文化又浮出了水面。每天中午吃完饭休息的时候都要来个三局两胜。你以为这篇是要介绍CFM，那就真的错了，下面我要给大家介绍一下我们打枪背后的那些事，其实就是我们的打枪计分系统。

计分系统1.0

这个计分系统的发起人是Johnny，Johnny喜欢数据，什么都喜欢搞个报表，他一开始的想法是搞个Excel，把我们每局的比分记下来，然后可以看到每个人的发挥趋势和排名；再一想还是搞个系统吧，有研究Excel的工夫，系统都写好了。然后吭哧吭哧，计分系统1.0就出来了。就是下图的样子：

这个其实还是两年前的那个版本。前段时间Johnny又加了一个胜率榜，可以看到谁跟谁组合胜率更高，见下图：

我们每次打完都要看下排名有没有变化，不过第一名就像一个bug样的存在，每个月赛结束总能高出第二名300多分，他就是我们的“录分员”小鑫鑫，录分是给他杀我们这么惨烈的惩罚。

计分系统2.0

1.0的版本已经可以录成绩，看数据了，那怎么还要2.0的版本。这是个好问题啊，就像你问你们产品经理为什么又要改版一样。这时你们产品经理会幽怨地看着你：客户需要啊。没错，2.0版是需求驱动的，只不过需求方就是我们自己。

忘记说了，现在打枪的都是我们的工程师，现在有7个人。既然说到这，我就介绍一下这7个guys：

• Johnny：闪闪的人民币玩家呀
• 金刚：BIA时代的枭雄，现在可以在猥琐的角落蹲到比赛结束
• 超人：相当生猛，总能把队友坑得不要不要
• 教练：狙神，瞬狙盲狙都不在话下
• 鑫鑫：最讨厌优秀的人比我们还努力，就是说他，现在经常限制他只用手枪
• 小旭：创造过一杀零死的辉煌战绩
• 我：我就是我，是颜色不一样的烟火

每次组队前，我们都要纠结个一分钟，谁都想抱小鑫鑫的大腿，但是腿只有两条，总要分出一个3v4的队形，如果是4v3，那就是有人厚颜无耻拽住了他的第三条腿（污~~），纠结完分组又要纠结打什么图。既然都这么纠结，干嘛不交给程序自动分组，随机选图。于是2.0版就增加了这两个功能：

随机选图就是从数组里随机挑一项，这个很简单。至于自动分组，这真的是个难题。

自动分组

直接跟选图一样，搞个随机的出来不就完了么。随机是简单，但随机出来的队形很有可能一家欢喜一家愁，公平分组才是解决之道。怎么保证公平，1.0版中不是都记录了比赛成绩，按比赛成绩分，让两对分值加和相差不大。是的，描述起来就是这么简单的一句话，转换成程序，真是一个“难题”。这很类似一个经典的NP难题(看，我没唬你们吧)，即一维装箱问题，打个比方：

1. 假设所有人总分加起来是100
2. 把两队看成两个箱子，每个箱子容积都是50
3. 把一个箱子装满到50，剩下的都装另一个箱子
4. 两队总分就都是50了

看起来不错哦，但是上面说了是类似，那不同的地方：

1. 两队不可能总能分成50:50
2. 怎么避免1v6这种队形(有小鑫鑫这个bug)
3. 成绩还有负数啊，装箱的容积怎么能是负数

所以我们要给装箱问题进行一些转换和限制，如：将负数补齐成正数；限制每个箱子至少装3个，最多装4个。具体算法可参考我的github：iammapping/autoGroup

似乎到这应该结束了，如果你这么认为，那就太低估我们工程师的折腾劲了。在2.0中还加入了一个重量级功能——自动录分。

自动录分

我们用录分来惩罚小鑫鑫，每局打完他都会把游戏结果截图，在全部结束后，把成绩录到计分系统里。罚在他身，痛在我们心呀。痛不是心疼他，是要焦急地等他录完成绩看最新排名。人工来录不仅慢还容易犯错，那就自动化吧。

方案验证

这里面最主要的难点就是如何识别出截图里的名字和比分，于是找到了开源的OCR程序tesseract，把整张截图给它识别：

> tesseract hh.png stdout -l eng+chi_sim

结果输出了一坨，我的天呐，真的是一坨：

这没办法解析啊。于是我把名字和比分单独截出来给它识别：

哇塞，它认出来了。确定这个方案可行，那就可以开干了。不会切图的前端不是好工程师，在Fw里标记了每个切割点的区域：

这里为了避免一张图片定位不准确，拿了多张图片调透明重叠在一起，方便找出比较准确的定位。

方案实施

从上图中切片得到位置信息，定义成php数组：

protected $imgMap = array(
	'1334x750' => array(
		'score' => array(
			'left' => array(468, 87, 66, 35),
			'right' => array(797, 87, 66, 35)
		),
		'players' => array(
			'left' => array(
				array(
					'name' => array(208, 176, 188, 27),
					'score' => array(353, 203, 90, 27)
				),
				array(
					'name' => array(208, 268, 188, 27),
					'score' => array(353, 295, 90, 27)
				),
				array(
					'name' => array(208, 360, 188, 27),
					'score' => array(353, 387, 90, 27)
				),
				array(
					'name' => array(208, 453, 188, 27),
					'score' => array(353, 480, 90, 27)
				),
				array(
					'name' => array(208, 547, 188, 27),
					'score' => array(353, 574, 90, 27)
				)
			),
			'right' => array(
				array(
					'name' => array(771, 176, 188, 27),
					'score' => array(920, 203, 90, 27)
				),
				array(
					'name' => array(771, 268, 188, 27),
					'score' => array(920, 295, 90, 27)
				),
				array(
					'name' => array(771, 360, 188, 27),
					'score' => array(920, 387, 90, 27)
				),
				array(
					'name' => array(771, 453, 188, 27),
					'score' => array(920, 480, 90, 27)
				),
				array(
					'name' => array(771, 547, 188, 27),
					'score' => array(920, 574, 90, 27)
				)
			)
		)
	)
);

1334x750是iphone6截图的尺寸，如有必要也可以扩展出其他尺寸的，不过标记位置信息真是个体力活。

大致步骤如下：

1. 提供比分图片上传接口
2. 上传后按定义好的的位置切分图片
3. 使用tesseract splice.png stdout -l eng+chi_sim识别切片的文字，参考：https://github.com/thiagoalessio/tesseract-ocr-for-php
4. 获取每个位置的识别结果。位置1和位置2是总比分，用来判断比赛输赢；位置3用来识别名字；位置4用来识别个人比分，如17/11，将17记作kill，将11记作die
5. 位置2数字更大，则右边所有的player都标记为胜利；如果相等，则都不不标记胜利；否则，左边所有的player都标记胜利
6. 将识别的结果自动填入，可人工校验修改

识别的核心代码参考：Recognize_Score_Model。将图片灰度化和反色对识别速度和准确度都没有太大的影响，就取消了。

完成？

自动录分程序一上，识别的速度和准确度都非常惊人，是惊人的慢和惊人的错误，用下来发现还没人工录入的效率高，不说名字，就连数字3568都分不清，这怎么能忍。主要问题还是出在了tesseract上，一定要想办法优化它的效率，好在它是可以训练的，于是按照这篇博客把它训练了一番。提取了一些样本，拼在一张图上训练：

训练顺利的话，会得到一个训练好的文件cf.traineddata

把这个文件放到/usr/local/share/tessdata/中，在识别的时候指定lang为cf就可以了，由于我们识别的图片都是切好的单个单词，可以指定psm为8，如：

> tesseract test.png stdout -l cf -psm 8

这样一优化，识别的速度和准确度都非常惊人，这次是惊人的快和惊人的准确。速度变快这是出乎意料的，不过再一想也合情合理，之前要在整个英文库和简体中文库匹配，现在只要匹配我们这几个名字和数字就可以了；准确度现在可达到99%，实测下来是完全准确的，扣1分不让它骄傲吧。

真的完成了

现在我们比赛结束，小鑫鑫只要在他iphone6的safari中打开上传页点击上传，勾选每局的截图上传，然后静候3s，以前手工可是要1分多钟，效率提高了至少20倍，上传成功后，成绩就会自动填入下图的表单，还做了一个简单的校验，如果识别有误就像左边出现红色警告，如果像右边都是绿色那就大可放心地点下绿色按钮保存成绩了。

结束

计分系统1.0和2.0差不多都是Johnny和我在业余时间开发，2.0差不多花了我4-5个晚上。短期来看折腾这些BB有意思么，花了那么多时间；但长期来看，节省的时间更多了，个人的见识增长了。

爱折腾，但不瞎折腾；崇尚高效，拒绝重复。这就是我们的工程师文化，也是我们的打枪文化。

题图引自：BIA3

当Web请求发起时，会先查看本地是否有该资源已缓存的副本，如果有，就直接从本地读取，而不需要从原始服务器中获取该资源。这样一来可以非常有效地减少冗余的数据传输，也可以减轻原始服务器的请求压力。下图就是一个请求的神奇之旅：

左边虚线框都是在缓存层完成，大部分情况下是指浏览器内部的缓存机制，也可以指一些缓存代理服务，如CDN等（本文不讨论）；右边虚线框都是在服务器端完成的。

下面就按照这个流程图，客户端使用Chrome浏览器打开Google（但愿你看到的不是404 not found）来演示不同场景下的请求。

缓存未命中

这是最简单的场景，所有资源都是从服务器返回，就好像没有缓存这一层一样。通常是资源从来没有请求过，或者在请求头部指明不使用缓存。Chrome开发者工具有个很方便的功能，就是可以设置当打开开发者工具时禁用缓存：

它的原理很简单，就是在每个请求前加上不使用缓存的头部cache-control: no-cache和pragma: no-cache：

在给静态文件打版本号还没流行的时候，这个办法也常用来更新静态文件的缓存，即用Ajax设置cache-control: no-cache和pragma: no-cache的头部将所有静态文件请求一遍。

缓存命中

这是我们最期望的结果。从上图看这个时候没有服务器什么事，如果是全静态内容，而且已被全缓存，即使没有网络连接也可以正常访问。

是否缓存

浏览器对请求过的资源默认都会按请求url缓存起来，这样再次请求时就可以直接返回缓存的对象。

即使设置了cache-control: no-cache和pragma: no-cache头部也依然会缓存，除非响应头部设置了cache-control: no-store就不会将该资源缓存。

是否过期

资源不是创建好就永远不会再变更，服务器端为防止缓存的资源与最新版不一致，就会给这些资源设置一个过期时间的响应头部，缓存就会按照这个过期时间存放资源，一旦过期，就会跟服务器校验，检查这个资源是否变更，如果有变更，就获取最新版。

过期时间可以由HTTP/1.0+的Expires头部和HTTP/1.1的Cache-Control: max-age头部来指定。前者是设置一个GMT的绝对过期时间，如：Expires: Wed, 20 Apr 2016, 09:11:33 GMT；后者是设置一个相对于资源第一次创建的存活时间（单位为秒），如：Cache-Control: max-age=3600，就表示在一小时后过期。

由上可知，缓存命中需要满足两个条件：

1. 已缓存
2. 缓存没有过期

命中缓存，Chrome开发工具会标记出from cache，而且request请求体也没那么复杂了😄 。

缓存再验证命中

上一场景中提到缓存资源都有一个过期时间，在当前时间超过这个过期时间后，客户端就不确定这个资源是否可信了，于是要询问服务器，这时会发一个If-Modified-Since头部，并带上缓存好的资源最后修改时间（这个时间是服务器的响应头部Last-Modified），如：If-Modified-Since: Wed, 13 Apr 2016, 09:11:33 GMT。服务器收到请求后，当发现有If-Modified-Since头部时，会将该时间与服务器端该资源的最后修改对比，如果相等，就会返回一个小的响应体，即：304 Not Modified；而不用返回一个比较大的完整资源。缓存收到304 Not Modified后，就知道这个资源没有变更，还可以继续使用，于是修改一下过期时间，然后当什么都没发生过。

这个场景，也叫作“缓慢命中”，虽然有与服务器通信，但是一旦命中，依然能节省不少的带宽资源。

用最后修改时间作为评判资源变更的唯一标准，这显然是不严谨的，有的资源在服务器端定时生成，修改时间一直在变，但内容不一定变化。这时可以用ETag和If-None-Match替代上面的Last-Modified和If-Modified-Since，ETag和Last-Modified也可以同时设置，同时验证。ETag一般用来设置文件的版本号，可以使用文件md5值，如ETag: "c9f8b79751fe3b975999de6cd82759ba"。

缓存再验证未命中

这个场景与上一个类似，只是在验证变更这一步出现不相等的结果。这时服务器会返回一个完整的200响应体，并带上最新的Last-Modified和ETag(如果有设置)，缓存会将副本更新然后传递给客户端。

总结

本文主要讲解基于http协议的Web缓存是怎么回事，内容大量参考自《HTTP权威指南--第7章 缓存》。缓存是把双刃剑，用得好可以非常显著提升性能，用得不好请刷新浏览器😓 。

原文：How to get a performance boost using Node.js native addons

也许你已经听说过上千次，但我今天要向你展示什么是Node.js的原生模块，以及你为什么应该关注它们。

Node.js addons是使用C或C++编写的动态链接共享对象，可以使用require()方法加载，并且像其他普通的Node.js模块一样使用。
(译注：addons: 扩展，为保持统一叫法，不予翻译)

说得这么好听，但是，为什么要我写C++代码，JavaScript已经让我很爽了，并且上一次看到C++代码还是在大学...答案没有别的只有性能！

一个实际的例子

比如，我们要创建一个在线的回文计算器工具，感谢Javascript这门高层次的语言，你很快就想到了一个干净利落的解决方案：

function isPalindrome(str) {
  return str === str.split('').reverse().join(''); 
}

简直就是天才？你迅速发布代码到生产环境，睡觉...但是几天后，你意识到这算法并没有看起来那么好，它实际上特别慢，于是你开始探索新的视野...

Node addons的生态系统

我们需要使用下面的工具来创建addon：

• node-gyp：用于编译原生addons的跨平台命令行接口。
• node-bindings：用于加载原生addon的.node文件的帮助模块。
• nan：使addon跨Node版本开发更简单。

全部安装：

> npm i node-gyp -g && npm i bindings nan --save

稍等片刻，我们添加"gypfile": true到package(译注：指添加到package.json文件)，并创建一个新binding.gyp文件：

{
  "targets": [ 
    { 
      "target_name": "palindrome",
      "sources": [ "palindrome.cc" ],
      "include_dirs": [ "<!(node -e \"require('nan')\")" ]
    } 
  ]
}

准备就绪，现在用C++写我们的回文方法，代码如下：

#include <nan.h>

using namespace v8;

void IsPalindrome(const FunctionCallbackInfo<Value>& info) {
  String::Utf8Value sentence(info[0]->ToString());
  std::string str = std::string(*sentence);
  int len = str.length();
  int half = len / 2;
  int start = 0;
  int end = len - 1;
  int space = 32;
  bool isPal = true;

  while (half > 0 && isPal) {
    bool startSpace = str.at(start) == space;
    bool endSpace = str.at(end) == space;

    if (str.at(start) == str.at(end)) {
      start++;
      end--;
    } else if (startSpace || endSpace) {
      startSpace && start++;
      endSpace && end--;
    } else {
      isPal = false;
    }

    half--;
  }

  info.GetReturnValue().Set(isPal);
}

void Init(Local<Object> exports, Local<Object> module) {
  NODE_SET_METHOD(module, "exports", IsPalindrome);
}

NODE_MODULE(addon, Init)

这也许不是最好的实现方式，但它的时间复杂度是O(n)，现在还是可以接受的。我们准备检查上面的代码，首先下面这几行：

void Init(Local<Object> exports, Local<Object> module) { 
  NODE_SET_METHOD(module, “exports”, IsPalindrome);
} 
NODE_MODULE(addon, Init)

暴露IsPalindrome方法，稍后会被Node引用，(有兴趣可以)在Node的源码中看一下NODE_MODULE和NODE_SET_METHOD方法。

另外这段代码有趣的部分：

void IsPalindrome(const FunctionCallbackInfo<Value>& info) {
  String::Utf8Value sentence(info[0]->ToString());
  std::string str = std::string(*sentence);

我们这里使用了一些v8的类，FunctionCallbackInfo提供调用上下文信息的访问，包括接收者，参数的数量和值，还有方法的持有者。最后，我们使用Utf8Value类将参数转换为std string，用以后续在算法中操作。

是时候衡量这两种实现的性能了，为此我们借助benchmarkjs，它也是jsperf.com内部使用的库：

> npm i --save benckmark

var Benchmark = require('benchmark');
var palindromeC = require('bindings')('palindrome.node');
var palindromeJs = require('./palindrome.js');
var suite = new Benchmark.Suite;
var str = 'a man a plan a cat a ham a yak a yam a hat a canal panama';

suite
.add('Javascript palindrome', function() {
  palindromeJs(str);
})
.add('C palindrome', function() {
  palindromeC(str);
})
.on('cycle', cycle)
.on('complete', complete)
.run({ 'async': true });

function cycle(event) {
  console.log(String(event.target));
}

function complete(a,b) {
  console.log('Fastest: ' + this.filter('fastest').map('name'));
  console.log('Slowest: ' + this.filter('slowest').map('name'));
}

C palindrome x 1,353,176 ops/sec ±1.98% (80 runs sampled)
Javascript palindrome x 293,383 ops/sec ±1.34% (87 runs sampled)

Fastest: C palindrome
Slowest: Javascript palindrome

走起，C回文比Javascript快了460%！😏😏 提升太惊人了？但是等等，我们有点作弊... 我们使用了两种不同的实现，Javascript的单行比起C++的时间复杂度要更高。我们现在尝试用Javascript实现C++一模一样的算法：

function isPalindrome(str) {
  var half = Math.round(str.length / 2);
  var start = 0;
  var end = str.length - 1;
  var palindrome = true;
  var SPACE = 32;
  var COMMA = 44;
  var startSpace, endSpace;

  while (half && palindrome) {
    startSpace = str.charCodeAt(start) === SPACE || str.charCodeAt(start) === COMMA;
    endSpace = str.charCodeAt(end) === SPACE ||  str.charCodeAt(end) === COMMA;

    if (str[start] == str[end]) {
      start++;
      end--;
    } else if (startSpace || endSpace) {
      startSpace && start++;
      endSpace && end--;
    } else {
      palindrome = false;
    }

    half--;
  }

  return palindrome;
}

C palindrome x 1,370,148 ops/sec ±1.32% (80 runs sampled)
Javascript palindrome x 3,326,042 ops/sec ±0.98% (82 runs sampled)

Fastest: Javascript palindrome
Slowest: C palindrome

神马，Javascript的实现现在更快了240%😲...那还有什么意思？好在我们还可以做些什么来解决这个问题。

引入nan

Node.js的原生抽象

由于V8（Node内核）的变化，保持愉快地跨版本编译原生插件，简直是个小噩梦，而nan的目标就是只保留开发原生Node.js插件的必要逻辑，而无需检查NODE_MODULE_VERSION。

我们原生的实现比js更慢是因为这个：

String::Utf8Value sentence(info[0]->ToString());
std::string str = std::string(*sentence);

这里我们只是把第一个参数转化为std string，但是由于Utf8Value的内部原理，我们付出昂贵的代价来转化。我们现在来看看使用nan是怎么做的：

Nan::Utf8String arg0(info[0]);
char *str = *arg0;

我们现在使用nan Utf8Value来替代v8 Utf8Value，并将其转化为字符数组。我们还做了一些小改动以适应字符数组：

#include <nan.h>

using namespace v8;

void IsPalindrome(const FunctionCallbackInfo<Value>& info) {
  Nan::Utf8String arg0(info[0]);
  char *str = *arg0;
  size_t len = arg0.length();
  int half = len / 2;
  int start = 0;
  int end = len - 1;
  int space = 32;
  int comma = 44;
  bool isPal = true;
  bool startSpace;
  bool endSpace;

  while (half > 0 && isPal) {
    startSpace = str[start] == space || str[start] == comma;
    endSpace = str[end] == space || str[end] == comma;

    if (str[start] == str[end]) {
      start++;
      end--;
    } else if (startSpace || endSpace) {
      startSpace && start++;
      endSpace && end--;
    } else {
      isPal = false;
    }

    half--;
  }

  info.GetReturnValue().Set(isPal);
}

void Init(Local<Object> exports, Local<Object> module) {
  NODE_SET_METHOD(module, "exports", IsPalindrome);
}

NODE_MODULE(addon, Init)

C palindrome x 5,753,415 ops/sec ±1.40% (84 runs sampled)
Javascript palindrome x 3,307,899 ops/sec ±1.28% (84 runs sampled)

Fastest: C palindrome
Slowest: Javascript palindrome

借助nan现在C++比js快了170% 😃

前所未有的大回文

最后，我们来试一个前所未有的大回文，看看更长的字符串性能能否保持或是更好。隆重介绍17,826字回文 😈。结果如下：

C palindrome x 4,636 ops/sec ±1.10% (83 runs sampled)
Javascript palindrome x 1,712 ops/sec ±1.22% (83 runs sampled)

Fastest: C palindrome
Slowest: Javascript palindrome

C++再次获得更好的性能，这次是270%。可能也没那么显著，但是你能发现字符串越长C++的性能会越好。

总结

我们看到了怎么创建并性能测试Node.js的原生addons，可能上面的例子并没有很好的性能，因为我们仅仅处理字符串，但至少手把手展示怎么做。

你可以查看完整的回文addon源码，还有性能测试的例子。

最后我必须承认很难找到合适的node addons文档和例子，不管怎样，下面推荐我学习途中的一些参考：

• Node.js official guide
• v8 getting started
• Addon examples
• v8 documentation
• Scott Frees blog
• Node Native addons slides by Chris Barber
• Community addons

Rock with async/await

本篇文章是作为上一篇的续集，考虑到第一篇的篇幅，还有更重要的一点就是上一篇讲的内容已经可以直接应用在最新版本的Node.js和一些高级浏览器（Chrome，FF）中，具体兼容性可参考：https://kangax.github.io/compat-table/es6/。

而这一篇讲的内容，是ECMAScript 2016（ES7）的async/await特性，目前的兼容性可参考：http://kangax.github.io/compat-table/esnext/#test-async_functions，虽然现在来看还不是非常乐观，但是我们可以通过第三方的代码转换工具（如Traceur和Babel），将这些新特性的代码转换为当前环境可运行的代码。

一个简单的例子

实现同步的sleep，同步的代码看起来应该是下面的样子：

function sleep(timeout) {
    setTimeout(function() {}, timeout);
}

function main() {
    console.time('how long did I sleep');
    sleep(3000);
    console.timeEnd('how long did I sleep');
}

main();
// how long did I sleep: 0ms

但是在js中的执行结果却是0ms，这不是我们预期的呀。

改造

按照这种同步的代码流程，怎么样才能输出3000ms呢？看过上一篇文章的童鞋应该很快就能想到使用Generator和yield，没看过的童鞋建议先看完上一篇再回来。

sleep(5min)

好，我就当你们都回来了，接下来就说说如何使用async/await实现“同步”的sleep。

await期望的值是一个Promise对象，改造sleep方法：

function sleep(timeout) {
    return new Promise(function(resolve, reject) {
        setTimeout(resolve, timeout);
    });
}

除此之外，main方法还需要使用async显式声明成异步方法：

async function main() {
    console.time('how long did I sleep');
    await sleep(3000);
    console.timeEnd('how long did I sleep');
}

将以上代码保存为async-sleep.js。前面也说了需要借助第三方代码转换工具，那我们就安装Babel：

> npm install --save-dev babel-cli

安装后执行：

> ./node_modules/babel-cli/bin/babel-node.js async-sleep.js

没出意外的话，我们应该看到...WTF，出错了

SyntaxError: async-sleep.js: Unexpected token (7:6)
   5 | }
   6 |
>  7 | async function main() {
     |       ^
   8 | 	console.time('how long did I sleep');
   9 | 	await sleep(3000);
  10 | 	console.timeEnd('how long did I sleep');

这时需要安装一个Babel的插件用于转换async：

> npm install --save-dev babel-plugin-transform-async-to-generator

安装好后，需要在运行目录添加一个配置文件.babelrc：

> vi .babelrc
{
    "plugins": ["transform-async-to-generator"]
}

或在命令中指定：

>  ./node_modules/babel-cli/bin/babel-node.js --plugins transform-async-to-generator async-sleep.js

没出意外的话，我们应该看到...WTF，又出错了

async-sleep.js:1
(function (exports, require, module, __filename, __dirname) { let main = (() => {
                                                              ^^^

SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode

好吧，提示也很明显，我们使用strict模式，完整的代码如下：

'use strict';

function sleep(timeout) {
    return new Promise(function(resolve, reject) {
        setTimeout(resolve, timeout);
    });
}

async function main() {
	console.time('how long did I sleep');
	await sleep(3000);
	console.timeEnd('how long did I sleep');
}

main();
// how long did I sleep: 3003ms

再执行，终于看到我们期望的3003ms。呃，怎么不是3000ms，不要在意这些细节。难道QQ空间曾经用这个实际延迟的误差来判断客户端CPU的繁忙程度也要告诉你。

看完这个例子，是不是发现async类似于Generator中的*，而await类似于yield，但是现在不需要再额外封装一个run方法了，这还是很方便的。

重写回调地狱的例子

继续重写那个回调地狱的例子：

1. 读取当前目录的package.json
2. 检查backup目录是否存在，如果不存在就创建backup目录
3. 将文件内容写到备份文件

readPackageFile、checkBackupDir和backupPackageFile直接使用上一篇中的定义：

var readPackageFile = new Promise(function(resolve, reject) {
    fs.readFile('./package.json', function(err, data) {
        if (err) {
            reject(err);
        }

        resolve(data);
    });
});

var checkBackupDir = new Promise(function(resolve, reject) {
    fs.exists('./backup', function(exists) {
        if (!exists) {
            resolve(mkBackupDir);
        } else {
            resolve();
        }
    });
});

var mkBackupDir = new Promise(function(resolve, reject) {
    // throw new Error('unexpected error');
    fs.mkdir('./backup', function(err) {
        if (err) {
            return reject(err);
        }

        resolve();
    });
});

function backupPackageFile(data) {
    return new Promise(function(resolve, reject) {
        fs.writeFile('./backup/package.json', data, function(err) {
            if (err) {
                return reject(err);
            }

            resolve();
        });
    });
};

Let's Rock：

(async function() {
    try {
        // 1. 读取当前目录的package.json
        var data = await readPackageFile;
        
        // 2. 检查backup目录是否存在，如果不存在就创建backup目录
        await checkBackupDir;

        // 3. 将文件内容写到备份文件
        await backupPackageFile(data);

        console.log('backup successed');
    } catch (err) {
        console.error(err);
    }
}());

总结

js正朝着越来越好的方向发展，不是吗？

参考地址

• Async/Await: The Hero JavaScript Deserved
• babel 6 async / await: Unexpected token
• Babel cli usage

题图引自：http://forwardjs.com/img/workshops/advancedjs-async.jpg

新的开发同事入职，总是要去帮他们重新搭建开发环境，刚开始一两个倒觉得还好，花半天时间就可以搞定；但随着新加入人数越来越多，而且还经常会碰到同事电脑上的某个服务没启动，导致项目没法跑起来，又要帮忙调试，这些无脑的体力活也变得越来越冗长乏味。消除重复，是程序猿的天生职责，工作的重复也不例外。

于是我找到了Vagrant，其实早在2014年就听说，只是当时团队还很小，而且每个人都能驾驭自己的开发环境，所以没多留意，只是知道有这么个东西。现在回想，当时真是目光短浅，早用起来就不会发上面那段牢骚了。下面进入正题。

什么是Vagrant？

Vagrant为开发环境而生，是用于创建并配置轻量的、可重现的、可移植的开发环境。

为什么要用Vagrant？

据我了解，目前团队合作的开发环境大致分为三种：

第一种：每个人的电脑都有一套独立配置的开发环境。这种方式如果在项目中需要依赖一个新的服务，那所有人的电脑都要挨个装个遍，虽然这个情况不会经常出现，一旦出现就是灾难。

第二种：有一台专供开发的服务器，服务器上每个人都有独立的空间用于托管并运行自己的代码。这种方式较为高级，成本相对也较高，但是也有一个致命的短板，如果有一个人把这台服务器搞挂了，那整个团队跟着歇菜。

第三种：使用类似Vagrant的虚拟化方式。过去你可能经常听说：喂，哥们，我代码更新了，你拉一下。使用Vagrant后，你可以：那个谁，我把开发环境更新了，你拉一下。

当然可能还有些土豪公司的做法是从第二种衍生出来，每个人有独立的开发服务器，有专职的运维同学统一配置，这里就不做讨论了。
对比以上三种方式，使用虚拟化的方便程度溢于言表。

Vagrant的工作原理

你看了上面那段可能还觉得一头雾水，你叫我拉一下，是拉什么？（呃，这位同学，不要想歪了）

如果使用传统的虚拟机搭建开发环境，大致步骤如下：

1. 下载一个虚拟化的软件，如：VMare，VirtualBox；
2. 然后找一个系统安装包安装；
3. 安装好了之后，进入系统，配置开发环境；
4. 配置代码目录共享到虚拟系统；
5. 大功告成，现在可以本地写代码，虚拟机执行了。

Vagrant的工作原理与上面类似，只是做了抽象，让配置和迁移更简单。

1. 首先需要安装一个Provider，这个Provider就是为Vagrant提供虚拟化服务的软件；
2. 下载一个Box，相当于上面的安装包，进入代码目录初始化；
3. 进入虚拟实例，配置开发环境；
4. 退出并关闭虚拟实例，将当前环境打包成一个新的Box；
5. 将这个Box共享给其他小伙伴，然后你们就可以快乐幸福地用同样的开发环境写代码了。

Vagrant的从0到1

1 下载VirtualBox

前往官网下载：https://www.virtualbox.org/wiki/Downloads，建议把Extension Pack也装上

2 下载Vagrant

前往官网下载：https://www.vagrantup.com/downloads.html

3 为Vagrant新增Box

使用命令vagrant box add {name} {url}，其中{name}是自定义的名称（可选），{url}可以是远程的文件地址或本地的文件路径，考虑到国内复杂的网络环境，尽量还是先下到本地。还有一定要从官方下载box，吸取15年xcode ghost事件的教训。

下载http://files.vagrantup.com/precise64.box到~/Downloads/precise64.box

执行：

> vagrant box add my-php-dev ~/Downloads/precise64.box

4 初始化

进入到我们的项目目录~/Documents/php/project初始化，使用上一步创建的box：

> cd ~/Documents/php/project
> vagrant init my-php-dev

初始化后产生了一个Vagrantfile文件，这是vagrant对当前项目的配置文件，以下有几个配置建议

4.1 网络配置

如果你想通过一个固定的ip访问到你的项目，那给这个虚拟实例设置一个固定的私有ip，注意不要与其他ip产生冲突：

config.vm.network "private_network", ip: "192.168.100.100"

这样可以方便我们配置一个host指向这个实例，如：

> vi /etc/hosts
192.168.100.100 dev.project.com

如果你的虚拟实例还需要访问外部的一些资源，比如局域网中的数据库，那么就需要为它桥接一个外网：

config.vm.network "public_network",
  # 默认由dhcp分配ip
  use_dhcp_assigned_default_route: true,
  # 桥接的方式，可设置多个
  bridge: ["en0: Wi-Fi (AirPort)", "en1: Wi-Fi (AirPort)"]

这里直接通过wifi连到局域网

4.2 工作目录配置

Vagrant启动后会把当前的项目目录挂载到/vagrant，但可以修改：

# 将当前目录mount到/var/www/project
config.vm.synced_folder ".", "/var/www/project", 
  # 如果不存在则创建
  create: true

更多配置请参考官方文档

5 启动

> vagrant up

启动后会创建一个Vagrant的工作目录.vagrant

如果启动时报错：

Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3` vagrant /vagrant
mount -t vboxsf -o uid=`id -u vagrant`,gid=`id -g vagrant` vagrant /vagrant

The error output from the last command was:

stdin: is not a tty
mount: unknown filesystem type 'vboxsf'

安装vagrant-vbguest插件

> vagrant plugin install vagrant-vbguest

如果还没解决，请参考https://github.com/mitchellh/vagrant/issues/3341

6 配置环境

登录到实例

> vagrant ssh

默认是使用vagrant用户登录。

上面安装的box是ubuntu，可参考http://www.cnblogs.com/CheeseZH/p/4694135.html安装，如果安装提示权限错误，加上sudo就可以

Vagrant的从1到n

1 打包

打包前需要将实例停止

# 停止实例
> vagrant halt
# 重新打包
> vagrant package

打包后会在当前目录生成一个package.box文件

2 分发

根据上面的步骤，Vagrant会在当前目录产生3个文件：

1. 配置文件：Vagrantfile
2. 工作目录：.vagrant
3. 新的Box：package.box

2.1 初级分发

初级的分发方式很简单，就是手动分发，把Vagrantfile和package.box拷给你的同事，假设他的项目目录是/mydev/php/project，当然在这之前他的电脑上必须预先安装好了VirtualBox和Vagrant。

第一次初始化开发环境：

# 将Vagrantfile拷到项目根目录
> mv Vagrantfile /mydev/php/project/
# 将package安装到vagrant，注意box的命名需与上文一致
> vagrant box add my-php-dev package.box
# 进入项目目录
> cd /mydev/php/project/
# 启动
> vagrant up

如果开发环境有变更，生成了新的package.box，重新拷贝过来，需要执行：

# 关闭并销毁当前虚拟实例
> vagrant destroy
> vagrant box remove my-php-dev

再重复上面第一次的步骤。

2.2 高级分发

上面初级分发虽然简单，但中间还是有很多人工干预的步骤，这增加了操作失误的概率，也无法实现上文提到“拉一下”的效果。

下面就说说如何实现“拉一下”的效果，需要搭建一个主机托管不同版本的Box。以下内容参考自self-hosted-vagrant-boxes-with-versioning

2.2.1 定义Box存放的目录结构

- /var/www
    `- vagrant                          # 根目录
       `- my-php-dev                    # Box文件夹
          |- boxes                      # 存放所有不同版本的Box
          |  |- my-php-dev_0.1.0.box    # 版本 0.1.0
          |  `- my-php-dev_0.1.1.box    # 版本 0.1.1
          `- my-php-dev.json            # Box的目录索引文件

根目录vagrant用来存放所有的Box集合，也许你还会建一个my-java-dev

2.2.2 配置Web服务

进入到服务器，确保服务器已安装好nginx，创建2.2.1中的目录结构：

> mkdir -p /var/www/vagrant/my-php-dev/boxes

新增配置文件：

> vi /etc/nginx/sites-enabled/vagrant

内容为：

server {
    listen   80;

    server_name vagrant.myhost.com;

    root /var/www/vagrant;

    # 访问box目录时，返回目录索引文件
    # e.g. http://vagrant.myhost.com/my-php-dev/ 解析为 /var/www/vagrant/my-php-dev/my-php-dev.json  
    location ~ ^/([^\/]+)/$ {
        index $1.json;
        try_files $uri $uri/ $1.json =404;
        autoindex off;
    }

    # 允许索引boxes目录
    location ~ ^/([^\/]+)/boxes/$ {
        try_files $uri $uri/ =404;
        autoindex on;
        autoindex_exact_size on;
        autoindex_localtime on;
    }

    # 修改json文件的header
    location ~ \.json$ {
        add_header Content-Type application/json;
    }

    # 修改json文件的header
    location ~ \.box$ {
        add_header Content-Type application/octet-stream;
    }

    # 阻止直接访问根目录
    location ~ ^/$ {
        return 403;
    }
}

重新载入nginx配置：

> service nginx reload

2.2.3 新增Box的目录索引文件

在服务器中进入box目录，添加目录索引文件：

> cd /var/www/vagrant/my-php-dev/
> vi my-php-dev.json

内容为：

{
    "name": "my-php-dev",
    "description": "my php development box",
    "versions": [{
        "version": "0.1.0",
        "providers": [{
            "name": "virtualbox",
            "url": "http://vagrant.myhost.com/my-php-dev/boxes/my-php-dev_0.1.0.box",
            "checksum_type": "sha1",
            "checksum": "d3597dccfdc6953d0a6eff4a9e1903f44f72ab94"
        }]
    },{
        "version": "0.1.1",
        "providers": [{
            "name": "virtualbox",
            "url": "http://vagrant.myhost.com/my-php-dev/boxes/my-php-dev_0.1.1.box",
            "checksum_type": "sha1",
            "checksum": "0b530d05896cfa60a3da4243d03eccb924b572e2"
        }]
    }]
}

box文件的checksum可通过openssl sha1生成：

> openssl sha1 /var/www/vagrant/my-php-dev/boxes/my-php-dev_0.1.0.box
SHA1(/var/www/vagrant/my-php-dev/boxes/my-php-dev_0.1.0.box)= d3597dccfdc6953d0a6eff4a9e1903f44f72ab94

2.2.4 上传你的Box

上面我们打包时生成的package.box，可以重命名为带版本号的文件名my-php-dev_0.1.0.box，也可以在打包时指定：

> vagrant package --output 'my-php-dev_0.1.1.box'

把my-php-dev_0.1.0.box和my-php-dev_0.1.1.box都上传到服务器的/var/www/vagrant/my-php-dev/boxes/目录中。

上传完成后，访问http://vagrant.myhost.com/vagrant/my-php-dev/boxes/应该会列出所有box文件。

大放送一个php脚本，自动生成目录索引文件：

<?php

$boxName = isset($argv[1]) ? $argv[1] : '';

if (!$boxName) {
    echo 'The box name is required' . PHP_EOL;
    exit(1);
}

$boxBaseDir = __DIR__ . '/' . $boxName;
$boxJsonFile = $boxBaseDir . '/' . $boxName . '.json';
$boxesDir = $boxBaseDir . '/boxes';

if (!file_exists($boxBaseDir) || !file_exists($boxJsonFile) || !file_exists($boxesDir)) {
    echo 'The box is not inited' . PHP_EOL;
    exit(1);
}

$meta = json_decode(file_get_contents($boxJsonFile), true);
$regVersionBox = '/_(\d+\.\d+\.\d+)\.box$/';

$boxes = array_filter(scandir($boxesDir), function($filename) use ($regVersionBox) {
    // 过滤掉不包含版本号的box文件
    return $filename != '.' && $filename != '..' && preg_match($regVersionBox, $filename);
});

$meta['versions'] = isset($meta['versions']) ? $meta['versions'] : array();
if (!isset($meta['baseurl'])) {
    echo 'Warning! baseurl is not defined in json' . PHP_EOL;
}

foreach ($boxes as $box) {
    preg_match($regVersionBox, $box, $match);
    $version = $match[1];
    $isVersionExist = false;
    foreach ($meta['versions'] as $ver) {
        if ($ver['version'] == $version) {
            $isVersionExist = true;
            break;
        }
    }
    if ($isVersionExist) {
        continue;
    }

    $checksum = sha1_file($boxesDir . '/' . $box);
    $meta['versions'][] = array(
        'version' => $version,
        'providers' => array(
            array(
                'name' => 'virtualbox',
                'url' => $meta['baseurl'] . '/' . $boxName . '/boxes/' . $box,
                'checksum_type' => 'sha1',
                'checksum' => $checksum
            )
        )
    );
}

$metaJson = json_encode($meta, JSON_PRETTY_PRINT);
file_put_contents($boxJsonFile, $metaJson);
echo $metaJson . PHP_EOL;
?>

将以上脚本保存到服务器目录/var/www/vagrant/中，存为autoversion.php，每次上传完新版本的box文件后，执行：

> cd /var/www/vagrant/
> php autoversion.php my-php-dev

就可以自动生成新的目录索引文件了。

2.2.5 修改Vagrantfile

修改本地项目中的Vagrantfile，在

config.vm.box = "my-php-dev"

之后添加：

config.vm.box_url = "http://vagrant.myhost.com/vagrant/my-php-dev/my-php-dev.json"

2.2.6 拉一下

将Vagrantfile与项目代码一样放到版本控制里，注意把.vagrant目录在版本控制中忽略。

在Vagrantfile中有一个配置被注释了:

# Disable automatic box update checking. If you disable this, then
# boxes will only be checked for updates when the user runs
# `vagrant box outdated`. This is not recommended.
# config.vm.box_check_update = false

就表示box_check_update默认是开启的，也就是说执行vagrant up时会自动检查Box是否有更新。

> vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'my-php-dev' is up to date...
==> default: A newer version of the box 'my-php-dev' is available! You currently
==> default: have version '0.1.0'. The latest is version '0.1.1'. Run
==> default: `vagrant box update` to update.
...

按照提示，执行vagrant box update就可以更新到最新的版本。

到此为止，我们的开发环境已经可以一键拉取了。

总结

使用Vagrant搭建开发环境，将大大减少重复配置的工作，是时候跟“代码在我这运行没问题”说再见了。

本文通过一个简单的需求：读取文件并备份到指定目录（详见第一段代码的注释），以不同的js代码实现，来演示代码是如何变优雅的。对比才能分清好坏，想知道什么是优雅的代码，先看看糟糕的代码。

不优雅的代码是什么样的？

1、 回调地狱

/**
 * 读取当前目录的package.json，并将其备份到backup目录
 * 
 * 1. 读取当前目录的package.json
 * 2. 检查backup目录是否存在，如果不存在就创建backup目录
 * 3. 将文件内容写到备份文件
 */
fs.readFile('./package.json', function(err, data) {
    if (err) {
        console.error(err);
    } else {
        fs.exists('./backup', function(exists) {
            if (!exists) {
                fs.mkdir('./backup', function(err) {
                    if (err) {
                        console.error(err);
                    } else {
                        // throw new Error('unexpected');
                        fs.writeFile('./backup/package.json', data, function(err) {
                            if (err) {
                                console.error(err);
                            } else {
                                console.log('backup successed');
                            }
                        });
                    }
                });
            } else {
                fs.writeFile('./backup/package.json', data, function(err) {
                    if (err) {
                        console.error(err);
                    } else {
                        console.log('backup successed');
                    }
                });
            }
        });
    }
});

2、 匿名调试

取消上面代码中抛出异常的注释再执行

wtf，这个unexpected错误从哪个方法抛出来的？

神马？你觉的这个代码写得很好，优雅得无可挑剔？那么你现在可以忽略下文直接去最后的评论写：楼主敏感词

怎样写才能让js回调看上去优雅？

1、 消除回调嵌套

2、 命名方法

fs.readFile('./package.json', function(err, data) {
    if (err) {
        console.error(err);
    } else {
        writeFileContentToBackup(data);
    }
});


function writeFileContentToBackup(fileContent) {
    checkBackupDir(function(err) {
        if (err) {
            console.error(err);
        } else {
            backup(fileContent, log);
        }
    });
}

function checkBackupDir(cb) {
    fs.exists('./backup', function(exists) {
        if (!exists) {
            mkBackupDir(cb);
        } else {
            cb(null);
        }
    });
}

function mkBackupDir(cb) {
    // throw new Error('unexpected');
    fs.mkdir('./backup', cb);
}

function backup(data, cb) {
    fs.writeFile('./backup/package.json', data, cb);
}

function log(err) {
    if (err) {
        console.error(err);
    } else {
        console.log('backup successed');
    }
}

我们现在可以快速定位抛出异常的方法

他山之石 可以攻玉

借助第三方库，优化异步代码

browser js

• jQuery Deferred
  • ajax
  • animate

NodeJs

• Async

  • async.each
  • async.map
  • async.waterfall

• ECMAScript 6

  • Promise
  • Generator

jQuery Deferred

在jQuery-1.5中引进，被应用在ajax、animate等异步方法上

一个简单的例子：

function sleep(timeout) {
    var dtd = $.Deferred();
    setTimeout(dtd.resolve, timeout);
    return dtd;
}

// 等同于上面的写法
function sleep(timeout) {
    return $.Deferred(function(dtd) {
        setTimeout(dtd.resolve, timeout);
    });
}

console.time('sleep');
sleep(2000).done(function() {
    console.timeEnd('sleep');
});

一个复杂的例子：

function loadImg(src) {
    var dtd = $.Deferred(),
        img = new Image;

    img.onload = function() {
        dtd.resolve(img);
    }

    img.onerror = function(e) {
        dtd.reject(e);
    }

    img.src = src;

    return dtd;
}

loadImg('http://www.baidu.com/favicon.ico').then(
    function(img) {
        $('body').prepend(img);
    }, function() {
        alert('load error');
    }
)

那么问题来了，我想要过5s后把百度Logo显示出来？

普通写法：

sleep(5000).done(function() {
     loadImg('http://www.baidu.com/favicon.ico').done(function(img) {
        $('body').prepend(img);
    });
});

二逼写法：

setTimeout(function() {
    loadImg('http://www.baidu.com/favicon.ico').done(function(img) {
        $('body').prepend(img);
    });
}, 5000);

文艺写法(睡5s和加载图片同步执行)：

$.when(sleep(5000), loadImg('http://www.baidu.com/favicon.ico')).done(function(ignore, img) {
    $('body').prepend(img);
});

Async

使用方法参考：https://github.com/caolan/async

优点：

1. 简单、易于理解
2. 函数丰富，几乎可以满足任何回调需求
3. 流行

缺点：

1. 额外引入第三方库
2. 虽然简单，但还是难以掌握所有api

ECMAScript 6

ES6的目标，是使得JavaScript语言可以用来编写大型的复杂的应用程序，成为企业级开发语言。

接下来介绍ES6的新特性：Promise对象和Generator函数，是如何让代码看起来更优雅。

更多ES6的特性参考：ECMAScript 6 入门

Promise

Promise对象的初始化以及使用：

var promise = new Promise(function(resolve, reject) {
    setTimeout(function() {
        if (true) {
            resolve('ok');
        } else {
            reject(new Error('unexpected error'));
        }
    }, 2000);
});

promise.then(function(msg) {
    // throw new Error('unexpected resolve error');
    console.log(msg);
}).catch(function(err) {
    console.error(err);
});

JavaScript Promise 的 API 会把任何包含有 then 方法的对象当作“类 Promise”（或者用术语来说就是 thenable）

与上面介绍的jQuery Deferred对象类似，但api方法和错误捕捉等不完全一样。
可以使用以下方法转换：

var promise = Promise.resolve($.Deferred());

那怎么使用Promise改写回调地狱那个例子？

// 1. 读取当前目录的package.json
readPackageFile.then(function(data) {
    // 2. 检查backup目录是否存在，如果不存在就创建backup目录
    return checkBackupDir.then(function() {
        // 3. 将文件内容写到备份文件
        return backupPackageFile(data);
    });
}).then(function() {
    console.log('backup successed');
}).catch(function(err) {
    console.error(err);
});

这么简单？

看看readPackageFile、checkBackupDir和backupPackageFile的定义：

var readPackageFile = new Promise(function(resolve, reject) {
    fs.readFile('./package.json', function(err, data) {
        if (err) {
            reject(err);
        }

        resolve(data);
    });
});

var checkBackupDir = new Promise(function(resolve, reject) {
    fs.exists('./backup', function(exists) {
        if (!exists) {
            resolve(mkBackupDir);
        } else {
            resolve();
        }
    });
});

var mkBackupDir = new Promise(function(resolve, reject) {
    // throw new Error('unexpected error');
    fs.mkdir('./backup', function(err) {
        if (err) {
            return reject(err);
        }

        resolve();
    });
});

function backupPackageFile(data) {
    return new Promise(function(resolve, reject) {
        fs.writeFile('./backup/package.json', data, function(err) {
            if (err) {
                return reject(err);
            }

            resolve();
        });
    });
};

是不是感觉到满满的欺骗，说好的简单呢，先别打，至少调用起来还是很简单的XD。个人觉得使用Promise最大的好处就是让调用方爽。

流程优化，使用js的无阻塞特性，我们发现第一步和第二步可以同步执行：

Promise.all([readPackageFile, checkBackupDir]).then(function(res) {
    return backupPackageFile(res[0]);
}).then(function() {
    console.log('backup successed');
}).catch(function(err) {
    console.error(err);
});

在ES5环境下可以使用的库：

• bluebird
• Q
• when
• WinJS
• RSVP.js

Generator

NodeJs默认不支持Generator的写法，但在v0.12后可以添加--harmony参数使其支持：

> node --harmony generator.js

允许函数在特定地方像return一样退出，但是稍后又能恢复到这个位置和状态上继续执行

function * foo(input) {
    console.log('这里会在第一次调用next方法时执行');
    yield input;
    console.log('这里不会被执行，除非再调一次next方法');
}

var g = foo(10);

console.log(Object.prototype.toString.call(g)); // [object Generator]
console.log(g.next()); // { value: 10, done: false }
console.log(g.next()); // { value: undefined, done: true }

如果觉得比较难理解，就把yield看成return语句，把整个函数拆分成许多小块，每次调用generator的next方法就按顺序执行一小块，执行到yield就退出。

告诉你一个惊人的秘密，我们现在可以“同步”写js的sleep了：

var sleepGenerator;

function sleep(time) {
    setTimeout(function() {
        sleepGenerator.next(); // step 5
    }, time);
}

var sleepGenerator = (function * () {
    console.log('wait...'); // step 2
    console.time('how long did I sleep'); // step 3
    yield sleep(2000); // step 4
    console.log('weakup'); // step 6
    console.timeEnd('how long did I sleep'); // step 7
}());

sleepGenerator.next(); // step 1

合体，使用Promise和Generator重写回调地狱的例子

合体前的准备工作，参考Q.async：

function run(makeGenerator) {
    function continuer(verb, arg) {
        var result;
        try {
            result = generator[verb](arg);
        } catch (err) {
            return Promise.reject(err);
        }
        if (result.done) {
            return result.value;
        } else {
            return Promise.resolve(result.value).then(callback, errback);
        }
    }
    var generator = makeGenerator.apply(this, arguments);
    var callback = continuer.bind(continuer, "next");
    var errback = continuer.bind(continuer, "throw");
    return callback();
}

readPackageFile、checkBackupDir和backupPackageFile直接使用上面Promise中的定义，是不是很爽。

合体后的执行：

run(function *() {
    try {
        // 1. 读取当前目录的package.json
        var data = yield readPackageFile;
        
        // 2. 检查backup目录是否存在，如果不存在就创建backup目录
        yield checkBackupDir;

        // 3. 将文件内容写到备份文件
        yield backupPackageFile(data);

        console.log('backup successed');
    } catch (err) {
        console.error(err);
    }
});

是不是感觉跟写同步代码一样了。

总结

看完本文，如果你感慨：“靠，js还能这样写”，那么我的目的就达到了。本文的写作初衷不是介绍Async、Deferred、Promise、Generator的用法，如果对于这几个概念不是很熟悉的话，建议查阅其他资料学习。写js就像说英语，不是write in js，而是think in js。不管使用那种方式，都是为了增强代码的可读性和可维护性；如果是在已有的项目中修改，还要考虑对现有代码的侵略性。

续集：如何优雅地写js异步代码(2)

参考地址

• 回调地狱
• JavaScript Promise启示录
• Promises/A+
• ECMAScript 6入门
• JavaScript Promises
• 使用 (Generator) 生成器解决 JavaScript 回调嵌套问题
• 拥抱Generator，告别回调

题图引自：http://forwardjs.com/img/workshops/advancedjs-async.jpg