现在买不如再等两个月

@yestodayHadRain 那打扰了，Windows server 没接触过，只会 Linux

CKEditor

保护了小白用户，事实上苹果对于小白用户确实很友好。
想玩机就去安卓平台，各种奇技淫巧

楼主你在云服务器里执行一下 free 命令，看看是 free 的值不足 20%还是 available 的值不足 20%。第二位的描述感觉是在说你的内存被 buff/cache 的文件缓存吃掉了，这种情况不需要管，当应用申请内存时操作系统会把文件缓存占用的内存吐出来的。

第一位肯定说的是 swap，第二位。。。好像在说 cache/buffer

我以前还调研了另一种适合小公司的部署方案，如下图所示

https://img.wakzz.cn/202102/pQ8yeTK2if.png

用开源框架 Kong 网关替代 Nginx(Kong 就是对 Nginx 做了一层封装)，然后自行代码开发实现一个节点监听服务，通过对接注册中心的 API 来实时监听各个服务节点的状态。当某服务节点上下线后，注册中心将节点上下线事件推送给监听服务，然后监听服务通过 Kong 的开放 API 修改 Kong 中的 upstream 。

通过上述方案从而实现一个注册中心同时管理微服务之间的服务发现和网关到服务的服务发现。此时应用发布流程例如对某服务的 a 、b 两节点发版时具体逻辑如下：
1. 请求注册中心下线该服务的 a 节点
2. 监听服务监听到 a 节点下线后自动将 Kong 中的 a 节点下线
3. 等待 a 节点无流量请求后发布重启 a 节点的新版本，等待策略简单方案就是等待 1 分钟，复杂点就是监控带宽
4. a 节点启动成功后自动将自己重新注册到注册中心
5. 监听服务监听到 a 节点上线后自动将 Kong 中的 a 节点上线
6. 接着同样的逻辑操作 b 节点

我以前还调研了另一种适合小公司的部署方案，如下图所示

@chenqh 我们公司的 ansible 脚本是自己写的，没有开源

@6EyesFlyFish 这让我想起一次跟第三方联调时压测的网络错误问题，抓包后发现压测到某个阈值就有大量的网络超时，最后查明是对方公司的宽带不够，吐血

通常指的并发是 RPS 每秒请求数量，TPS 是每秒事务请求数量，QPS 是每秒读请求数量，而 RPS 不区分事务请求和读请求，就单纯的每秒请求数量。

主流方案就是先切流量再部署的滚动部署方案，常见的就是 nginx 的 upstream 修改，以及 k8s 的 dns 服务发现。

@rrzwxq 偶现的话，抓包吧，如果是网络问题的话，楼主这个情况应该是异常的连接先 TCP 握手成功，然后 TLS 建立途中出现丢包，接着 TCP 默认重试 3 次发包失败后不再重试，最终断开 TCP 。
如果抓到的包确实符合这个描述，那就是网络问题石锤了。

@zxCoder 其他端口试过，至少在少量 HTTP 请求的前提下没问题。量大了就不知道了，说不准也有个阈值

存 es，并且由自己指定记录 ID，例如以用户 id+搜索内容的 md5 做 id，来实现防重复的情况。

其他服务商我不知道，但楼主这个情况，腾讯云亲测不行。

腾讯云这边买的服务器，如果使用 80 和 443 端口，刚开始没问题，但没几天就会被禁掉，然后强制要求用户实名和域名备案。

建议楼主抓个包，把异常 TCP 抓到后贴出来，单单通过楼主目前提供的数据推测原因有点困难