我在 Small talk 的第二期「 2020 可能对于每一个人都是非常特殊的一年，中间发生的几乎每一件事都能和疫情联系起来。本来盼望了很久能在春节去蛋黄的老家放烟花，然而随着新冠疫情愈演愈烈，我们最后在 1 月 17 日决定取消了行程。

在疫情的初期也就是春节期间，事件的发展有着很大的不确定性，这种不确定性和媒体中对立的观点对我的情绪影响也很大，从这里开始，应该说这一整年我的情绪都很差。这次疫情也打破了我之前对于科技和未来的一些想象 —— 原来在今天，病毒会对人类社会造成这么大的影响、给我们的生活带来这么大的变化，而且这种变化很有可能常态化地持续下去。

年初蛋黄开始在我的指导下比较系统地开始学习 JavaScript 和 Web，中间短暂地工作过几个月，后面又开始学 Swift。一开始我非常着急希望蛋黄能学会一些技能然后开始工作，为此经常吵架。但后来蛋黄工作后我的情绪也没有变好，变得越来越难调节自己的情绪、总是在患得患失，也发生了很多不开心的事情。在这种情况下也很难去规划未来，只能先调整情绪，这个过程中全靠蛋黄哄着我。这对我的内容创作影响也很大，今年的内容输出非常少。希望我们能早些回到刚搬到昆山时的状态。

在年初我们参加了一次 烧火节 的线下活动，以此为契机拍摄制作了我的第一个 Vlog「第一届烧火节 Vlog：钻木取火、烧烤露营」。在之后我陆续购买了新的相机和稳定器等设备、拍摄了大量的素材，也制作了其他几个视频，但回过头来看烧火节的 Vlog 仍然是我最满意的一个视频。在疫情有了一定缓解之后我们还去了迪士尼和横店，也拍了很多视频，不过一直没有来得及剪辑成片。

今年我业余时间完成的最大的一个项目是 NAS，我花了半年的时间，先在树莓派上做实验，然后购买了 HPE MicroServer Gen 10 作为正式环境，希望能解决未来十年的存储需求。我还将整个过程写成了一篇文章「我的 NAS 选型与搭建过程」。它的主机名叫 infinity，实际投入使用后确实给了我很大的安全感 —— 这是一个由我所熟悉的开源软件构建的、有着先进的备份和纠错机制的存储系统，数据一旦被导入其中就几乎不可能再丢失。

所幸在疫情期间我也找到了一些投资机会，在全面的货币增发的情况下，今年收入和个人资产都有不小的增长，尤其在年底，密码货币差不多已经涨回了 2017 年的高点。从我工作以来这种收入和资产的不断增长，让我一直对未来保持着一种乐观的态度。

在工作方面，今年最大的变化是我需要花更多的时间去协调其他同事的工作，拆分工作、制定计划、参与面试，将自己的知识和经验分享给新加入的同事。随着工作年限的增加，工作本身会要求你承担更重要、更复杂（但可能没那么有趣）的工作，如果跟不上这种变化可能就需要给别人让位了，我想这应该就是所谓的「35 岁危机」。

一转眼从北京回到昆山也两年多了，开始觉得昆山实在是待够了 —— 现在我们几乎把昆山能逛的地方都逛了遍。我们接下来大概率会搬到上海，因为相比于其他选择，这可能是最容易做出的一个改变。其实这有点像我三年前搬去北京的理由，但我觉得上海无论是环境还是生活节奏应该都会比北京好很多。

在有了搬去上海这个想法之后，我发现我越来越害怕失去，之前每次搬家的过程中会扔掉很多东西，但现在就想把所有东西都留着；我会舍不得昆山的办公室；舍不得我们在昆山的房子 —— 我们在这里住了三年，留下了很多回忆，同时在不断地改造这个房子，让人觉得很难有比这里更舒服的地方了。我也会担心皮蛋豆腐 —— 它们今年经常会吐，中间豆腐还有那么半个月食欲不佳，虽然最后去医院检查时一切正常。

]]> https://jysperm.me/2020/12/summary-of-2020/ 2020-12-30T17:00:00.000Z

2020 可能对于每一个人都是非常特殊的一年，中间发生的几乎每一件事都能和疫情联系起来。本来盼望了很久能在春节去蛋黄的老家放烟花，然而随着新冠疫情愈演愈烈，我们最后在 1 月 17 日决定取消了行程。

在疫情的初期也就是春节期间，事件的发展有着很大的不确定性，]]>

2026-05-01T15:13:06.181Z 王子亭 jysperm@gmail.com 在 2016 年我拥有了第一台 NAS —— 群晖的 DS215J，其实在之后的很长一段时间其实并没有派上多大用场，因为我的数据并不多，大都存储在云端，更多的是体验一下 NAS 的功能和工作流。

直到最近我才开始真正地将 NAS 利用上，于是准备升级一下，但考虑到群晖的性价比实在太低，再加上去年配置 Linux 软路由让我对基于「原生 Linux」的开源解决方案信心和兴趣大增，于是准备自己 DIY 一台 NAS，计划解决未来十年的存储需求。

我依然选择了我最熟悉的 Ubuntu 作为操作系统、Ansible 作为配置管理工具，因此这个 NAS 的大部分配置都可以在我的 GitHub 上找到。

注意这个仓库中的 Ansible 配置仅供参考，不建议直接运行，因为我在编写这些配置时并未充分考虑兼容性和可移植性。

文件系统

对于一台 NAS 来说最重要的当然是文件系统，不需要太多调研就可以找到 ZFS —— 可能是目前在数据可靠性上下功夫最多的单机文件系统了，于是我的整个选型就围绕 ZFS 展开了。

ZFS 既是文件系统，同时又是阵列（RAID）管理器，这为它带来了一些其他文件系统难以提供的能力：

• ZFS 为每个块都存储了校验和，同时会定期扫描整个硬盘，从 RAID 中的其他硬盘修复意外损坏的数据（如宇宙射线导致的比特翻转）。
• 在 RAID 的基础上可以 指定某些目录以更多的份数冗余存储，对于重要的数据即使损坏的硬盘超过了 RAID 方案的限制，依然有可能找回。

ZFS 还支持数据加密、压缩和去重，这三项功能以一种巧妙的顺序工作，并不会互相冲突，同时这些所有选项都可以设置在目录（dataset）级别、可以随时更改（只对新数据生效）。

ZFS 当然也支持快照，快照可以被导出为二进制流，被存储到任何地方。这个功能可以让你在不丢失任何元信息的情况下对 ZFS 的文件系统进行备份、传输和恢复。

硬件

我并不擅长淘硬件，于是就选择了 HPE 的 MicroServer Gen10，一个四盘位的成品微型服务器，CPU 是 AMD X3421 ，8G ECC 内存，也是标准的 x86 通用硬件，应该不太容易遇到坑。

我用转接卡在 PCI-E 插槽上装了一块 NVME SSD，用作系统盘和 ZFS 的读缓存（L2ARC，不过从后面的统计来看效果并不明显），数据盘则暂时用的是旧的硬盘，最终会升级到四块 4T 的硬盘。这里需要注意的是因为 ZFS 不支持更改 RAID 的结构，所以必须在一开始就配置足够的硬盘来占位，后续再升级容量，我甚至用 USB 接了一块移动硬盘来凑数。

ZFS

因为是四盘位，所以我采用了 raidz1（RAID5），冗余一块盘作为校验，如果最终所有的盘都升级到 4T，一共是 12T 的实际可用容量。

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

root@infinity:~# zpool status pool: storage state: ONLINE config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 sda ONLINE 0 0 0 sdb ONLINE 0 0 0 sdc ONLINE 0 0 0 sdd ONLINE 0 0 0 cache nvme0n1p4 ONLINE 0 0 0 root@infinity:~# zpool list NAME SIZE ALLOC FREE CKPOINT FRAG CAP DEDUP HEALTH storage 7.27T 3.52T 3.75T - 10% 48% 1.00x ONLINE

通常认为 RAID5 在出现硬盘故障的恢复过程中存在着较高的风险发生第二块盘故障、最终丢失数据的的情况；或者硬盘上的数据随着时间推移发生比特翻转导致数据损坏。但考虑到 ZFS 会定期做数据校验来保证数据的正确性，再综合考虑盘位数量和容量，我认为这个风险还是可以接受的，后面也会提到还有异地备份作为兜底措施。

我开启了 ZFS 的加密功能，但这带来了一个问题：我不能把密钥以明文的方式存储在 NAS 的系统盘 —— 否则密钥和密文放在一起的话，这个加密就失去意义了。所以每次 NAS 重启后，都需要我亲自输入密码、挂载 ZFS 的 dataset，然后再启动其他依赖存储池的服务。

我还开启了 ZFS 的数据压缩，默认的 lz4 只会占用少量的 CPU 却可以在一些情况下提高 IO 性能 —— 因为需要读取的数据量变少了。因为去重对资源的需求较高，相当于需要为整个硬盘建立一个索引来找到重复的块，我并没有开启去重功能。

一些评论认为 ZFS 对内存的需求高、必须使用 ECC 内存。这其实是一种误解：更多的内存可以提升 ZFS 的性能，ECC 则可以避免系统中所有应用遇到内存错误，但这些并不是必须的，即使没有更多的内存或 ECC，ZFS 依然有着不输其他文件系统的性能和数据完整性保证。

存储服务

小知识：SMB 是目前应用得最广泛的局域网文件共享协议，在主流的操作系统中都有内建的支持。CIFS 是微软（Windows）对 SMB 的一个实现，而我们会用到的 Samba 是另一个实现了 SMB 协议的自由软件。

作为 NAS 最核心的功能就是通过 SMB 协议向外提供存储服务，所有的成品 NAS 都有丰富的选项来配置 SMB 的功能，但我们就只能直接去编辑 Samba 的配置文件了，Samba 直接采用了 Linux 的用户和文件权限机制，配置起来也不算太麻烦：

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

# 可以在 path 中使用占位符来为每个用户提供单独的 Home 目录 # 可以在 valid users 中使用用户组来控制可访问的用户 [Home] path = /storage/private/homes/%U writeable = yes valid users = @staff # Samba 默认以登录用户创建文件，但 NextCloud 以 www-data 运行，可以用 force user 覆盖为特定的用户 [NextCloud] path = /storage/nextcloud/data/%U/files writeable = yes valid users = @staff force user = www-data # 通过这些设置可以让 macOS 的 TimeMachine 也通过 SMB 进行备份 # 详见 https://www.reddit.com/r/homelab/comments/83vkaz/howto_make_time_machine_backups_on_a_samba/ [TimeMachine] path = /storage/backups/timemachines/%U writable = yes valid users = @staff durable handles = yes kernel oplocks = no kernel share modes = no posix locking = no vfs objects = catia fruit streams_xattr ea support = yes inherit acls = yes fruit:time machine = yes # 对于共享的目录可以用 force group 覆盖文件的所属组、用 create mask 覆盖文件的权限位 [VideoWorks] path = /storage/shares/VideoWorks writeable = yes valid users = @staff force group = staff create mask = 0775 # 还可以设置游客可读、指定用户组可写的公开目录 [Resources] path = /storage/public/Resources guest ok = yes write list = @staff force group = +staff create mask = 0775

从上面的配置中也可以看到这些共享目录分散在几个不同的路径，为了匹配不同的数据类型、方便在目录级别进行单独设置，我划分了几个 dataset:

• db 存放应用的数据库文件，将 recordsize 设置为了 8k（默认 128k）。
• nextcloud NextCloud 的数据目录，也可被 SMB 访问。
• private 每个用户的个人文件。
• shares 家庭内部共享的文件（如拍摄的视频）。
• public 可以从互联网上下载到的文件，不参与异地备份。
• backups 备份（Time Machine 等），不参与异地备份。

1 2 3 4 5 6 7 8 9

root@infinity:~# zfs list NAME USED AVAIL REFER MOUNTPOINT storage 2.27T 286G 169K /storage storage/backups 793G 286G 766G /storage/backups storage/db 741M 286G 339M /storage/db storage/nextcloud 207G 286G 207G /storage/nextcloud storage/private 62.2G 286G 62.2G /storage/private storage/public 648G 286G 613G /storage/public storage/shares 615G 286G 609G /storage/shares

应用

首先我安装了 Netdata，这是一个开箱即用的监控工具，在仅占用少量资源的情况下提供秒级精度的大量统计指标，非常适合用于监控单台服务器的性能瓶颈。

其余的应用都被我运行在了 Docker 中（使用 docker-compose 来管理），这样可以隔离应用的运行环境，提升宿主机的稳定性，安装、升级、卸载应用也会更方便。

其中最重要的一个应用是 NextCloud，这是一个开源的同步盘，我主要看中它的 iOS 应用和 iOS 有不错的整合，可以正确地同步 Live Photo，也可以在 iOS 的文件应用中被调用。

NextCloud 服务端会直接读写文件系统中的文件，而不是将文件存储在数据库里，这意味着 NextCloud 的数据目录同时也可以通过 Samba 来访问，这一点非常方便（不过需要一个定时任务来刷新 NextCloud 数据库中的元信息）。

我还在 Docker 中运行了这些服务，它们都是开源的：

• Miniflux，一个 RSS 服务端，通过 Fever API 支持绝大部分的 RSS 客户端。
• Bitwarden（非官方实现），一个密码管理器，提供有各平台的客户端和浏览器插件。
• Transmission，一个 BitTorrent 客户端，提供基于 Web 的管理界面。

外部访问

如果要真正地用 NAS 来替代网盘的话，还是需要保证不在家里的内网的时候也可以访问到文件的。

通常的做法是使用 DDNS（动态 DNS）将一个域名解析至家庭宽带的 IP，这要求家庭宽带有公网 IP，而且运营商允许在 80 或 443 端口提供 Web 服务。我不想依赖这一点，所以想到了用 frp 来进行「反向代理」，如果你确实有公网 IP 的话，也可以使用 DDNS 的方案，这样会省去一个中转服务器，也可以有更好的速度。

为了让 NextCloud 能有一个固定的地址（如 https://nextcloud.example.com）我将域名在内外网分别进行了解析，在家时解析到内网地址，在外解析到中转服务器。无论是内外网，数据流都会经过 Let’s Encrypt 的 SSL 加密，这样就不需要中转服务器有较高的安全保证。

虽然不需要先拨一个 VPN 确实很方便，但将 NextCloud 开放在公网上 并不安全，在社区中已有用户 要求 NextCloud 客户端支持双向 SSL 认证，我也非常期待这个功能，可以在公网访问上提供更好的安全性。

我还在 NAS 上安装了 WireGuard，这是一个内建在 Linux 内核中的 VPN 模块，同样通过 frp 暴露在外网，除了 NextCloud 之外的服务，如 SMB、SSH 和 Nextdata 都可以通过 WireGuard 来访问。

如果你不执着于开源方案的话，也可以试试 ZeroTier，它提供了 NAT 穿透的能力，让你的设备和 NAS 之间可以不借助中转服务器直接传输，改善连接速度。

备份和数据完整性

在 raidz1 的基础上，我设置了定时任务让 ZFS 每天生成一个快照，还写了一个脚本来按照类似 Time Machine 的规则来清理备份：保留最近一周的每天快照、最近一个月的每周快照、最近一年的每月快照、以及每年的快照。

1 2 3 4 5 6 7 8 9 10 11

root@infinity:~# zfs list storage/nextcloud -t snapshot NAME USED AVAIL REFER MOUNTPOINT storage/nextcloud@2020-09-05 83.9M - 182G - storage/nextcloud@2020-09-15 35.2M - 207G - storage/nextcloud@2020-09-21 30.2M - 207G - storage/nextcloud@2020-09-23 29.7M - 207G - storage/nextcloud@2020-09-26 29.3M - 207G - storage/nextcloud@2020-09-27 28.2M - 207G - storage/nextcloud@2020-09-28 28.2M - 207G - storage/nextcloud@2020-09-29 29.1M - 207G - storage/nextcloud@2020-09-30 33.5M - 207G -

快照主要是为了防止人工的误操作，除了单纯的、当场就能发现的手滑之外，有时你会误以为你不会用到这个文件而将它删除，直到很久之后才发现并非如此。

同时每周会有定时任务使用 restic 备份一个快照到 Backblaze B2 作为异地备份，这是一个价格较低的对象存储，非常适合备份。restic 支持增量的快照备份，也支持加密。出于成本考虑，异地备份仅包括由我产生的数据，并不包括 public 和 backups 目录。

我曾考虑过直接在远端运行一个 ZFS 来进行备份，zfs send / recv 支持以二进制流的形式传输一个快照 —— 不需要远端安装其他任何的工具，只需要用 shell 的管道操作符将 zfs send 的字节流重定向到 ssh 命令即可。这个方案非常具有技术美感，但考虑到块存储的价格是对象存储的十倍以上，最后还是放弃了这个方案。

成本核算

