比如掘金的奖品发货问题，用户总是每天反馈。为什么会有这么多反馈？负责的人每天都在做什么？

1、你的活动结束后，有没有按照承诺的时间发出奖品。如果不能，为什么不说？

2、如果是部分发货，为什么不跟未发货的同学解释？

3、如果用户没有按时填写问卷，有没有应对方案。有没有可能做的更有温度一点？

4、每次活动到处嗷嗷嗷，实际最后啥也不是，为什么自己不反思？

别找那么多理由，你特么是运营，这都干不好？你还能干啥？

如果你觉得好难做哦，那可能难的不是这些事本身，难的是改变自己的一些旧行为或习惯。

new bing 的申请，没啥好说的，简单直接，跟 Notion AI 一样，最好全局一下，进入网址www.bing.com/new，加入等待，等通知邮件。

但是有大部分同学，应该跟我一样，自己用了多年的主账号，不管怎么样，按照网上说的各种法子尝试都是不会成功。

如下图所示：点击“加入等待列表”但一直提示“出错了，请重试”，

无奈之下，换了一个新账号尝试，如果你是一个注册的新账号，new bing一定会成功加入 waitling list。

作为微软 office 365 多年的订阅用户，微软全系列产品 msdn订阅 的正版用户。在关键时候P 用没有。在 msdn 社区反馈之后，接到专家的一个电话，告知解决方案。

之前用过的解决方案：

• 什么改 dns 都是瞎扯。
• 有人说可能跟Microsoft rewards 有关系，我也清理了全部rewards，仍然出现同样错误。在手机上面尝试加入等待列表，错误一样。

真正的解决方案：

最终跟专家确认，new bing 的体验确实受 Microsoft rewards 影响，但是清理全部 rewards 没什么用，可以通过：https://rewards.bing.com/optout 退出rewards计划，之后再通过：https://rewards.bing.com/加入rewards； 之后再点击加入waitling list 候补就可以了。

工作中很容易犯下这样的错误，在不假思索或者证据不足的情况下，对问题进行主观性判断，并给出一个偏主观的结论，接着开始拒绝新的思想、经验或观点，并对他人的意见也持怀疑态度。

保持认知的开放性，比较重要，但前提是能够感知到自己对认知闭合的倾向性。

• 原文地址：3 Uncommon Bash Tricks That You Should Know
• 原文作者：Adam Green
• 译文出自：掘金翻译计划

优秀的开发人员往往键入的内容更少 —— 这也让他们能够：

• 更快地工作
• 更准确地工作
• 减少错误
• 减轻双手疲劳的压力

一种减少键入的方法是恰当地使用你的命令行（通常是 Bash），而本文将要向大家介绍的内容就是 —— 3 个减少键入的 Bash 技巧。

本文中介绍的 3 个 Bash 技巧是：

1. 使用 {a,b} —— 扩展参数，以避免再次键入单个命令
2. 使用 $_ —— 访问最后一个参数，以避免从最后一个命令中重新键入
3. 使用 ^old^new —— 快速更改最后一条命令的一部分

所有这些技巧都与 zsh 兼容。

本文输入的命令均以 $ 开头。对于命令行解析后的代码，我将在相关代码下面以不带 $ 的单独一行写出这句代码等同的解析后的代码。

{a,b} 拓展参数

当我们在编写命令时，我们常会重复输入同一个命令。

以更改文件后缀为例，我们一般使用的是 mv：

1

$ mv README.txt README.md

注意到我们写了两次 README，而参数扩展就可以避免这种重复 —— 更改文件的后缀而无需输入 README 两次：

1
2

$ mv README.{txt,md}
mv README.txt README.md

我们使用的参数扩展为 {txt,md}，而它将会扩展为两个参数 —— txt md（会以空格分隔）。

参数扩展会为花括号内，以逗号分割的每个元素分别创建一个参数：

1
2
3
4
5

$ echo {1,2,3}
1 2 3

$ echo pre{1,2,3}
pre1 pre2 pre3

空元素将创建不带任何替换项的参数：

1
2

$ echo pre{,1,2}fix
prefix pre1fix pre2fix

另一个例子 —— 我们将要把 data 文件夹中的 models 文件夹重命名为 ml：

1

$ mv data/models data/ml

我们可以使用参数扩展来节省重新输入 data/ 的时间：

1
2

$ mv data/{models,ml}
mv data/models data/ml

我们可以使用带有数字序列的参数扩展 —— 这在创建顺序编号目录时很有用：

1
2

$ mkdir data{0..2}
mkdir data0 data1 data2

我们还可以在参数内部进行参数扩展 —— 例如，更改路径中的文件夹名称：

1
2

$ cat models/{baseline,final}/data.csv
cat models/baseline/data.csv models/final/data.csv

