以下内容仅为我自己操作转出的记录，仅供参考
一切请以银行和基金平台提供的信息为准

准备工作

在转出之前，先确保在直销平台中所有的交易都已经确认，并终止定投计划。并且要和银行确认好，托管转入的份额会不会统计在银行的总资产中。

天弘基金平台支持在网页上自助完成一步转托管，在提交之前，需要先知道招商银行的席位号、网点号（这个似乎只有天弘基金转出时才需要）、转入的基金账号。

我从基金平台和银行客服问到的招商银行席位号和网点号都是007，基金账号可以从招商银行的手机银行里面查到。

• 登录招商银行手机银行，前往财富页面，再点基金，然后点击右上角小人图标

• 在弹出的菜单里点我的基金账号

• 然后在列表里找天弘基金，点进去

• 在我的基金账号页面里找到关联基金交易账号，这就是要转入的基金账号

如果在基金账号里找不到天弘基金，那就先在银行里按照最低金额买一次，等基金公司确认之后再找。在银行里找不到基金公司多半是因为之前没在银行里开过这家公司的账户，买一份代销等确认好了之后，账户就开好了。

提交转出申请

转出操作需要到天弘基金网页版操作。登录到自己的账户，在列表里找到要转出的直销份额，点击其他菜单中的转托管出。

然后分别填写要转出的份额、招商银行的席位号（对方销售商）、网点号（对方份额托管网点），和刚刚查到的基金账号（对方交易账号）。

确认无误后，点击下一步，并在弹出的窗口中再次确认，就提交好了。然后就是等基金平台确认托管转出交易。如果确认失败，可以到基金平台找人工客服凭姓名和身份证号查询失败原因。

为什么要买它

决定买电纸书阅读器主要有两个原因。之前我一直用iPad Pro看书，但这玩意又大又重，用起来不方便，拿在手里不舒服不说，通勤路上还得反复从包里掏出来再塞回去，实在是麻烦。实体书也买了不少，但是搬家后又懒得翻出来，可怜的书们就只是在箱子里吃灰。所以我总是想找一个小巧的可以随时看书的玩意。正好在同事的桌子上看到一个小巧的阅读器，就决定也搞一个。

选择文石Leaf 3C也没啥特别的理由，就是这位同事用的Leaf 2，我拿起来大概试了下，尺寸和重量都挑不出啥毛病，加上不想花太多钱，于是就买了这个二手的Leaf 3C。

初体验

一拿到手，第一感觉就是，好轻！我终于不用再端着iPad看书了(T_T)！机身只有6毫米厚，重量也只有190克，粗略感受下来，比手上的iPhone 12 Pro大概要轻一半，甚至跟它的磁吸保护壳差不多重。轻薄纤细的机身拿起来就非常的顺手。

前面板是一整块有点磨砂质感的玻璃，触感细腻，摩擦力也正正好，而且不会留下指纹。占据大部分面积的一块7英寸的Kaleido 3彩墨触屏，右边边缘有两个可以用来翻页的按键，正好适合我用右手拿着看书。如果你不喜欢用右手操作的话，系统层面也支持将整个屏幕旋转90度、180度、270度，来让你以一个你喜欢的姿势阅读。不过这个按键的手感并不是非常好。首先它会晃，其次，它并不是像手机的音量键那样是一个平整的按键，而是按键的中部下面压着一个贴片按钮开关，如果你按的位置很靠近边缘的话，就很有可能根本按不下去。

阅读黑白文本的体验不用说。7英寸，300PPI的屏幕，我觉得完全够用。屏幕还自带前光，可以调节亮度和色温，就算睡前想要看会书也是没问题的，虽然可能对眼睛不太好……

但要是你想拿它看彩色的漫画，那你可能就要失望了。这块屏幕只能展现4096种颜色（根据维基百科，相当于上世纪八九十年代的Amiga电脑），彩色表现非常的素，没办法展现鲜艳的色彩。实际的显示效果可以看下面的对比图。系统虽然自带了“均衡”和“鲜艳”两种色彩预设，也可以自定义，但恕我眼拙，没看出有什么明显的区别。

显示	截图

它的内置阅读器也有个小bug。我目前的系统版本是4.0.2，在使用V3引擎阅读竖版书籍时，书中的插图无法正常显示。比如下面的对比图中，“一九二九年的大崩盘”和“印钞票”这两节之间是有一个插图的，但是以竖排显示时，阅读器无法正常显示插图。好在这个问题可以通过在阅读器内单独讲这本书转为横排来解决。我也向文石开发团队反馈了这个问题，希望将来会修复。

竖排	横排

还有个小问题是，它会有点阴阳屏。如果仔细盯着它看，就能隐约看到远离按键的一侧要比靠近按键的一侧要稍微暗一点。但查过资料发现，这应该是电纸书的通病，因为前光是从侧面照明的，无法避免亮度不均匀的问题，只能自己慢慢习惯。

软件上，它的操作系统是基于Android 11深度定制的，除了自带的阅读软件，你还可以安装其他的读书平台（甚至可以直接把Z-Library的客户端装上，就省的用电脑往里面拷书了）。考虑到电纸书的使用场景，系统提供了一个方便的入口来控制应用冻结，并且新安装的软件也可以自动冻结，这样就可以有效避免各种后台进程在你并不需要的时候运行，让续航更稳。实际用下来，续航不用担心，除非你有无可救药的续航焦虑。我每天开着前光，平均用它内置的阅读软件看两小时，一周下来大约会消耗70%电量。不过这是用内置阅读软件的情况，用第三方软件的话，耗电就明显会变多。

买书

虽然Z-Library上面可以免费下载海量的书籍，但我更愿意花钱购买正版来支持作者。另外我希望买完书之后能自己保存一份电子书的副本，并用任意我喜欢的工具阅读，所以像微信读书和京东书城等国内常用的电子书平台全部被我排除在外 —— 它们只让你在自家的app里阅读，并不能下载，太不自由了。

而且比起订阅读书软件的会员，我也更喜欢买断制。因为我觉得，只有我买断这本书并且下载到这本书的副本，我才是真正拥有了这本书。而开会员更像是租了某个图书馆的入场资格，虽然整个图书馆的书我可以随便看，但我并不拥有任何一本，平台也可以随时换源甚至下架某本书，而我对此无能为力。更别提有的书只在A平台能看，而另一本书只能在B平台看的这种麻烦事。

最后我折腾出来一套有点拧巴的买书流程：

• 首先去Rakuten Kobo、HyRead、读墨等港台的电子书商城购买，然后通过Calibre的插件把DRM去掉，然后导入阅读器，用它自带的软件阅读。美国亚马逊的Kindle商城里面也可以买，但我还没试过去除Kindle格式电子书的DRM，也不确定阅读器是否支持Kindle的AZW格式。
• 如果在上面这三个书店都找不到，那就去微信阅读里面买断这本书，然后再去Z-Library找高质量的epub。我不清楚这样下载到的书在严格意义上还算不算盗版，但至少我为它付费了，读起来也心安理得。
• 如果Z-Library上都找不到高质量的副本，那就用第三方工具从微信读书中导出，再将下载到的HTML和资源文件放进Calibre，自己手动做成epub。这做起来就比较耗时耗力了，好在下载器是开源的，我可以修改它的代码为我完成最麻烦的部分。

目前我的书都是在Rakuten Kobo上面买的，唯一的门槛就是，你要有一张VISA或者万事达卡组织的借记卡或信用卡，或者有一个PayPal账户。但是各家银行都有发行VISA和万事达的信用卡，中国区PayPal注册也很简单，所以也不算什么大问题。哦对，如果你买的书很贵的话，记得去网上搜Kobo的折扣码，我用过一个7折和一个8折的折扣，还是很爽的。便宜书就别用了，因为一个折扣码只能用一次，别浪费在便宜的书上。

还有一点要注意，因为这些平台都位于香港或台湾，所以大部分书都是繁体中文。如果你平时不习惯看繁体字，那买之前最好先确认一下。

使用Calibre去除DRM

⚠️ ⚠️ ⚠️ 本节内容所述教程仅应用来方便自己阅读 ⚠️ ⚠️ ⚠️
⚠️ ⚠️ ⚠️ 尊重知识产权 ⚠️ ⚠️ ⚠️
⚠️ ⚠️ ⚠️ 不要制作和分发盗版书 ⚠️ ⚠️ ⚠️

在Kobo购买的电子书都是有DRM保护的。虽然我们可以使用Adobe Digital Editions下载得到epub文件，但是这些文件都受Adobe DRM保护，拷进阅读器也无法打开。为了能脱离Kobo平台，我们就需要使用Calibre和DeDRM插件来去除DRM。

首先到Calibre官网下载并安装Calibre。然后前往DeDRM_tools - GitHub Releases下载最新的DeDRM插件。将下载的zip文件解压缩，可以得到两个压缩包DeDRM_plugin.zip和Obok_plugin.zip。

接下来打开Calibre，点击顶部工具栏的首选项按钮。

首先进入导入/导出中的保存书籍到硬盘，取消勾选将非英语字符转换为对应英语字符，并点击应用，这样在导出时就可以保留书籍原本的文件名。

然后在首选项窗口，找到高级选项中的插件并点击，接下来点击从文件加载插件，分别加载DeDRM_plugin.zip和Obok_plugin.zip。安装完成后勾选插件列表上面的仅显示用户自己安装的插件并搜索drm，如果搜到如下图一样的结果，就说明插件安装成功了。

接下来前往Adobe Digital Editions下载页，下载Adobe Digital Editions (ADE)并安装。安装完成后打开ADE，点击帮助菜单中的授权计算机。如果你有Adobe账号的话，就在这里输入账号的邮箱和密码来登录；如果没有的话，就勾选窗口下部的我想要在不使用ID的情况下对我的计算机授权。然后点击授权按钮，等待授权完成。

接下来，前往Kobo书城的我的账户 -> 书籍，找到你已经购买的电子书，点击书名上方的三个点展开菜单，再点击菜单中的下载。这时候你会下载到一个名为URLLink.acsm的文件。把这个文件拖进ADE，然后ADE会下载这本书的EPUB文件，当然，这个文件是加密的。下载成功后，在ADE中右击刚刚下载的书，并点击在资源管理器中显示文件。

然后，从刚刚打开的资源管理器窗口中，将你的书拖到Calibre的主界面中，这时候Calibre就会自动解除这本书的DRM并导入它的书库。然后在Calibre中右击这本书，点击菜单打开书籍文件夹 -> 打开书籍文件夹，就能找到去掉了DRM的EPUB文件。然后你就可以把这个文件复制到阅读器中，使用它内置的阅读器阅读了。

因为我用的是搭载RouterOS的Mikrotik路由器，所以文中涉及的命令都将是RouterOS的语法。不过我也会讲明操作的原理，所以你也可以跟着思路针对你的路由器进行配置。唯一需要注意的就是，要确保你的路由器可以自己配置iptables规则。

如下是我的网络拓扑，其中：

• 光猫的管理地址为192.168.0.1，独占192.168.0.0/24网段
• 路由器的地址为192.168.1.1，它和内网的各个设备占用192.168.1.0/24网段

那么要通过路由器访问到光猫的话，只需要做下面三件事：

• 给路由器的WAN口分配一个192.168.0.0/24网段的地址，比如192.168.0.2

1

/ip/address/add address=192.168.0.2/24 comment="Modem access" interface=ether1 network=192.168.0.0

• 在防火墙的nat表中配置如下规则

1

/ip/firewall/nat/add action=masquerade chain=srcnat comment="Access to modem subnet" dst-address=192.168.0.0/24 src-address=192.168.1.0/24

这条规则可以让路由器在收到向光猫发出的数据包后进行一次源地址伪装，使其看起来像是从路由器发出的，并在路由器收到响应的数据包后，再将其目标地址和端口修改会发出请求的电脑。

• 在防火墙的mangle表中配置如下规则

1

/ip/firewall/mangle add action=accept chain=prerouting comment="Access to modem subnet" dst-address=192.168.0.0/24 src-address=192.168.1.0/24

这条规则将告知路由器在收到从内网访问光猫的数据包时，直接放行这个数据包，不再进行任何其他的标记或改变路由行为的操作。这条规则并不是必须的，但是如果你在mangle表中有其他的规则，那还是加上它比较好，以避免访问到光猫的数据包被错误的标记，或者产生非预期的行为。

上面两条RouterOS命令我也用ChatGPT翻译成了iptables命令，供参考：

1
2
3
4
5

# /ip firewall nat add action=masquerade chain=srcnat comment="Access to modem subnet" dst-address=192.168.0.0/24 src-address=192.168.1.0/24
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.0.0/24 -j MASQUERADE -m comment --comment "Access to modem subnet"

# /ip firewall/mangle add action=accept chain=prerouting comment="Access to modem subnet" dst-address=192.168.0.0/24 src-address=192.168.1.0/24
iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -d 192.168.0.0/24 -j ACCEPT -m comment --comment "Access to modem subnet"

注销的卡

开始之前先盘一下库存和年费：

• 招行银联金卡 - 6笔消费刷免年费
• 招行全币种VISA卡 - 有效期内免年费
• 招行全币种JCB卡 - 有效期内免年费
• 招行运通金卡 - 6笔消费刷免年费
• 招行英雄联盟联名银联金卡 - 6笔消费刷免年费
• 招行和卡银联金卡 - 6笔消费刷免年费
• 交行魔都优逸白金银联卡 - 6笔消费刷免年费
• 浦发魔都白金银联卡 - 终身免年费

看得出来，光是要把年费刷掉，就要费一点精力，而且这些卡几乎没有任何权益，所以非必要就注销。

• 招行：
  • 只留下银联金卡、VISA和JCB。银联用来备用，而且买苹果设备还能享受24期免息分期。JCB绑了日区Apple ID做iCloud付款卡，而现在日区又不能新绑非日本发行的JCB卡，所以这张万万不能没。VISA反正免年费，留着以防万一。
  • 运通在当时申请的时候还是有效期内免年费的，但是现在运通卡支持人民币结算后，就要收年费了。所以注销。该说不说，最早拿到的是运通Clear卡，卡面很好看（我也是冲着卡面才办的），但后面换发就变成了百夫长经典金卡。
  • 英雄联盟卡是还没毕业那会就申请的校园信用卡，为的是打英雄联盟对局就能得银行积分，但是就算最上头的那段时间似乎也没攒下多少积分，而且那会似乎都已经是活动的尾声了。现在留着也没用，所以注销。
  • 和卡……嘛，它其实是顶替了崩坏三联名八重樱银联卡，但到期的时候已经没有联名卡板了，给我换成了和卡。本来就是收藏来用的，所以注销（想来当初就不应该激活的）。