硬件上其实我预算并不紧张，留的余量也比较大，如果换一些性价比更高的硬件的话，价格还可以下降很多。

• 主机（主板、CPU、内存、系统盘） 3500 元
• 硬盘（4 * 4T） 2200 元（其实目前只买了一块，其他三块是旧的）

考虑到我之前的群辉用了五年，新的 NAS 设计使用寿命定在十年：

• 硬件成本折合每年 570 元
• 电费（35W）每年 110 元
• 远程访问每年 100 元（国内年付促销服务器，如有公网 IP 使用 DDNS 则无需此项）
• 异地备份每年 415 元（按量付费，这里按 1T 需要异地备份的数据计算）

总共 12T 的容量每年 1195 元，折合 1T 每月 8 元，如果去掉远程访问和异地备份的话则是 1T 每月 5 元。

为什么要用自部署方案

相比于使用云服务，第一个理由自然是对数据的「掌控感」，虽然没有什么确凿的理由说云服务就一定不安全，但有些人就是喜欢这种对个人数据的掌控感。

还有一个技术原因是部署在家中内网的 NAS 可以通过 SMB 简单地支持一些「在线编辑」，如直接加载 NAS 上的素材进行视频剪辑、甚至将整个工程文件都直接放在 NAS 上。使用云服务的话一方面是没有 SMB 协议的支持，即使支持延迟对于在线编辑来说也是无法接受的。

另外一个不能忽略的话题就是成本，在这里我们只考虑以容量为计价方案的网盘服务，iCloud、Google Drive、Dropbox 的价格方案都非常接近，在超过 200G（大概 $3）这一档之后就直接跳到了 2T（大概 $10），这时云服务按量付费的优势其实就没有了，是一个切换到自部署方案的一个不错的时间点，一次性投入之后只需 2 - 3 年即可回本。

当然最重要的一点是兴趣，在这个折腾的过程中你需要做很多决定、遇到很多困难，最后搭建出来一个几乎是独一无二的自部署方案。如果你能在这个过程中找到乐趣的话，那当然是非常值得的；反过来如果你没有兴趣，算上投入的时间成本，自部署方案的性价比将会非常低。

任何自部署的方案都需要长期的维护才能保持工作，对后端运维完全没有兴趣怎么办，不如了解一下 LeanCloud，领先的 BaaS 提供商，为移动开发提供强有力的后端支持。

]]> https://jysperm.me/2020/11/my-opensource-nas-build/ 2020-11-03T17:00:00.000Z

在 2016 年我拥有了第一台 NAS —— 群晖的 DS215J，其实在之后的很长一段时间其实并没有派上多大用场，因为我的数据并不多，大都存储在云端，更多的是体验一下 NAS 的功能和工作流。

直到最近我才开始真正地将 NAS 利用上，于是准备升级一下，但考]]>

2026-05-01T15:13:06.184Z 王子亭 jysperm@gmail.com 作为一个 Node.js 开发者，我很早便了解到了 TypeScript，但又因为我对 CoffeeScript 的喜爱，直到 2016 年才试用了一下 TypeScript，但当时对它的学习并不深入，直到最近又在工作中用 TypeScript 开发了两个后端项目，对 TypeScript 有了一些新的理解。

为 JavaScript 添加类型

大家总会把 TypeScript 和其他语言去做对比，说它是在模仿 Java 或 C#，我也曾一度相信了这种说法。但其实并非如此，TypeScript 的类型系统和工作机制是如此的独特，无法简单地描述成是在模仿哪一个语言，更像是在 JavaScript 的基础上重新发明了 JavaScript。

究其根本，TypeScript 并不是一个全新的语言，它是在一个已有的语言 —— 还是一个非常灵活的动态类型语言上添加静态约束。在官方 Wiki 上的 TypeScript Design Goals 中有提到，TypeScript 并不是要从 JavaScript 中抽取出一个具有静态化语义的子集，而是要尽可能去支持之前社区中已有的编程范式，避免与常见的用法产生不兼容。

这意味着 TypeScript 试图为 JavaScript 已有的大量十分「动态」的特性去提供静态语义。一般认为「静态类型」的标志是在编译时为变量确定类型，但 TypeScript 很特殊，因为 JavaScript 本身的动态性，TypeScript 中的类型更像是一种「约束」，它尊重已有的 JavaScript 设计范式，同时尽可能添加一点静态约束 —— 这种约束不会影响到代码的表达能力。或者说，TypeScript 会以 JavaScript 的表达能力为先、以 JavaScript 的运行时行为为先，而静态约束则次之。

这样听起来 TypeScript 是不是很无聊呢，毕竟 Python 也有 Type Checking，JavaScript 之前也有 Flow。的确如此，但 TypeScript 的类型系统的表达能力和工具链的支持实在太强了，并不像其他一些静态类型标注仅能覆盖一些简单的情况，而是能够深刻地参与到整个开发过程中，提高开发效率。

前面提到 TypeScript 并不想发明新的范式，而是要尽可能支持 JavaScript 已有的用法。因此虽然 TypeScript 有着强大的类型系统、大量的特性，但对于 JavaScript 开发者开说学习成本并不高，因为几乎每个特性都可以对应 JavaScript 社区中一种常见的范式。

基于属性的类型系统

在 JavaScript 中，对象（Object）是最常用的类型之一，我们会使用大量的对象字面量来组织数据，我们经常将很多不同的参数塞进一个对象，或者从一个函数中返回一个对象，对象中还可以再嵌套对象。可以说对象是 JavaScript 中最常用的数据容器，但并没有类型去约束它。

例如 request 这个库会要求使用者将发起请求的所有参数一股脑地以一个对象的形式作为参数传入。这就是非常典型的 JavaScript 风格。再比如 JavaScript 中一个 Promise 对象只需有 then 和 catch 这两个实例方法就可以，而并不真的需要真的来自标准库中的 Promise 构造器，实际上也有很多第三方的 Promise 的实现，或一些返回类 Promise 对象的库（例如一些 ORM）。

在 JavaScript 中我们通常只关注一个对象是否有我们需要的属性和方法，这种范式被称为「鸭子类型（Duck typing）」，就是说「当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子，那么这只鸟就可以被称为鸭子」。

所以 TypeScript 选择了一种基于属性的类型系统（Structural type system），这种类型系统不再关注一个变量被标称的类型（由哪一个构造器构造），而是 在进行类型检查时，将对象拆开，抽丝剥茧，逐个去比较组成这个对象的每一个不可细分的成员。如果一个对象有着一个类型所要求的所有属性或方法，那么就可以当作这个类型来使用。

这就是 TypeScript 类型系统的核心 —— Interface（接口）：

1 2 3

interface LabeledValue { label: string }

TypeScript 并不关心 Interface 本身的名字，与其说是「类型」，它更像是一种约束。一个对象只要有一个字符串类型的 label 属性，就可以说它满足了 LabeledValue 的约束。它可以是一个其他类的实例、可以是字面量、可以有额外的属性；只要它满足 LabeledValue 所要求的属性，就可以被赋值给这个类型的变量、传递给这个类型的参数。

前面提到 Interface 实际上是一组属性或一组约束的集合，说到集合，当然就可以进行交集、并集之类的运算。例如 type C = A & B 表示 C 需要同时满足类型 A 和类型 B 的约束，可以简单地实现类型的组合；而 type C = A | B 则表示 C 只需满足 A 和 B 任一类型的约束，可以实现联合类型（Union Type）。

接下来我会挑选一些 TypeScript 具有代表性的一些特性进行介绍，它们之间环环相扣，十分精妙。

字符串魔法：字面量

在 TypeScript 中，字面量也是一种类型：

1 2 3

type Name = 'ziting' const myName: Name = 'ziting'

在上面的代码中，Name 类型唯一合法的值就是 ziting 这个字符串 —— 这看起来毫无意义，但如果我们引入前面提到的集合运算（联合类型）呢？

1 2 3 4 5 6

type Method = 'GET' | 'PUT' | 'DELETE' interface Request { method: Method url: string }

上面的代码中我们约束了 Request 的 method 只能是 GET、PUT 和 DELETE 之一，这比单纯地约束它是一个字符串类型要更加准确。这是 JavaScript 开发者经常使用的一种模式 —— 用字符串来表示枚举类型，字符串更灵活也更具有可读性。

在 lodash 之类的库中，JavaScript 开发者还非常喜欢使用字符串来传递属性名，在 JavaScript 中这很容易出错。而 TypeScript 则提供了专门的语法和内建的工具类型来实现对这些字符串字面量的计算，提供静态的类型检查：

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

interface Todo { title: string description: string completed: boolean } // keyof 将 interface 的所有属性名提取成一个新的联合类型 type KeyOfTodo = keyof Todo // 'title' | 'description' | 'completed' // Pick 可以从一个 interface 中提取一组属性，生成新的类型 type TodoPreview = Pick<Todo, 'title' | 'completed'> // {title: string, completed: boolean} // Extract 可以找到两个并集类型的交集，生成新的类型 type Inter = Extract<keyof Todo, "title" | "author"> // "title"

借助这些语法和后面提到的泛型能力，JavaScript 中各种以字符串的形式传递属性名、魔法般的对象处理，也都可以得到准确的类型检查。

类型元编程：泛型

泛型提供了一种将类型参数化的能力，在其他语言中最基本的用途是定义容器类型，使得工具函数可以不必知道被操作的变量的具体类型。JavaScript 中的数组或 Promise 在 TypeScript 中都会被表述为这样的泛型类型，例如 Promise.all 的类型定义可以写成：

1	function all<T>(values: Array<T | Promise<T>>): Promise<Array<T>>

可以看到类型参数可以被用来构造更复杂的类型，进行集合运算或嵌套。

默认情况下，因为类型参数可以是任意的类型，所以不能假定它有某些属性或方法，也就不能访问它的任何属性，只有添加了约束才能遵循这个约束去使用它，同时 TypeScript 会依照这个约束限制传入的类型：

1 2 3 4 5 6 7

interface Lengthwise { length: number } function logLength<T extends Lengthwise>(arg: T) { console.log(arg.length) }

约束中也可以用到其他的类型参数或使用多个类型参数，在下面的代码中我们限制类型参数 K 必须是 obj 的一个属性名：

1 2 3

function getProperty<T, K extends keyof T>(obj: T, key: K) { return obj[key]; }

除了在函数上使用泛型之外，我们还可以定义泛型类型：

1 2 3

type Partial<T> = { [P in keyof T]?: T[P]; }

当定义泛型类型时我们实际上是在定义一种处理类型的「函数」，使用泛型参数去生成新的类型，这也被称作「元编程」。例如 Partial 会遍历传入类型 T 的每一个属性，返回一个所有属性都可空的新类型：

1 2 3 4 5 6

interface Person { name: string } const a: Person = {} // 报错 Property 'name' is missing in type '{}' but required in type 'Person'. const b: Partial<Person> = {}

前面我们提到的 Pick 和 Extract 都是这样的泛型类型。

在此之外 TypeScript 甚至可以在定义泛型类型时进行条件判断和递归，这使得 TypeScript 的类型系统变成了 图灵完备的，可以在编译阶段进行任何计算。

你可能会怀疑这样复杂的类型真的有用么？其实这些特性更多地是提供给库开发者使用的，对于 JavaScript 社区中的 ORM、数据结构，或者是 lodash 这样的库来说，如此强大的类型系统是非常必要的，lodash 的 类型定义 行数甚至是它本身代码的几十倍。

类型方程式：自动推导

但其实我们并不一定要掌握这么复杂的类型系统，实际上前面介绍的高级特性在业务代码中都极少被用到。TypeScript 并不希望标注类型给开发者造成太大的负担，因此 TypeScript 会尽可能地进行类型推导，让开发者在大多数情况下不必手动标注类型。

1 2 3 4 5 6 7 8 9 10 11

const bool = true // bool 是字面量类型 true let num = 1 // num 是 number let arr = [0, 1, 'str'] // arr 是 (number | string)[] let body = await fs.readFile() // body 是 Buffer // cpuModels 是 string[] let cpuModels = os.cpus().map( cpu => { // cpu 是 os.CpuInfo return cpu.model })

类型推导同样可以用在泛型中，例如前面提到的 Promise.all 和 getProperty，我们在使用时都不必去管泛型参数：

1 2 3 4 5 6 7

// 调用 Promise.all<Buffer>，files 的类型是 Promise<Buffer[]> const files = Promise.all(paths.map( path => fs.readFile(path))) // 调用 Promise.all<number[]>，numbers 的类型是 Promise<number[]> const numbers = Promise.all([1, 2, 3, 4]) // 调用 getProperty<{a: number}, 'a'>，a 的类型是 number const a = getProperty({a: 2}, 'a')

前面提到泛型是在将类型参数化，引入一个未知数来代替实际的类型，所以说泛型对于 TypeScript 就像是一个方程式一样，只要你提供了能够解开这个方程的其他未知数，TypeScript 就可以推导出剩余的泛型类型。

价值十亿美金的错误

在很多语言中访问空指针都会报出异常（在 JavaScript 中是从 null 或 undefined 上读取属性时），空指针异常被称为「价值十亿美元的错误」。TypeScript 则为空值检查也提供了支持（需开启 strictNullChecks），虽然这依赖于类型定义的正确性，并没有运行时的保证，但依然可以提前在编译期发现大部分的错误，提高开发效率。

TypeScript 中的类型是不可为空（undefined 或 null）的，对于可空的类型必须表示成和 undefined 或 null 的并集类型，这样当你试图从一个可能为 undefined 的变量上读取属性时，TypeScript 就会报错了。

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

function logDateValue1(date: Date) { // 不可空 console.log(date.valueOf()) } logDateValue1(new Date) logDateValue1() // 报错 An argument for 'date' was not provided. function logDateValue2(date: Date | undefined) { // 可空 console.log(date.valueOf()) // 报错 Object is possibly 'undefined'. } logDateValue2(new Date) logDateValue2()

在这种情况下 TypeScript 会要求你先对这个值进行判断，排除其为 undefined 可能性。这就要说到 TypeScript 的另外一项特性 —— 其基于控制流的类型分析。例如在你使用 if 对变量进行非空判断后，在 if 之后的花括号中这个变量就会变成非空类型：

1 2 3 4 5 6 7 8

function print(str: string | null) { // str 在这里的类型是 string | null console.log(str.trim()) // 报错 Object is possibly 'null'. if (str !== null) { // str 在这里的类型是 string console.log(str.trim()) } }

同样的类型分析也发生在使用 if、switch 等语句对并集类型进行判断时：

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

interface Rectangle { kind: 'rectangle' width: number height: number } interface Circle { kind: 'circle' radius: number } function area(s: Rectangle | Circle) { // s 在这里的类型是 Rectangle | Circle switch (s.kind) { case "rectangle": // s 在这里的类型是 Rectangle return s.height * s.width case "circle": // s 在这里的类型是 Circle return Math.PI * s.radius ** 2; } }

仅仅工作在编译阶段

TypeScript 最终仍然会编译到 JavaScript，再被 JavaScript 引擎（如 V8）执行，在生成出的代码中不会包含任何类型信息，TypeScript 也不会添加任何与运行时行为有关的功能。

TypeScript 仅仅提供了类型检查，但它并没有去保证通过检查的代码一定是可以正确运行的。可能一个变量在 TypeScript 的类型声明中是一个数字，但并不能阻止它在运行时变成一个字符串 —— 可能是使用了强制类型转换或使用了其他非 TypeScript 的库且类型定义文件有误。

在 TypeScript 中你可以将类型设置为 any 来绕过几乎所有检查，或者用 as 来强制「转换」类型，当然就像前面提到的那样，这里转换的仅仅是 TypeScript 在编译阶段的类型标注，并不会改变运行时的类型。虽然 TypeScript 设计上要去支持 JavaScript 的所有范式，但难免有一些极端的用例无法覆盖到，这时如何使用 any 就非常考验开发者的经验了。

编程语言的类型系统总是需要在灵活和复杂、简单和死板之间做出权衡，TypeScript 则给出了一个完全不同的答案 —— 将编译期的检查和运行时的行为分别看待。这是 TypeScript 饱受争议的一点，有人认为这样非常没有安全感，即使通过了编译期检查在运行时依然有可能得到错误的类型，也有人认为 这是一个非常切合工程实际的选择 —— 你可以用 any 来跳过类型检查，添加一些过于复杂或无法实现的代码，虽然这破坏了类型安全，但确实又解决了问题。

那么这种仅仅工作在编译阶段类型检查有意义么？我认为当然是有的，毕竟 JavaScript 已经提供了足够使用的运行时行为，而且要保持与 JavaScript 的互操作性。大家需要的只是 TypeScript 的类型检查来提高开发效率，除了编译阶段的检查来尽早发现错误以外，TypeScript 的类型信息也可以给编辑器（IDE）非常准确的补全建议。

与 JavaScript 代码一起工作

任何基于 JavaScript 的技术都要去解决和标准 JavaScript 代码的互操作性 —— TypeScript 不可能创造出一个平行与 JavaScript 的世界，它必须依赖社区中已有的数十万的 JavaScript 包。

因此 TypeScript 引入了一种类型描述文件，允许社区为 JavaScript 编写类型描述文件，来让用到它们的代码可以得到 TypeScript 的类型检查。

描述文件的确是 TypeScript 开发中最大的痛点，毕竟只有当找全了定义文件之后，才会有流畅的开发体验。在开发的过程中不可避免地会用到一些特定领域的、小众的库，这时就必须要去考虑这个库是否有定义文件、定义文件的质量如何、是否需要自己为其编写定义文件。对于不涉及复杂泛型的库来说，写定义文件并不会花太多时间，你也只需要给自己用到的接口写定义，但终究是一个分心的点。

小结

TypeScript 有着先进的类型系统，而且这个先进并不是「学术」意义上的先进，而是「工程」意义上的先进，能够切实地提高开发效率，减轻动态类型的心理负担，提前发现错误。所以在此建议所有的 JavaScript 开发者都了解和尝试一下 TypeScript，对于 JavaScript 的开发者来说，TypeScript 的入门成本非常低。

在 LeanCloud，控制台在最近的一次的重构中切换到了 TypeScript，提高了前端项目的工程化水平，让代码可以被长时间地维护下去。同时我们一部分既有的基于 Node.js 的后端项目也在切换到 TypeScript。

LeanCloud 的一些内部工具和边缘服务也会优先考虑 TypeScript，较低的学习成本（谁没写过几行 JavaScript 呀！）、静态类型检查和优秀的 IDE 支持，极大地降低了新同事参与不熟悉或长时间无人维护的项目的门槛，提高大家改进内部工具的积极性。

LeanCloud 的 JavaScript SDK、Node SDK 和 Play SDK 都添加了 TypeScript 的定义文件（并且打算在之后的版本中使用 TypeScript 改写），让使用 LeanCloud 的开发者可以在 TypeScript 中使用 SDK，即使不用 TypeScript，定义文件也可以帮助编辑器来改进代码补全和类型提示。

如果你也希望一起来完善这些项目，可以了解一下在 LeanCloud 的 工作机会。

参考资料：

• TypeScript Evolution
• TypeScript Deep Dive（中文版）
• TypeScript Design Goals
• The TypeScript Handbook
• 浅谈 TypeScript 类型系统
• TypeScript类型元编程：实现8位数的算术运算
• 编程的智慧（正确处理 null 指针）
• The worst mistake of computer science（中文版）

]]> https://jysperm.me/2020/06/typescript-reinvent-javascript/ 2020-06-09T17:00:00.000Z

作为一个 Node.js 开发者，我很早便了解到了 TypeScript，但又因为我对 CoffeeScript 的喜爱，直到 2016 年才试用了一下 TypeScript，但当时对它的学习并不深入，直到最近又在工作中用 TypeScript 开发了两个后端项目，对 Ty]]>

