```
function timeout(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}


// e.g.
async function waiting_until_succeed(retry_interval = 2000) {
try {
const result = await api_client.getXXByXX();
} catch (err) {
logger.info(` ${err.message}`);
await timeout(retry_interval);
return waiting_until_succeed();
}
}

```

谁知道 pixel 2 XL 是 HTC 还是 LG 代工的？

额。。把递归改成动态规划就解决了啊
这种 cpu-bound 的业务逻辑，开大于核心数的线程是没用的

最近刚搞了个类似的项目，就题目中的一些用语针对说一说当梳理一下，不一定很有条理：

1. jwt 可以吊销，至于要不要在 db 里存 token 列表可以看业务所用 token 的有效时长。很短的话(交易的分钟级，还有些数天情况的业务)用 redis 等基于内存的 cache 业足够了。以(userId, jwt, secret)这么个元祖的长度为例的话，cache 里存百万千万个数据一点都不是问题。有效期更长的话 db + cache 是一个很简单的方案。

2. jwt 如果选用 HS256 算法，加解密是对称过程，跟非对称型加密相比开销并不大。

3. jwt 相比随机字符串，带来的额外好处还是很明显的。签名后的 jwt 不可伪造，因为秘钥在服务端。比如在 payload 里写入你的全局 ID，这样能通过 gateway 的所有请求，到了后端各个微服务。微服务可以认为这个 token 是有效的，然后从 token 里解出 payload 确认你的真实身份，做一些额外的校验逻辑。另外 jwt 是标准格式，不但各大语言都有数个对应的实现，而且 payload 里面一些约定字段也都是标准化的，能被很多 gateway 的 plugin 所支持。比如 exp 表示过期时间，jti 避免重放攻击。还可以将一些权限 /scope 等自定义数据放到 payload 中，让 gateway 判断你这个用户被允许访问哪些 API。因为 payload 已经被 token 签名了，服务端知道 payload 有没有被篡改。

4. 4 楼的话 我能想象出的方案是，客户端带着 token 请求 server 的任一接口，如果返回 401 token 失效 /过期 这时客户端就可以强制登出，让用户重新进行登录获取新的 token (这也算客户端能知道 token 失效的一个例子吧)

npm 比 pip 好用很多是事实，吐槽的人也蛮多。 但是在 yarn 出来后，npm 迭代速度明显快了。

有人了解过 npm 怎么 exclude 一个传递依赖么？

https://mistertea.github.io/EternalTCP/ 比 mosh 好用

曾专门调研过私有云网盘方案的人来作答，建议 seafile，有官方 docker-compose

1. node 单线程在用户态，v8 里针对 IO 是有线程池的(我的描述不一定很精准)
2. 能利用
3. 没影响

http://liyangready.github.io/2015/08/14/nodejs%E7%9C%9F%E7%9A%84%E6%98%AF%E5%8D%95%E7%BA%BF%E7%A8%8B%E5%90%97%EF%BC%9F/

@happya 匿名性？这个跟区块链不是很相关。区块链的优势在于不可篡改(共识机制)，区块你当成一个只能 insert 不能 update 和 delete 的分布式数据库，在整个 p2p 网络大部分人的见证下写入成功。所以留痕后数据是永久存在，可以被拿来认证的。

金融领域各个行业监管机构比如证监会，可以率领各大券商形成一个行业链(联盟链)，然后通过智能合约的技术将若干需要签署 /留痕 /归档等业务集成在区块服务里，比如将你一笔基金的购买留痕写入区块链中永久的存起来，事后无法抵赖。在信用这方面同样也有很多类似的玩法。

至于交易，我个人不是很看好(毕竟这是一套效率奇低的系统)。

不懂就多读书，区块链本身综合了计算机科学，经济学与密码学三个领域的知识，而且作者在这三个领域都有想当的理解和高度(所以中本聪曾被质疑并不是一个真人，可能是一个组织)。

至于在金融领域，对监管的意义大一些：合规留痕，智能合约。

@iugo https://www.youtube.com/watch?v=v1CmGbOGb2I&t=3052s ←_←

@SlipStupig git 也可以走 http 账号密码的形式，形如 git clone https://username:[email protected]/group/project 反正 dockerfile 在你本地也不担心密码泄露。

不过这种场景有些别扭：Image 作为交付的承载，理应在 gitlab 提交时候自己触发远程机器或跟它同一个域负责构建机器上的 CI 构建过程。最后你本地 pull 下来直接用 Image

@xingda920813 you are right，第一点，就我的体会来说，kotlin 直接 copy 来官方的构建模板很顺滑，而 scala 数次没有折腾成功就弃了，所以没太展开。感谢补充