• 交行：这卡好像是刚工作那会，银行业务员直接来公司给我们推销的。想想，刚毕业，也没啥钱，就能下个白金卡，自然是忍不住诱惑就办了。结果最后沦为逢年过节回老家的时候刷地铁用。没权益还要惦记着刷免年费，所以注销。
• 浦发：好像也是刚工作的时候银行业务员直接来公司推销的，当时一听，白金卡，还终身免年费，那干脆办下来，放着不用也没啥损失。结果好像去年的时候，这张卡因为太久不用，在银行系统里变成了一个很奇怪的状态，就是卡虽然没注销，但是在浦大喜奔里面又没法查到状态，点进去就会报错。既然如此，干脆销了一了百了。

新办的卡

说起权益，我主要关心消费返现和机场贵宾厅。今年4月份去香港旅游回来的那天，我累到坐在登机口的长椅上几乎晕厥，那时候就想，如果能给我个沙发让我舒舒服服小眯一会就好了。那机场的贵宾厅岂不是就能满足？但是毕竟每年我也就是往返老家以及出去旅游一两次的时候才会坐飞机，满打满算一年也就坐4到8趟，而刚性年费的高端白金卡提供的几十次甚至无限次贵宾厅，对我来说绝对是溢出的。

所以最后需求就固定成，有消费返现，有机场贵宾厅，权益达成条件不要太复杂，可以免年费，而且最好能集中在同一家银行，这样可以更集中地累计积分。

经过研究之后，我最终得到了这样的一个方案（注意，以下关于权益的描述仅代表我个人的理解，请以银行app中的实际描述为准）：

• 广发多利白金卡
  • 权益：
    • 美团和滴滴消费返现10%（还有另外几个渠道也会返10%，但我不常用就不写了）。
    • 支付宝、微信、云闪付消费返1%。
    • 每自然月最多积累100元返现。每自然月消费满3000元后，次月就可以到app的权益中心用累计的返利金兑换返利券（目前是攒满100就能兑5张20的，消费入账过几天后会自动抵扣，不用手动操作）。
  • 缺点：这张卡消费没有积分。
  • 年费：首年免年费，消费12笔或连续12个月绑定第三方支付（微信、支付宝、京东三选一）免次年年费。说白了就是往支付宝上一绑就不用操心了。
  • 使用场景：上班的时候用美团点外卖，以及偶尔用滴滴打车，返利金攒够100元并且总消费满3000元就换别的卡刷。毕竟消费没有积分，这个月溢出的返利金也不会结转到次月，再继续刷下去又成了有出没进。
• 广发万事达真情白金卡
  • 权益：
    • 京东、拼多多、美团等渠道消费8倍积分。
    • 微信、支付宝消费1.5倍积分。
    • 境外消费2倍积分。
  • 年费：首年免年费，消费12笔或连续12个月绑定第三方支付（微信、支付宝、京东三选一）免次年年费。既然这个在京东消费有8倍积分，那就挂在京东支付上免年费。
  • 使用场景：既然美团消费8倍积分，那返利卡刷满之后，再点外卖就刷这个，此外就是在京东买东西也刷这个。
• 广发美国运通真情白金卡
  • 权益：
    • 网购消费可以得三倍积分，亲测下馆子吃饭用支付宝付款，或者用外卖平台点外卖，然后用这张卡付款，就能得三倍积分。
    • 在运通体系中是蓝盒子SELECT级别，绑定运通微信服务号后还能享受运通卡组织的一些权益，一大堆但都聊胜于无，就不写了。
  • 年费：首年免年费，当年年费周期内消费12笔免次年年费。
  • 使用场景：返利卡刷满之后就主刷这个，用日常各种消费积累积分。吃吃喝喝啥的咋也能刷出来12笔，顺便就把年费免了。
• 广发银联鼎极白金卡（臻瑞版）
  • 权益：
    • 当月消费满3000元后，次月起两个月内可免费享受2次广发冠名机场和高铁站贵宾厅。
    • 境内消费2倍积分，境外消费3倍积分。
    • 可以15000积分兑换100航空里程。
    • 消费积分在5年到期后可以再延续5年有效期，也就是说你累积的积分可以10年不过期。
    • 附带一张Infinite级别的VISA卡，可以享受VISA卡组织的权益。
    • 除此之外还有很多别的权益，但我用不上，就不写了。
  • 年费：首年免年费，激活后365天内消费满48笔，或激活日起连续12个月绑定第三方支付（微信、支付宝、京东三选一）免次年年费。说白了也是往支付宝一绑就不用操心了。
  • 使用场景：这张卡消费权益不如上面几张，但是它的重点是可以用15000积分换100航司里程，我逢年过节往返老家主要坐国航的航班，那么除了坐飞机积累的里程，还可以用这张卡兑换国航里程。所以这其实是一张扔抽屉里面的工具卡，不消费，只用它延长积分有效期以及兑换航司里程，
• 广发万事达给力外币卡
  • 权益：境外消费随机返现，返现直接入账，不占用多利白金卡的返利金池。别的记不清了，这张卡暂时还是下架状态，也没法再去查证。
  • 缺点：app上没有细说“随机返现”的细则，暂不清楚是笔笔返随机金额，还是有的消费给返有的不给。另外，虽然这张卡是万事达World级别，但是不能参与万事达消费大挑战活动。
  • 年费：首年免年费，该卡刷卡达3笔，或当前年费周期下本人所有信用卡消费15笔，免次年年费。因为我日常就刷上面那些广发信用卡，所以这张就会连带着免掉年费。
  • 使用场景：绑Netflix之类的所有能绑的境外平台，薅月费年费的羊毛，以及出境游可以带上。

以上这些就是日常消费的主力卡，平时靠多利白金卡和万事达真情白金卡薅返利金和积分的羊毛，如果有坐飞机出行的需求，就拿鼎极白金卡提前一个多月买好往返机票，这就几乎能凑满贵宾厅的3000元门槛，就算不够也就缺几百块，点点外卖下下馆子，或者给公交卡和Steam充个值就有了。而且都是同一家银行，积分非常集中，并且年费全部都可以免掉。需求达成。

除了上面这些，我还办了另外几张锦上添花的。

• 中国银行全币种国际芯片威士白金卡 - 首先这张卡是免年费的，其次它是VISA Infinite级别，还有开户礼羊毛可以薅。计划薅完开户礼后就放在抽屉里当作备用。
• 中国银行JCB招财猫白金卡 - 这张卡也是免年费的，而且是日元入账，免去了日元 -> 美元 -> 人民币的二次汇率折损。同样也有开户礼羊毛可以薅。此外，这张卡是JCB Platinum级别，每年可以免费享受6次日本和夏威夷的贵宾厅，并且可以绑定Lounge Key，每年免费享受2次日本和夏威夷以外的贵宾厅。所以计划是薅完开户礼后就当备用，将来去日本旅游的时候带上，以及将来绑到日区iCloud消费。
• 中国银行莫奈睡莲万事达卡 - 这张卡也免年费，是万事达World级别，并且可以参与万事达消费大挑战活动，而且最重要的是卡面很好看。目前还是放在抽屉里备用，将来出境游的时候可以带上试试参与消费大挑战活动。
• 光大阳光车主数字卡财富版紫蕴麒麟 - 这张卡我主要看中它每年给5点贵宾休息室点数，以及月均资产达标3000元就能免年费，可以低成本的拉低我每年贵宾厅的需求成本。这张卡暂时还没办，因为我是这个月才往光大银行存了3000元，要在下个月办卡才能免掉年费。

这几张卡在实际使用体验后，我会再发文分享我的使用心得。

以上。

说干就干，在一顿网上冲浪之后，我看到有人已经实现了利用字节跳动火山引擎的“扣子（Coze）”实现了这个功能，但作者并没有放出来具体的实现。我一方面很不喜欢需要私信进群这种操作，另一方面还是自己做一个才最符合自己的需求（拜托，我可是程序员欸），所以自己动手实现了一个工作流，可以完整转存帖子的标题、内容、图片到自己的Notion。

大致的功能设计

关于这个工作流，我希望它能做到这些：

• 自动解析小红书分享链接（类似94 某某某发布了一篇小红书笔记，快来看吧！ 😆 zop6CK2fPRDGwIT 😆 http://xhslink.com/a/5ZOdZhppuYteb，复制本条信息，打开【小红书】App查看精彩内容！）的这种。我需要它能从这个分享链接中获取到对应笔记的真实地址。哦对，这条链接就不用试了，因为这是一条我自己编的。
• 自动解析小红书笔记，将里面的标题、内容、图片全部提取出来。
• 在成功提取出笔记内容之后，它可以将图片上传到Notion，并将其嵌入到Notion文档中。
• 可以通过手机直接分享到工作流，而不是拷出来分享链接，再打开Coze手动运行它。

我不需要它做的是：

• 转存视频。因为视频我可以直接保存到相册，或者手机录屏。而且对我来说，视频的信息密度比文字低，就算保存下来，我也要再把内容提炼成文字版保存。
• 转存评论。评论区的内容通常会很杂乱，没有全部转存的必要。有价值的内容我再手动拷到自己的帖子里面就是了。
• 监控小红书收藏夹。我觉得它暂时没这个本事，要做到这个，我可能需要单独开发一个程序。

简单介绍一下它具体是怎么工作的

这个工作流看起来是这样的

具体工作起来，会进行下面这几步操作：

• 首先使用配置好的token尝试连接Notion，如果连不上，那也就别费劲干后面的事了，赶紧报错通知用户检查
• 接下来先解析分享链接，把实际的短链接拿出来，然后再用短链接换到对应的长链接
• 得到长链接后，就可以调用插件得到这个笔记的标题、内容、图片地址，并能以JSON格式输出
• 得到了笔记的内容之后，我就可以把图片逐个下载下来，再上传到Notion，然后使用这些内容创建一篇帖子
• 最后，如果帖子创建成功，那么返回帖子的链接

在Notion中要做的准备

我的这个工作流是基于Notion的数据库实现的，所以首先需要在Notion中创建一个新的数据库。这个数据库将会包含三个列：

• Name - 数据库默认存在并不可删除的列，作为帖子的标题
• Images - 一个Files & media类型的列，图片将在这里保存及展示
• Tags - 一个Multi-select类型的列，用于保存帖子的标签

最终你应该会得到一个这样的数据库：

接下来，因为我们需要调用Notion的API来上传图片和创建帖子，所以我们需要前往Notion Integrations页面为其创建一个API key，配置它的权限，并将刚才创建好的数据库与它绑定。

首先点New Integration创建一个API key。名字无所谓，类型选Internal。

创建成功后会自动跳转到Configuration页面。在Capabilities的Content Capabilities中勾选Read、Update和Insert权限，然后在User Capabilities中选择No user information。

接下来到Access页面，点Edit access并勾上刚刚创建的数据库。

至此Notion部分的准备工作就结束了。

创建工作流

接下来就是到扣子平台创建工作流了。登陆后点击创建，然后选择创建智能体，起个名字点击创建，就会进入智能体的编辑界面。

配置工作流的变量

首先点击变量部分的加号，并创建三个变量：

• rednote_cookie - 小红书的cookie，解析笔记内容要用到，并且这个cookie似乎不能来自被封禁的账号
• notion_page_root - Notion数据库的ID，在Notion中点进去上面创建的数据库，将浏览器地址栏中的URL去掉https://www.notion.so/和问号后面的东西，剩下的这部分就是数据库ID
• notion_secret - Notion的API key，回到创建API key的页面，点击Internal Integration Secret的Show并把内容拷过来就行

然后，就可以开始开发工作流本体了。

配置工作流组件

这里我会逐个介绍每个节点的配置，至于节点之间的连接关系，如果你看文字看不明白的话，就参考上面的截图。

• 在开始节点添加一个string类型的输入，名为rednote_share，用来传入小红书的分享链接
• 添加notion数据库助手服务的get_database_info节点，添加两个输入变量
  • secret引用用户变量notion_secret
  • url填写数据库的URL，就是从浏览器地址栏复制出来的那个，记得去掉问号和后面的东西
• 添加一个选择器节点，检查get_database_info节点的code输出字段是否不等于0。如果满足条件，即说明数据库连接不成功，应当报错并退出
• 为上一步的选择器节点的如果添加一个输出节点
  • 添加两个输出变量
    • database_id引用get_database_info的输出字段id
    • message引用get_database_info的输出字段msg
  • 配置输出内容为连接Notion数据库{{database_id}}失败，错误信息：{{message}}
• 再为上一步的选择器节点的否则添加一个小红书的get_url节点，其输入变量share_content引用开始节点的rednote_share
• 继续为get_url添加小红书连接处理的shoturl节点，其输入变量short_url引用上一步get_url节点的url输出字段
• 然后添加一个小红书笔记详情的GetNoteData节点，其输入变量url引用上一步shoturl节点的long_url输出字段
• 接下来创建一个代码节点，这是整个工作流的核心
  • 添加如下输入变量：
    • title引用GetNoteData的title输出字段
    • content引用GetNoteData的content输出字段
    • images引用GetNoteData的images输出字段
    • tags引用GetNoteData的tags输出字段
    • parent_id引用用户变量notion_page_root
    • secret引用用户变量notion_secret
  • 添加一个类型为Object的输出变量response，并添加如下输出字段
    • status，类型为Integer
    • message，类型为String
    • url，类型为String
  • 点击代码节点的在IDE中编辑，清空内容并粘贴如下代码片段（我知道，这代码很不Pythonic）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149

import os
import tempfile
import requests_async as requests


async def main(args: Args) -> Output:
    params = args.params

    parent_id = params['parent_id']
    secret = params['secret']
    title = params['title']
    content = params['content']
    images = params['images']
    tags = params['tags']

    file_upload_id_list = await transfer_images(secret, images)
    post = build_post(parent_id, title, content, file_upload_id_list, tags)
    create_post_response = await create_post(secret, post)

    # 构建输出对象
    ret: Output = {
        "response": create_post_response
    }
    return ret