2023-12-06T12:33:18.000Z 王子亭 jysperm@gmail.com 我从小一直生活在湿度很低的北方，常年鼻子和咽喉不舒服，经常流鼻血，但因为从小如此，也没觉得有什么不对劲。而来到苏州之后，我就觉得苏州湿润的空气真是好呀，鼻炎和咽炎的症状几乎没有了。但等到冬天开空调的时候就觉得无法再回到那么干燥的环境了，于是开始疯狂地买加湿器，这么多年下来，应该买过差不多十个加湿器了。

加湿原理

超声波 加湿器使用超声波将水打散成为非常小的小液滴，然后用风扇吹出，小水珠通常会在落地之前蒸发为水蒸汽，溶解至空气中。超声波加湿器是使用最普遍、价格最低、同价位加湿量最大的加湿器类型。其主要缺点是超声波会将水中的固体颗粒物和溶解物一起吹出，且容易有颗粒较大的液滴未能在落地之前完全溶解到空气中。虽说超声波加湿器被认为并没有耗材，但实际上其核心组件雾化片的寿命只有两年左右，且难以更换。

冷蒸发 加湿器使用风扇将空气吹过吸水的多孔材料，加速水的蒸发。冷蒸发是近一段时间中被高端的加湿器所采用的技术，不会有固体颗粒物进入空气，加湿量随湿度变化有一定自我调节的能力。其主要缺点是单位价格加湿量较低（且加湿量和噪音成正比），用于吸水的多孔材料作为耗材需要定时更换。

热蒸发 加湿器简单地通过加热水来产生水蒸汽。热蒸发加湿量较大（和功率成正比），同样没有固体颗粒物进入空气。其主要缺点是耗电较多，会增加室内温度（冬天倒是不要紧），且高温蒸汽遇到低温物体会产生水珠凝结。

类型	价格	水珠凝结	耗电	耗材和使用寿命	固体颗粒物	加湿量(同价位)
超声波	低	有	低	无耗材 寿命短	有	高
冷蒸发	高	无	低	有耗材	无	低
热蒸发	中等	有	高	无耗材	无	中等

在加湿原理上面我觉得很难一概而论，需要具体情况具体分析。但如果你不知道怎么选的话，可以先买个性价比最高的超声波加湿器试试看。

湿度

我们通常说的湿度其实是指相对湿度，即相对于当前空气中能溶解水蒸汽的最大量来说的湿度。人在不同的温度下对于同一相对湿度的感受是完全不同的，在 28 度下 40% 的相对湿度会比较舒适，而在 22 度下则需要 60% 的相对湿度才能达到相同的感受。

于是我找到了一个单一指标来衡量体感湿度 —— 露点，露点描述的是在当前温度和相对湿度的条件下，空气中的水蒸汽遇到多冷的物体时会凝结成小水珠，综合了温度、相对湿度和大气压力的影响。

对于我而言我觉得理想的露点是在 13 度左右，也就是我前面说的 28 度下 40%、22 度下 60%。如果你不像我这么喜欢湿润的空气，可以调低一点，例如 10 度左右。

加湿量

首先我们根据房间容积（这里以我家客厅 90 立方米计算）、目标温度和目标湿度来计算所需要的加湿量。我这里的计算并没有扣除家具所占用的空间，主要是考虑到家具本身（尤其是织物）也是会吸水的，所以综合考量下来不加也不减。

先计算不开空调和加湿器时的基准值，按室外温度 10 度，相对湿度 60% 计算，查表可得每立方米有 5.63g 的水蒸汽，总共就是 90m^2 * 5.63g = 506.7g，相当于我们房间里本来就有这么多水。

然后按照目标温度 24 度，目标露点 13 度，算出目标相对湿度是 50%，查表可得每立方米有 10.85g 的水蒸汽，总共就是 90m^2 * 10.85g = 976.5g，相当于我们的目标是房间里有这么多水。

这意味着我们需要补充差不多 500g 的水到空气中，但需要注意的是房间并不是密闭的，房间里的空气一直在和外界进行着交换，水蒸汽会流失到外界，也会在低温物体（如玻璃）上凝结为小水珠。以我个人的经验，如果你需要补充 500g 的水到空气中的话，那差不多你就需要一个加湿量 500ml/h 的加湿器 —— 相当于每小时房间里的水分都会流失掉一遍。如果加湿器的加湿量不够的话，就会出现即使一直开到最大，湿度也升不上去的情况。

500ml/h 已经算是加湿量比较大量的加湿器了，你需要考虑是使用多个加湿器还是单个加湿器。多个加湿器的话维护成本会比较高，你需要单独为每个加湿器加水、进行清洗和维护；单个加湿器的话则要考虑如何增加空气的对流，让整个房间保持相对均匀的湿度，例如冬天开空调的话，可以把加湿器放在空调可以直接吹到的地方。

功能

在购买加湿器的时候需要留意这些功能：

• 上加水 极大地提升了加水的便利性，直接关系到使用体验。
• 水箱 注意确认容量是否足够、水箱的形状是否容易清洗。
• 通电自动启动 有些加湿器在接通电源后还需要触摸按键才能启动，这样便无法与智能插座配合使用。
• 出雾高度和方向 出雾方向是否可调，这会影响加湿器放置的灵活性。
• 紫外线除菌 见后面「固体颗粒物」小节。

可有可无的功能：

• 红外线遥控 可以和智能家居组件配合使用。
• 指示灯 如果是放在卧室的话，需要确认指示灯的亮度以及是否可以关闭，否则可能关灯后会显得太亮。
• 智能控制 大多需要专门的应用，难以和既有的智能家居一同工作，不如用智能插座或红外遥控来解决。
• 恒湿 位于机器本体上的湿度传感器非常不准确，效果有限（尤其对于超声波加湿器）。

不太需要关注的功能：

• 静音 大多数超声波加湿器都没多大差别。
• 缺水保护 所有加湿器都有的功能。

没什么用的功能：

• 银离子 效果要比紫外线差很多，而且需要耗材。
• 净水滤芯 本来加的都是干净的水，没有必要过滤，而且需要耗材。
• 负离子 并没有可靠的资料表明这个功能有什么作用。

关于大雾量加湿器：

单个超声波雾化片可以提供 300ml/h - 400ml/h 的加湿量，再大的加湿量就需要考虑多个雾化片的加湿器了。

固体颗粒物

超声波加湿器会将水打成小液滴，这会导致家用的固体颗粒物传感器瞬间爆表，但实际上家用的传感器是无法区分小液滴和真正的固体颗粒物的，因此这个传感器的数值并不能说明有多少固体颗粒物进入到了空气中。

但我们仍有必要考虑微生物在加湿器内滋生并随着小液滴进入空气的情况，市场上目前有紫外线和银离子两种方案来解决这一问题。

经过我的调查，紫外线的除菌效果要远优于银离子，且不需要耗材：

• 紫外线被标注为「除菌」，而银离子被标注为「抑菌」
• 网络上一些细菌培养实验显示紫外线的除菌效果更好
• 高端的加湿器通常采用紫外线除菌

下一个问题就是加湿器中到底应该加什么水呢？

一派观点认为自来水中的余氯有助于减少加湿器中的细菌；另一派观点认为有条件加纯水当然应该加纯水，可以减少被超声波打入空气中的溶解物数量（尤其一些地区自来水的 TDS 非常高），也可以延长超声波雾化片、冷蒸发的多孔材料、热蒸发的电热管的使用寿命。

所以综合考虑，建议大家选择有紫外线除菌功能的加湿器，然后向加湿器中添加净水器产生的纯水来避免自来水中的溶解物进入空气。

参考资料

• 露点
• 相对湿度与露点对照表
• 相对湿度与绝对湿度对照表
• 器物于我：加湿器：超声波、蒸发和电热
• 爱否科技：加湿器选购全指南
• 老爸测评：从 100 到 4000的加湿器，谁才是性价比之王？

]]> https://jysperm.me/2020/02/buying-humidifier/ 2020-02-06T17:00:00.000Z

我从小一直生活在湿度很低的北方，常年鼻子和咽喉不舒服，经常流鼻血，但因为从小如此，也没觉得有什么不对劲。而来到苏州之后，我就觉得苏州湿润的空气真是好呀，鼻炎和咽炎的症状几乎没有了。但等到冬天开空调的时候就觉得无法再回到那么干燥的环境了，于是开始疯狂地买加湿器，这么多年下来，]]>

2023-12-06T12:33:18.000Z 王子亭 jysperm@gmail.com Redis 的工程价值

今年一开始先是完善了去年的 任务队列，为了让它真正地被用起来，我将之前由另外一个服务实现的定时任务系统也合并进了这个任务队列，让它有了一些固定的流量，以便我来发现性能上的问题，进一步完善它。

这项工作最后取得了还不错的效果，开始有了用户使用任务队列的功能。我也写了一篇文章来介绍 用 Redis 来实现定时任务，当然这篇文章中介绍的是一种经过极度简化的范式，实际上实际的代码要复杂的多，例如序列化、错误处理、结果查询、限流、统计等额外的特性。

这个项目让我再度增加了对 Redis 的好感，这次我用到了比较大量的 Lua Script 来保证分布式架构下的一致性（Redis 的Lua Script 会被独占地执行）。在将一致性需求限制到单个 Redis 实例可以容纳的范围（Redis 只使用一个线程）并且 Redis 运行相对稳定的情况（故障切换会丢失数据），Redis 为业务层提供了一个非常「够用」的高性能的、有一致性保证的数据同步方案。这并不是说 Redis 提供的方案有多么完美，而是在性能、功能、一致性、可靠性上提供了一个非常好的这种，更具有工程价值。

Golang 的表达能力

我还尝试了为 LeanCloud 写一个 Golang 的 SDK（后来因时间安排的关系暂停掉了，目前还未发布），就像之前我为 DeployBeta 写 ORM 一样，同样遇到了 Golang表达能力不足的问题。问题主要在于 Golang 中并没有能让 Struct 继承方法的机制（数据字段则可以通过内嵌匿名 Struct 的方式来继承）。

所以当用户定义一个「继承」自 ORM 基类的 Struct 时，我们无法向用户定义的 Struct 上添加例如 Save、Set 之类的方法，无法有效地追踪用户对于数据对象的改动。

经过几个版本的改动，我最后选择了一种将所有基本类型（string、int）包装为 Struct 的方案：

type Todo struct {  orm.ObjectMeta  Name     orm.String `orm:"name"`  Priority orm.Number `orm:"priority"`}todo := Todo{  Name:     orm.NewString("test"),  Priority: orm.NewNumber(1),}err = orm.Save(&todo)todo.Name.Set("test")todo.Priority.Incr(1)err = orm.Save(&todo)fmt.Println(todo.Name.Get(), todo.Priority.Get())

这个方案可以做到不以字符串的形式传递字段名（可以得到编译期的类型检查），可以追踪对每个字段进行的修改（包括 Incr 等运算）。我将 Set 添加到了基本类型的封装类型上，将 Save 作为了一个全局方法，避开了 Golang 对于继承的限制。带来的问题则是用户需要通过我们的封装方法（Get）来访问字段的值；同时今后设计嵌套对象时也需要更大的工作量。

所以并不是如 Golang 的支持者说的那样，更少的特性意味着更简单的设计。当业务逻辑确实复杂，语言表达能力又非常匮乏的情况下，会逼着开发者做出一些不优雅的、不易理解的、反常规的设计，这些代码往往非常容易出错（例如反射、代码生成、强制类型转换等），而本来这些需求（如继承）在其他语言里是可以非常轻易地解决的。

TypeScript 的胜利

之前因为对 CoffeeScript 的喜爱，我的 TypeScript 使用经验非常少，终于今年我也不得不去接受 TypeScript 了。今年我用 TypeScript 开发了两个新的后端项目，也更深入地学习了 TypeScript，经过进一步的了解，我逐渐地发现了 TypeScript 的闪光点，之后我会单独写一篇文章来介绍 TypeScript。

TypeScript 有着一个先进的类型系统，这种先进并非是学术意义上的先进，而是工程意义上的先进。它几乎可以为所有 JavaScript 中常见的范式添加静态约束，得益于强大的类型推导，在大部分情况下并不需要自己添加类型标注，但却能在编译期提前发现错误、配合 Language Server 得到准确的代码补全和类型提示信息，完全没有前面提到的 Golang 中的那种束缚感。

因为 TypeScript 并不打算创造新的范式，而是尽可能将 JavaScript 社区中已有的范式用静态类型的语义描述起来。这样最大程度上地降低了 JavaScript 开发者学习的成本，提高了与标准 JavaScript 代码的互操作性，我认为这也是 TypeScript 能够取得成功的关键。

同时我也不得不接受 Atom 的市场已经几乎完全被 VS Code 取代的现实，切换到了对 TypeScript 支持更好的 VS Code。现在想想 Atom 失败的原因一方面是在 CoffeeScript 已经表现出没落的时候选择了 CoffeeScript；另一方面是希望依靠社区的力量，但又缺乏对社区的引导。例如对于插件的 GUI 改动引导不够导致界面卡顿，对于代码补全、调试等常见需求没能建立统一的标准等等。

Kubernetes 的阴谋

今年其中一个新项目是开发一个数据库调度平台，在 Kubernetes 上运行数据库容器，这和我之前在 DeployBeta 实现的原型非常相似，只不过这次是真的要上线的项目。

在去年和今年对 Kubernetes 的了解过程中我逐渐对 Kubernetes 由粉转黑。我现在认为 Kubernetes 是以 Google 为首的三大云计算巨头的垄断工具，他们开发出了一个如此复杂的系统，并引导其作为行业标准。虽然 Kubernetes 是开源并由社区维护的，但真正能够独立搭建好 Kubernetes 及其插件的公司是极少数，甚至可以说除了三大巨头之外，其他的云计算公司都不能提供稳定可靠的 Kubernetes 集群。最后大家在尝试过自己搭建之后，还是不得不购买三大巨头的 Kubernetes 云，毕竟这是行业标准嘛。