最后一个示例：在 mv 命令中，我们使用了 3 个参数 —— 将两个 Python 文件移动到 tests 文件夹中：

1

$ mv test_unit.py test_system.py tests

小结

每当你在单个命令中多次键入某些内容时，参数扩展极大可能可以帮助你节省精力。

使用 $_ 使用访问最后一个参数

终端由一系列命令操作构成，而我们经常在多个命令之间重用信息。

如果说我们前面的技巧，参数扩展，是用于减少在单个命令上的键入的。那么现在这个技巧则是用于减少对多个命令的键入。

以创建文件夹并将当前目录转移到其中的情况为例：

1
2

$ mkdir temp
$ cd temp

现在我们其实可以通过使用 $_ 将上个命令的参数传递过来，避免让自己重复键入同样的内容：

1
2
3

$ mkdir temp    
$ cd $_ 
cd temp 

上面的代码中，我们使用了 $_ 访问上一个命令的最后一个参数，在本例中这个参数为 temp。

想要重用上一个命令的最后一个参数（本例中为 temp）的场景其实非常普遍，以至于 Bash 会将其存储在一个特殊的变量 _ 中。我们需要使用 $ 前缀来访问它（与 $PATH 或 $HOME 相同）。

下面是使用 $_ 的另一个示例 —— 移动文件并借助 cat 使用打印内容到 STDOUT：

1
2

$ mv main.py src/main.py 
$ cat src/main.py

那么现在我们该如何再次重用最后一个参数 src/main.py？

你可以使用以下命令重写此代码，$_ 在第二个命令中会自动替换为 src/main.py：

1
2
3

$ mv main.py src/main.py 
$ cat $_
cat src/main.py

使用 $_ 意味着你不需要重写复杂的文件路径，从而不会在重新键入时出错。

小结

每当你需要在多个命令重复键入某些内容时，使用 $_ 可能有助于减轻疲惫的双手的压力。

使用 ^old^new 快速替换

有时，我们可能在命令行管理程序中运行了一个命令，并很快意识到自己在命令中犯了一个错误。

但其实我们无需再次键入命令，我们可以使用快速替换，通过更换上一个命令中的内容来修复错误。

举个例子 —— 你希望通过 ssh 连接到服务器，并运行了命令去连接 —— 运行后才意识到用户名应该是 user 而非 ubuntu！

1

$ ssh ubuntu@198.compute.com

你可以使用快速替换来更改所需的部分，而不必再次重新键入整个命令以在此处将 ubuntu 改为 user：

1
2

$ ^ubuntu^user
ssh user@198.compute.com

快速替换的格式是 ^old^new，等效于：

1

$ !!:s/old/new

!! 用于获取最后一个命令，而 :s 是替换的正则表达式。我想你会同意 ^old^new 减轻了不少工作负担！

小结

当你写错了命令，并且命令不方便重写（例如很长），那么，使用 ^old^new 能够极大的减轻你的麻烦。

感谢阅读！

如果发现译文存在错误或其他需要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。

• 原文地址：why Websockets are Hard To Scale？
• 原文作者：nooptoday
• 译文出自：掘金翻译计划
• 本文永久链接：https://github.com/xitu/gold-miner/blob/master/article/2022/why-websockets-are-hard-to-scale.md
• 译者：CompetitiveLin
• 校对者：CarlosChenN Quincy-Ye

为什么 Websockets 难以扩展？

封面图片来自于 法比奥

Websockets 提供了一个重要的特性：双向通信。这使得服务器在不需要客户机请求的情况下向客户机推送事件。

Websockets 这种双向的特性是一把双刃剑！尽管这种特性为 websockets 提供了大量的用例，但与 HTTP 服务器相比，实现一个可伸缩的 websockets 服务器要困难得多。

无耻的自我推销： 我认为 websockets 是 web 网页的一个重要部分并且它们需要在软件开发界得到更多的认可。我正在计划发布更多的有关于 websockets 的文章。如果你不想错过这些文章，你可以访问 https://nooptoday.com/ 并且订阅我的邮箱列表！

是什么让 Websockets 如此独一无二?

Websocket 是一个应用层的协议，就像 HTTP 是另外一个应用层的协议一样。这两个协议都是通过 TCP 连接实现的。但是他们有不同特点，就像他们代表着通信世界的两个不同国家（如果这样形容能让你理解的话）。

HTTP 带有基于请求—响应的通信模型的标志，Websocket 带有双向通信模型的标志。

附注：为了更清晰地描述 Websocket，你将在文章中看到 HTTP 和 Websocket 的对比。但这并不意味着它们是相互竞争的协议，相反，它们都有自己的用例。

Websocket 的特点：

• 双向通信
• 长期的 TCP 连接
• 有状态的协议

HTTP 的特点：

• 基于请求响应的通信
• 短期的 TCP 连接
• 无状态的协议

