首页 (5) - 码厩

#548 对过去工作的一点总结和反思

个人工作 2022-01-01

#547 IPv6 地址

计算机网络 IPv6 2021-12-30

#546 转载：免费的编程书籍

阅读开发者 2021-12-30

#545 VPN 重新配置流程

个人工作 2021-12-27

处于安全原因，每隔几个月重新更换一次 OpenVPN 的配置文件，以防被攻击。运维讲配置文件加密打包分发给每个人，然后大家将其覆盖到现在的目录中。

我是 Linux 环境（Ubuntu, 准备切入 Fedora），这里我记录一下更新流程，下次务必 1 分钟之内切换完成。

通过密码解压配置文件

ls ~/Documents/Mine/config20211213/
# ca.crt  client.crt  client.key  client.ovpn

备份之前的证书文件

cd /etc/openvpn
sudo mkdir backup20211227
sudo mv ca.crt client.crt client.key client.ovpn backup20211227/
sudo cp client.conf backup20211227/

采用新的证书文件

sudo mv ~/Documents/Mine/config20211213/{ca.crt,client.crt,client.key,client.ovpn} /etc/openvpn
sudo chmod 400 /etc/openvpn/{ca.crt,client.crt,client.key,client.ovpn}

通过和旧的 client.ovpn 文件比对，讲需要修改的地方同步到 /etc/openvpn/client.conf 中
```
sudo diff client.ovpn backup20211227/client.ovpn
sudo vim /etc/openvpn/client.conf
# w! sudo tee %
```
重新启动 OpenVPN，试一下是否配置成功
```
sudo systemctl restart openvpn@client
```

#544 转载：正则表达式历史

开发者正则表达式 2021-12-19

正则表达式在我们日常的软件开发过程中被广泛使用，例如编写 Nginx 配置文件、在 Linux 与 macOS 下查找文件，然而不同软件不同操作系统对于正则的应用有着不一样的行为，主要原因是正则表达式演进过程中，出现 POSIX 与 PCRE 派系之分。

#543 操作系统是如何解析 DNS 的 [编辑中]

DNS 2021-12-17

#542 DNS 负载均衡 [编辑中]

DNS 负载均衡 2021-12-17

#541 curl 使用的 DNS 为什么和 dig 的结果不一致 [编辑中]

Linux Curl dig 开发工具 2021-12-17

#540 Bing 打不开了

互联网 Bing 搜索引擎 2021-12-17

Bing 是我的默认搜索引擎。但是今天早上发现 Bing 打不开了，只有通过特殊手段才行。

应监管部门要求，Bing 需要在 30 天内对搜索框的建议功能做出整改，看到很多网友贴出了公告。
https://www4.bing.com 目前可用 (随时会挂)
切换到谷歌 DNS 之后，Bing 可以正常访问

Update @ 2021-12-19: 必应搜索恢复正常访问（持续时间大约 2 天）。

#539 Tornado 正在死亡

Tornado 2021-12-16

2020 年 10 月发布的 6.1，结果到现在，已经一年多过去了，6.2 还没有见到。
Update @ 2022-04-28: 又过去了小半年，6.2 还是没有影子。

从 GitHub 提交频率图上明显可以看到 Tornado 的活跃度大幅下滑，2020 年的提交已然不多，2021 年更加惨不忍睹。

官方协程框架 AsyncIO 的诞生，标志着 Tornado 的历史使命已经完成。

是时候带着对 Tornado 的回忆，全面转投原生协程生态了。

#538 plocate

Linux 命令行 2021-12-15

#537 基于 CentOS Stream 的桌面环境

CentOS 2021-12-15

CentOS Stream 9 已于月初发布，基于 Fedora 34，这就是 RHEL 9 未来的发展方向。
CentOS Stream 的稳定性应该是比 Fedora 更好，如果我想选择改用 Fedora 当桌面环境，为什么不试试 CentOS Stream 呢？
这里就开始调研一下。

#536 Node 包管理器

NodeJS 2021-12-14

#535 DNS_PROBE_FINISHED_NXDOMAIN

Web开发 DNS 2021-12-14

浏览器突然打不开 zhihu.com, 报 DNS_PROBE_FINISHED_NXDOMAIN。
Windows 网络诊断之后说是 DNS 不可用。
经过检查，使用 DHCP 获取到的 DNS 172.16.0.1。
改成 AliDNS: 223.5.5.5, 223.6.6.6 之后就好了。
然后再改回默认的 DNS 发现也能正常访问了。

我应该在出现问题的时候先尝试 nslookup 一下，看看 DNS 解析出来的到底是个什么结果。
下次遇到再继续更新。

C:\Users\Administrator>ipconfig /all | findstr DNS
   主 DNS 后缀 . . . . . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :
   DNS 服务器  . . . . . . . . . . . : 172.16.0.1
   连接特定的 DNS 后缀 . . . . . . . :
   DNS 服务器  . . . . . . . . . . . : fec0:0:0:ffff::1%1
   连接特定的 DNS 后缀 . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :

C:\Users\Administrator>nslookup zhihu.com
服务器:  UnKnown
Address:  172.16.0.1

非权威应答:
名称:    zhihu.com
Address:  103.41.167.234

#534 Tornado HTTP 服务的 “ACK”

Tornado 2021-12-13

一个请求会先到 A 服务，然后通过 HTTP 调用的方式传到 B 服务 (基于 Tornado)
面对突然涌来的大量请求，B 服务负载迅速升高，响应时间拉长
A 服务的部分请求因为超时断开，然后重发

也就是说，在负载较高的时候，B 会收到一些重复请求。因为负载高的时候，B 其实已经接收过一遍，只是没有响应。
B 服务处理任务结束之后，会将请求加入幂等。但是在 B 服务正在处理的时候，还是会有重复处理的可能性。
如果是一些对数据可靠性有一定要求的场景，这样重复的处理就不能接受。

比较合适的设计应该是 A 和 B 之间通过 MQ 通讯，根本不可能有这样的情况发生，哪怕请求再多也可以按照自己的速度消费，使系统保持最佳状态运行。而且，服务之间解耦之后，可以避免相互影响。

但是，如果不能改变 A B 两个服务的现有设计（调用关系），可以做的事情：

通过请求的正常返回来当 ACK 机制 (本文原本想重点说的内容)
1. 将请求的接收和处理拆开
2. 请求收到，加入队列，然后就可以返回了，这个时间非常短，这个过程出现问题的可能性非常低
3. 如果在处理请求之前，连接断开，那就结束流程，抛弃任务
A 服务的重试机制延迟一个合适的时间（比如 3 分钟）处理，可以通过 MQ, DB, Redis 实现

两个方案都应该能大幅减小出现重复请求的情况，双管齐下效果会更好。
方案一, 如果引入 MQ 或 DB 的话，就会觉得为什么不在 A 服务做；如果不引入新组件的化，复杂是需要保证服务突然挂掉之后，队列数据的恢复。只能在启动服务时通过扫描日志来恢复数据。
方案二，无论是业务还是代码，影响范围比较小，易于实现。

Tornado 实现 ACK 机制

客户端在正常流程处理完成之前，断开连接，会触发 on_connection_close 调用，可以在这个里面做手脚。

class MainHandler(tornado.web.RequestHandler):
    def post(self):
        if self._finished:
            return
        # do something

    def on_connection_close(self):
        LOG.debug('connection closed')
        self._finished = True
        super().on_connection_close()

一	二	三	四	五	六	日