今年看过觉得最好的书是「数据密集型应用系统设计（DDIA）」，它给我的数据库调度平台带来了很多启发。书中介绍了分布式架构对于数据库的挑战，包括数据模型、复制、分区、事务、分布式共识等等，以及各个数据库在面对这些挑战时采取的解决方案，只有理清这些思路，才能在面对复杂的业务的时候采用一种或几种合适的数据库。

我的理解是当数据存在于两台或更多的计算机之上时（原因可能是容量或可用性要求），就可以称作「大数据」了。因为从一台到两台是一个质的变化，而从两台到更多只不过是量的变化。就如书中所说，在单机条件下，所有的称作都是确定的，一个操作要么成功要么失败（可能伴随着程序或系统的崩溃）；但在分布式条件下，对于经过网络的操作会引入成功和失败之外的第三种情况 —— 网络延迟，你无法预测一个操作会在下一秒完成还是永远都不会完成。所以分布式系统需要被设计成可以在容忍一定的错误（部分失效）的情况下继续运行。无论是一个分布式数据库还是一个分布式的容器平台，其实都在与这种不确定性的超时进行对抗。

写不下去的业余项目

现在我愈发认识到软件开发不是一个人的单打独斗，之前在做一些业余项目的时候还会有一些幻想，幻想自己能长期维护下去、能吸引到其他的贡献者、能建立起一个社区。但现在想想还是以内容作为主要的输出更有可行性。同时因为我对现在的工作非常满意，在工作中基本完全满足了我对于写代码和团队协作的欲望，所以我可以将业余时间放在其他的输出形式上，在接下来一年中输出更多的文章或视频，这样我的经验和知识会给读者带来更大的价值。

]]> https://jysperm.me/2020/01/programming-of-2019/ 2020-01-30T17:00:00.000Z

Redis 的工程价值

今年一开始先是完善了去年的 转眼又一年过去了，今年我将更多的时间放在了除了编程之外其他的业余爱好上面，例如太空探索、开车、乐高、视频拍摄和剪辑、无人机、游戏、记账等等。

在今年年初和蛋黄一起去 体验了一次游轮 —— 一种不需要做计划、自助吃喝、走几步路就可以回到室内、再多走几步就能回到房间的「佛系旅行项目」，不喜欢出门的蛋黄对此表示非常满意。

在 2018 年末我和蛋黄一起报名了驾校，在 6 月拿到驾照的当天，我们就租了一辆共享汽车上路了，然后第二天就开去了上海，第三天就出了一次不大不小的事故 —— 蛋黄开着车误上了上海的高速路，在下闸道时减速不及撞到了护栏。

在驾驶生涯的初期遇到这样一个不大不小的事故其实也算是一种幸运，可以让我们更直接地认识到驾驶本身的危险性、提高安全意识，避免之后更严重的事故。

在之后的半年里我们也经常开着共享汽车出去玩，加起来可能开了两、三千公里的样子，不过大多还是短途，最远也就是苏州和上海。目前我的驾驶经验绝大部分是在电动汽车上，想想我可能算是第一代直接接触电动车的驾驶者了。我们今年还去了南京、大连和沈阳，我们都分别在目的地租了车，以一种不同于以往的方式在其他城市旅行。

确实掌握了开车这项技能之后就像打开了新世界大门，占据了城市大量面积的公共道路其实是为汽车而设计的，坐在驾驶位去看到道路的设计、道路上的标识标线，有一种完全不同的感受。也认识到了汽车确实是最伟大的发明之一，极大地拓展了人类的活动空间、活动的自由性。

今年比之前投入了更多的时间在游戏上面，首先是年初突然发现我曾在 Steam 中买过一个叫坎巴拉太空计划的游戏，恰逢当时对 太空探索 重拾兴趣，于是便一发不可收拾，目前已成为我 Steam 上游戏时间第二的游戏。

在 2017 年我曾从朋友那里借过一台 Switch，但因为他并非任天堂粉丝，机器里也仅有一款任天堂的游戏，所以当时并没有对 Switch 产生兴趣。今年我开始在一些游戏相关的自媒体了解到业界对于任天堂极高的评价，于是在 8 月时入手了一台 Switch，接触到了 赛尔达传说：旷野之息、马里欧：奥德赛、喷射战士 2、健身环大冒险这样的任天堂第一方游戏，这些游戏的设计和制作水平让我完全成为了任天堂的粉丝，不由得有一种过去十几年的游戏都白玩了的感觉。

在今年一月时我决定用复式记账的方式记一年的帐，来和 2016 年的年度支出分析 做一个比较。复式记账用账户之间款项的转移代替了单纯的支出流水帐，可以更好地体现投资、货币兑换，也可以更好地进行回溯和纠错。

但因为现在我和蛋黄的支出都是混在一起的，所以需要连着她的帐目一起记，否则这个账就没什么意义了。因此每次记账我都需要去翻她的交易记录，确认一些款项，导致记账这件事情经常拖延很久，到现在也只把帐目清理到了今年 7 月。后面我会尽力把这一整年的帐目整理完，来写一篇日志，但之后可能就不会再这样记完整的账目了，可能会考虑退回之前每个月记录一次个账户快照的方式。

在今年中，偶尔几次会有一种通过视频来记录和展示生活中有趣的瞬间的冲动。我用去年买的小蚁微单和今年买的无人机拍摄了不少素材，也录制了一些游戏实况，做了一些尝试，但实际的产出的视频很少。

• 我的 Bilibili 帐号
• 我的 Youtube 帐号

和文字内容不同，视频的拍摄是不能轻易重来的，需要后期将素材剪辑成作品。而且和之前我录制的播客相比，视频的素材要更加非线性，剪播客更多的是将「不想要的部分剪掉」，而剪视频则是「将想要的部分挑出来」，后者的难度要高出不少。

同时视频的制作对设备的要求也更高，不过我想着还是不要一下子买太多设备，不如每产出几个视频就升级一样设备，这样可能会让我的视频播主之路变得更有趣，有一种逐渐升级的感觉。

皮蛋豆腐还是一如既往。

]]> https://jysperm.me/2019/12/summary-of-2019/ 2019-12-30T17:00:00.000Z

转眼又一年过去了，今年我将更多的时间放在了除了编程之外其他的业余爱好上面，例如太空探索、开车、乐高、视频拍摄和剪辑、无人机、游戏、记账等等。

在今年年初和蛋黄一起去 又一年过去了，已经 24 岁了，最近两年我已经有些感觉到了时间的流逝。大概人对时间流逝的感觉是基于已经度过的时间吧 —— 同样的一年在 16 岁时是经历过人生的 1/16，而现在的一年则只是 1/23。这就开始让我在很多事情上有一种「会不会太晚了」的焦虑，尤其今年移民的进程并不顺利，之前觉得自己年龄小的优势可能会越来越小。

最近两年学习和输出的节奏也慢了一些，休息时间更多地选择看视频来放松，表达欲望也比之前下降了不少。偶尔会有一些灵感，但大多没能写完，都积压在了草稿箱中，博客快要变成年更了。这当然不是一个好现象，我还是希望能花更多的时间做一些输出。今年我决定减少在业余时间对于写代码的投入，不去造一些很可能没有什么后续的轮子了。而是花更多的时间在写文章，包括技术文章上，这样能帮助到更多人，我也会得到更直接的反馈。

虽然去年和蛋黄的那次比较大的矛盾在年初就结束了，但对我一整年的心态的影响还是很大，有些患得患失，对我们的未来有点迷茫，或者说觉得未来是很遥远的事情，就想维持现有的状态。就像人们觉得 35 岁之后诞生的科技都是违反自然规律的，现在想想我们互相对于在一起之前或刚在一起时就已经暴露出来的差异，就更容易互相接受；但对于之后才暴露出来的差异则非常难以互相理解。

蛋黄在年初就说要学习编程并希望直接去找编程相关的工作，一年里她也断断续续、三天打渔两头晒网地学，但进度实在太慢了，也没有什么阶段性的进展，还不愿意听我的建议。所以我还是对她的工作和学习能力有一些担忧、担心她能够找到合适的工作，也担心之前完全交给她的移民的事情是否做出了正确的决策。如果没有的话，其实包括学习编程和移民，都是在坚持一个结果非常渺茫的事情，这种感觉让我非常焦虑。

]]> https://jysperm.me/2019/11/thinking-about-my-23/ 2019-11-24T17:00:00.000Z

又一年过去了，已经 24 岁了，最近两年我已经有些感觉到了时间的流逝。大概人对时间流逝的感觉是基于已经度过的时间吧 —— 同样的一年在 16 岁时是经历过人生的 1/16，而现在的一年则只是 1/23。这就开始让我在很多事情上有一种「会不会太晚了」的焦虑]]>

2023-12-06T12:33:18.000Z 王子亭 jysperm@gmail.com 开门见山地说，「塞尔达传说：旷野之息」是我玩过最好的 RPG（角色扮演）游戏，可能也是目前最好玩的开放世界、动作解密类的 RPG 游戏。我在八月初买了 Switch 和旷野之息之后，几乎每天晚上、每个周末都在玩，上班也要带着午休的时候玩，出门也要带着边走边玩。目前的游戏时间超过 160 小时，我觉得就算买来 Switch 只用来玩旷野之息，也值了。

对一个事物最好的评价应该是「恰到好处」，旷野之息就是这样一个恰到好处的游戏，很难说它有什么地方是最好的，但就是各种恰到好处的取舍，让它营造出了一个有着充分的代入感的世界，成为了最好玩的游戏。

旷野之息选择了一种类似赛璐珞的风格来渲染 3D 模型，带来了一种非常特殊的、类似水彩画的视觉风格。旷野之息在掌机模式下是 720p 30 帧，TV 模式下是 960p 30 帧，只能说是一个中规中矩的数据，不如同时期游戏在我的 Windows PC 上的效果。实际游玩过程中在极少数光影比较复杂的雨林场景会有明显的掉帧，其他的时候都非常流畅。

探索开放世界

旷野之息首先给我带来的就是「探索」的乐趣，我在开始玩旷野之息之前并没有看太多的测评，在打开游戏时其实我对这个「世界」一无所知（尤其塞尔达传说是一个系列作品），但好在本作的主角也失去了记忆，同样对这个世界一无所知，我随着主角的视角探索着这个世界，了解之前发生过的事情，经历着很多个「第一次」，体验着很久都没有过的、有关发现的乐趣。

如果你准备在近期游玩旷野之息，并且想充分体验这种「探索」的乐趣，那么建议你关掉这篇文章，在完成主线剧情之前不要看任何的测评、教程和攻略。 如果你不打算在近期游玩的话，还是可以继续看的，毕竟在一段时间后你的记忆就会模糊掉，不至于太严重地影响探索的乐趣。

有一个说法是，「开放世界」的重点不在于「开放」而在于「世界」。只有构建了一个能够让玩家产生代入感的世界，玩家才会感觉到开放，感觉自己可以在这个世界中获得自由。

旷野之息便做到了这一点，它有着一个非常大的无缝地图，据网友测算面积大概在 40 - 80 平方公里左右，其中有平原、湿地、火山、雪山、沙漠、峡谷等地形，因为面积足够大，这些地形之间的过渡也非常自然。更关键的是，这几十平方公里的地图是经过精心设计的，而不是随意摆放或随机生成的，地图的每一个角落都恰到好处地安排了可以互动的元素，可以是一个有趣的景观，一个驿站、一个村落、一个怪物营地、一个解谜任务，或是一个可收集要素。

旷野之息赋予了主角攀爬、滑翔、游泳的能力，因此这个巨大的地图对于玩家来说并不是平面的，而是立体的，玩家可以先攀爬到高处，再通过滑翔越过低处的障碍等等。地形会阻挡或引导玩家的视线，从地图上的一个点到另外一个点不再是一条直线，每一条路线上都会有不同的体验。

图为从山上远眺海拉鲁平原

当你想要探索一个地区的时候，也会非常自然地先登上高处 —— 这是我第一次在游戏中产生这么直观的念头，也是我第一次在一个游戏里认真地俯瞰远处的事物，因为我知道视线所及的一些都是可探索的，我早晚有一天会去到那里，而不仅仅是一张贴图。前面提到的攀爬、滑翔和游泳都会用到一个「精力值」，用尽的话就会从山上跌落，所以还是要谨慎地在登山过程中寻找落脚点来休息。

游戏中的主线和支线任务会引导你去探索地图，所有的故事也围绕着这个地图展开。同时在游玩的过程中你也会有一种内在的动力，想要去走遍地图的每个区域。只有这样一个足够庞大和丰富的世界，才会让玩家感受到这是一个完整的世界，而不是自己被局限在某个小区域。再加上天气和昼夜的变化，在不同的时间和天气，来到同一个地方，观感是完全不同的，这在扩充了游戏内容的同时也进一步提升了代入感。

图为第一次遇到的龙，非常震撼

我们不提人物、剧情、战斗，仅仅这个地图就值得说这么多，实际上我觉得旷野之息的要素完全是基于这张地图展开的。旷野之息并不是要复刻一个「真实」的世界（例如 GTA），而是要在其中去填充有趣的细节，给玩家带来一种经过了精心设计的探索体验。

非线性流程

因为开放世界的缘故，旷野之息的剧情是非线性的，玩家可以自由选择完成主线和支线任务的顺序。当然游戏并不会把这些任务摆出来给你选，所以其实是很随机地，你走到了哪里就遇到了什么样的任务。这样的设定造成每个玩家的体验是完全不同的，每个玩家完成每个任务、第一次遇到某个事物的顺序都是不同的，每个玩家觉得有趣和困难的点也不同。

游戏一开始就告诉你了反派盖农就在城堡里，你需要去城堡里救公主。而其余大部分的剧情都是非常直接地在为这个目标服务，例如有若干段回忆（CG）告诉你一百年前发生的事情，另外一部分有关四大神兽的主线任务则是为击败盖农所做的准备。这样的设计让玩家在探索世界的过程中不至于失去目标，因为你知道你做的一切都是在积蓄力量，等待着有朝一日去城堡战胜盖农，救出公主，拯救世界。城堡位于地图的中央，在整个游戏的过程中你一直都能看得到城堡，记得自己的目标。

图为远处的海拉鲁城堡

不同于其他一些 RPG 游戏，旷野之息中并没有经验、等级和技能树这样的机制来大幅提升主角的能力；防具系统也较为简单，只能增加防御和提供一些特殊效果；完成的神庙数量会增加血量和精力槽（限制攀爬、游泳和滑翔续航）。

在此之外，游戏并没有限制你在什么样的阶段可以去挑战什么样的敌人。你在游戏的过程中可以感受到更大程度上是因为你的技术的提升（或者说对游戏机制的了解），你才能够逐步地去挑战更强大的敌人。除了一开始的初始台地之外，游戏也没有限制你在什么样的阶段可以去到地图的哪个区域，在非常早的阶段，你就获得了去到地图上任意一点、甚至跳过剧情直接挑战最终 Boss 的能力。

图为进入城堡挑战盖农之前

图为赛尔达公主封印盖农

相比于其他一些游戏中手把手地、较为出戏的「新手教程」，旷野之息将所有的引导都放在了游戏流程中。一部分内容会通过不那么显眼的 NPC 对话来交待，另外一部分则可能完全没有介绍，而是将你放到一个较为封闭的环境中，然后等待你自己去摸索发现新机制的用法，然后再逐渐地增加难度、与其他机制进行组合。

1 + 1 > 2 的互动机制

旷野之息的互动机制，包括和怪物的互动（战斗）、和环境的互动（探索）、和谜题机关的互动（解谜）都显得精简而完备，更注重将不同的元素加以组合，用少量的机制来支持多样的玩法，而不是简单地堆砌。

游戏中没有复杂的战斗技能，魔法效果也仅有三种：冰、火、电。但无论是武器、怪物还是环境都会和这三种基本属性发生互动。

• 冰可以可以被火融化、拿着冰属性的武器可以抵御炎热、冰属性的武器可以冻结敌人。
• 火会产生上升气流吹起滑翔伞、火可以抵御寒冷、火可以点燃草、篝火或者敌人、烘烤食物。
• 电可以在水中传导更远、金属物体可以导电、雷属性的武器可以麻痹目标令其手持的武器掉落。

图为使用篝火来融化冰块

游戏中还有温度、天气和日夜变换，这些效果不仅仅在影响着视觉效果，也在非常积极地参与游戏机制：

• 玩家需要穿戴对应抗性的防具来抵御过高或者过低的温度，过高的温度会烤熟食物、点燃木质武器；过低的温度则会冷冻食物。
• 雨会浇灭火、会让岩壁变得湿滑难以攀爬；金属物体在雷雨天会被雷劈。
• 风会影响草燃烧的方向、可以吹走物品、滑翔伞会沿着风的方向滑行。
• 夜晚会出现骷髅构成的敌人、萤火虫等生物；NPC 和怪物在夜晚也会睡觉；晚上会有陨石（流星）掉落；昼夜变换也会影响沙漠地区的温度。