有状态 vs. 无状态协议

我相信你看过一些关于创建无状态、可无限扩展的后端服务器的文章。这些文章会告诉你使用 JWT 令牌进行无状态的身份验证，并在无状态应用程序中使用 lambda 函数等。

• 这些文章所谈论的状态是什么？当涉及到扩展服务器应用程序时，为什么它如此重要？

状态是你的应用程序为了正确运行所必须记住的所有信息。例如，你的应用程序应该记住已经登录的用户。99% 的应用程序都这么做并且它被成为会话管理。

• OK，状态真是一个很好的东西！那为什么人们讨厌它并且总是试图做出无状态的应用呢？

你需要在某些地方存储你的状态，而那个地方通常是服务器的内存。但是你的应用服务器的内存对于其他服务器来说是不可访问的，那么问题就来了。

想象这样一个场景：

• 用户 A 向服务器 1 发起请求。服务器 1 授权给用户 A，接着在内存中存储它的会话 A。
• 用户 A 向服务器 2 发起第二个请求。服务器 2 搜索保存的会话，但是无法找到会话 A，因为它被存储在服务器 1 内部。

为了让你的服务器变得可扩展，你需要在应用程序之外管理状态。例如，你可以将会话保存到 Redis 实例中。这使得应用程序状态可以通过 Redis 对所有服务器可用，并且服务器 2 可以从 Redis 读取会话 A。

有状态的 Websocket： 打开 Websocket 连接就像客户端和服务器之间的婚礼：连接一直保持打开状态，直到其中一方关闭它（当然，或者由于网络条件欺骗它）。

无状态的 HTTP： 另一方面，HTTP 是一个令人心碎的协议，它希望尽快结束所有事情。打开 HTTP 连接后，客户端发送请求，服务器一响应，连接就会关闭。

OK，我不开玩笑了，但是记住，Websocket 连接通常是长连接，而 HTTP 连接注定是尽早结束的。当你把 Websocket 引入到你的应用程序时，它就变成了有状态的。

如果你想知道

尽管 HTTP 和 Websocket 都构建在 TCP 之上，但一个是无状态的，而另一个是有状态的。为了简单起见，我不想让你对 TCP 的细节感到困惑。但是请记住，即使在 HTTP 中，底层 TCP 连接也可能存在很长时间。这超出了本文的范围，但你可以在这里学到更多。

我不能只使用一个 Redis 实例来存储套接字吗？

在上一个有关会话的例子中，其解决方法很简单。使用外部服务来存储会话，这样其他所有服务器都可以从那里读取会话（Redis 实例）。

Websockets 是一个不同的例子，因为你的状态不仅仅是关于套接字的数据，所以不可避免地要在服务器中存储连接。每个 websocket 连接都绑定到一台服务器上，其他服务器无法向该连接发送数据。

现在，第二个问题来了，你必须有一种方法让其他服务器发送消息到 websocket 连接。为此，您需要一种在服务器之间发送消息的方法。幸运的是，这已经有一个称为消息代理的东西。你甚至可以使用 Redis 的发布/订阅机制在你的服务器之间发送消息。

让我们总结一下目前为止我们讨论的内容：

• Websocket 连接是有状态的
• Websocket 服务器自动成为有状态的应用程序
• 为了使有状态应用程序能够扩展，您需要有一个外部状态存储（例如：Redis）
• Websocket 连接绑定到单个服务器
• 服务器需要连接到消息代理，将消息发送到其他服务器中的 websockets

（就这样吗？添加一个 Redis 实例到我的堆栈就可以解决了所有的 Websockets可伸缩的问题？）

不幸的是，不是的。好吧，可伸缩的 websocket 架构还有另一个问题：负载均衡

Websockets 的负载均衡

负载均衡是确保所有服务器共享同等负载的一项技术。在普通的 HTTP 服务器中，这可以通过简单的算法例如轮询来实现。但这对于 Websocket 服务器来说并不理想。

想象一下你拥有一个自动伸缩的服务器组，这意味着，随着负载的增加，新的实例将会被部署，而随着负载的减少，一些实例将被关闭。

因为 HTTP 请求的生存时间很短，因此即使添加或删除服务器，所有实例之间的负载也会均衡一些。

Websocket 连接的生存时间很长（持久的），这意味着新服务器不会从旧服务器上减轻负载。因为，旧服务器仍然坚持它们的 websocket 连接。举个例子，假设服务器 1 拥有 1000 个开放的 websocket 连接。理想情况下，当添加一个新的服务器服务器 2 时，你希望将 500 个 websocket 连接从服务器 1 转移到服务器 2。但这对于传统的负载平衡器来说是不可能的。

你可以断开所有的 websocket 连接，并期望客户端重新连接。然后你就可以在你的服务器上实现 500 / 500 个 websocket 连接的分布方案，但这是一个糟糕的解决方案，因为：