async def transfer_images(secret: str, images: list[str]) -> list[str]:
    file_upload_id_list = []
    for image in images:
        tmp_file_path = await download_image_file(image)
        file_upload_id = await upload_file_to_notion(secret, tmp_file_path)
        file_upload_id_list.append(file_upload_id)

    return file_upload_id_list


async def download_image_file(url: str) -> str:
    tmp_file = tempfile.NamedTemporaryFile(delete=False, suffix='.jpg')
    tmp_file_path = tmp_file.name
    tmp_file.close()

    response = await requests.get(url)
    with open(tmp_file_path, 'wb') as file:
        file.write(response.content)
    
    return tmp_file_path


async def upload_file_to_notion(secret: str, file_path: str) -> str:
    # Initiate file upload
    url = 'https://api.notion.com/v1/file_uploads'
    response = await requests.post(url, headers={
        'Authorization': 'Bearer ' + secret,
        'Notion-Version': '2022-06-28',
    }, data={
        'mode': 'single_part',
    })
    file_upload_id = response.json()['id']

    # Upload the file
    with open(file_path, 'rb') as file:
        files =  {
            'file': (os.path.basename(file_path), file, 'image/jpeg')
        }
        url = f'https://api.notion.com/v1/file_uploads/{file_upload_id}/send'
        await requests.post(url, headers={
            'Authorization': 'Bearer ' + secret,
            'Notion-Version': '2022-06-28',
        }, files=files)
    
    return file_upload_id


def build_post(parent_id: str, title: str, content: str, file_ids: list[str], tags: list[str]) -> object:
    content_blocks = build_content_blocks(content)
    
    files = []
    for file_id in file_ids:
        files.append({
            'type': 'file_upload',
            'file_upload': {
                'id': file_id
            }
        })


    return {
        'parent': {
            'database_id': parent_id
        },
        'properties': {
            'Name': {
                'title': [
                    {
                        'text': {
                            'content': title
                        }
                    }
                ]
            },
            'Images': {
                'files': files
            },
            'Tags': {
                "multi_select": build_tag_properties(tags)
            }
        },
        'children': content_blocks
    }


def build_content_blocks(content: str) -> list[object]:
    blocks = [];
    paragraphs = content.replace('\t', '').split('\n')
    for paragraph in paragraphs:
        blocks.append({
            'object': 'block',
            'type': 'paragraph',
            'paragraph': {
                'rich_text': [
                    {
                        'type': 'text',
                        'text': {
                            'content': paragraph
                        }
                    }
                ]
            }
        })

    return blocks;


def build_tag_properties(tags: list[str]) -> list[object]:
    items = []
    for tag in tags:
        items.append({
            "name": tag
        })
    return items


async def create_post(secret: str, post: object) -> str:
    url = 'https://api.notion.com/v1/pages'
    response = await requests.post(url, headers={
        'Authorization': 'Bearer ' + secret,
        'Notion-Version': '2022-06-28',
    }, json=post)
    return response.json()

• 为代码节点添加一个选择器节点，判断代码节点的输出字段status是否为200，并分别为其添加如下后续节点
  • 如果部分添加输出节点，添加一个输入变量output，引用代码节点的url输出字段，输出内容为{{output}}，负责在帖子创建成功后输出帖子URL
  • 否则部分添加输出节点，添加一个输入变量output，引用代码节点的message输出字段，输出内容为{{output}}，负责在帖子创建失败后输出错误信息
• 添加一个变量聚合节点并关联连接Notion失败的输出节点、创建帖子成功的URL输出节点、创建帖子失败的错误信息输出节点，其Group1的配置参考下图
  
• 最后为变量聚合节点添加一个结束节点，添加一个输出变量output引用变量聚合节点的Group1输出字段

如果最后你的工作流与我上面的截图一致，那么就大致可以认为你的工作流配置是正确的了。接下来就可以点击试运行按钮，贴一个小红书分享链接，来测试这个工作流。一切正常的话，工作流会输出一个Notion的URL，同时你在Notion的这个数据库中就能看见刚刚转存过来的帖子。

接下来的计划

目前这个工作流虽然实现了转存小红书笔记的功能，但仍有下面几个问题：

• 小红书的cookie不会自动刷新，那么在cookie过期后，整个工作流就不能正常运行，需要用户手动去浏览器拷贝小红书的cookie并进入智能体配置页面更新
• 在手机上不能很方便的调用这个工作流，目前只能进入到工作流编辑页面，通过试运行的方式调用
• Notion中的帖子不会去重，意味着如果我反复转存同一篇笔记，那么Notion中就会出现多个一模一样的帖子
• 小红书解析相关功能依赖别人提供的插件，而这些插件有被下架的风险

所以接下来我计划做两件事：

• 一个Chrome浏览器插件，它可以定时刷新小红书页面并截获cookie，然后调用扣子的API更新对应的变量值
• 一个基于iOS的Scriptable应用的脚本，使其支持系统的分享功能，它将可以调用扣子的API来调用这个工作流，并将小红书分享链接作为参数传入

至于帖子重复的问题我不打算用代码的方式解决，因为收益实在太低了，就算重复了，也无非手动去Notion里删一下的事。插件被下架的风险暂时也不打算考虑，现有的能用就先用着，哪天不能用了再说。

以下内容除特别注明外，皆翻译自原文。我亦不对内容做任何的担保，并不对任何可能产生的后果（包括但不限于文件丢失）负责。

在使用Docker的时候，你有可能会遇到这么一种很难受的情况，就是你敲了Ctrl-C想停掉这个容器，但这个容器却无动于衷。或者又可能你的容器停止了，但留下了一堆僵尸进程。这些问题通常来自于一个开发者们从一开始就没想明白的问题 —— 如果你的程序成为了容器中的PID 1会怎么样。

什么是PID 1

在Linux系统中，PID 1（进程号1）是在系统启动过程中第一个启动的进程。它扮演着一个特殊的角色，即系统的初始化者。它将负责启动和管理所有其他的进程。在Docker容器中，你启动的第一个进程将默认成为PID 1。

例如：

1

docker run -it node:18 node

这时候，Node.js的进程就是PID 1。

为什么PID 1很特别？

PID 1的进程在Linux中会有如下几种特殊的行为：

1. 响应信号的方式不同
   大多数UNIX进程会自动接收并处理类似SIGINT（来自Ctrl-C）和SIGTERM（来自docker stop命令）的信号。
   但是PID 1的进程默认不会接收这些信号，除非它们主动监听。
2. 收割僵尸进程
   如果PID 1不等待子进程，那么这些子进程就会变成僵尸。尽管它们已经退出了，但仍然会消耗系统资源。（译者注：我理解就是在容器停止的时候，主进程不等待它的子进程全部退出成功再退出，而是就自己拍拍屁股走人了）
   这会慢慢地拖慢这个容器的性能，或让这个容器的行为变得失控。

问题示例

假设我们有这样一个简单的Node.js应用：

1
2

// app.js
setInterval(() => console.log('Running...'), 1000);

这个应用会运行在一个Docker容器中：

1

docker run -it node:18 node app.js

如果此时你尝试使用Ctrl-C退出，那么什么都不会发生。很奇怪对吧？因为：

• Node.js在容器中是PID 1进程
• 当它是PID 1的时候，它没有正确转发或监听SIGINT信号

最终，你可能会一边纳闷为啥Ctrl-C不好使，一边反复敲它。这时候就是tini出场的时候了。

tini：轻量的init

tini是个简化的初始化（init）系统，体积只有几KB，并且专为容器环境设计。Docker甚至集成了它，你只需要用--init参数就能开启。

tini负责干什么？

1. 信号转发
   它会监听类似SIGINT和SIGTERM之类的信号，并正确地将其转发到你的应用程序。这样一来，Ctrl-C或docker stop就会按照预期工作了。
2. 收割僵尸进程
   tini会收割死亡的子进程，这样它们就不会变成僵尸了。
3. 就像一个负责任的PID 1一样干活
   它工作起来就像一个真正的Linux初始化系统，只是更小了点。

怎么用tini？

方法1:使用Docker内置的功能

Docker在引擎内部已经集成了tini，所以你在运行容器时加上--init参数，那么Docker就会自动使用tini作为容器内的PID 1进程。你不需要额外安装或配置什么东西，只需要在命令中加上--init，就像这样：

1

docker run --init -it node:18 node app.js

方法2:在Dockerfile中手动添加tini

你也可以显式地为Dockerfile添加tini：

1
2
3
4
5
6
7
8
9
10

FROM node:18

# 安装tini
RUN apt-get update && apt-get install -y tini

# 使tini成为入口点
ENTRYPOINT ["/usr/bin/tini", "--"]

# 运行你的应用
CMD ["node", "app.js"]

然后你可以像往常一样构建和运行它：

1
2

docker build -t node-app .
docker run -it node-app

为什么在生产环境会很重要？

在生产环境（比如Kubernetes）中，无法处理信号可能会引发这些问题：

• 应用程序无法干净的退出
• 数据因为处理停机的逻辑没有触发而导致损坏
• 僵尸进程造成资源泄漏

使用tini就可以用最小的成本避免这些问题。

最后的一点想法

尽管容器内部的行为很容易被忽略，但理解PID 1如何工作，以及tini解决了什么问题，能让你的容器变得更加干净、安全，并更容易维护。所以下次你遇到哪个应用不响应Ctrl-C，记得叫来小小的tini。

译者注：如果你使用Docker Compose编排容器的话，那么在配置文件中指定init: true就可以引入tini了，就像这样：

1
2
3
4

services:
    app:
        image: alpine:latest
        init: true

请实现一个泛型类BlockingQueue：

1. 构造函数里指定队列容量
2. void put(T item) 队列满了会阻塞，直到队列有空间
3. T take()，队列空时会阻塞，直到队列有元素

我寻思做做看，结果写出来的答案我自己都看不下去，那干脆看看Java里面是咋实现的。

我的实现

先看看我写的玩意是啥德行吧。实话说这玩意看着都不像能正常工作的样子（虽然实际上它还真能用）

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

public class BlockingQueue<T> {
    private final Object[] items;
    private final int maxSize;
    private volatile int count;

    public BlockingQueue(final int size) {
        this.items = new Object[size];
        this.maxSize = size;
    }

    public synchronized void put(final T item) throws InterruptedException {
        while (this.count >= maxSize) {
            wait();
        }

        while (true) {
            if (this.count < maxSize) {
                notifyAll();
                break;
            }
        }

        synchronized (this) {
            items[count] = item;
            count++;
        }
    }

    public synchronized T take() throws InterruptedException {
        while (count == 0) {
            wait();
        }

        while (true) {
            if (count > 0) {
                notifyAll();
                break;

            }
        }

        final T item = (T) items[0];

        for (int i = 1; i < count; i++) {
            items[i - 1] = items[i];
        }
        count--;

        return item;
    }
}

这段代码主要有俩问题，一个是这些while循环看着很不爽；另一个是在取出元素后逐个将元素左移的操作效率非常的低；而且满天飞的wait()和notifyAll()也会影响代码的可读性。

那么接下来看看这段代码怎么优化成接近Java自己的实现。

优化阻塞

BlockingQueue的一个机制是，在队列空时取元素的操作会被阻塞，而在队列满时放元素的操作会被阻塞。在Java的ArrayBlockingQueue中，它并没有使用synchronized加锁，而是用了ReentrantLock对象。此外对于阻塞线程和唤醒线程操作，它也没有用wait()和notifyAll()，而是通过两个Condition对象notEmpty和notFull实现。

所以改进方案就是，去掉方法定义中的synchronized关键字，换成用ReentrantLock加锁解锁；去掉wait()和notifyAll()，改成用notEmpty和notFull管理状态以及负责唤醒，同时可以借助这两个变量的语义增强代码的可读性。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

public class BlockingQueue<T> {
    private final Object[] items;
    private final int maxSize;
    private int count = 0;

    private final ReentrantLock lock;
    private final Condition notEmpty;
    private final Condition notFull;

    public BlockingQueue(final int size) {
        this.items = new Object[size];
        this.maxSize = size;

        this.lock = new ReentrantLock();
        this.notEmpty = lock.newCondition();
        this.notFull = lock.newCondition();
    }

    public void put(final T item) throws InterruptedException {
        // 尝试上锁，使其线程安全
        final ReentrantLock lock = this.lock;
        lock.lockInterruptibly();

        try {
            while (count >= maxSize) {
                // 在队列满时使当前线程进入等待状态
                // 直到其signal()方法被调用
                notFull.await();
            }

            // 存入元素，更新元素数量
            items[count] = item;
            count++;

            // 通知此时队列非空，唤醒在调用take()方法时因队列空而被阻塞的线程
            notEmpty.signal();
        } finally {
            // 最后无论如何要保证锁被释放
            lock.unlock();
        }
    }

    public T take() throws InterruptedException {
        // 尝试上锁，使其线程安全
        final ReentrantLock lock = this.lock;
        lock.lockInterruptibly();

        try {
            while (count == 0) {
                // 在队列空时使当前线程进入等待状态
                // 直到其signal()方法被调用
                notEmpty.await();
            }

            // 取出最早被放入的元素
            final T item = (T) items[0];
            // 领头的元素出列了，后面的往前挪一个位置
            for (int i = 1; i < count; i++) {
                items[i - 1] = items[i];
            }
            // 更新元素数量
            count--;

            // 通知此时队列非满，唤醒在调用put()方法时因队列满而被阻塞的线程
            notFull.signal();

            return item;
        } finally {
            // 最后无论如何要保证锁被释放
            notFull.signal();
        }

    }
}

优化取出元素后更新队列内容

如果这是一个非常大的队列，那么用一个for循环将所有元素往左移来更新队列内容的方式会消耗巨量的时间，显然它的效率是非常低的。相比于每次取出元素后都重排数组中的元素，Java中ArrayBlockingQueue则是利用循环数组的思路，通过两个指针来指示当前该从什么位置取或该向什么位置存（这不是经典的双指针玩法么，前段时间刷LeetCode还做过呢，咋就没想起来），这样每次存取元素后，只需要更新指针指向的位置就行，效率可想而知非常高。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