总之这些机制以一种「合乎逻辑」的方式在产生着互相作用，也在影响你游戏时的行为，你会做出一些非常符合逻辑的行为，进一步提升代入感。例如在下雨时因为难以攀爬、能见度不高，你会想要找个地方避雨，点燃篝火来消磨时间；在身上着火的时候会想要跳入水中灭火等等。

这样的组合机制会让玩家非常积极地去尝试新的互动类型，同时旷野之息的死亡惩罚也非常地低，游戏允许在任何时刻暂停来更换武器和防具、服用料理和药物，在除 Boss 战的任何时候传送和存档，死亡不会掉落任何物品或携带负面效果，非战斗死亡（摔死、溺水）自动在最近的安全地点复活。

战斗、解谜和其他

这个世界是如此地吸引我，以至于同样非常吸引人的战斗和解谜被我放在了最后来介绍。

游戏的战斗和解密共用了一套物理引擎，它支持了前面提到的冰、火、电、风等互动效果，也支持了炸弹、磁铁、冰块、时间暂停这几个有限的解谜技能。这意味着游戏中并不存在明确的「战斗技能」和「解谜技能」的区分，你可以用磁铁吸起铁块来砸死怪物，也可以用电属性的武器来点亮解密关卡中的电路。

虽然前面提到游戏的要素十分精简，怪物仅有十几种模型，但战斗的流畅性和打击感却意外地好，可以锁定视角、可以潜行暗杀、可以蓄力和跳劈、可以投掷、可以弹反、可以骑马战斗、在飞行中拉弓可以触发「林克时间」—— 放慢时间来提供更多瞄准的时间。同时旷野之息中有弓箭、单手剑、双手剑、枪等不同类型的武器，种类多但不重复。这些机制的组合让旷野之息即使作为一个刷怪的游戏也相当有可玩性。

图为使用弓箭射击守护者

旷野之息有一个很有趣的设定，武器是有耐久度的，且耗尽会直接消失，无法修复。这意味着无论多厉害的武器，大概在砍了几十下之后便会消失。虽然有些朋友表示非常不舒服，但我觉得一旦接受了这种设定就会感觉到这是一个很好的设计：鼓励玩家尝试不同的武器，而不是一直用着「最好的武器」；同时后期打小怪时也不会那么无聊 —— 我通常是用比较差一点的武器打小怪。

因为旷野之息的地图如此之大，虽然可以随时传送，但仍有时候需要借助载具来赶路，不算 DLC 中的摩托车的话，唯一可用的载具就是马。而马这个系统的设计也非常地下功夫，和其他的游戏内容很好地结合在了一起，例如游戏中有 15 个以寄存马匹为核心服务的驿站，顺便也承担了其他一些补给功能。

马匹需要你自己去捕捉，在捕捉到马匹之后还要经过一段时间的磨合来达到最好的操控效果。在地图中有比较明显的「道路」你在骑马的时候会有意识地沿着道路来走 —— 否则马跨越障碍的能力是很差的，游戏中刻意模拟了一种「操纵另外一个生物」的感觉，让你感觉到马并不是万能的，但在有条件的时候你一定会想到它。

DLC

在完成主线任务（讨伐盖农）之前我就买了 DLC，作为一个统计爱好者，主要还是看是看中了可以在大地图上显示轨迹的功能：

DLC 中的剑之试炼和英杰的诗篇是在完成主线后开始打的，总体上来说我对这两个 DLC 并不感兴趣，原因是这两个 DLC 都以解密和限制性的战斗关卡为主，相比于游戏本体难度也有提升，但并没有给我带来探索的乐趣，截至本文发布我还未完成剑之试炼。

小结

旷野之息就是这样一个可以称之为艺术品的游戏，它恰到好处地营造了一个让你有着充分的代入感的世界，也提供了充实的游戏内容，可以轻松支持 200 小时左右的游戏时间。本文也仅仅是从我的个人的角度介绍了最吸引我的部分，但仍有大量的游戏机制和内容并没有提到，在此推荐所有读者尝试一下这款游戏。

]]> https://jysperm.me/2019/10/zelda-breath-of-the-wild/ 2019-10-26T17:00:00.000Z

开门见山地说，「塞尔达传说：旷野之息」是我玩过最好的 RPG（角色扮演）游戏]]>

2026-05-01T15:13:06.182Z 王子亭 jysperm@gmail.com 这篇文章会带领大家实现一个基于 Redis 的分布式高可用定时任务系统，其中的 worker 以 Node.js 为例，但其实可以使用任何语言来实现。这篇文章不会给出完整的代码，更侧重于探索的过程。

高可用设计

首先我们希望让 worker 是无状态的，这样会大幅减少对于 worker 的高可用需求，也不涉及到 worker 之间的数据同步或者选举。我们将所有的状态集中到 Redis 上，Redis 可以用 Master-Slave + Sentinel 的方式达到一个相对较高的可用性。

为什么不使用选举 Master 的方式？

有一种很常见的做法是在单个实例上完成所有的工作，这样甚至连 Redis 都不需要了。但为了保证高可用，往往会同时启动多个实例，然后引入一个「选举」的过程来决定谁是那个完成所有工作的人（称为 master），在 master 失效后，则需要重新进行选举，选出另外一个 master。

简单来说我觉得这种做法不够「分布式」，只有一个 master 在工作，其他实例只是热备而已，同时选举和对 master 失效的监测也是一个非常麻烦的事情。而在我们的方案中所有的 worker 都是平等的，都在执行任务，可以在任意时候创建或移除 worker。

核心循环

对于一个定时任务系统来说，核心的工作是给定时任务们按时间排序，然后找到并等待下一个需要触发的任务。Redis 刚好为我们提供了 ZSET 这种支持排序的集合类型，ZSET 中存储着若干个互不相同的 member（字符串或二进制数据），每个 member 有一个相关联的 score（数字），整个 ZSET 会按照 score 排序，基于这样的数据结构提供了若干操作。

我们将定时任务的 ID 作为 member 放在一个叫 cronjobs 的 ZSET 里，使用下次触发时间作为 score 来排序，这样便得到了一个以下次触发时间排序的列表。

我们可以这样向系统中添加任务：

1	redisClient.zadd('cronjobs', nextTriggerAt(cronjobId), cronjobId)

用 ZRANGE cronjobs 0 -1 WITHSCORES 可以看到已添加的任务：

1 2 3 4 5

127.0.0.1:6379> ZRANGE cronjobs 0 -1 WITHSCORES 1) "2" 2) "1565453967832" 3) "1" 4) "1565453998742"

然后我们可以在 worker 中写一个无限循环，不断地检查这个 ZSET 中 score 最小（触发时间最早）的任务是否已经超过了当前时间，如果是的话就执行这个任务，并修改 ZSET 中的 score 为下次触发时间，Node.js 的代码如下：

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

while (true) { const [cronjobId, triggerAt] = await redisClient.zrange('cronjobs', 0, 0, 'WITHSCORES') if (parseInt(triggerAt) < Date.now()) { // ZADD CH 会返回被修改 member 数量，只有当成功修改了 score 我们才会继续执行，否则说明这个任务已经被其他的 worker 执行了 if (await redisClient.zadd('cronjobs', 'CH', nextTriggerAt(cronjobId), cronjobId)) { // 异步地运行任务，避免「阻塞」核心循环 runJob(cronjobId) } } else { // 等待下一个任务触发，如果距离下一个任务的触发少于 10 秒，则等待下一个任务执行，否则等待 10 秒后重试。 await bluebird.delay(triggerAt ? Math.min(parseInt(triggerAt) - Date.now(), 10000) : 10000) } }

上面的循环构成了这个定时任务系统最核心的部分，后面我们会逐渐地完善他。

为什么不用 Keyspace Notifications?

在社区中有很多文章推荐简单地使用 Keyspace Notifications 来实现「定时」，即为一个 key 设置一个过期时间，然后订阅这个 key 过期的事件。但这种方式主要的问题是 Redis 的 Pub/Sub 并不保证送达，如果刚好在这个 key 过期时 worker 不在线，那么这一次触发就不会生效；如果刚好有多个 worker 在线，那么这一次触发的任务也可能被执行多次。

而我们选择的基于 ZSET 的方式，需要 worker 主动修改 ZSET 中的下次触发时间，即使 worker 暂时不可用，在恢复时也会继续执行之前剩余的任务。

这样 Redis 就变成了系统的单点？

是这样的，这个系统中几乎全部的状态都存储于 Redis 上，可以说是系统中的单点。但相比于 worker，Redis（或其他的数据库）是一个更稳定、更标准化的组件。你可以用官方的 Master-Slave + Sentinel 方案来达到一个相对较高的可用性，你也可以使用由云服务厂商提供的托管 Redis 产品，避免自己来维护它。

继续完善

CRON 表达式

前面的代码中我们并没有实现 nextTriggerAt，你可以用 cron-parser 这样的库去解析 CRON 表达式，计算下次触发时间：

1 2 3 4 5 6 7

const cronParser = require('cron-parser') async function nextTriggerAt(cronjobId) { // 从 Redis 或其他数据库中根据 cronjobId 拉取定时任务的详情 const cronjobInfo = await getCronjobInfo(cronjobId) return cronParser.parseExpression(cronjobInfo.cron).next().getTime() }

中断任务处理

如果一个 Worker 意外退出，那么当时正在被它处理的所有任务都会永久性地丢失。为了避免这种情况，我们将正在执行的任务也存储到 Redis 中（一个叫 running 的 ZSET）：

1 2 3 4 5 6 7 8 9

if (await redisClient.zadd('cronjobs', 'CH', nextTriggerAt(cronjobId), cronjobId)) { // 为每个任务生成一个随机的 uuid 以便能单独地追踪每个任务，例如打印到日志中 await redisClient.zadd('running', Date.now() + 60000, `${cronjobId}:${uuid.v4()}`) runJob(cronjobId).finally( () => { // 在一个任务被完成时，我们还需要将它从 running 集合中取出 redisClient.zrem('running', uniqueId) }) }

如果你有一些为多实例应用编写代码的经验，那么可能会注意到这里存在一个竞态条件：对 cronjobs 和 running 的操作并不是原子的，可能会出现对 cronjobs 的操作成功了，随即 worker 意外退出，没有来得及写入 running 的情况。

因为这里我们需要对 ZADD 的返回值做判断，所以不能简单地使用 Redis 的 Pipeline 功能，而是要用到 Lua Script：

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

redisClient.defineCommand('startJob', { lua: ` local cronjobId = ARGV[1] local jobName = ARGV[2] local nextTriggerAt = tonumber(ARGV[3]) local timeoutAt = tonumber(ARGV[4]) local changed = redis.call('ZADD', 'cronjobs', 'CH', nextTriggerAt, cronjobId) if changed ~= 0 then redis.call('ZADD', 'running', timeoutAt, jobName) end return changed ` })

经过修改后的核心循环：

1 2 3 4 5 6 7

const jobName = `${cronjobId}:${uuid.v4()}` if (await redisClient.startJob(cronjobId, jobName, nextTriggerAt(cronjobId), Date.now() + 60000)) { runJob(cronjobId).finally( () => { redisClient.zrem('running', uniqueId) }) }

然后我们便可以添加另外一个循环，从 running 中拉取已经超时的任务进行重试或其他处理，这里不再给出具体的代码。

Lua Script

Lua Script 是 Redis 提供的一种类似事务能力，Redis 保证每个 Lua Script 都是串行执行的，中途不会有其他指令被执行，这提供了一种非常强的一致性保证。在实际的开发中，我们可以将需要一致性保证的逻辑写成 Lua Script。

平滑关闭

我们不可避免地会对 worker 进程进行新版本的部署或其他维护，因此我们需要一种平滑的方式来关闭 worker 进程，让它继续执行已经收到的任务，但不去接受新的任务，在执行完当前的任务之后，主动退出。

在 Unix 中最正统的方式是实现自定义的 SIGINT 处理器来实现这个功能，即由终端模拟器、进程管理器或容器平台向程序发送 SIGINT 信号，程序即开始进行退出前的清理工作，然后待清理工作结束后，程序主动退出。当然进程管理器也有可能等不及，再发送一个强制结束的 SIGKILL。

所以我们需要将所有正在执行的任务注册到一个全局的 Promise 数组中，然后在受到 SIGINT 时停止接受新任务，并等待所有正在执行的任务完成后主动退出：

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

let runningJobs = [] let shuttingDown = false process.on('SIGTERM', () => { shuttingDown = true // 等待 runningJobs 中所有的任务完成，无论成功还是失败 Promise.all(runningJobs.map( p => p.catch(() => {}) )).then( () => { process.exit(0) }) })

修改核心循环，在开始任务时将 runJob 返回的 Promise 存入 runningJobs，然后在任务执行完时取出：

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

while (true) { if (shuttingDown) { break } // ... if (await redisClient.zadd('cronjobs', 'CH', nextTriggerAt(cronjobId), cronjobId)) { // 异步地运行任务，避免「阻塞」核心循环 const jobPromise = runJob(cronjobId) jobPromise.finally( () => { _.pull(runningJobs, jobPromise) )) runningJobs.push(jobPromise) } // ... }

容量的横向拓展

目前这个定时任务系统中的 worker 是可以无限拓展的，但 Redis 却是整个系统中的瓶颈，每个 worker 都需要从 Redis 获取任务来执行。按照我们对于 Redis 通常 70k QPS 的估计，按每个任务需要执行 5 个命令计算，整个系统可以支持每秒 14k 次任务触发，对于绝大部分的场景其实完全够用了。

如果要继续拓展的话，我的建议是根据业务上的一些区分（例如用户、任务类型）将队列分散到不同的 Key 上面（例如 userA:cronjobs 和 userB:cornjobs），这样便可以利用 Redis Cluster 的分片功能来进行扩展了。

小结

我们用 ZSET 将定时任务按照触发时间排序，然后使用一个无限循环来拉取需要触发的任务，实现了一个分布式定时任务系统的核心部分，读者可以在此基础上根据自己的需要做进一步扩展。

本文甚至没有给出完整的代码，因此并不能直接地复制到你的项目中使用，更多地在于提出和讨论一种解决方案。社区中也有一些类似的开源组件可供选用，例如 Bull 是一个功能完整的任务队列，其中包括了定时任务功能，Bull 使用了和本文类似的 ZSET + Scripting 技术，使用 Redis 作为后端。

]]> https://jysperm.me/2019/08/redis-cronjob-system/ 2019-08-18T17:00:00.000Z

这篇文章会带领大家实现一个基于 Redis 的分布式高可用定时任务系统，其中的 worker 以 Node.js 为例，但其实可以使用任何语言来实现。这篇文章不会给出完整的代码，更侧重于探索的过程。

2023-12-06T12:33:18.000Z 王子亭 jysperm@gmail.com 从小我就对太空以及人类对太空的探索特别感兴趣，最近一段时间因猎鹰重型火箭首次商业发射和回收成功，又激起了我对于太空探索的兴趣，今天我想讲一讲我和太空探索的故事以及这件事为何如此让我着迷。

在 2002 年前后（7 岁），我爸送了我两本书 最新21世纪少年儿童百科 和「十万个为什么」（这个版本全是文字、每本几百页左右、共 12 册，我并没有在网络上找到，现在想起来这本书的目标用户也许是家长才对）。我对太空探索以及其他科学知识的启蒙都来自于这两本书，小时候可以阅读的内容并不多，在之后的近十年中，这两本我起码看了十几遍以上，不过现在其实并不能想起来着两本书上具体讲了什么，只有一些模糊的片段。

后来 2005 年（10 岁）的暑假，发现号航天飞机在哥伦比亚号的事故后首次 执行任务，我记得那半个月我每天都从新闻和报纸关注事件的动态，还用积木（其实是麻将牌）去模拟我所理解的航天飞机发射过程。那时候每天晚上会有一段固定的时间，爷爷会给我解答一些我感兴趣的问题，我当时并不理解太空是怎样的，也不了解飞船是如何工作的。我想搞清楚这些，但受限于当时的知识，我只能以我所理解的方式去提问，所以很多时候并没有得到想要的答案。

值得一提的时候我高中有那么一年多在玩 EVE 这个游戏，其实说起来 EVE 在飞船的操纵上已经十分简化了，游戏背景中的先进科技也绕开了现实中的燃料和光速等限制。但在 EVE 中驾驶飞船给了我对于宇宙的一种直观的认识 —— 星球是如此地大、星球之间的距离是如此地远，其余的空间都是一片虚无，如果没有一个坐标的话，你几乎不可能和别人相遇。

对我影响比较大的作品还有 三体 和 星际穿越。三体是我在高中的时候看的，因为我小说其实看得并不多，所以这是第一本让我印象深刻的科幻小说；星际穿越则是我刚刚离开学校（18 岁）时看的，也是我非常喜欢的太空背景电影。这两部作品构建了我对于太空的形象化的认识，无论是三体中的黑暗森林设定还是星际穿越中黑洞的视觉呈现，都很好地把握了宇宙的尺度。当时看完星际穿越我发了一条 推文：「看了 Interstellar, 虽然不喜欢结局，但确实是一部非常之优秀的科幻作品。觉得在宇宙面前人类的力量实在太渺小，或许其他的技术难关都可以克服，但时间的限制是永远突破不了的。大概人类永远也无法离开地球，因为一旦到宇宙中去，对于人类，时间或是过于短暂，或是无比漫长。」

蛋黄同样对太空探索很感兴趣，近两年我们也看了不少相关的纪录片，我们经常互相拉着对方讲新了解到的关于太空探索有趣的事情：蛋黄讲得比较多的是历史，而我会更关注技术。我们关注最多的具体项目还是阿波罗计划了，毕竟是人类首次登上另外一颗星球，直到目前依然保持着人类所到达的最远的地方的记录。在做了更多了解之后，我发现其实有非常多的美国公司（尤其是飞机制造商）都参与了阿波罗计划，负责具体的火箭和飞船制造，而 NASA 主要负责的是设计和组织，整个项目也可以算是人类历史上最宏大的工程之一了。

提到太空探索的爱好者，就必须要提 Kerbal Space Program（坎巴拉太空计划）这款游戏，基本上在知乎这样的社区只要涉及航天或火箭相关的话题，评论区就一定有人刷坎巴拉的梗。在我入手这个游戏后便很快沉迷无法自发，在游戏中我可以亲手实现之前的文字或视频中见到过无数次的技术：发射入轨、霍曼转移、交会对接、反推着陆、引力弹弓。也对比冲、Δv 之类的数值有了更深刻的认识，之后再看纪录片的时候就能脑补出其中提到的各种操作了。后面我应该会专门写一篇文章来介绍坎巴拉太空计划这个游戏。

那么为什么我对于太空探索如此着迷呢？首先我还是视它为一种兴趣，是因为去了解这些知识会让我感到高兴和满足，而不是我要用这些知识做一件什么事情。相比于其他的学科，例如数学、物理甚至是计算机，最新的研究成果几乎都是我无法理解的，并不适合作为消遣和兴趣；而美国人登陆了月球、火星发现了液态水、木卫四可能存在生命这些就要好理解得多。这大概是因为作为太空探索的主力 —— NASA 的大部分资金都来自于财政拨款，这要求它必须以一种普通人能够理解的方式，向美国的纳税人解释他们的工作，以得到更多人的支持、得到更多的拨款。

接下来的几年也非常值得期待，在太空竞赛、人类登月之后，经过几十年的修整，接下来十几年人类很有可能会在航天领域取得新突破。比如 SpaceX 的 BFR 和 Starlink，人类重返月球和登上火星以及更多的深空探测计划。

]]> https://jysperm.me/2019/07/space-exploration/ 2019-07-01T17:00:00.000Z

从小我就对太空以及人类对太空的探索特别感兴趣，最近一段时间因猎鹰重型火箭首次商业发射和回收成功，又激起了我对于太空探索的兴趣，今天我想讲一讲我和太空探索的故事以及这件事为何如此让我着迷。

在 2002 年前后（7 岁），我爸送了我两本书 除了是哆啦 A 梦的铁杆粉丝之外，我也算是刘慈欣的粉丝 —— 三体自然不用说，其他所有的短篇小说我都看过两到三遍，这些短篇小说一点都不比三体逊色，流浪地球就是其中之一。

刘慈欣的小说向来重设定而轻情节，小说关注的是全人类的命运，主角只是叙述的视角而非故事的核心。在阅读小说的过程中，你体验到的不是沉浸感，而是一种站在上帝视角观察人类的新奇感，其中的人物只是当时社会中人类的典型代表。他会在小说中使用类似「刹车时代」、「威慑纪元」这样的标题来强化这种上帝视角，让书中短短几句的描述比电影的特效画面更加让人感到震撼。

最近我又重温了刘慈欣的几个短篇小说，包括：

• 流浪地球：给地球装上发动机来驶离太阳系
• 镜子：一台能够根据宇宙的初始状态模拟整个宇宙的计算机
• 吞食者：外星人通过环状太空船套住地球并掠夺地球的资源
• 山：一个诞生于行星地心的机械文明探索世界的故事
• 地火：通过点燃地下的煤层的方式来开采水煤气
• 地球大炮：挖一条贯通地球地心的隧道
• 赡养人类：在贫富差距达到极致之后，99% 的财富都集中到了一个人

回到流浪地球这个电影，视觉效果我还是很满意的，也确实是头一次看到中国的地标能够出现在科幻片或者灾难片中。情节上前半部分对于世界观的介绍还可以，但后半部分就非常俗套了，就是一个很普通的、几个英雄拯救地球的故事。其实我更宁可电影能从中间结束 —— 让地球撞木星也不是不可以。

前面提到过，流浪地球的小说关注的是全人类的命运、全人类在面对灾难时的反应，给人一种宏大和震撼的感觉，而电影则完全没有继承小说的精神内核，显得格局太小，更偏向于主角在整个大的世界观中的个人体验，而不是整个流浪地球计划。

我认为小说中有两个关键的点电影没有表达出来，一是人们对于「太阳」的情感的变化，以前太阳象征着温暖、壮美，但当人们知道这个太阳随时可能会爆炸之后，太阳便变成了恐惧的象征。在变轨的过程中地球一次次地接近和远离太阳，每当地球到达近日点的时候，这种恐惧就会到达顶峰。这种恐惧在几代人的时间里渗透到了社会文化和每个人的心中。而当地球逃离了太阳系、从对太阳的恐惧中解脱之后，人们又开始怀念太阳的温暖，开始怀疑整个计划是否正确。

另外一点是人们面对灾难时的冷静和理性，小说中有一个情节是在地下城遇到岩浆涌入需要撤离时，自动按照年龄排成一队，因为通常来说越年轻的人对于社会的价值会越大。因为人类知道了自己的命运，但又不知道自己是否可以逃离，太阳又永远悬在天上，这种恐惧深刻地影响了人们对于生活的态度，这也可以解释为什么人类能够组成联合政府、能够在全世界范围内协调和完成如此大规模的地球发动机。

当然这些评价是我从原著读者的角度来说的，如果作为一个普通的的科幻电影，或普通的国产电影，它应该是合格的。结尾的地方有一个很短的镜头是北京的地下城里有一队人在游行，举着一个「我们要太阳」的牌子，这个才是小说本来的结尾，算一个彩蛋吧。

]]> https://jysperm.me/2019/03/the-wandering-earth/ 2019-03-12T17:00:00.000Z

除了是哆啦 A 梦的铁杆粉丝之外，我也算是刘慈欣的粉丝 —— 三体自然不用说，其他所有的短篇小说我都看过两到三遍，这些短篇小说一点都不比三体逊色，流浪地球就是其中之一。

刘慈欣的小说向来重设定而轻情节，小说关注的是全人类的命运，主角只是叙述的视角而非故事的核心]]>