有人提到很疑惑 kotlin 和 scala 的区别，作为一个双修且两个语言都有上过准生产环境的经历(感谢开明又帅气的 boss)，简单说说我的浅显理解:
1. kotlin 运行时相对轻量，标准库逻辑不多。这主要体现出二者在实现思路上的显著差别，kotlin 一切尽可能复用 Java 已有的逻辑和实现，不少 API 仅仅是 Java 版本的封装。而 scala 则是一切都自己来一套。得益于此 kotlin 获得了与 Java 强大的交互性，kt 文件可以跟 Java 文件混写在一个工程(与 scala 不同的一点在于，kotlin 甚至不用以大目录区分)，并在 Intellij 大法的加成下，拥有无语伦比的开发体验。
这一点也或多或少体现在工具链上，kotlin 可以与 maven/gradle 无缝交互，而 scala 的官方构建工具 sbt 有一定上手难度，再加上众所周知的原因，从 sbt 的安装到工程导入伊始便会遇到层层阻碍，私以为这一点极大地阻碍了 scala 在国内的推广。

2. 在 Functional Programming 支持层面，二者均支持 first-class function/high-order function, Closure, Algebraic Data Type, Type Inference 尾递归优化等在静态语言里如果想舒爽的使用 FP Style 所必须的元素. 相比于 scala, kotlin 还欠缺 Pattern matching, Lazy evaluation 等特性，不过当前的程度已经足够令我满意。和 golang 这种欠缺类型多态的语言相比，kotlin 与 scala 都可以将很多副作用(Nullable，Either，Throwable，IO)直接 encode 进入类型系统，并通过类型系统直接表达和保证对这些副作用的正确处理。相关的 TypeClass/Monad 类库推荐 https://github.com/MarioAriasC/funKTionale 类比 scala 社区比较流行的 scalaz 和 cats.

3. 开源社区的亲和力与推广，Jetbrains 在营销和推广方面显然是个经验丰富的老司机，合纵连横多点开花收获了 Spring, Eclipse(Vert.x)等多个在 Java 领域举足轻重的大型社区官方支持。至于跟 Google Android 团队的关系也早在 Google 启用 Android Studio 作为 official support IDE 时算起便暧昧起来了。另一边，scala 社区背后的 Typesafe 公司(现在更名为 Lightbend)则曾对 Spring 抛来的橄榄枝不理不睬，保持一副高冷作风(e.g. 于 2012 年烂尾的 spring-scala 项目)。毕竟那边也有自己一套 Akka, Play, Lagom 等有自己玩法的技术栈，不亦乐乎。

4. 兼容性，算是一把双刃剑，可以扩大占有份额，也是创新前行路上的镣铐。kotlin 当前版本的字节码是 jdk 1.6 的规范（即使 kotlin 1.1 在编译期给定-jvm-target 1.8 开关，生成的字节码也仍然没有利用 invokedynamic, default method ）。另一点，同样也得益于小体积的标准库，在 Android 平台面对 APP 体积与 65535 方法数限制时，足以游刃有余。scala 从 2.12 起只能运行在 jdk 1.8 上面。

5. 创新与野心：2008 年横空出世的 scala 带来很多创新点，收获了极大地关注度，以至于倒逼促成了 jdk 1.8 的若干语法改动(stream API, optional, lambda)。kotlin 相对于 scala 或一众现代高级语言来说，更多的是取其精华且有所舍弃(比如 implict 这种相对复杂且显著拖慢 compiler 的特性) 并且吸收了其他领域语言的特性(比如 Delegated properties 应该是借鉴自 Objc 的 KVO?) 增强语言在移动平台的表达力。这一头 scala-native 这种玩票性质的工程多年还没什么进展，而另一头 Jetbrains 已经招兵买马组织了一波独立团队去并行研发 kotlin-native, 我内心还是很希望 Jetbrains 能把主要精力聚焦到 be a better Java, 至于 better c++这种事情完全可以交给 Rust 去折腾。

6. 学习成本，综合前面几点，尤其是第一点，kotlin 当前版本（ 1.1.2 ）几乎是处于没有标准库的阶段，对于一个 Java 熟手来说，简单通读一遍官网的语法规范即可上手。而随着后期 kotlin 其他标准库的补全和语法 /关键字的丰富(coroutine 协程 API 将于 1.2 版本彻底稳定，而剑指 Functional Programming 的 immutable collections 也正在紧锣密鼓的研发中)，后面学习起来会遭遇更多的信息和心智负担。考虑到实用性和上手速度，对这两门语言都感兴趣的话，我建议（先）学习 kotlin，而且是立刻和马上学起。

有感而发加上闲得慌，一不小心写成了长文，希望对有兴趣想尝试的小伙伴们有些许帮助。

@dawniii 1.2 之后实现的，这种方式弊端是方法不能被内联，否则还是不能让出时间片。

最近重构一个 python2+twisted 的项目，感觉 qps 也就 300 左右，很忧伤。。

有人对 twisted tornado node.js 写的 restful 的 benchmark 比例有个大概了解么？

优先 orm 吧 复杂的话着重优化建模，性能敏感场景再裸写 sql

redux-saga +1

redux-thunk 和 promise 都改变了 Action 的语义，不推荐