public class BlockingQueue<T> {
    private final Object[] items;
    private int count = 0;
    private int takeIndex = 0;
    private int putIndex = 0;

    private final ReentrantLock lock;
    private final Condition notEmpty;
    private final Condition notFull;

    public BlockingQueue(final int size) {
        this.items = new Object[size];

        this.lock = new ReentrantLock();
        this.notEmpty = lock.newCondition();
        this.notFull = lock.newCondition();
    }

    public void put(final T item) throws InterruptedException {
        final ReentrantLock lock = this.lock;
        lock.lockInterruptibly();

        try {
            while (count >= items.length) {
                notFull.await();
            }

            items[putIndex] = item;
            count++;

            // 存完元素之后，写指针往后挪一位
            // 如果指针挪完之后突破了数组末尾，那么写指针循环到数组头
            // 因为在队列满的时候线程会被阻塞，所以不会出现元素被覆盖的情况
            if (++putIndex == items.length) {
                putIndex = 0;
            }

            notEmpty.signal();
        } finally {
            lock.unlock();
        }
    }

    public T take() throws InterruptedException {
        final ReentrantLock lock = this.lock;
        lock.lockInterruptibly();

        try {
            while (count == 0) {
                notEmpty.await();
            }

            final T item = (T) items[takeIndex];
            items[takeIndex] = null;
            count--;

            // 取出当前元素后，读指针往后挪一位
            // 如果指针挪完之后突破了数组末尾，那么读指针循环到数组头
            // 因为在队列空的时候线程会被阻塞，所以不会出现读到无效元素的情况
            if (++takeIndex == items.length) {
                takeIndex = 0;
            }

            notFull.signal();

            return item;
        } finally {
            notFull.signal();
        }
    }
}

一些无效的尝试

这一节并没有解决方案，如果你不关心我之前的心路历程，那么可以放心跳到下一节。

最起初，我以为是机械硬盘发热导致的，毕竟问题是出在我把机械硬盘装进来之后。为此我还调换了硬盘的安装位置，把机械硬盘从3、4号盘位移到了靠上的1、3号盘位。

1
2
3
4

---------------------          ---------------------
| 1 - SSD | 3 - HDD |    =>    | 1 - HDD | 3 - HDD |
| 2 - SSD | 4 - HDD |          | 2 - SSD | 4 - SSD |
---------------------          ---------------------

可惜，并没有任何好转。风扇依旧时不时开始跟李有田似的狂飙，唯一区别是风扇能刹住车（为李有田默哀一秒……

后来我觉得，会不会是硬盘在跑PT的时候真的太热了？但是我也在下载的时候摸过硬盘，那个温度撑死只能算温热，怎么想也不会造成整机过热啊？但是本着“能解决问题就行，哪怕再花点钱”的想法，我开始找用来替换的4TB 2.5寸SATA接口固态硬盘。结果……并不理想，现在京东自营只找到了三款。更难受的是，根据论坛上的赛博邻居反馈，其中两款是数据火葬场；而剩下的那款，一块盘要卖我两千多块，也就是说两块盘加起来比我买这台Gen 10 Plus都贵。所以，换硬盘这个方案也被否了。

正巧就在这个时候，它又开始狂飙。我想，iLO里面不是能看见温度吗？那赶紧看看是啥玩意这么热呗？这一看，才找到了问题的根源。

问题根源及解决方案

趁着风扇狂飙之际，我进入了iLO的温度页面，发现有个传感器12 - AHCI Max HD的当前温度是50°C，而它的警告阈值是60°C，严重错误阈值是70°C。也就是说，这时候BIOS发现这个东西烫的要挂掉了，所以就要赶紧让风扇转起来散热。等了一会风扇慢下来之后，我发现这个传感器的值变成了35°C，而且怎么刷新都不变。

搁网上一顿冲浪之后找到了惠普的一篇通告，从这里得知这并不是一个物理上的传感器，它检测到的温度是通过惠普的一个叫Agentless Management Service的软件组件向主板汇报的。此外还找到日立的一个类似的通告说硬盘在AHCI模式下会导致风扇转速异常升高。

到ESXi里面检查了之后，发现我用的惠普定制系统里面是带着AMS组件的。这时候我灵机一动，既然是因为AMS汇报了错误的温度才导致这个问题，而要让AMS汇报正确的温度，那我就得把硬盘换成HPE认证的盘，可想而知这玩意没准会相当贵，而且作为个人用户都不一定买得到。那如果我把AMS卸了，让传感器拿不到数据呢？

说干就干。保险起见我先去了惠普支持网站，下载好了最新版的AMS软件包，一旦出了问题我还可以把它再装回去。然后回到ESXi，开启SSH。

1
2
3
4
5
6
7
8
9
10
11

# 找到AMS的软件包名
[root@ESXi:~] esxcli software vib list | grep ams
# 这个是给Gen 10系列用的
amsd 701.11.8.5.22-1OEM.701.0.0.16850804 HPE VMwareAccepted 2023-08-08
# 这个是给Gen 11系列用的
amsdv 701.11.3.0.17-1OEM.701.0.0.16850804 HPE VMwareAccepted 2023-06-12

# 分别给这俩都卸了
# 命令输出我已经忘了，而且这不重要，就不写了
[root@ESXi:~] esxcli software vib remove -n amsdv
[root@ESXi:~] esxcli software vib remove -n amsd

两条卸载命令都成功之后，逐个关掉虚拟机，然后重启ESXi使修改生效。果不其然，重启之后，iLO系统信息里面显示Agentless Management Service不可用，温度页面里12 - AHCI HD Max传感器也消失了。经过一星期的测试，风扇也确实没再狂飙过。问题解决！

一点碎碎念

尽管这个解决方案远称不上完美，甚至有点“解决提出问题的人”的感觉。但这应该是权衡利弊之后的最优解。买HPE认证硬盘？拜托我只是拿它存电影而已，虽然要是全丢了也挺心疼，但它们确实不值这个钱。卖掉Gen 10 Plus再自己组一套NAS？那又太折腾了，我实在懒得搞。而且就算夏天天气热起来之后，我毕竟也不是重度PT玩家，大部分时间硬盘都是空载的，我相信它不会变得很热，不会因为俩机械硬盘搞炸整台服务器。

背景

谈论实现之前，我先说一下我有哪些工具可以使用：

• SecretKeyService：一个可以保存对称及非对称加密密钥的服务
• CredentialVault：一个用来存放密钥的服务，密钥一旦存入，就只能再通过API的方式得到其原文
• ConfigurationCenter：配置中心，不提供任何加密功能，在配置内容更新后可以通过Spring的事件通知到使用了这个配置的服务

接到这个需求后，我下意识地觉得应该用CredentialVault解决问题，但是仔细想想，发现并不能。因为按照公司要求，API key的密码必须定期轮换，而老的密码在轮换之后就会马上失效。尽管我们有两套API key来避免前面的问题，但是更换API key密钥对又需要修改配置文件，并经历code review及上线部署，依旧需要一定的人工操作。我的设想是，只需要在一个地方设定好要生效的API key，接下来所有用到这个API key的服务都能自动更新。这样看来，似乎带有通知功能的配置中心是唯一解。但是配置中心不提供加密功能，所以还需要SecretKeyService提供一个对称加密密钥来把API key的密码加密，然后将它放到配置中心。

记不住这些名字没关系，后面你也看不到它们了。

实现

在确定要用的工具之后，就可以开始着手将它们拼装在一起了。因为原本公司的代码需要保密，所以下面的代码更多是展示思路，大概率你不能直接拷出来放到你的项目中用。

PropertyLoader

因为直接把配置源从文件换成配置中心有一定的风险，保险起见我们决定逐步迁移配置，在迁移期间需要同时支持配置文件和配置中心。所以，就诞生了PropertyLoader。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

public class PropertyLoader {
    // 负责加解密的服务，它会从SecretKeyService取得密钥并对给定字符串完成加解密
    private final EncryptionDecryptionService encryptionDecryptionService;
    // 配置中心的客户端
    private final ConfigurationCenterClient configurationCenterClient;
    // 配置文件
    private final Properties properties;

    public PropertyLoader(
        final EncryptionDecryptionService encryptionDecryptionService,
        final ConfigurationCenterClient configurationCenterClient,
        final Properties properties,
    ) {
        this.encryptionDecryptionService = encryptionDecryptionService;
        this.configurationCenterClient = configurationCenterClient;
        this.properties = properties;
    }

    /**
     * 从配置中心或配置文件取得一个key的值
     * 
     * @param key Property或配置中心条目的key
     * @return 取到的值，不会为null
     * @throws PropertyNotFoundException 当在配置中心和配置文件中都找不到这个key时抛出，这通常意味着我们把某条配置漏掉了
     */
    public String loadProperty(final String key) {
        // 首先尝试从配置中心取值，如果取不到则返回null
        String value = configurationCenterClient.getValue(key);
        if (value == null) {
            value = properties.getProperty(key);
        }
        if (value == null) {
            throw new PropertyNotFoundException(key);
        }

        return value;
    }

    /**
     * 从配置中心或配置文件取得一个key的值并将其解密
     * 
     * @param key Property或配置中心条目的key
     * @return 取到的值，不会为null
     * @throws PropertyNotFoundException 当在配置中心和配置文件中都找不到这个key时抛出，这通常意味着我们把某条配置漏掉了
     */
    public String loadEncryptedProperty(final String key) {
        final String encryptedValue = configurationCenterClient.getValue(key);
        if (encryptedValue == null) {
            // 如果从配置中心拿不到值，那就从property文件中拿未加密的原文
            final String plainValue = properties.getProperty(key);
            if (plainValue == null) {
                throw new PropertyNotFoundException(key);
            }

            return plainValue;
        }

        return encryptionDecryptionService.decrypt(encryptedValue);
    }

    /**
     * 检查配置文件或配置中心是否有指定的key
     * 
     * @param key 要检查的key
     * @return 当这个key存在时返回true，反之返回false
     */
    public boolean hasProperty(final String key) {
        return configurationCenterClient.getKeys().contains(key) || properties.containsKey(key);
    }
}

实现观察者模式

上面说到了，我需要在监听到配置中心发出的事件后，更新相关对象中的配置。显然，在每个对象中都实现一个Spring事件监听器是很蠢的，我们应该在一处监听Spring事件，然后将其以某种方式广播到相关的对象。看起来，观察者模式是个不错的选择。

观察者模式包含两个组件：notifier和subject。Subject作为观众，观察着某个事件；notifier则负责将事件通知给各个subject。

OK，理论有这些就够了。接下来我们把它实现。首先是subject。

观察者模式 - subject

首选我们用一个抽象类定义一个观察者要有的行为，需要成为观察者的类将会继承这个抽象类。

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

public abstract class ConfigRefreshObserverSubject {
    // 观察到配置更新后，从PropertyLoader获取新的值
    private final PropertyLoader propertyLoader;
    // 这个观察者关心的key
    // 因为要计算在这个对象中当前生效的配置的签名，所以要配置这个对象关心哪些key
    // 然后取出这些key对应的value来计算签名
    private final List<String> monitoredKeys;
    // 当前生效的配置的一个签名
    // 可以将其理解为当前配置的一个哈希，实际上是综合当前生效的配置生成的一个UUID
    // 在收到配置刷新事件后，会将新配置的签名与当前签名比较
    // 仅在签名不一致时刷新对象中的配置
    private String configSignature;

    public ConfigRefreshObserverSubject(
        final PropertyLoader propertyLoader,
        final List<String> monitoredKeys
    ) {
        this.propertyLoader = propertyLoader;
        this.monitoredKeys = monitoredKeys;
        // 在初始化时计算当前生效配置的签名
        this.configSignature = calculateConfigurationSignature();
    }

    /**
     * 这个方法留给实际成为subject的类去实现具体它要怎么刷新自己的配置
     */
    public abstract void refreshConfigImpl();

    /**
     * 这个方法留给notifier调用，实现更新配置及刷新配置签名
     */
    public final void refreshConfig() {
        refreshConfigImpl();
        configSignature = calculateConfigurationSignature();
    }

    public PropertyLoader getPropertyLoader() {
        return this.propertyLoader;
    }

    public String getConfigSignature() {
        return this.configSignature;
    }

    protected String calculateConfigurationSignature() {
        final StringBuilder newConfigurationSignatureSeedBuilder = new StringBuilder();
        for (String key : monitoredKeys) {
            if (!propertyLoader.hasProperty(key)) {
                // 如果找不到某个关心的key，那么说明要么初始配置有问题，要么刷新的配置有问题
                // 这时候尽早抛出异常引发开发人员关注
                throw new IllegalArgumentException("Missing property: " + key + " for class: " + this.getClass().getSimpleName());
            }

            newConfigurationSignatureSeedBuilder.append(propertyLoader.loadProperty(key));
        }

        return UUID.nameUUIDFromBytes(newConfigurationSignatureSeedBuilder.toString().getBytes()).toString();
    }
}

观察者模式 - notifier

在观察者模式中，notifier将作为一个单例存在，各个subject会注册到这个notifier，并在接收到事件后被notifier逐个通知。

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

public class ConfigRefreshObserverNotifier {
    // 用于存放各个subject的注册表
    // 在某些情况下，同一个subject可能会被重复注册，所以这里我会把subject的类名作为key放在map中
    // 方便在注册时检查是否重复注册
    private static final Map<String, ConfigRefreshObserverSubject> subjects = new HashMap<>();

    private ConfigRefreshObserverNotifier() {
        // notifier作为一个单例，我们不希望它被实例化
        throw new UnsupportedOperationException("ConfigRefreshObserverNotifier shouldn't be instantiated");
    }

    /**
     * 注册subject
     * @param subject 待注册的subject对象
     */
    public static void register(final ConfigRefreshObserverSubject subject) {
        if (!isSubjectRegistered(subject)) {
            subjects.put(subject.getClass().getSimpleName(), subject);
        }
    }

    /**
     * 向各个subject发出配置更新的通知
     */
    public static void notifyObservers() {
        for (final ConfigRefreshObserverSubject subject : subjects.values()) {
            // 计算新配置的签名
            final String newConfigSignature = subject.calculateConfigurationSignature();
            // 仅当签名不同，即配置有变化时，才通知对应的subject更新
            if (!newConfigSignature.equals(subject.getConfigSignature())) {
                subject.refreshConfig();
            }
        }
    }