2023-12-06T12:33:18.000Z 王子亭 jysperm@gmail.com 今年我完成的业余项目确实非常少，勉强算下来也就只有 DeployBeta 的 0.4 版本和 Elecpass 的 v3 版本。

所以我今年得到的一个重要的教训就是 一次要专注于一个项目，同时尽快完成一个阶段性的可用版本，尽快发布。尤其是对于我来说，还有全职工作，业余时间并不多，如果不能尽快发布，获得一些反馈，就失去了继续完善的动力，而且会摊子越铺越大，一直无法发布。

在这一点上，DeployBeta 是一个反面的例子，持续了两年的时间，但也没到可以对外发布的标准。而 Elecpass 是一个正面的例子，在 2017 年 10 月，我花了半个月的时间就发布了两个版本，之后一年多的时间我自己一直在使用，然后在今年十一月集中花了一周的时间发布了 v3 版本（筛选框、布局优化、强化编辑功能、编译 Windows 版），这个项目大部分的时候都是「已发布」状态，而不是还有功能做到一半。

---

在 DeployBeta v4 版本的前夕我将 DeployBeta 开源了，在 v4 和后续的未发布版本中，我实现了 MySQL、Redis、MongoDB 三种数据库的支持、重写了基于 Etcd 的 ORM。所以今年我也写了一些 Golang，今年我主要的怨念在于 Golang 中缺乏对于接口数组（或者说泛型数组）的支持，只能使用 interface{} 和反射来实现 ORM 中「获取结果数组」的功能。

这个 ORM 其实就是将 JSON 数据存储在 Etcd 中，同时提供关系和事务的简单封装。这其实和 Kubernetes 中的 api-server 做的事情差不多，但因为没有找到比较好的关于 Kubernetes 使用 Etcd 的文档，所以我没有太多地参考它。

---

为什么容器平台能够简化容器的管理工作呢？我认为一个重要的原因是容器平台提供了一种纯描述式的定义文件，让开发者去描述所期望的最终状态。这一点在 Kubernetes 中实现得最为彻底，我相信这也是 Kubernetes 成功的原因之一。

今年因为工作的原因，我非常深度地接触了 Kubernetes，在其基础上进行封装，来提供容器服务。Kubernetes 不仅仅是一个工具，同时也是一个平台，它以 RESTFul 风格的 API 将所有功能抽象为资源，然后由每种资源的 Controller 去将对象的实际状态同步到预期的状态。这意味着在 Kubernetes 的基础上你可以去添加自定义的资源和相应的 Controller 去拓展它的功能。

在对 Dockerfile 的抽象能力忍无可忍之后，今年我用 Node.js 为 Dockerfile 实现了一个简易的 DSL，主要是将 Dockerfile 分为多个段落，然后在每个段落中结构化地保存指令数据，以便在对 Dockerfile 的整个处理过程中随时向任何段落添加或修改指令，最后等到完成所有的处理之后再将结构化的指令数据生成真正的 Dockerfile。经过这样的过程生成的 Dockerfile 有着更规范的格式，更有利于跨应用甚至跨语言之间的缓存。

其实我们在生产环境使用容器技术已经很多年了，但很多时候只是将已有的程序跑在容器里而已，而没能做到 Container Native。例如我们实际上还有很多容器在依赖本地存储、没有有效的健康检查、不能正确地处理信号来实现平滑关闭。

---

我司今年发布了一个 游戏后端解决方案，它本质上是一个「消息转发服务」，帮助游戏的客户端之间来转发消息、同步状态。

但出于反作弊的需要，我们还需要提供一种在服务器端运行游戏逻辑的能力。对于暴露这种能力的方式，一开始我们内部有两种方案。我认为比较好的方案是将这种在服务器端运行的游戏逻辑也作为一个客户端去加入到消息服务中，以消息服务为中心与其他客户端进行交互。这样做的好处是：

• 在服务器和客户端之间复用大部分的游戏逻辑
• 单机游戏 => 动作同步 => 状态同步 的迁移过程非常平滑
• 服务器端的游戏逻辑和消息转发服务解耦

为了验证这个方案的可行性，我花了一些时间制作了一个 Demo，实现了一个 简单的回合制卡牌游戏，这种模式后来也被我司发布为了正式的产品：Client Engine。

在这个过程中我其实是第一次接触游戏后端的开发，其实我并没有去了解既有的游戏框架，但在不知不觉中也重新发明了一些轮子，例如「动作」和「状态」的概念，感觉去探索游戏的开发过程还是挺有意思的一键事情。

---

今年年初的时候我尝试为云引擎加上了 任务队列 的功能，因为云引擎本来已经有了基于 HTTP 的云函数功能，所以我想这个任务队列只提供一种调度的能力，而不提供计算资源，依然通过 HTTP 来调用原本的云函数。我认为这样的形式可以减少引入的新概念，降低介入的成本。

但低调公布之后的效果并不是很好，我觉得其中一个原因是是我自己就比较少用任务队列，所以比较难站在用户的角度去考虑他们需要任务队列有怎样的功能、希望超时和并发的控制是怎样的。在新的一年里我还会继续改进这个功能，去参考其他类似的云服务如何设计任何队列的功能。

大概是因为我的服务器端编程经验都在 Node.js 上，Node.js 中异步任务的成本很低，所以不需要出于减少线程开销的考虑去使用任务队列；同时我会通过 Redis 来维护一些关键状态，消除单点、保证因应用重启而中断的任务可以恢复，所以也几乎不需要任务队列去保证任务执行的连续性。

在这个功能的实现上我重度地使用了 Redis：使用 Redis 存储所有的状态、提供一致性保证，用 Node.js 去实现 Worker，调用 Lua Script 去实现原子操作。说起来 Redis 是我用过最好的服务器端软件之一，我认为 Redis 找到了一个非常好的切入点、找准了自己的定位，才使得它的设计看起来那么简单。

应该说任务队列的需求是非常多样化的，每种业务可能都会对任务队列有不同的需求，再加上很大程度上又是语言相关的，所以我觉得在这个方面如果能做一些开源项目也会有比较大的空间，例如我就觉得 Redis 5 中的 Stream 类型就是为任务队列设计的，想去写一个充分利用 Stream 特性的任务队列。

]]> https://jysperm.me/2019/01/programming-of-2018/ 2019-01-30T17:00:00.000Z

今年我完成的业余项目确实非常少，勉强算下来也就只有 DeployBeta 的 0.4 版本和 就如 2018 年度小结 中说的那样，蛋黄并不喜欢出门旅行，就喜欢宅在家里，那怎么办呢，于是我们想到了一种合适的「佛系旅行项目」—— 游轮。在游轮上不需要做计划、想去哪就去哪，绝大部分项目不需要额外付费，在船上只需要走几步路就可以回到室内、找到卫生间，再多走几步就可以回到房间或者找到餐厅（也不需要额外付费）。

我们去的是「喜悦号」的游轮，往返上海和福冈（船每次出海停靠日本不同的港口）。5 天 4 夜，其实就是四个整天（两天在海上、一天停靠在日本、登船和下船加起来一天）。总体上我是比较满意的，船上设施和房间内都非常新、非常干净（蛋黄非常看重这一点），这艘船只启用了一年半，三月末就会离开中国，所以还是要把握机会的。

整个行程人均 2900 元（2200 房费 + 400 固定支出的「小费」+ 300 额外付费项目），这个性价比我觉得也非常可以了，这个价格是淡季的价格，赶上假期就会贵很多。我们住的是阳台房，基本就是比快捷酒店小一些的房间，卫生间很小但设施设计得很好，所以并不难用，有一个露天阳台可以看海。

关于船上设施网上的介绍很全了，我就只谈个人感受。

我们全部吃的是免费餐厅（因为网上测评说收费餐厅并没有比免费的强多少，然后价格很贵），吃得还是很好的，有两种免费餐厅，一种是自助餐，面积很大，饮料、水果和糕点很全、主菜每天会变化但品种不多、没什么海鲜。

另一种是正餐厅，每天有一套不同的菜单（五、六个菜），中西餐的菜混合，每天都有一道虾（很大），还有牛排和三文鱼，这些食材的品质我觉得都是非常好的。然而中餐做得比较「西式」，不看菜单根本猜不出来是什么菜，经蛋黄点拨发现原来是他们不会炒菜，感觉都是炖出来的 … 西餐的话我还是非常满意的。

刚进黄海的时候风景不怎么样，水很浑浊，到靠近日本的地方海才变得非常蓝、非常绿，天也是蓝的，很美。

然后晚上可以看到满天的星星，已经很多年没见过了（当然这一点比较依赖于天气，只有一天晚上没有云，才能看到星星）。船很稳，前两天根本感觉，后面两天开始有一些浪，但还是非常稳的，稳到蛋黄觉得船震没有什么特别的感觉。

上海到日本这片海域，基本全程都能看到其他的船，甲板上有两个望远镜可以用，但蛋黄觉得自己带一个望远镜会更好，可以看海岸、船和海鸥。

室外的气温和昆山差不多，但顶层的风非常大；室内则是恒温的，空调非常足。

甲板上有露天的温水游泳池，还看到有人在里面游。

船上有很多演出和活动（还有广场舞），都是免费的，我们看了两场歌舞剧和一场杂耍。歌舞剧看不太懂，但舞台效果还是很不错的。船上有几个露天的泳池，里面是温水，看到有几个人在游。还有一些乒乓球台，和蛋黄打了很久的乒乓球。

付费娱乐项目我最感兴趣的还是卡丁车，$10 一次五分钟，和之前在昆山玩的比起来价格差不多，但不够刺激：车不够快、不能漂移、赛道窄不容易超车，碰到不会开的人就会一直堵着路，不过既然是在船上也不能要求太高了，我全程玩了三场还是挺开心的。因为船上以大爷大妈为主，所以这些娱乐项目的人很少，不需要排队。