1. 服务器将受到重连接请求的狂轰滥炸，服务器负载将大幅波动
2. 如果频繁地扩展服务器，客户端将频繁地重新连接，这可能会对用户体验产生负面影响
3. 这不是一个优雅的解决方案，（我知道你们关心这个！）

这个问题最优雅的解决方法被称为：一致性哈希

负载均衡算法：一致性哈希

如今有各种各样的负载均衡算法，但一致性哈希来自另一个世界。（图片白纸上的内容译为“一致性哈希真的很棒！请改变我的这个想法。”）

使用一致性哈希的负载均衡背后的基本思想是：

• 对即将到来并带有某些属性的连接进行哈希操作，就比如用户 ID => 哈希值
• 然后你可以用哈希值来确定该用户应该连接到哪个服务器

这里假设你的哈希函数将用户 ID 均匀分配到哈希值。

但是！总是有一个但是，不是吗？现在在添加或删除服务器时仍然存在这个问题。解决方案是在添加或删除新服务器时断开连接。

（等一下，什么！你刚刚还说这个一个坏主意？现在怎么又变成了解决方案了呢？）

这个解决方案的美妙之处在于，使用一致性哈希，你不必断开所有连接，而只需删除部分连接。实际上，你需要断开多少连接就断开多少连接。让我用一个场景来解释：

• 最开始， 服务器 1 有 1000 个连接
• 新增服务器 2
• 一旦新增了服务器 2，服务器 1 就会运行重新平衡算法
• 重新平衡算法检测哪些 websocket 连接需要断开，如果我们的哈希函数检测到大约 500 个连接需要到服务器 2
• 服务器 1 向这 500 个客户端发出重新连接消息，然后它们连接到服务器 2。

这是ByteByteGo的一个很棒的视频，这个视频从视觉上解释了这个概念。

一个更简单且高效的解决办法

Discord 管理大量 Websocket 连接。他们是如何解决负载均衡的问题？

如果你研究了开发者文档关于如何建立 websocket 连接，下面是他们是如何做到的：

• 发送一个 HTTP 的 GET 请求到 /gateway 端点，接收可用的 Websocket 服务器 url。
• 连接到 Websocket 服务器。

这个解决方案的神奇之处在于，你可以控制新客户端应该连接哪台服务器。如果添加新服务器，则可以将所有新连接定向到新服务器。如果你想将 500 个连接从服务器 1 移动到服务器 2，只需从服务器 1 删除500个连接，并从 /gateway 端点提供服务器 2 地址。

/gateway 端点需要知道所有服务器的负载分布，并据此做出决策。以最小的负载直接返回服务器的 url。

与一致散列相比，这种解决方案有效且简单得多。但是，一致哈希方法不需要知道所有服务器的负载分布，也不需要事先进行 HTTP 请求。因此，客户端可以更快地连接，但这通常不是一个重要的考虑因素。此外，实现一致的哈希算法也很棘手。这就是为什么，我计划后续写一篇关于为负载均衡 Websockets 实现一致性哈希的文章。

我希望你能从这篇文章中学到一些新的东西，请在评论中告诉我你的想法。如果你不想错过新的文章，你可以订阅邮件列表！

如果发现译文存在错误或其他需要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。

准备

• 首先能能访问 Google（前置条件，不能明确说，懂得都懂）
• 你得有一个国外手机号，GV 号肯定不行。
  • 如果你没有国外手机号，推荐sms-activate.org

注册短信平台并充值

• 先行注册sms-activate.org
• 注册好之后进行对应的充值

接码费用一次为 10.5 卢布，大约1.2 人民币。因为充值默认为美元，可以选择充值 1 美元进去，

注册OpenAI账号

• 打开https://beta.openai.com/signup 页面进行相应的注册。
  • 这里同样需要你能访问Google且 ip 不是香港，最好是美国、新加坡等等，不然会提示不能在当前国家服务。
• 注册成功进入下面填写手机号的页面
  • 下面记得切换下国家区号，这里的区号默认是你代理的。

准备接码

这里需要注意下的就是，目前好像就只有巴西和印度支持了，之前我选的印尼，是可以收到码的。

• 然后再刚刚填写手机号码的页面填入申请的手机号

开始使用ChatGPT

注册完后，我们去ChatGPT网站去登陆。https://chat.openai.com/auth/login

12 月 6 日更新

• 如果你的页面出现下面提示，说明你代理不行~~

• 接不到码，可以在那个有效期内退回换个号试试。
  • 有人直接把发的电话输入框里，没去掉区号也可以收到
• 这个接码网站很全面，我演示充值是 1 美元，你也可以冲一个 0.18美元
• 目前完全支持的是印度+巴西。你也可以选择其他国家的 any+other 选择合适的费用即可。