一次让性能提升 1500% 的经历

一般来说,我这里的基础设施得益于 CDN、OSS 和网关层,到了这里都不用扛太多的流量,只要写的不怎么车祸,后端都不存在什么性能瓶颈。

但是这次要上一个灰度功能,需要和业务相结合,在此之前我们的灰度都是以 DNS 为标准进行地区式的灰度,但是现在流量必须要直接打到后端才能判断,如果前面缓存了就没办法灰度了——因此没办法,我们只能船到桥头自然直——扛吧。

先来简单描述一下我们的代码逻辑:查询 1 -> 处理逻辑 -> 查询 2 -> 查询 3 -> 处理逻辑 -> 灰度判断 -> 返回。

最初保持了最原始的代码,没有设置任何缓存,这在过去是满足需求的,因为缓存是由网关层的反向代理帮我们在 Header 里加上的,包括了 s-max-age 和 max-age。

- 阅读剩余部分 -

聊聊技术演讲的二三事

今天在公司看到了一个同事的演讲总结,觉得其实自己也应该总结一下。

目前自己参加过四次演讲,一共是:

  1. Node Party 2017 - 女程序员的自我修养
  2. Coding 技术小馆 - 女程序员与开源程序
  3. FreeCodeCamp Shanghai 2018 - 闲话 CDN
  4. 2018 计算机大会前端分会场 - 字符级静态资源增量更新实践

- 阅读剩余部分 -

解除 axios Request Body 大小限制

之前经常有用户反馈我们做的系统中,在上传过程中会遇到 Request body larger than maxBodyLength limit,其实这个问题之前已经存在了很久,但是一直没去动。

最初以为是服务端发出的 error,因为默认使用的 koa-body 在旧版本也有上传内容的大小限制,但是后来调试过程中发现请求根本没发出去——

- 阅读剩余部分 -

聊聊阿里云 OSS 的转义设计问题

今天同事向我反馈,当我们的静态资源有中文名混杂 + 和空格 时,得到的链接并不能打开,返回的是 404.

举个例子,假定我们的资源为:

http://example-resource.oss-cn-shanghai.aliyuncs.com/23232323/中文 + 文件-file.ec296f20-d67b-11e8-a623-7b28809dc3c9.js

那么在浏览器中访问的文件名应该被转义为:

%E4%B8%AD%E6%96%87%20+%20%E6%96%87%E4%BB%B6-file.ec296f20-d67b-11e8-a623-7b28809dc3c9.js

注意,在这里,空格被转义为 %20,而 + 没有进行任何处理。

- 阅读剩余部分 -

粗体的玄学:谈谈 b 与 strong

之前遇到了在一段提示中需要加粗的问题,我们都知道,加粗有几种写法:

  • font-weight
  • <b>
  • <strong>

但是,这三者到底有什么区别——

在大多数场景下,我都会选择使用 font-weight,众所周知的是,HTML 应该与语义结合,如果是一般的加粗,那么使用 font-weight 刚刚好。

- 阅读剩余部分 -

npm shrinkwrap 与 package-lock

从开搞到文章结束过了一个月……所以……看看就行

前两天在一个群里看到一个问题,有人问「yarn 能不能人工锁版本号」,刚开始我们都没有理解,觉得明明直接用 yarn 或者 yarn install 就能生成 lock 文件,为什么要人工生成。

于是被介绍了一个 npm shrinkwrap,这是在 package-lock 出现之前就有的项目依赖锁定工具,实际上效果和 package-lock 差不多,唯一的不同是:npm shrinkwrap 是手动生成的。同样的,在更新包、删除包时也需要在完成后手动使用 npm shrinkwrap

在现代的版本中,如果两者同时存在,那么会优先取 shrinkwrap:

This command installs a package, and any packages that it depends on. If the package has a package-lock or shrinkwrap file, the installation of dependencies will be driven by that, with an npm-shrinkwrap.json taking precedence if both files exist. See package-lock.json and npm-shrinkwrap.

- 阅读剩余部分 -

NAS 入门篇

由于 Time Machine 先后救我于水火之中两次,但是我的路由器实在不方便做,仗着有一点微小的闲钱(2000 块……),我就开始研究 NAS 了。

货比三家

在购买之前,首先先查了一波 NAS 的户口:群晖、威联通、玩客云——玩客云首先由于功能薄弱先 Pass,与其说玩客,不如说是视频+,具体是在什么值得买看到的……Emmmm,一点都不 Server。

威联通的价格比群晖低好多,不过相对的软件生态也不太一样,刚开始苏老师跟我疯狂案例威联通,看了一下价格还算可以,同样的价格群晖的配置比威联通低一点,而且还只有两个盘位,隔壁威联通能买到四个盘位,配置可扩展性也更高一点——但是在 DIY 的黑群的对比下,完全是碾压级别的……便宜。

- 阅读剩余部分 -

我只想让一堆 Promise 跑起来:promise-foreach

最近在写项目的时候有个需求:我的 Promise 即使失败了也没关系——更进一步的,当且仅当失败率大于某一值,这才是一个失败的请求。

于是我查看了包括 ES6 Promise 和 Bluebird 的实现,发现都没有我想要的效果:

  1. 异步无序
  2. 每个方法使用相同处理函数
  3. 失败不影响结果

在完成项目之后把函数抽出来作为一个单独的 utils 模块发布,今天总算把 lint 和 test 补齐了,于是顺手写一篇宣传文。

他没什么大作用,函数实现还是表现形式都比较 Low:

const foreach = require('sky-promise-foreach')

foreach([...promises], (result) => {
  // success handler for each promise
}, (err) => {
  // error handler for each promise
})

在同事的建议下,之后有空可能会出一个改版,把这个库做的更通用一点。

Repo 地址:https://github.com/csvwolf/promise-foreach

[翻译]小心你复制的内容:使用零宽字符将用户名不可见的插入文本中

翻译源:Be careful what you copy: Invisibly inserting usernames into text with Zero-Width Characters

不想读?试试这个 demo

零宽字符都是不可见的「非打印」字符,大多数应用程序中都不会显示这些字符。比如,我在这句话中添加了十个零宽字符​​​​​​​​​​,你能分辨出来吗?(提示:将句子粘贴到 Diff Checker 来查看这些字符的位置。这些字符可以被用于做某些用户的「指纹」字符。)

- 阅读剩余部分 -

脏读、幻读与不可重复读

最近在读 《MySQL 技术内幕 InnoDB 存储引擎》,里面提到的各种概念都很新鲜,以前听说过脏读、幻读、不可重复读,但是对于概念不甚了解,于是查了一下,这里做个笔记。

数据库事务特征

数据库事务特征,即 ACID:

A Atomicity 原子性

- 阅读剩余部分 -