到日本之后的岸上观光项目很坑，基本相当于是被卖给了旅行社（以每个人 500 的价格，不想跟团的话要交 500），带你去一些一点都不好玩的景点、一点都不好吃的「美食广场」、一点都不便宜的免税店，行程还特别赶。

关于这个船三月末离开中国，主要是觉得中国人额外的消费太少，工作人员说在欧美航线一周可以卖 50000 瓶啤酒，然而船上基本都是中老年人，酒吧根本没有人。我和蛋黄觉得很大原因是这个公司（这个公司只有这一艘游轮在中国）不了解中国的情况，没有开发出适合中国大爷大妈的额外消费项目，比如搞搞中医按摩针灸、卖点保健品，实在不行搞个水池让大家扔硬币也行呀。有钱的大爷大妈还是很多的，有一天吃饭和做旁边的一对上海大爷大妈聊天，家里在上海几套房，经常坐游轮（估计这是他们坐的最低端的游轮了），说今天买包买衣服就花了两万多 …. 还觉得特别值。

据说这艘船是为中国人设计的（比如热水和热水壶），船上大部分的服务人员都是中国人，餐厅和客房的服务员则主要是东南亚人。不过总之绝大部分地方都只需要用到中文，对大爷大妈还是非常友好的。东南亚的服务人员的态度非常好，总会笑着打招呼，虽然不会中文也会积极地沟通；然而部分中国的服务人员态度不是很好。

船上网络是额外付费的，大概 500 元全程，我没有买，因为我已经做好准备把「没有网络」作为这次游轮体验的一部分了。实际上因为每天的活动内容都很丰富，没有网络也不会无聊，就看着船下的海浪都可以看很久。我带了电脑、几本书、iPad 和相机，但实际上并没有用到，就是因为船上的活动太丰富；相机的话，因为我换了 iPhone 8，感觉和相机的拍照效果已经差不多了，所以也没怎么用上。

我们在船上看了泰坦尼克号作为安全教育片，我事前事后也了解了不少游轮的背景知识以及泰坦尼克号的故事，经过那之后，现在海上的安全标准应该已经非常可靠了，但蛋黄还是表示想坐一坐救生船（忘记拍救生船的照片了）。

]]> https://jysperm.me/2019/01/cruise-line/ 2019-01-09T17:00:00.000Z

就如 2018 年度小结 中说的那样，蛋黄并不喜欢出门旅行，就喜欢宅在家里，那怎么办呢，于是我们想到了一种合适的「佛系旅行项目」—— 游轮。在游轮上不需要做计划、想去哪就去哪，绝大部分项目不需要]]>

2026-05-01T15:13:06.182Z 王子亭 jysperm@gmail.com 转眼又一年过去了，今年我们又回到了昆山，节奏放慢了很多，更多的时间花在了「生活」本身上面。

就如去年的小结中计划的那样，今年四月我们从北京搬回了昆山，接着搬家的机会添置了很多新物件，比如戴森的吸尘器、洗碗机、全自动咖啡机、米皮新风、扫地机器人、恒温龙头、Mesh 路由器、冰箱、桌子椅子、1.8 米的床和床垫等。昆山的厨房也更大了一点，买了更多的锅具和碗筷，感觉生活质量提高了一大截。

在昆山安顿下来之后，因为家里有了更多的地方，所以又买了一些玩具，包括 乐高的跑车 和 乐高的小火车，甚至现在有一个大桌子专门摆我的玩具。

今年我也花了不少时间在「建造类」游戏上，主要包括 天际线（Cities: Skylines）、缺氧（Oxygen Not Included）和异形工厂（Factorio）。异星工厂是我今年新发现的游戏，主要内容是建造自动化的流水线，非常对我的胃口，记得当时连着玩了几天，花了 50 多个小时第一次通关。

皮蛋豆腐今年也三岁了，和之前比起来它们更加「成熟稳重」了。从搬到昆山开始，豆腐总在猫砂盆旁边的地面上撒尿，经过一番摸索后发现原来是它对每天晚上被关在阳台表示不满。于是从那之后就不再把皮蛋豆腐关在阳台上了，即使我们出门也会把它们留在客厅，在我们睡觉的时候也会让它们进入我们的房间，它们有时候睡在衣柜里、有时候睡在地上、有时候睡在椅子上、还有的时候睡在蛋黄的被子上，但它们要是睡在我的被子上就会被我踢下去。

今年也全面启动移民的进程，我们的主要目标是加拿大，毕竟加拿大是英语国家、是高福利的发达国家，同时也是一个传统的移民国家。对于我来说主要是自考学历和英语这两大块，今年一年都在背单词，但其实三天打渔两天晒网，效果并不是很显著。

关于英语学习，我觉得 我们老板的文章 就挺有道理的，要在实际的日常场景中学习英语，将之前消费的一部分中文内容替换成英文。于是我将手机和电脑的系统语言改为英语、开始在洗澡时改听英文的播客、改去 Youtube 直接看一些英文播主的视频、去读技术类的英文书。在产出的方面则新的开源项目都使用英文来写文档和注释，后续还打算开始在 Medium 上开始写英文的博客。

在九月份的时候，我放弃了之前等自动驾驶汽车的想法，决定考一个驾照，主要是考虑可以创造一种租车前往公共交通不便利的地方的可能，尤其如果以后准备去加拿大的话。于是我和蛋黄一块报名，顺利通过了科目一和科目二，剩下的部分则有待明年继续。

在今年的最后两个月，我和蛋黄陷入了一场长达两个月的争吵，主要是关于原生家庭的观念冲突。虽然我们都从一开始就认为我们作为一个小家庭应该和双方的原生家庭保持独立，但因为成长环境、和家人的相处方式的不同，在具体的做法上面还是有非常大的分歧。我不想在这里描述细节，但这件事对我们的负面影响都很大，并且一直持续到了 2019 年。

今年和蛋黄一起去了沈阳、天津和无锡旅行，不过蛋黄其实并不喜欢出门旅行，在外面一副特别「丧」的样子，有时候还发脾气。

除此之外，我还和公司一起去了菲律宾、自己去了海南。在菲律宾的长滩岛的体验其实并不怎么好 —— 主要是没什么吃的，虽然是一个小岛，但并没有吃到什么海鲜。

在 iPhone SE 服役两年半之后，在双十一我入手了 iPhone 8，相比于全面屏和人脸识别，我还是更喜欢指纹。无线充电也非常方便，尤其后来我在家里的桌面上打了一个孔，安装了宜家的嵌入式充电器。

今年币圈和整个投资市场、全球经济都非常不好，大家都说今年只要不亏就算赚了。在股票上面我今年勉强没有亏，但在币圈可是亏惨了，相比于年初几乎跌掉了八成。

]]> https://jysperm.me/2018/12/summary-of-2018/ 2018-12-30T17:00:00.000Z

转眼又一年过去了，今年我们又回到了昆山，节奏放慢了很多，更多的时间花在了「生活」本身上面。

就如去年的小结中计划的那样，今年四月我们从北京搬回了昆山，接着搬家的机会添置了很多新物件，比如戴森的吸尘器、洗碗机、全自动咖啡机、米皮新风、扫地机器人、恒温龙头、

2026-05-01T15:13:06.185Z 王子亭 jysperm@gmail.com 蛋黄总说我过去二十几年过得顺风顺水，想想也是，虽然有小的波折，但并没有什么让我后悔的事情。我觉得这当然有运气的成分，但和我个人的选择也是分不开的。

在大家抱怨学校生活时，我就想找一个彻底的方式来摆脱学校的限制，于是后来我退学了；在大家抱怨工作不称心的时候，我就想着一定要去一家能让我开心地工作的公司，于是我找到了番茄土豆和 LeanCloud；现在我仍在听着大家抱怨着生活中的种种，于是我也在准备着一个能够彻底摆脱这些问题的计划。

对于这个选择我的心情非常复杂，既有期待也有不安；既怪自己行动得太晚了，但也明白是遇到了蛋黄才让我有了勇气和决心来准备移民。在我们刚刚在一起的时候其实就已经有了这个想法，也在陆续做着准备，在过去的一年中，整个路线逐渐清晰了起来，我们也越来越期待成功的那一天，这将会是我下一个重要的选择。

国内就总喜欢黑高福利国家人们不好好工作、人力成本高的要死，黑民主国家办事效率低、办不成大事。但我现在越来越觉得，这也许才是一个稳定的国家的常态，充分保障个人的自由、甚至说保障人们「不求上进」的自由，平衡各方的利益，这样才能带来稳定。

随着一开始的「矜持」被放下，这一年中我们吵得确实比刚在一起的几个月要多得多。但我和蛋黄已经为未来做了这么多规划了，虽然大大小小的分歧吵闹不断，但我还是相信我们会一直走下去。年初我在知乎上回答了一个 关于完美女朋友的问题，也为自己找到了「完美女朋友」而高兴 —— 当然我现在也是。但还有一点我比较关心的是，蛋黄还没找到工作，我觉得工作是生活中很重要的一部分，我希望她也能找到一个愿意为之投入，也能获取合理的收入的工作。另外我觉得人在开始工作之后可能对于很多事情的看法会有一个比较大的转变，对这种转变我还是期待更多一点，我觉得那时她会更能够理解我的一些想法。

在 LeanCloud 工作三年了，期间也有人问我要不要考虑其他的工作机会，我想了一下，继续留在 LeanCloud 大概是因为这里的工作既「稳定」又「充满挑战」。这么说也许看似矛盾，但我说的稳定是指，这里的工作全部围绕着 LeanCloud 这个云平台 —— 更具体来说是围绕着云引擎，它本身已经是一个相对稳定的系统了，有着不小的用户量，需要以严肃的态度去对待每一个改动；充满挑战是指围绕这个大的方向，还是可以做很多有趣的尝试的，工作的方向和内容并没有受到限制，而且我会感觉到我个人的决定，对公司的产品是有着直接的影响的。

]]> https://jysperm.me/2018/11/thinking-about-my-22/ 2018-11-24T17:00:00.000Z

蛋黄总说我过去二十几年过得顺风顺水，想想也是，虽然有小的波折，但并没有什么让我后悔的事情。我觉得这当然有运气的成分，但和我个人的选择也是分不开的。

在大家抱怨学校生活时，我就想找一个彻底的方式来摆脱学校的限制，于是后来我退学了；在大家抱怨工作不称心的时候，我就]]>

2023-12-06T12:33:18.000Z 王子亭 jysperm@gmail.com 当我们公司决定推出一个「多人在线游戏后端解决方案」的时候，我其实很疑惑会有一个「通用」的方案可以解决所有在线游戏的后端需求么？

于是在前一段时间，我尝试开发了一个「多人在线卡牌对战游戏」，支持了「斗地主」游戏规则的一个子集，可以在 play-cards.leanapp.cn 访问到，源代码在 jysperm/play-cards。不过请不要指望能够匹配到其他玩家 —— 你需要自己开三个窗口，通过左右手互搏的方式来体验游戏，下面是一个演示视频：

https://streamable.com/belpq

动作同步和状态同步

其实这个游戏的关键就是在多个客户端之间来同步数据、实现联机游戏，为此我先了解了一下业界总结出的两种同步模型：「动作同步」和「状态同步」。

在动作同步（帧同步）中：

• 客户端发送操作，服务器只转发客户端的操作
• 游戏逻辑主要在客户端运行（通常客户端需要掌握所有数据）
• 延迟低，适合 RTS、MOBA、FPS
• 可以让所有客户端有一个完全一致的时间轴

游戏状态的计算必须是确定的，不能有随机数，这样才能保证不同的客户端在应用相同的一系列动作之后能够得到相同的状态（游戏画面）。

在状态同步（C/S 同步）中：

• 客户端发送操作，服务器转发计算后的游戏状态
• 游戏逻辑主要在服务器运行（可以只向客户端发送部分数据）
• 易于反作弊，适合 MMORPG、回合制（卡牌）游戏

因为游戏逻辑需要运行在服务器，所以服务器程序还是必不可少的。

选型

因为这是一个实验性质的项目，因此我想同时实现这两种同步模式来进行对比。在这里我挑选了一个回合制、属于非对称博弈的卡牌游戏作为游戏的内容。

我首先实现了动作同步，在动作同步中服务器几乎不需要做什么事情，只是作为一个「消息服务」来转发客户端的动作。于是我在这里使用了 LeanCloud Play 来完成这个消息转发的工作，每局游戏对应 Play 中的一个 Room，Play 允许客户端在房间中向其他玩家广播消息。

然后我又尝试将这个游戏改为了状态同步 —— 我引入一个运行在服务器上的特殊客户端（称为 MasterClient）。这个客户端中同样连入 Play 的消息服务，其中运行着完整的游戏逻辑，它将其他真正玩家的动作作为输入，然后输出游戏状态给其他真正玩家的客户端来展示，防止客户端作弊。

动作和状态

前面我提到业界已经总结出了两种同步模式，即动作同步和状态同步，「动作（Action）」和「状态（State）」这两个概念会贯穿这篇文章。

动作即玩家对于游戏的「输入」，可以是按键、点击，或者更抽象的动作，例如在这个游戏中我定义了两种动作 —— 出牌和放弃出牌：

type GameAction = PlayCardsAction | PassActioninterface PlayCardsAction {  action: 'playCards'  player: Player  cards: Card[]}interface PassAction {  action: 'pass'  player: Player}

状态即用来表示整个游戏局势所需的所有数据，例如在这个游戏中：

export interface GameState {  players: Player[]  playersCardsCount: PlayersCardsCount  myCards: Card[]  previousCards: Card[]  previousCardsPlayer?: Player  currentPlayer?: Player  winer?: Player}

游戏抽象

有了动作和状态的概念，我们就可以对游戏进行一个抽象了，我设计了一个 Game 类，是对一局游戏整个生命周期的封装，这个类将会同时运行于客户端和服务器：

// 事件：action（当前玩家的动作）、stateChanged（游戏状态变化）、errorclass Game extends EventEmitter {  constructor(seed: string, players: Player[])  // 获取游戏状态（供 UI 调用）  public getState(player: Player): GameState  // 设置游戏状态（状态同步时），会触发 stateChanged 事件  public setState(player: Player, state: GameState)  // 当前玩家执行动作，会触发 action 事件  public performAction(action: GameAction)  // 应用其他玩家的动作（动作同步时）  public applyAction(action: GameAction)}

在客户端中，当 UI 捕捉到用户的输入时，执行 Game.performAction，动作（Action）的执行会改变状态（State），触发 stateChanged 事件，UI 收到这个事件后根据新的游戏状态来重绘 UI。

至于其他游戏逻辑则主要是关于「一组牌能够管得上另一组牌」的判断，在此不再罗列。

结构

在这个游戏中，我们将消息转发（由 LeanCloud Play 提供）视作一项服务、视作一个中心。所有玩家的客户端都连接到消息转发服务上，同时每局游戏我们还需加入一个运行在服务器上的 MasterClient 来提供特殊的管理能力。

为了将两种同步模式做成可简单替换的，我其实将服务器程序作为了一个必选组件（master-client 目录），但这个服务器程序在动作同步中只是负责创建房间（可以移到客户端），并不参与游戏逻辑。

我的代码分为 3 个部分：

common├── game.ts└── types.tsbrowser-client├── app.tsx└── client-sync.tsmaster-client├── server-sync.ts└── server.ts

• common 部分会同时运行在服务器和客户端，包含游戏的核心逻辑
• browser-client 是运行在浏览器中的客户端，包含 UI
• master-client 是运行在服务器端中的 MasterClient

动作同步

我首先实现的是动作同步（client-sync.ts 和 server-sync.ts 中的 actionSyncController），这种模式下客户端发送动作（Action），服务器只转发动作，游戏逻辑主要在客户端运行，客户端掌握所有的数据（包括其他玩家的手牌）。

客户端的工作：

• game.on('action') 时（表示用户在 UI 上进行了一个动作），通过 Play 将动作广播给其他客户端play.sendEvent(action)
• play.on('customEvent') 时（表示收到其他客户端广播的动作），应用其他玩家的动作 game.applyAction(action)

而服务器端几乎没有什么工作，只是帮助客户端创建一个房间而已。

状态同步

在状态同步（client-sync.ts 和 server-sync.ts 中的 statusSyncContorller）中，客户端发送动作（Action），服务器运行游戏逻辑后，转发计算后的游戏状态（State），游戏逻辑主要在服务器运行，客户端只做展现，只知道自己的手牌。

客户端的工作：

• game.on('action') 时（表示玩家在 UI 上进行了一个动作），通过 Play 将动作单独发送给 MasterClient play.sendEvent(action)（需加参数 {receiverGroup: ReceiverGroup.MasterClient}）
• play.on('customEvent') 时（表示收到 MasterClient 广播的最新状态），从服务器覆盖游戏状态 game.setState(state)

MasterClient 在服务器的工作：