    private static boolean isSubjectRegistered(final ConfigRefreshObserverSubject subject) {
        final String subjectClassName = subject.getClass().getSimpleName();
        return subjects.containsKey(subjectClassName);
    }
}

观察者模式 - 实际的观察者类

有了subject，接下来就可以让实际要监控配置更新的类继承ConfigRefreshObserverSubject，将它变为一个观察者，并实现更新配置的逻辑。这部分其实很简单，就是给对应的字段重新赋值。

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

public class SomeServiceClient extends ConfigRefreshObserverSubject {
    private String endpoint;
    private String username;
    private String password;

    public SomeServiceClient(final PropertyLoader propertyLoader) {
        super(
            propertyLoader,
            List.of("some-service-endpoint", "some-service-username", "some-service-password")
        );

        initializeProperties();
        ConfigRefreshObserverNotifier.register(this);
    }

    private void initializeProperties() {
        final PropertyLoader propertyLoader = super.getPropertyLoader();

        this.endpoint = propertyLoader.loadProperty("some-service-endpoint");
        this.username = propertyLoader.loadProperty("some-service-username");
        this.password = propertyLoader.loadEncryptedProperty("some-service-password");
    }

    @Override
    public void refreshConfigImpl() {
        initializeProperties();
    }

    // 实际这个类的业务实现与本文无关，就省略了
    // 说白了无非就是往endpoint发请求，带上username和password来认证
}

上面的代码应该很容易理解，在配置刷新前，SomeServiceClient就用当前生效的配置去发请求，在配置刷新后，这个观察者就可以马上得知这个事件并从配置中心取得最新的值替换当前生效的配置。这个过程几乎是瞬间完成的，不会对业务产生影响。

监听配置刷新事件

上面洋洋洒洒实现了一堆东西，但最重要的一个还没有实现，那就是配置刷新事件的监听器。因为配置中心会通过Spring事件来发布，所以只需要找个地方实现一个@EventListener方法就行。

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

@Configuration
public class BeanFactory {
    @Bean
    public SomeServiceClient someServiceClient(
        final ResourceLoader resourceLoader,
        final EncryptionDecryptionService encryptionDecryptionService 
    ) {
        final Properties properties = ResourcesUtils.loadProperties(
            resourceLoader,
            ResourcesUtils.CLASSPATH_META_INF + "/some-service.properties"
        );

        final PropertyLoader propertyLoader = new PropertyLoader(encryptionDecryptionService, properties);
        
        return new SomeServiceClient(propertyLoader);
    }

    @EventListener
    public void handleConfigRefreshEvent(final ConfigRefreshEvent event) {
        if (event.getProjects().contains("my-config-project")) {
            ConfigRefreshObserverNotifier.notifyObservers();
        }
    }
}

以上，就完成了一个利用配置中心的通知机制实现的配置动态更新功能。

Pub/Sub（即publish/subscribe的简称）是一个在分布式系统中给不同组件互相通信的一种消息传递技术。这种消息传递技术与传统的点对点通信（即一个服务直接向另一个服务发送消息）不同，它是一种异步且可伸缩的消息服务，并且它可以将负责发布消息的服务与负责处理消息的服务分隔开。

在这篇博客中，我们会探索Pub/Sub的原理，以及Redis是如何实现这个通信模型的。我们会分析Redis中错综复杂的实现，将目光聚焦并深入到内存级别的实现的细节上，来让我们完全理解Pub/Sub机制，以及通过Redis完成的项目实践。

Pub/Sub入门

Pub/Sub是一个消息模型，它可以让分布式系统中的不同组件互相通信。发布者向一个主题（topic）发送信息，订阅者则从这个主题中接收信息。发送者在这个过程中可以保持匿名，当然如果在消息中包含了发送者的信息，那么订阅者也可以通过它来确定发送者的身份。Pub/Sub系统保证了消息可以被送达到所有对这个主题感兴趣的订阅者。在恰当的配置下，这将会是一个高度可扩展并且很可靠的消息传递系统，它将可以处理大量的数据。此外，在适当的大小、网络状况，以及订阅者的处理时间的前提下，Pub/Sub允许服务以1毫秒的延迟进行异步通信，因此它非常适合现代快速的分布式应用程序。

Pub/Sub模型

Pub/Sub的模型很简单，消息中介从发布者收到消息，然后将消息分发到各个订阅者。订阅者在得到消息后，就可以根据实际的场景对消息进行处理。基于发布者和订阅者的数量，这个模型通常可以被归为四类，即一对一、一对多、多对一、多对多。

Pub/Sub核心概念

在我们深入去了解Pub/Sub的细节和实现之前，我们需要先对Pub/Sub相关的核心概念有所了解。Pub/Sub系统包含多个组件，下表描述了其中的一些主要的组件：

Redis Pub/Sub

现在我们已经了解了关于Pub/Sub的一些抽象概念，并且知道了它是如何工作的。接下来我们需要深入到Redis针对Pub/Sub的实现，来了解消息从发布者发布出来，到结束于订阅者这个过程中，系统是如何通信的。

Redis通过在客户端之间实现一个简单而高效的消息系统来实现Pub/Sub。在Redis中，一个客户端可以“发布”一条消息到一个命名的通道，其他客户端则可以“订阅”这个通道来接收消息。

当一个客户端向这个通道发布了一条消息，Redis将会把这个消息发送到所有订阅了这个通道的客户端。这样，应用程序的不同组件之间就可以实时地通信并交换信息。

Redis Pub/Sub提供了一个轻量级、高速，并且可扩展的消息传递解决方案，并且可以用于各种场景下，比如实现一个实时通知、在不同微服务之间发送消息，或在一个应用的不同组件之间通信。

同步通信

Redis Pub/Sub是同步的。为了保证消息可以成功被传递，订阅者和发布者必须同时连接到Redis。

你可以将它想象成一个收音机电台，在调频到这个频道之后，你就可以收听它的内容。然而，在收音机被关掉之后，你就没法再收听了。

这意味着如果一个订阅者断开了连接，过了一会又连了上来，那么它将无法收到断开期间发出来的消息。也就是说，这限制了Redis Pub/Sub只能用在允许数据可能丢失的场景下。

发射后不管 (Fire & Forget)

“发射后不管”是一种信息传递模式，在这种模式下，发送方不会期望从接收方明确确认信息已经被收到。发送方只会将消息发出去，然后就继续开始做后面的事，不管消息有没有被接收方收到。

仅向外播散 (Fan-out Only)

Redis Pub/Sub只管向外播散消息，也就是说，当发布者发布了一条消息后，这条消息会被广播到所有当前活动的订阅者。所有订阅者都会收到这条消息的副本，不管它们是不是对这条消息感兴趣。

掀开Redis Pub/Sub的引擎盖

Redis最著名的功能是键值服务器。当客户端连接到Redis服务器后，它将会与服务器建立TCP连接，并开始向服务器发送命令。

但是Redis也是个消息服务器！一个对topicA感兴趣的客户端可以向Redis服务器建立一个TCP连接，发送SUBSCRIBE topicA命令，然后等待与topicA相关的新闻。“新闻机构”也可以连接到Redis服务器，发送PUBLISH topicA message-data，然后所有订阅了这个主题的客户端都将收到这条价值连城的消息。

如果放大了看Redis里面发生了什么，我们可以想象Redis会跟踪每个套接字(socket)的订阅集：

咱们继续深入看看Redis是怎么做的。

最初的Pub/Sub实现允许客户端发送三个新的命令：PUBLISH，SUBSCRIBE，和UNSUBSCRIBE。Redis使用了一个全局变量pubsub_channels来跟踪各个订阅，在其中Redis维护了一个通道名和订阅它的客户端对象的映射关系。每个客户端对象代表一个TCP连接的客户端，并通过其对应的文件描述符来跟踪。

当一个客户端发送SUBSCRIBE命令后，它对应的客户端对象就会被加到对应通道的客户端对象集中。
在发布信息时，Redis会从pubsub_channel中找到这个主题对应的订阅者，并针对每个客户端启动一个计划任务来向对应的套接字发送信息。

处理连接断开

客户端的连接可能会因为客户端断开连接，或者网线被拔掉而断开。当有连接断开时，Redis必须将对应的订阅清理掉。假设客户端A断开了连接，那么为了将这个客户端从pubsub_channels中清除，Redis需要遍历每个通道(“topicA”和”topicB”)，并从它们的客户端对象集中删掉它。

可想而知，遍历所有的通道的效率是非常低的。按道理，Redis只需要访问”topicA”这个通道，因为客户端A只订阅了它。为了将这个理论变成实际，Redis标记了各个客户端及其订阅的通道，并将其与pubsub_channels同步。这样，Redis就只需要访问这个客户端相关的通道，而不需要低效的遍历所有的通道。我们在图中可以将这些标记画成绿色的圆：

落实理论

我们已经知道，全局变量pubsub_channels的数据结构基本上就是一个Map<ChannelName, Set<Client>>，而每个客户端的订阅集就是个Set<ChannelName>。但是这些都只是一个抽象的数据结构，没法说明内存中是如何表现的。所以我们继续放大，看看内存中的样子。

pubsub_channels这个Map实际上是个哈希表，其中通道名会被哈希，然后放到一个2^n长的数组中的对应位置。

包含了8个桶的数组pubsub_channels是一块独立分配出来的内存空间。要发布消息到一个通道，首先它会将通道名进行哈希，找到它对应的桶，然后遍历这个通道相关联的各个客户端。然而不同的通道名又可能会被哈希到同一个桶中，为了解决这个哈希冲突问题，Redis使用了一个叫“哈希链”的方案，即每个桶都会指向一个保存着通道的链表。比如在上面的例子中，“topicA”和“topicB”都被哈希到了第三个桶中。实际上为了以防万一，Redis会在启动时为它的哈希函数选择一个随机的种子来尝试避免出现哈希碰撞，这也可以防止被恶意用户蓄意订阅到会被哈希到同一个位置的大量通道而导致性能下降。

在下图中，绿色的字符串是通道的名字，作为哈希表的键；紫色的是客户端的集合，作为哈希表的值。但“集合”在这里也是个抽象的概念，它在Redis中是怎样表现的呢？答案是，另一个链表！

我们可能会觉得字符串“topicA”和“topicB”是在哈希链里面的，但实际不是。每个字符串都是独立分配的一块内存空间。字符串在Redis中被广泛使用着，它们甚至有自己的名字叫“简单动态字符串（Simple Dynamic Strings）”，其内容分三部分：已占用的空间、剩余的空间，和一个字符数组。

到现在我们已经快要到内存级别了，但是还有一件事没有提到，那就是每个通道的客户端集。在这里，Redis并没有选择用链表，而是用了另一个哈希表，其中通道的名字就是哈希表的键。

我暂时还不清楚为什么Redis选择用链表保存通道的客户端集，而又选择哈希表来保存客户端的通道集。我怀疑Redis选择在通道的客户端集上用链表是因为，链表更适用于发布的场景，因为在发布时会需要遍历它；而选择在客户端的通道集上用哈希表则是因为它更适用于订阅和取消订阅的场景，因为此时要做的是在里面做查找。如果你有更深入的理解，请告诉我。

需要注意的是，在每个客户端的哈希链上，指向它的值的指针是被忽略的，这片内存没有被用到。当用哈希表来表示一个集合的时候，我们只会用到它的键。相比较于我们从代码复用中得到的收益，这部分浪费不值一提。

终于，我们快要接近真相了：图中的每个方块都代表redis-server进程中分配的一块内存。现在我们来回顾一下PUBLISH和SUBSCRIBE的算法：

• 在PUBLISH的时候，首先对通道的名字做一次哈希，接下来遍历哈希链，将要发布的通道名与哈希链中的各个通道名做比较。在找到我们要的那个通道后，从中得到它的客户端列表。然后遍历客户端列表，将消息发至各个客户端。
• 在SUBSCRIBE的时候，首先像PUBLISH一样找到保存着客户端的那个链表，然后将新的客户端附加在链表的尾部。并且将要订阅的通道添加到客户端维护的哈希表中。

可以实时操作的哈希表

要注意这些哈希表的大小是不同的，而且都大概与其元素数量成比例。Redis会根据元素数量调整哈希表的大小。但是，Redis的设计目标是低延迟，而调整哈希表又是个比较耗时的操作。那么Redis是怎么做到在调整哈希表大小时不产生延迟尖峰的？

答案是：Redis会逐步的调整哈希表的大小。它在底层维护了新旧两个哈希表。假设pubsub_channels这个哈希表正在经历调整。

每当Redis对哈希表进行操作时（查询、插入、删除……），它都会稍微调整一下哈希表的大小。它会跟踪有多少老的桶被移动到了新的桶中，然后在每次操作中，它都会再移动几个过去。这样一来，调整大小的工作量就会被限制，使得Redis在调整期间也可以保证响应。

不再订阅昂贵的东西（Expensive unsubscribed）

在Pub/Sub中还有一个很重要的操作：UNSUBSCRIBE，它所做的与SUBSCRIBE正相反，它会使客户端不再订阅到指定的通道，也不会再收到来自这个通道的消息。那么利用上面说过的数据结构，你会怎么实现UNSUBSCRIBE功能呢？Redis是这样做的：

在UNSUBSCRIBE时，首先找到这个通道对应的客户端链表，然后遍历整个链表直到找到我们要删除的那个客户端。

也就是说，UNSUBSCRIBE操作的耗时是O(n)，其中n就是客户端的数量。如果一个通道有大量的客户端订阅，那么UNSUBSCRIBE操作就会变得很昂贵。所以，你要么需要限制你的客户端数量，要么需要限制它们订阅的通道的数量。Pusher的一个优化就是去掉重复的订阅，数百万的Pusher订阅会被折叠为数量更少的Redis订阅。

Redis可以通过把存放客户端订阅的链表换成哈希表来优化，但也可能不会很理想，会导致发布消息稍稍变慢，因为遍历哈希表比遍历链表慢。Redis选择针对PUBLISH操作去做优化，因为它们比变更订阅更加常见。

按照表达式匹配订阅（Pattern subscriptions）