• 为每局游戏创建一个 Game 对象。
• play.on('customEvent') 时（表示玩家进行了一个操作），在游戏对象上执行动作 game.performAction(action)
• game.on('stateChanged') 时，给每一个玩家发送最新的游戏状态 play.sendEvent(state)

复用代码

在完成这个实验性质的项目后，我们需要来思考一下，哪些代码是可以复用的。

• Game 类为一个游戏的过程提供了一个非常基本的抽象（即通过动作去改变状态），也为数据同步提供了基础的支持（action 事件和 stateChanged 事件）。
• MasterClient 中对房间的管理是通用的，并且还有很大的改善空间，比如支持多实例允许并实现负载均衡等。

我将我使用的这种开发多人在线游戏的方式称之为 MasterClient 模式，它的好处是：

• 在服务器和客户端之间复用大部分的游戏逻辑 如果你像我一样使用 JavaScript 的话，那么可以在服务器和客户端运行完全相同的代码。
• 单机游戏 => 动作同步 => 状态同步 的迁移过程非常平滑 只要一开始能够区分好动作和状态，那么这个迁移的过程中只需改动少数代码。
• 服务器端的游戏逻辑和消息转发服务解耦 消息转发服务可以更加稳定；MasterClient 则可以更快速地迭代。
• 符合开发者直觉 至少我作为一个游戏开发的小白是觉得挺符合直觉的

Play & Client Engine

在我完成这个项目的过程中，我也不断地与公司的同事保持着沟通，经过几个月的努力，LeanCloud 在 Play 基础上发布了 Client Engine —— 一个用于托管 MasterClient 的容器平台（类似于云引擎），同时我们也提供了一个项目骨架，集成了我前面提到的功能，帮助开发者实现服务器端逻辑：

• 游戏抽象 提供了一个类似的 Game 类来帮助开发者管理房间和玩家、填充游戏逻辑，在 Play 的基础上提供 RxJS 风格的高层次 API 来操作游戏动作和状态。
• 负载均衡 提供了一个 GameManager 类来管理房间的创建，允许 Master Client 以多实例的集群模式运行，以便进行横向扩展，消除容量瓶颈。
• 平滑部署 当你部署新版本的时候，旧实例会等待已有的房间完成游戏再退出，你可以在任何时候部署新的版本而不必担心影响用户的游戏。

我的这个项目早于 Client Engine 成型，是对通用游戏后端的一个实验。如果你希望编写类似的游戏，请阅读 Client Engine 的文档，并基于 Client Engine 的脚手架来进行开发，而不要直接基于本项目修改。

小结

本文探索的是一种「通用游戏后端」的解决方案，在这个小项目中我们用到了两个 LeanCloud 的服务：Play 和 Client Engine。

• LeanCloud Play 扮演的是一个「消息转发服务」，它会维持与所有客户端（包括 Master Client）的长链接，允许客户端之间广播或单发消息。
• LeanCloud Client Engine 提供了一个可信的服务器端环境来运行客户端 —— 在本文的例子中是 MasterClient，可以将游戏逻辑运行在服务器端来实现反作弊。

借助这两个服务，我们将对游戏服务器的开发需求降到了最低，只需编写运行于服务器端的游戏逻辑即可，而不必关心链接的保持、消息的转发和服务器环境和扩容等问题。

]]> https://jysperm.me/2018/11/play-cards-realtime-game/ 2018-11-21T17:00:00.000Z

当我们公司决定推出一个「多人在线游戏后端解决方案」的时候，我其实很疑惑会有一个「通用」的方案可以解决所有在线游戏的后端需求么？

于是在前一段时间，我尝试开发了一个「多人在线卡牌对战游戏」，支持了「斗地主」游戏规则的一个子集，可以在

本文整理自 彩排 中的一期播客。

什么是自由软件

我总结了三点自由：

• 出于任何目的、以任何方式 使用该软件的自由（包括商业用途，一些商业软件限制你不得进行破解、不能用于犯罪活动就是在限制你使用的方式或目的）。
• 修改软件的自由，当然修改软件的前提是你要能够得到源代码。
• 重新分发的自由，不仅是分发原始版本，你也可以分发修改后的版本。

只有符合这三条才可以算自由软件，有一些只开源代码（可能是为了安全审计，或者只限非商业用途）的软件并不能算自由软件。

我们经常看到的 GPL、Apache、MIT 都属于自由软件许可证，这些许可证会在前面的三项自由之外附加一些限制条款，但这些限制条款与自由软件中的自由并不冲突。

Copyleft 的 GPL 家族

在自由软件许可证中，有一类特殊的被称为 Copyleft 的许可证（Copyleft 是一个与 Copyright 相对的词，代表着一种具有「传染性」的自由），其中最知名的就是 GPL 家族了，我们接下来会聊到其中的 GPL、LGPL 和 AGPL。

Copyleft 的特点在于它有一种理想主义的野心 —— 它希望这个世界上所有的软件都是自由的，因此这些许可证都是具有「传染性」的。它们在自由软件的基础上附加了一个最主要的限制条款：在重新分发 Copyleft 的软件时，必须授予用户同等的自由、也必须附加同等的限制条款。在实践中一般就是说，你修改一个 GPL 的软件后，你再发布的时候也必须是 GPL，其他人修改了你修改后的软件，也必须是 GPL，这就是所谓的传染性。

自由软件社区中有很多使用 GPL 许可证的软件，例如我们熟知的 Linux、WordPress 等等。说到 WordPress，现在有很多公开出售 WordPress 主题或插件的社区，但按照 GPL 的许可证，主题或插件中的 PHP 代码显然属于衍生作品，必须使用 GPL 许可证来发布（而 CSS 和 JavaScript 可以通过单独以其他协议发布来规避），所以理论上，任何一个人购买了 WordPress 主题，那么他都可以随意地再次出售这个主题（这是 GPL 授予他的权利），在 2013 年我便就此话题写过一篇 文章。

GPL 中的衍生作品

我们再来看 GPL 的限制条款，即「再分发衍生作品时必须授予用户同等的自由」，这里有两个词可以单独拿出来讨论一下，「分发」和「衍生作品」。

所谓 分发 就是说你把这个软件（包括修改后的版本）发送给其他人使用，例如你开发了一个桌面软件，当你给用户提供下载时，这就是一种分发行为；当你提供一个库（无论是源代码还是二进制版本）也是一次分发行为；甚至包括浏览器中的 JavaScript 也算分发行为 —— 因为用户的浏览器需要从你的服务器下载 JavaScript.

GPL 为了保证用户有修改软件的自由，要求你在进行分发时同时提供源代码。而分发可能是公开的，也可能是小范围的，如果你在网络上公开发布一个软件，那么你也必须公开发布源代码；但如果你只是私下发给一个朋友，或在公司内部分发一个内部软件，那么你只需要向这个朋友，或者在你的公司内部提供源代码。所以说「分发」和「提供源代码」的行为是挂钩的，你向谁分发就向谁提供源代码。

所谓 衍生作品，GPL 认为只要你的项目中用到了 GPL 的代码，都可以算衍生代码，无论你是把 GPL 代码作为一个主要功能，还是用来做一个非常细枝末节的功能。而且 GPL 感染的对象是你的整个软件，也就是说只要你的项目用了 GPL，那么整个项目都被感染成了 GPL，你在进行发布时需要提供整个项目的源代码。

这样听起来 GPL 的确很流氓，那么具体到条款上，GPL 什么情况下会感染你的项目呢？我总结了一下，除非你采用以下三种隔离方法中的一种，将 GPL 代码与你的项目进行了隔离，否则都会被 GPL 感染：

• 内存地址空间隔离，即如果你的代码和用到的 GPL 代码不共享内存地址空间，例如分别属于两个进程（操作系统帮你做了内存地址空间隔离），或者分别属于内核态和用户态那么就不算衍生作品，例如 Linux 并不会感染运行在 Linux 上的程序。
• 代码和数据隔离，即如果你的代码和 GPL 的代码是分别作为代码和数据被看待的，那么不算衍生作品。例如用 GCC 编译你的程序是不会感染的，因为在编译时，你的程序是作为数据被看待的；同理，用 Emacs 编写代码也不会感染被编写的代码。
• 指令计数器隔离，这个是针对虚拟机的一种例外，像 JVM 这样的运行环境，实际上是虚拟了一个 CPU 去执行其上的 Java 操作码，这个虚拟的 CPU 实际上有着和物理 CPU 不同的指令计数器（即 CPU 用来记录当前执行位置的寄存器），因此 JVM 不会感染运行在其上的 Java 代码。

注意这里的例外并不包括静态链接和动态链接，因此如果你静态链接一个 GPL 的库也是会感染你的整个项目的；至于动态链接则目前还存在争议，GNU 极力认为动态链接也在感染的范围内。

LGPL

除了 GPL 还有一个叫 LGPL 的许可证，它是一个比 GPL 宽松一些的许可证，LGPL 中将衍生作品的范围减少到「同一个编译单元」，允许用户在使用了 LGPL 的静态链接库时，仅将 LGPL 代码所属的编译单元开源，所谓编译单元在 C 这样的语言里就是一个文件，若干个编译单元会在最后被链接到一起，形成一个可执行文件。

但如果推广到一些并没有明确区分编译和链接环节的基于虚拟机的语言（例如 Java 或 JavaScript）中，则还有一些争议，一般是认为一个包属于一个编译单元。

LGPL 被广泛地使用在依赖库中，例如 Qt 和 FFmpeg 都使用 LGPL 许可证，但实际上作为 GNU 之父的 Richard 后来并不建议大家使用 LGPL，而是建议大家直接使用原版的 GPL。

他在一篇题为「Why you shouldn’t use LGPL for your next library」的文章中说，非自由软件的开发者往往都有很多金钱上的优势，我们这些自由软件的开发者必须团结起来以便得到某种优势来和他们对抗。如果我们发布的库都使用原版的 GPL，那么我们这些自由软件开发者将获得一种巨大的优势 —— 我们可以使用这些库，但那些非自由软件开发者却不能。

所以后来 Richard 将 LGPL 的全称从 GNU Library License 改为了 GNU Lesser License，并且不建议大家在新的项目中使用。

GPL 在法律上的现状

GPL 在法律上的现状并不乐观，很多时候 GPL 是一种君子协定，很多人经常是基于道德，或者很多公司是基于声誉的考量才去遵守 GPL。虽然 GPL 许可证本质上是一种合同，将代码的使用权有限制地授予愿意遵守这个限制的人。但 GPL 的主要诉求是「开源代码」，而即使赢得诉讼，（至少在中国）法院也不会帮你强制执行「开源代码」这一判决；因为通常法院只能强制执行经济类的判决，如果你要求经济上的赔偿的话，因为 GPL 中并没有写明不遵守许可证的情况下的罚金，因此你可能需要证明被告不开源这一行为给他带来了多大的利益或者给你造成了多大损失，注意并不是他使用你的代码得到的利益，而仅仅是不开源这一行为的利益。

尤其很多开源项目并没有精力去打官司，一部分开源软件可能只是会在网站上登出一个「耻辱柱」的页面，列出哪些项目或公司使用了他们的代码却没有遵守 GPL 许可证，例如 FFmpeg 的网站。

AGPL

接下来我们来介绍 GPL 家族的另一位成员 AGPL，AGPL 是一个更严格的 GPL 协议，代表性的项目是 MongoDB —— 一个非常知名的非关系型数据库。考虑到现在是互联网时代，很多公司会将 MongoDB 之类的开源软件进行一些修改或封装，然后提供基于 MongoDB 的云服务来盈利。于是就有了 AGPL 许可证，AGPL 将分发的行为扩展到了「通过网络提供服务」，之前的 GPL 对于服务器端应用是没有什么约束的，因为服务器端应用并不会发布给最终用户，但如果你使用了 AGPL 来通过网络提供服务，那么你也需要开源你对其的修改。

就在发文前，MongoDB 宣布新版本将会切换到 SSPL，这个协议是对 AGPL 的进一步细化，规定了若提供主要价值来自于 MongoDB 的云服务，就必须开源能够让用户运行起来这个服务所需的所有组件，包括用户界面、API、自动化、监控、备份等组件。

非 Copyleft 许可证

前面花了很多篇幅去介绍 GPL 家族，的确他们是自由软件中最有趣也最优代表性的部分。但现在一些新的开源软件往往会选择一个非 Copyleft 的许可证，例如 Apache、BSD、MIT 等等，不过这些协议的条款相对简单，一句话便可概括。

其中 MIT 许可证仅仅要求用户进行署名，所谓署名是你必须将用到的自由软件代码的许可证附带在你分发的每份软件中，并且让用户能够看到，例如在很多软件的某个隐蔽的角落，你可以看到一个叫「开源许可证」或「法律信息」的按钮，点开可以看到它用到的所有自由软件的许可证。

当然你也就可以连署名都不要求的话，你可以选择直接将你的作品释放到共有领域，例如 SQLite（一个嵌入式关系型数据库）就直接被发布到了共有领域，你可以用它的代码做任何事情，连署名都不需要。

BSD 会稍微严格一些，除了要求署名之外还要求用户不得使用其名字用作宣传的用途，例如你基于一个 BSD 协议的软件发布了一个修改后的版本你必须为它起一个新的名字，和原有项目做出明确的区分，以免误导其他用户。

而 Apache 许可证在 BSD 的基础上还要求你在发布修改后的版本时明确注明对哪些文件、做了什么修改。

这里需要注意的一点是这些许可证的授权往往是 不可撤销 的，一旦你曾经以某个许可证发布了一个项目，那么任何人都可以按照你当时发布的那个版本的许可证去使用你当时发布的那个版本的代码。当然你可以从某个时间点开始以新的许可证来发布代码，但其他人依然可以选择遵守旧的许可证去使用旧的版本。这一点是写在大部分自由软件许可证中的条款，是出于保护自由软件代码的使用者的考虑，否则如果你可以随时收回你的授权，是没有任何人敢去用你的代码的。

Creative Commons

前面我们提到的的都是针对于代码的许可证，但有的时候我们也希望授予文本作品的读者一些自由。我接下来介绍的这个「创作共用许可证」就是这样的一种许可证，通常缩写为 CC.

CC 许可证将文本作品的作者常见的几种诉求总结成了四点：

• BY 署名
• SA 相同方式共享，所有的衍生作品都必须使用同样的许可证，类似于 GPL 的要求，但因为文本作品的衍生关系相对简单，所以可能并没有太多人关注它的传染性
• NC 禁止商业使用
• ND 禁止演绎

这四种诉求可以被组合到一起，例如我的博客选用了 CC 署名、非商业使用、相同方式共享发布。也就是说你可以非商业的目的自由地使用和分发这篇文章，需要提供指向 caipai.fm 的链接，如果你修改了文章则必须也允许其他人以相同的方式转载和修改。

CLA

我们还会看到一些软件同时是自由软件（比如 Qt 和 MySQL），也提供了商业授权，如果你购买了他们的商业授权，那么你并不需要遵守自由软件的许可证，这是如何做到的呢？

首先，一个作品的作者是有权决定如何把这个作品的使用权授予其他人的，他可以即发布一个面向所有人的自由软件许可证的版本，当然这个自由软件版本其实也是有限制的；他也可以以单独的、有着完全不同的限制的方式来把使用权授予其他人，商业授权就是这样实现的。

但很多社区开发的自由软件，例如 Linux，一旦有来自社区的贡献者参与了进来之后，最初的发起者就没有权利去修改许可证或发行商业版本了，因为这时已经没有人拥有这个软件的所有的代码的所有权利了，因为这个软件的不同的部分的代码来自不同的贡献者，他们只是以这个项目的自由软件许可证发布他们的代码，所有人都必须遵守这个自由软件许可证，而显然将一个 GPL 许可证的自由软件改为其他非 Copyleft 许可证是不行的，因为这违反了 GPL 许可证的要求。

所以在实践上，很多社区开发的软件会要求贡献者在提交代码之前签署一份协议（通常缩写为 CLA），这份协议的主要内容有两点：

• 贡献者授予软件的维护者有关此次贡献的代码的永久的、无限制的使用权（而不仅仅是按照自由软件许可证授权）。
• 贡献者声明自己拥有所贡献的代码的相关权利（而不是从另外一个不兼容的许可证的项目、或非开源项目中拷贝的）。

如果一个社区开发的软件一开始就这么做，那么第一条保证了软件的维护者始终拥有对所有代码的没有限制的使用权，这样项目的维护者才有可能修改许可证或者发行商业授权；而第二点我个人认为只是为了在出现著作权纠纷时，规避一些法律上的问题。

拓展阅读：

• https://www.gnu.org/philosophy/free-sw.html（GNU 对自由软件的解释）
• https://choosealicense.com（GitHub 旗下帮助你选择开源软件协议的网站）
• http://web.archive.org/web/20161026203954/https://cla.github.com/agreement（GitHub 的 CLA）