最初的Pub/Sub提供了PUBLISH、SUBSCRIBE和UNSUBSCRIBE三个命令。不久之后，Redis引入了一个名为“按照表达式匹配订阅”的新功能及其命令PSUBSCRIBE，这个可以让客户端订阅所有匹配了某个正则表达式的主题。

现在，如果一个客户端发送了命令PSUBSCRIBE food.donuts.*，然后一个发布者发送了命令PUBLISH food.donuts.glazed 2-for-£2，那么订阅者也会收到消息，因为food.donuts.glazed匹配了正则表达式food.donuts.*。

按照表达式订阅的实现是与普通的订阅完全不同的。除了全局的pubsub_channels哈希表之外，还有一个全局的pubsub_patterns列表。这是一个包含了pubsubPattern对象的列表，每个对象与一个客户端订阅的一个表达式相关联。类似地，每个客户端对象也有一个包含着它订阅的表达式的链表。下图展示了当客户端B订阅了drink?，同时客户端A和客户端B订阅了food.*之后，redis-server进程的内存的样子：

图示的左侧是一个全局的链表，每个节点都指向一个pubsubPattern，每个表达式在内存中都是字符串字面量。在图示的右侧，每个客户端都有一个关联着它的订阅的链表。

当一个客户端发送命令PUBLISH food.donuts 5-for-£1，Redis就会遍历pubsub_patterns列表，并将字符串food.donuts与每个表达式匹配。每遇到一个符合的匹配，Redis就会发送消息5-for-£1到关联的客户端。

这个实现可能有一个让你惊讶的点：如果多个客户端订阅到同一个表达式时，这些订阅不会被组合在一起。如果有10000个客户端都订阅了food.*，那么你将会得到一个包含了10000个表达式的链表，其中每个元素在发布消息的时候都会被匹配。这种设计假定模式订阅集很小，而且各不相同。

另一个会让你惊讶的点是，表达式都是以其原文存储的，它们并没有被编译。这一点尤其有趣，因为Redis的匹配函数stringmatch有一些有趣的坏情况。如下展示了Redis是如何把字符串aa与表达式*a*a*b相匹配的：

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

stringmatch("*a*a*b", "aa")
    stringmatch("a*a*b", "aa")
        stringmatch("*a*b", "a")
            stringmatch("a*b", "a")
                stringmatch("*b", "")
                    stringmatch("b", "")
                        false
            stringmatch("a*b", "")
                false
    stringmatch("a*a*b", "a")
        stringmatch("*a*b", "")
            stringmatch("a*b", "")
                false
    stringmatch("a*a*b", "")
        false

这种带有许多glob的恶意表达式会导致匹配的执行时间爆炸性增长。Redis的表达式语言虽然可以被编译成确定有限状态自动机（DFA），来让匹配耗时变得线性，但却没这么做。

所以长话短说，你不应该把Redis的按表达式匹配功能开放给不被信任的客户端，因为这可能会引来两种攻击：一种是订阅大量的表达式，另一种就是刻意制造的表达式。在Pusher，我们会非常小心地处理Redis的按表达式订阅功能。

Pub/Sub的使用场景

我们现在知道了Pub/Sub的技术细节，以及在Redis中是怎么实现的。接下来我们看看有哪些使用场景。

Redis提供的异步集成功能提高了系统的整体灵活性和稳定性，使其能够满足各种场景，包括：

• 实时消息和聊天
• 物联网设备
• 新闻发布和警告
• 分布式计算和微服务
• 事件驱动的架构
• 组件间解耦，以及减少依赖
• 扇入处理（Fan-in processing）—— 将多个消息组合成一个消息的过程被称为扇入处理。
• 刷新分布式缓存

结论

Redis是实现Pub/Sub最常用的工具之一。它因扩展性、低延迟和易于集成而广为人知。我们也在内存块级别探讨了Redis的工作原理。

Redis Pub/Sub是一个高效的分发消息的方法，但我们也要知道它在哪些方面做了优化，以及在哪有陷阱。要想彻底了解的话，那就去研究源码吧！一句话，记得只在可信的环境中使用Redis，并要限制客户端的数量，并且小心处理按照表达式的订阅。

使用@Autowired通过代理调用

这个方法的思路是，利用@Autowired注解注入自身的代理对象，然后通过代理对象完成方法调用。

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

@Service
public class DemoService {
    @Autowired
    private DemoService demoService;

    public String helloWorld() {
        demoService.test();
        return "Hello World!";
    }

    public String test() {
        return "Test";
    }
}

这个操作我也在本地的一个Spring Boot项目中验证确实是可行的，前提是要在application.properties里面配置允许循环引用spring.main.allow-circular-references=true。而且这个操作有一个缺点，就是自身代理对象demoService必须通过字段注入的方式完成依赖注入，如果用构造方法注入，启动的时候就会报循环依赖错误导致项目无法成功启动（不用想也知道，在构造方法里面依赖自己肯定不行啊）。

我个人并不喜欢这个方法，一个原因是因为我不喜欢循环引用，另一个原因是我不喜欢字段注入，毕竟Spring早就推荐改成构造方法注入了。所以，我们继续看下一个方法。

使用AopContext.currentProxy()

另一个方法是使用AopContext#currentProxy()静态方法获取到当前的代理对象，也就是对象自己，然后再通过这个代理对象进行方法调用。

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

@Service
public class DemoService {
    public String helloWorld() {
        final DemoService demoService = (DemoService) AopContext.currentProxy();
        demoService.test();
        return "Hello World!";
    }

    public String test() {
        return "Test";
    }
}

但是如果就这样运行，你就会得到这样一条错误信息：

1

java.lang.IllegalStateException: Cannot find current proxy: Set 'exposeProxy' property on Advised to 'true' to make it available, and ensure that AopContext.currentProxy() is invoked in the same thread as the AOP invocation context.

看来ChatGPT没把话说全啊，好在我的IDEA里面装了通义灵码，把代码上下文和这个异常抛给它之后，它告诉我要通过注解@EnableAspectJAutoProxy(exposeProxy = true)配置Spring AOP允许暴露当前代理对象。那么按照它的说法，我给切面配置类加上这个注解：

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

@Aspect
@Component
@EnableAspectJAutoProxy(exposeProxy = true) // <-- 就这个，它的默认值是false
public class DemoAopAdvice {
    private static final Logger LOGGER = LoggerFactory.getLogger(DemoAopAdvice.class);

    @Pointcut("execution(* com.example.demo.DemoService.*(..))")
    public void test() {
    }

    @Before("test()")
    public void before() {
        LOGGER.info("Before");
    }
}

再重启应用，就发现demoService里面的内部调用成功触发了AOP切面。

通义灵码还提醒我，在多线程环境中，要确保AopContext#currentProxy()必须在与AOP调用相同的线程中调用。此外，根据currentProxy()的JavaDoc，调用它的方法也必须经过了AOP调用，否则会抛出IllegalStateException异常。点进currentProxy()方法的实现，发现它内部是用ThreadLocal来保存代理对象的，同时在这个类中还有一个setCurrentProxy(Object)方法来把当前的代理对象保存到ThreadLocal中。下断点调试后发现，setCurrentProxy(Object)这个方法会先被执行，然后再走到我们实际调用的方法。这正好解释了为什么要注意在相同的线程中调用AopContext#currentProxy()，并且调用它的方法必须是经过了AOP调用的，因为不这样的话ThreadLocal中根本就没东西可拿。

ChatGPT的回答

在 Java 代码中直接写字符串值（即 硬编码字符串）通常是不推荐的，主要从以下两个方面考虑：

1. 代码可读性和可维护性

• 降低可读性：直接在代码中写死字符串值，容易让代码的意图变得不清晰，阅读时难以理解这个字符串的作用。
• 难以维护：如果字符串值在多个地方使用，一旦需要修改，就必须逐个查找替换，容易遗漏或出错。
• 不利于国际化（i18n）：如果程序需要支持多种语言，硬编码字符串必须手动提取，而如果使用常量或资源文件，则可以更方便地进行国际化处理。

2. JVM 内部优化

• 字符串常量池优化：JVM 会对字符串字面量进行**字符串常量池（String Pool）**处理，避免重复创建相同的字符串实例。但如果字符串值是动态拼接或new关键字创建的，就可能无法享受这种优化。
• 减少堆内存占用：使用String变量或final常量，JVM 可能会进行常量折叠，减少运行时重复创建的开销，提高效率。
• 提高性能：直接写字符串字面量可能会在某些情况下导致 JVM 额外分配对象，而使用final常量或intern()方法可以优化内存占用。

果然除了可读性考虑，JVM也会对字符串常量做一些优化。但，什么是常量折叠？

常量折叠

追问ChatGPT什么是常量折叠后，它是这么回到我的：

常量折叠（Constant Folding） 是 JVM 编译优化（Just-In-Time Compilation, JIT） 或 Java 编译器（javac）在编译阶段执行的一种优化策略，它会在 编译期 计算出可以确定的常量表达式，并用计算结果替换原始表达式，从而减少运行时的计算开销。

1. 常量折叠的作用

常量折叠的核心目标是提前计算出能确定的值，避免运行时重复计算，从而提高性能。例如，以下代码：

1 2 3 4 5 6

public class Test { public static void main(String[] args) { int a = 2 * 3; // 计算常量表达式 System.out.println(a); } }

在编译阶段，JVM 会将2 * 3计算为6，然后直接将6存入字节码，而不是在运行时执行乘法计算。

2. 常量折叠的典型场景

（前略）

（2）字符串常量优化
如果字符串是常量，编译器会在编译时进行字符串拼接优化，避免运行时的StringBuilder操作：

1 2 3 4 5 6 7 8

public class StringConstantFolding { public static void main(String[] args) { final String s1 = "Hello, "; final String s2 = "World!"; String s3 = s1 + s2; // 直接折叠为 "Hello, World!" System.out.println(s3); } }

优化后的字节码相当于：

1	String s3 = "Hello, World!";

（后略）

3. 什么时候不会发生常量折叠？
   （1）变量不是final - 如果变量不是final，编译器无法确定其值，因此不会进行常量折叠
   （2）值在运行时才能确定 - 如果值依赖于外部输入、方法调用、对象实例等，JVM 不能在编译时优化

也就是说，如果在代码里这样写：

1
2
3
4
5
6
7
8

public class Test {
    private static final String HELLO = "hello, ";
    private static final String WORLD = "world";

    public static void main(String[] args) {
        System.out.println(HELLO + WORLD);
    }
}

那么实际上JVM就会给你优化成：

1
2
3
4
5
6
7
8

public class Test{
    private static final String HELLO = "hello, ";
    private static final String WORLD = "world";

    public static void main(String[] args) {
        System.out.println("hello, world");
    }
}

将这段代码编译后再用javap反编译，可以看到这样的结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

Classfile /Users/boris1993/Developer/java/leetcode/src/Test.class
  Last modified Mar 6, 2025; size 523 bytes
  SHA-256 checksum 3443c8e0a13cd862c0195b772bb4290bde7e1d07b50818d531c2b5d66d665270
  Compiled from "Test.java"
public class Test
  minor version: 0
  major version: 65
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER
  this_class: #13                         // Test
  super_class: #2                         // java/lang/Object
  interfaces: 0, fields: 2, methods: 2, attributes: 1
Constant pool:
   #1 = Methodref          #2.#3          // java/lang/Object."<init>":()V
   #2 = Class              #4             // java/lang/Object
   #3 = NameAndType        #5:#6          // "<init>":()V
   #4 = Utf8               java/lang/Object
   #5 = Utf8               <init>
   #6 = Utf8               ()V
   #7 = Fieldref           #8.#9          // java/lang/System.out:Ljava/io/PrintStream;
   #8 = Class              #10            // java/lang/System
   #9 = NameAndType        #11:#12        // out:Ljava/io/PrintStream;
  #10 = Utf8               java/lang/System
  #11 = Utf8               out
  #12 = Utf8               Ljava/io/PrintStream;
  #13 = Class              #14            // Test
  #14 = Utf8               Test
  #15 = String             #16            // hello, world
  #16 = Utf8               hello, world
  #17 = Methodref          #18.#19        // java/io/PrintStream.println:(Ljava/lang/String;)V
  #18 = Class              #20            // java/io/PrintStream
  #19 = NameAndType        #21:#22        // println:(Ljava/lang/String;)V
  #20 = Utf8               java/io/PrintStream
  #21 = Utf8               println
  #22 = Utf8               (Ljava/lang/String;)V
  #23 = Utf8               HELLO
  #24 = Utf8               Ljava/lang/String;
  #25 = Utf8               ConstantValue
  #26 = String             #27            // hello,
  #27 = Utf8               hello,
  #28 = Utf8               WORLD
  #29 = String             #30            // world
  #30 = Utf8               world
  #31 = Utf8               Code
  #32 = Utf8               LineNumberTable
  #33 = Utf8               main
  #34 = Utf8               ([Ljava/lang/String;)V
  #35 = Utf8               SourceFile
  #36 = Utf8               Test.java
{
  public Test();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 1: 0

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #15                 // String hello, world
         5: invokevirtual #17                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 6: 0
        line 7: 8
}
SourceFile: "Test.java"

首先可以看到，在常量池中有这么两行代码：

1
2

#15 = String             #16            // hello, world
#16 = Utf8               hello, world

证明代码中HELLO + WORLD的值已经被编译器优化成了一个计算好的常量。在main方法的字节码中也可以看到

1
2
3
4
5
6
7
8
9

public static void main(java.lang.String[]);
  descriptor: ([Ljava/lang/String;)V
  flags: (0x0009) ACC_PUBLIC, ACC_STATIC
  Code:
    stack=2, locals=1, args_size=1
       0: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #15                 // String hello, world
       5: invokevirtual #17                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return

JVM直接加载了”hello, world”这个字符串，而不是调用了InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;在运行时进行字符串拼接。

总结

综上所述，使用字符串常量而不是直接写字符串值，除了让代码更可读更易于维护之外，我感觉最主要的优点就是针对字符串常量的拼接结果也会被放到常量池中，避免了在运行时反复创建新的字符串对象，造成性能浪费。

正好我最近也在开始接触Dev Container并使用它给一个开源项目成功提交了代码，正好趁热打铁，把写博客的Hexo环境从本机挪到Dev Container中。

配置VSCode

我的计划是用VSCode来在容器中写博客，那么为了让VSCode支持Dev Container，我们需要安装Dev Containers这个VSCode扩展。哦对，你还得有个Docker，不论是本机还是在哪个服务器上。我这就用本机的Docker演示了。

装好扩展之后，就可以开始写Dev Container的配置了。因为不同项目对应的开发容器必然是不同的，所以Dev Container的配置会放到项目目录中。通常来说，Dev Container相关的文件都会放到项目根目录下的.devcontainer目录中，所以我们可以在项目目录下创建.devcontainer/devcontainer.json，并填入如下内容：

1
2
3
4
5
6
7
8
9
10

{
    // Dev Container的名字
    "name": "blog",
    // 基础Docker镜像
    "image": "node:lts-alpine",
    // 容器创建好之后要执行的命令
    "postCreateCommand": "sh .devcontainer/post_create.sh",
    // 要转发到主机的端口
    "forwardPorts": [4000]
}

因为基础镜像node:lts-alpine中并不包含我们需要的git、gpg、hexo等环境，所以我们需要通过postCreateCommand指定容器在启动之后执行命令来安装这些依赖。post_create.sh的内容如下：

1
2
3
4

#!/bin/sh

apk add --no-cache gpg git
npm install -g hexo-cli

然后用快捷键ctrl-shift-p（macOS就是⌘-shift-p）唤出命令面板，选择Dev Containers: Rebuild and Reopen in Container来构建容器并进入容器开发。如果将来devcontainer.json或相关的配置发生变化，我们也可以在命令面板中选择Dev Containers: Rebuild Container来重建容器。

编写容器的Dockerfile

上面提到的通过postCreateCommand来安装依赖的方式，虽然可行，但是不优雅，毕竟每次创建容器都要重新安装一次，就很浪费。所以我们也可以给我们的Dev Container写一个Dockerfile，这样就可以只初始化一次然后一直用下去了。

1
2
3
4
5
6
7
8

FROM node:lts-alpine

LABEL devcontainer.metadata = '[{ \
    "forwardPorts": [4000] \
}]'

RUN apk add --no-cache gpg git \
 && npm install -g hexo-cli

与部署用的Dockerfile不同，我们只需要写配置环境相关的命令就可以，不需要把工作空间拷贝进去，因为Dev Container会自动把这个目录mount到容器中。此外，在Dockerfile中还可以在devcontainer.metadata中提前指定好一些配置，以减少devcontainer.json的行数。

配置GPG

上面一步完成之后，Dev Container的配置其实就完成了。但如果你像我一样为Git配置了GPG签名，同时又是在macOS下开发，那么你还需要对GPG做一些额外的配置。首先我们需要安装pinentry-mac，然后编辑~/.gnupg/gpg-agent.conf文件，添加一行pinentry-program /usr/local/bin/pinentry-mac。如果你曾经在JetBrains IDE中点过它的Configure GPG Agent to support own pinentry，那么你就要把它添加的那行pinentry-program替换成这一条，否则我们在容器中提交更新的时候，GPG会因为找不到/Users/username/.gnupg/pinentry-ide.sh而报错。

参考文档

• Developing inside a Container
• Develop on a remote Docker host
• 使用Dev Container开发 - Claws小花园

看见硬盘空间不足，首先下意识df -h了一下，确实满了。

1
2
3
4
5
6
7
8
9
10

$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              392M  3.5M  389M   1% /run
efivarfs                            64K   41K   19K  70% /sys/firmware/efi/efivars
/dev/mapper/ubuntu--vg-ubuntu--lv   48G   45G  314M 100% /
tmpfs                              2.0G     0  2.0G   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/sda2                          2.0G  266M  1.6G  15% /boot
/dev/sda1                          1.1G  6.2M  1.1G   1% /boot/efi
tmpfs                              392M   12K  392M   1% /run/user/1000

但是ESXi里面显示这个虚拟机是有一个100GB的虚拟磁盘的，而df只显示出将近50GB，那就是说要么有50GB没分，要么出别的问题了。首先排除最简单的情况，看看是不是有一半的硬盘没分进去。

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

$ sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
NAME                      FSTYPE        SIZE MOUNTPOINT                    LABEL
loop0                                  10.1M /snap/canonical-livepatch/282 
loop1                                  10.7M /snap/canonical-livepatch/286 
loop2                                   104M /snap/core/16928              
loop3                                 104.2M /snap/core/17200              
loop4                                  55.7M /snap/core18/2829             
loop5                                  55.4M /snap/core18/2846             
loop6                                    64M /snap/core20/2379             
loop7                                  63.7M /snap/core20/2434             
loop9                                  73.9M /snap/core22/1663             
loop10                                   71M /snap/prometheus/86           
loop11                                 38.8M /snap/snapd/21759             
loop12                                 44.3M /snap/snapd/23258             
loop13                                 73.9M /snap/core22/1722             
sda                                     100G                               
├─sda1                    vfat            1G /boot/efi                     
├─sda2                    ext4            2G /boot                         
└─sda3                    LVM2_member  96.9G                               
  └─ubuntu--vg-ubuntu--lv ext4         48.5G /                             
sr0                                    1024M                               

从上面的命令输出可以看到，sda这块盘的100GB都认出来了，sda3分区也确实分了96.9GB，但是ubuntu--vg-ubuntu--lv这个卷只分配了48.5GB，也就是整个LVM的一半。

查阅了教程，了解到可以用lvdisplay来检查LVM逻辑卷的空间，并可以用vgdisplay检查volume group的空间。遂分别执行。

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

$ sudo vgdisplay
  --- Volume group ---
  VG Name               ubuntu-vg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <96.95 GiB
  PE Size               4.00 MiB
  Total PE              24818
  Alloc PE / Size       12409 / 48.47 GiB
  Free  PE / Size       12409 / 48.47 GiB
  VG UUID               zaKkwe-YemQ-dRcV-mrhe-v181-0Ixc-0KVaVL

$ sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               ubuntu-vg
  PV Size               <96.95 GiB / not usable 3.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              24818
  Free PE               12409
  Allocated PE          12409
  PV UUID               3FWWGz-CbIQ-BI9e-vMMd-p0Hu-eWUa-rZSeK8

其实看不看都一样，已经知道根源是空间没全部分给这个卷。那么接下来就可以用lvextend来扩展指定的卷。我直接把所有的空余空间全都分配进去。

1
2
3

$ sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv 
  Size of logical volume ubuntu-vg/ubuntu-lv changed from 48.47 GiB (12409 extents) to <96.95 GiB (24818 extents).
  Logical volume ubuntu-vg/ubuntu-lv successfully resized.

OK，卷扩容成功。但这时候实际的文件系统大小还没变，接下来需要用resize2fs扩容文件系统。

1
2
3
4
5

$ sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv 
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/mapper/ubuntu--vg-ubuntu--lv is mounted on /; on-line resizing required
old_desc_blocks = 7, new_desc_blocks = 13
The filesystem on /dev/mapper/ubuntu--vg-ubuntu--lv is now 25413632 (4k) blocks long.

完事，这时候再df -h就能看到根挂载点有将近100GB的空间了，扩容成功。

1
2
3
4
5
6
7
8
9
10

$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              392M  3.5M  389M   1% /run
efivarfs                            64K   41K   19K  70% /sys/firmware/efi/efivars
/dev/mapper/ubuntu--vg-ubuntu--lv   96G   45G   47G  50% /
tmpfs                              2.0G     0  2.0G   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/sda2                          2.0G  266M  1.6G  15% /boot
/dev/sda1                          1.1G  6.2M  1.1G   1% /boot/efi
tmpfs                              392M   12K  392M   1% /run/user/1000

因为僵尸进程在ps中的状态是Z，所以我首先用ps aux | grep 'Z'找到这个僵尸进程的PID。此外因为僵尸进程无法被直接杀死，只能杀掉其父进程来将其连根拔起，所以我还需要用pstree命令找到它的父进程PID。

1
2
3
4
5
6
7
8
9

$ ps aux | grep 'Z'
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      630024  0.0  0.0      0     0 ?        Z    00:55   0:00 [wget] <defunct>
boris19+ 1180864  0.0  0.0   9696  2332 pts/0    S+   23:52   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox Z
$ pstree -p -s 630024
systemd(1)───containerd-shim(2642178)───node(2642199)───wget(630024)
$ ps aux | grep 2642199
boris19+ 1181119  0.0  0.0   9696  2288 pts/0    S+   23:53   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox 2642199
root     2642199  0.0  0.8 21690116 35956 ?      Ssl  Sep07   3:21 node /app/dist/index.js

这里可以看到，僵尸wget的父进程是node，它的PID是2642199，而node的父进程是containerd-shim，也就是说这是一个Docker容器里的进程。我不确定这时候直接杀掉node能不能解决问题。但是老话说，来都来了，那不如继续挖下去。所以我开始尝试去找这个node是哪个容器运行的。

在这我稍微走了点弯路。一开始我是想通过搜索index.js关键词来找到容器，所以执行了下docker ps | grep index.js，但是显然这行不通，不然也不会有这篇文了。在稍微网上冲浪之后，我学到了一个新命令systemd-cgls，它可以递归展示出cgroup的内容。因为Docker用到的技术之一就是cgroup，那么想必这就是突破口。在执行了它之后，它打出来了一大片东西，就像这样：

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

Control group /:
-.slice
├─user.slice 
│ └─user-1000.slice 
│   ├─user@1000.service 
│   │ └─init.scope 
│   │   ├─1180199 /lib/systemd/systemd --user
│   │   └─1180200 (sd-pam)
│   └─session-35890.scope 
│     ├─1180196 sshd: boris1993 [priv]
│     ├─1180374 sshd: boris1993@pts/0
│     ├─1180376 -zsh
│     ├─1182022 systemd-cgls
│     └─1182023 pager
├─init.scope 
│ └─1 /sbin/init
└─system.slice 
  ├─irqbalance.service 
  │ └─941 /usr/sbin/irqbalance --foreground
  ├─docker-27434de50f56b4e096bf5f38bafc76f5c74622c758be1a3f2b9531a3549f4550.scope 
  │ └─3204915 /jellyfin/jellyfin
  ├─docker-adf03dfa49427d2d651cd9101c3033adb00396ed45c390dd6bfda0b9b73eeae3.scope 
  │ └─3775 /watchtower
  ├─open-vm-tools.service 
  │ └─812 /usr/bin/vmtoolsd
  ├─containerd.service 
  │ ├─   1017 /usr/bin/containerd
  │ ├─   2197 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 0e752935d348c3a41d66fe539a06268ee29c6975d1d8f0da41bd0c52b5adf337>
  │ ├─   2479 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 6f5e80ca8977314f3d3a9a47a93509438040a6908bde34cc578cdd3e8263c01a>
  │ ├─   2497 /usr/bin/containerd-shim-runc-v2 -namespace moby -id db3750e57842656c285e9641c4391df926721c94722bfb323789967c3a76d23f>
  │ ├─   2886 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 46520cd2506055c50ef361f50381a65b5077ee7b7d2607e26290d70f8b7292ba>
  │ ├─   3449 /usr/bin/containerd-shim-runc-v2 -namespace moby -id d45b7c4e806f1c0e681f317b548f795ff09eab53bc4d1a6bde05aa1fbb5064ee>
  │ ├─   3451 /usr/bin/containerd-shim-runc-v2 -namespace moby -id adf03dfa49427d2d651cd9101c3033adb00396ed45c390dd6bfda0b9b73eeae3>
  │ ├─   3554 /usr/bin/containerd-shim-runc-v2 -namespace moby -id fd2c2b6dfd77b23c0cdd59d50b33bbf70ab8046bf27ffeb595fbeadadf0a4a99>
  │ ├─   3837 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 6195cb19666ad7c58ce26a115ba4f2ea3b32185acb0c33ff80cbade860693fd0>
  │ ├─   3840 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 559a99dc9580a0ddea8501df71bbce3affb90cf3a91152b8274ae508c20e0f32>
  │ ├─   3901 /usr/bin/containerd-shim-runc-v2 -namespace moby -id b11d850487921e336178dd9267b0f281eea279d0135d1d5b853e63f945246baf>
  │ ├─   3964 /usr/bin/containerd-shim-runc-v2 -namespace moby -id f3f9400aeab6331d55166b1c80cd3e27dc2083664a6126cccf279340ab738364>
  │ ├─   5852 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 722497f0a71df4060151468e590b5a69a49332ba379b17c9504077b18bbd1dfc>

好在它的输出就像less一样，可以上下卷动，也可以用ed命令（就像vi一样），那么自然而然，我可以用/2642199来找到那一行。

1
2

├─docker-ce8f490423d791ed5f6d1aa2b705d797fc3fd2ddc34816d47c228f6fb9a20c63.scope 
│ └─2642199 node /app/dist/index.js

好，现在我们知道了容器的ID是ce8f490423d7。虽然现在就可以重启它了，但是我的好奇心不允许我这么做，我想知道是哪个容器。所以

1
2

$ docker ps | grep ce8f490423d
ce8f490423d7   boris1993/qinglong-bot:latest                                      "docker-entrypoint.s…"   12 days ago     Up 12 days (healthy)   0.0.0.0:3001->3000/tcp, :::3001->3000/tcp                                                                                     qinglong-bot

啊好吧，竟然是我那个青龙的机器人。这里面我只用了wget来做容器的liveness check，我不理解这么简单的操作怎么就能整出一个僵尸进程来。算了，以后有空再分析吧。重启容器，杀掉僵尸，睡觉。

1
2

$ docker restart ce8f490423d
ce8f490423d

这时候再用ps aux | grep 'Z'就看不到有僵尸进程，也就说明处置成功了。

以下内容除特别注明外，皆翻译自原文。我亦不对内容做任何的担保，并不对任何可能产生的后果（包括但不限于文件丢失或功能异常）负责。

好吧，咱们看看这个代码：

1
2
3
4
5
6
7
8
9
10

const reportError = ({ message }) => {
    // 把错误信息发给我们的日志服务...
}

try {
    throw new Error('Oh no!')
} catch (error) {
    // 我们会让代码继续执行，但先把错误报告出去
    reportError({ message: error.message })
}

这么写应该足够好了吧？嘛，毕竟这是JavaScript。要是换成TypeScript的话：

1
2
3
4
5
6
7
8
9
10

const reportError = ({ message }: { message: string }) => {
    // 把错误信息发给我们的日志服务...
}

try {
    throw new Error('Oh no!')
} catch (error) {
    // 我们会让代码继续执行，但先把错误报告出去
    reportError({ message: error.message })
}

这时候reportError的error.message这部分就要报错了。因为（就在最近）TypeScript把error的类型定义成了unknown。这倒也是事实，因为它确实没法保证抛出的错误的类型。哦对，这也是你不能用promise的泛型(Promise<ResolvedValue, NopeYouCantProvideARejectedValueType>)，来给promise reject的.catch(error => {})指定类型的原因。而且，被抛出来的东西可能都不是一个error，它可以是任何东西：

1
2
3
4
5
6

throw '啥玩意？！' // 译者注：原文为 'What the!?'，请尝试用东北口音理解
throw 7
throw { wut: 'is this' } // 译者注：wut可以用来表达“傻眼”语境下的what，类似“什么鬼”
throw null
throw new Promise(() => {})
throw undefined

说真的，你可以想throw啥就throw啥，啥东西都行。那，要解决上面提到的错误信息好像挺简单对吧，我们在catch中声明代码只会抛出error不就行了？

1
2
3
4
5
6

try {
    throw new Error('Oh no!')
} catch (error: Error) {
    // 我们会让代码继续执行，但先把错误报告出去
    reportError({ message: error.message })
}

想的美！现在你会得到这么一条TypeScript的编译错误：

1

Catch clause variable type annotation must be 'any' or 'unknown' if specified. ts(1196)

报这个错的原因是，尽管看起来在我们的代码里不可能会抛出来其他的东西，但JavaScript就这么逗，一个第三方库完全有可能做点什么奇怪的事，比如给Error的构造函数来个猴子补丁（译者注：monkey-patching），让它抛出点不一样的东西：

1
2
3

Error = function () {
    throw 'Flowers'
} as any

那咱们开发者该怎么办？我们只能尽力，比如这样：

1
2
3
4
5
6
7
8

try {
    throw new Error('Oh no!')
} catch (error) {
    let message = 'Unknown Error'
    if (error instanceof Error) message = error.message
    // 我们会让代码继续执行，但先把错误报告出去
    reportError({ message })
}

妥了这不！现在TypeScript也不跟我们嚷嚷有问题了，而且万一这个error是什么奇怪的东西，我们也用了合适的办法来处理它了。而且这段代码我们还能继续优化成这样：

1
2
3
4
5
6
7
8
9

try {
    throw new Error('Oh no!')
} catch (error) {
    let message
    if (error instanceof Error) message = error.message
    else message = String(error)
    // 我们会让代码继续执行，但先把错误报告出去
    reportError({ message })
}

那么现在，如果这个error不是一个Error对象，那么我们就直接把它变成一个字符串并祈祷这个错误信息能有点用。

然后，我们还能把这段代码抽出来做成一个工具方法来给所有的catch块用：

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

function getErrorMessage(error: unknown) {
    if (error instanceof Error) return error.message
    return String(error)
}

const reportError = ({ message }: { message: string }) => {
    // 把错误信息发给我们的日志服务...
}

try {
    throw new Error('Oh no!')
} catch (error) {
    // 我们会让代码继续执行，但先把错误报告出去
    reportError({ message: getErrorMessage(error) })
}

这个写法在我的项目里面特别好用。希望也能帮助到你！

更新：Nicolas针对error对象并不真的是error的情况提了一个很好的建议。此外Jesse也提出了一个建议，在可能的情况下把error对象也转换成字符串。把这些结合起来，我们就得到了这样的一份代码：

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

type ErrorWithMessage = {
    message: string
}

function isErrorWithMessage(error: unknown): error is ErrorWithMessage {
    return (
        typeof error === 'object' &&
        error !== null &&
        'message' in error &&
        typeof (error as Record<string, unknown>).message === 'string'
    )
}

function toErrorWithMessage(maybeError: unknown): ErrorWithMessage {
    if (isErrorWithMessage(maybeError)) return maybeError

    try {
        return new Error(JSON.stringify(maybeError))
    } catch {
        // fallback in case there's an error stringifying the maybeError
        // like with circular references for example.
        return new Error(String(maybeError))
    }
}

function getErrorMessage(error: unknown) {
    return toErrorWithMessage(error).message
}

简直太好使了！

结论

我觉得关键在于，尽管TypeScript有一些奇怪的地方，但也绝对不要因为你觉得这不可能就忽略TypeScript抛出的编译错误或警告。大多数情况下，意外是非常有可能发生的，而TypeScript很好的强制你去处理这些“不太可能发生”的情况……然后你也很有可能会发现，这些情况并没有你想的那么少见。

译者的碎碎念：作为一个TypeScript纯新手的我，最后这段代码给我看傻了。Java里面非常常见的try {...} catch (Exception e) {...}在TypeScript里面竟然能玩这么花……

以下内容除特别注明外，皆翻译自原文。我亦不对内容做任何的担保，并不对任何可能产生的后果（包括但不限于文件丢失）负责。

免责声明：标题有些夸大其词了，而且针对这个问题也有其他好用的解决方案。但我确实觉得这也是一个优雅的技巧。

最近我在Hacker News中看到一篇帖子，是讨论人们怎么管理他们的点文件的。在这篇帖子中，用户StreakyCobra分享了一个他的很优雅的配置，而且我觉得非常的靠谱。正巧我也在开始用同样的技巧来管理我的系统。这个技巧也只有一个前置条件：你安装了Git。

按他的说法，这个技巧：

不需要别的工具，不需要创建符号链接，文件都被版本控制系统跟踪，你可以用不同的分支来管理不同的系统，在全新的系统中你也可以轻松复用你的配置。

这个技巧包括两个部分：用一个单独的文件夹（如$HOME/.cfg或$HOME/.myconfig）作为裸Git仓库；和一个专门用来操作这个仓库的命令别名（译者注：alias）。

从零开始

如果你还没有用一个Git仓库来跟踪你的配置文件，那么你可以从下面这几个简单的命令开始，一步步实现这个技巧。

1
2
3
4

git init --bare $HOME/.cfg
alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
config config --local status.showUntrackedFiles no
echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.bashrc

• 第一条命令会创建一个用来跟踪文件的裸Git仓库~/.cfg（配置仓库）
• 接下来创建一个命令别名config，在我们要操作配置仓库时就会用这个命令，而不是git命令
• 设定一个仅对配置仓库生效的设定 —— 不显示未追踪的文件，这样在我们执行config status等命令的时候，我们不想跟踪的文件就不会以untracked状态被显示出来
• 此外我们可以把这个别名的声明添加到.bashrc里面，方便以后使用

我把上面这些命令集合成了一个代码片段放到了Bitbucket上，并给它做了一个短链接，所以你可以用下面的命令一键执行：

1

curl -Lks http://bit.do/cfg-init | /bin/bash

（译者注：在执行来自网络的代码之前，一定记得先看看内容。闭著眼执行远程命令是一件很危险的事，因为你不知道这个链接的内容是否还正确，比如曾经课本上本来指向《历朝历代咏武侯诗词大全》的网址，在域名过期之后被黄网搞去了……）

在配置完成后，$HOME目录下的文件就可以用刚刚创建的config别名来进行版本控制了，比如：

1
2
3
4
5
6

config status
config add .vimrc
config commit -m "Add .vimrc"
config add .bashrc
config commit -m "Add .bashrc"
config push

把这些点文件安装到新系统（或迁移到本系统）

如果你已经用Git仓库管理你的配置或者点文件，那你可以跟着下面的步骤，来把这个配置迁移到新的系统：

• 首先确认你已经配置好了命令别名

1

alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'

• 在克隆你的配置仓库前，记得让git忽略它，以避免各种奇怪的问题

1

echo ".cfg" >> .gitignore

• 然后你就可以把你的点文件克隆到一个存在于“点目录”的裸仓库中

1

git clone --bare <git-repo-url> $HOME/.cfg

• 在当前shell会话中定义好config这个别名

1

alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'

• 从裸仓库中把配置checkout到$HOME

1

config checkout

这一步可能会报这样的错误

1
2
3
4
5

error: The following untracked working tree files would be overwritten by checkout:
    .bashrc
    .gitignore
Please move or remove them before you can switch branches.
Aborting

这是因为你的$HOME目录可能已经有这些文件，而checkout操作可能会让它们被覆盖。解决方法也很简单：这些文件要是有用，那就备份出来，没用那就删了。你可以用我这个比较粗糙的命令，来一键把有冲突的文件移动到备份目录：

1
2
3

mkdir -p .config-backup && \
config checkout 2>&1 | egrep "\s+\." | awk {'print $1'} | \
xargs -I{} mv {} .config-backup/{}

然后重新执行config checkout

• 为配置仓库设定不显示未跟踪的文件

1

config config --local status.showUntrackedFiles no

• 到此就完成了，接下来你就可以和之前一样用config命令来管理你的点文件了。

同样，我也提供了一个一键脚本，把它作为代码片段放在了Bitbucket上。你可以用这个命令来执行：

1

curl -Lks http://bit.do/cfg-install | /bin/bash

为了文章的完整起见，这是我最终得到的脚本（已经在很多个全新启动的Alpine Linux容器中做过测试）

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

git clone --bare https://bitbucket.org/durdn/cfg.git $HOME/.cfg
function config {
   /usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME $@
}
mkdir -p .config-backup
config checkout
if [ $? = 0 ]; then
  echo "Checked out config.";
else
  echo "Backing up pre-existing dot files.";
  config checkout 2>&1 | egrep "\s+\." | awk {'print $1'} | xargs -I{} mv {} .config-backup/{}
fi;
config checkout
config config status.showUntrackedFiles no

（译者注：原文的if-else部分似乎缩进有问题，我调整了下格式，未对脚本内容做改动）

结语

我希望你们能觉得这个管理点文件的小技巧能产生帮助。如果你有兴趣的话，可以到这里看我的点文件。另外别忘了关注@durdn或我那炫酷的小组@atlassiandev。

首次运行brew bundle的时候它就会自动安装了。如果要导出App Store安装的程序的话，那么还需要安装mas这个Formula。

然后就可以执行brew bundle dump，它会在当前目录下生成一个Brewfile文件，里面就是你电脑上目前装的软件，内容就像这样：

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

# 各个Homebrew仓库
tap "beeftornado/rmtree"
tap "bell-sw/liberica"
tap "homebrew/autoupdate"
tap "homebrew/bundle"
tap "homebrew/cask-fonts"
tap "homebrew/cask-versions"

# 通过Homebrew安装的Formula
brew "cloudflared"
brew "curl"
brew "git"

# 通过Homebrew安装的Cask
cask "1password"
cask "alfred"
cask "altserver"
cask "arc"
cask "bartender"

# 通过App Store安装的软件
mas "DaVinci Resolve", id: 571213070
mas "Eul", id: 1541991958
mas "Termius", id: 1176074088
mas "WireGuard", id: 1451685025
mas "Xnip", id: 1221250572

# VS Code插件
vscode "ms-python.debugpy"
vscode "ms-python.python"
vscode "redhat.vscode-yaml"

我的这个Brewfile算是简单的，它还支持配置安装参数等，具体可以参考Homebrew Bundle的实例。

如果在导出的时候在当前目录已经存在一个Brewfile，那么它会报错说文件已存在。这时候可以加--force参数强制导出，要在cron里定时导出的话这个参数会很有用。此外如果你想要每个软件的简介，那么还可以加上--describe参数，出来的Brewfile就会是这样的：

1
2
3
4
5
6

# Mac App Store command-line interface
brew "mas"
# Java-based project management
brew "maven"
# Menu bar icon organiser
cask "bartender"

不过--describe参数只对brew和cask条目生效，tap、mas和vscode条目都是没有描述的。

我试用后发现，似乎mas这部分会把你已经卸载的软件也列出来，而第二次再dump的时候又另外发现了一个之前没列出来而已经通过App Store安装的程序，所以这部分可能需要在导出之后自己再人工校验一下。

要按照Brewfile安装软件的话，只需要cd到Brewfile所在位置然后执行brew bundle就会自动开始安装。

如果要把不在Brewfile中的软件删除，那么可以运行brew bundle cleanup命令。

此外，运行brew bundle check可以检查哪些软件在Brewfile里列出来了，但是还没安装。但是我用刚刚导出的Brewfile检查却报了brew bundle can't satisfy your Brewfile's dependencies.Satisfy missing dependencies with ``brew bundle install``.这样的消息，我就有点怀疑这个检查到底准不准……

什么是AQS

AbstractQueuedSynchronizer，抽象队列同步器，是很多同步器（如ReentrantLock、CountDownLatch、Semaphore）等都是基于它实现的。

在AQS内部，它维护了一个FIFO队列，和一个volatile类型的变量state。FIFO队列用来实现多线程的排队工作，线程加锁失败时，这个线程就会被封装成一个Node节点放到队尾，然后当锁被释放后，队列头部的线程就会被唤醒并让它重新尝试获取锁；state变量用来记录锁的状态，如Semaphore的permit就是存在state里面的。

状态管理

上面说到，AQS使用一个volatile的int变量state来管理锁的状态，state为0时说明锁被释放，反之锁被持有。

AQS提供了三个方法来同步锁的状态：getState()，setState(int newState)和compareAndSetState(int expect, int update)。

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

/**
 * The synchronization state.
 */
private volatile int state;

/**
 * Returns the current value of synchronization state.
 * This operation has memory semantics of a {@code volatile} read.
 * @return current state value
 */
protected final int getState() {
    return state;
}

/**
 * Sets the value of synchronization state.
 * This operation has memory semantics of a {@code volatile} write.
 * @param newState the new state value
 */
protected final void setState(int newState) {
    state = newState;
}

/**
 * Atomically sets synchronization state to the given updated
 * value if the current state value equals the expected value.
 * This operation has memory semantics of a {@code volatile} read
 * and write.
 *
 * @param expect the expected value
 * @param update the new value
 * @return {@code true} if successful. False return indicates that the actual
 *         value was not equal to the expected value.
 */
protected final boolean compareAndSetState(int expect, int update) {
    return U.compareAndSetInt(this, STATE, expect, update);
}