HTTP/2.0 需要 https
只需要将 listen 443 ssl; 修改为 listen 443 ssl http2;
临时将当前 Shell 会话的文件描述符限制到 65535
ulimit -n 65535
ulimit -n # 查看软限制
ulimit -Hn # 查看硬限制
https://mp.weixin.qq.com/s/BZcRwgGZNinBK9K2L38LYg
Infra 软件的主要使用者, 正在从开发者迅速转向 AI Agent.
计算机底层的东西只从被发明出来之后就一直没变过.
现在的计算机世界都构建在这上面. 大模型在训练的时候,阅读了大量的代码. 对这些底层东西的"理解/认知"已经很深了.
所以设计给 Agent 使用的软件并不是去发明一套"全新的接口",而是贴近这些底层东西的.
好的心智模型的特征是它一定是可扩展的。
心智模型的理解: 就类似于 java 中的接口.心智模型(接口)不变, 实现是可以各种各样.
以文件系统为例: 在文件系统中有 目录,文件, echo, cat, ls, cp 等概念. 这个就理解为心智模型.
关系型数据库有 mysql, oracle, ms sql, sqlite 等. 都有 库, 表, 字段, 行 的概念, 都能增删改查. 只是语法有些许区别.
软件生态重不重要?
对于 Agent 来说, 并不关心你数据库选的是 mysql, oracle, ms sql, sqlite 哪个, 对于它们之间的区别 Agent 都能很快适配.
接口设计
对 Agent 来说好的接口设计应该
当底层系统软件的心智模型是对的、接口的语义是稳定的、结果是可验证的时，上层调用者（Agent）的少量歧义并不会成为系统性问题。Agent 可以通过上下文、反馈和反复尝试来消解它（通常不会错得离谱），而不需要一开始就被迫进入一套过度严格的形式体系。
Server-Sent Events, 是一种基于 HTTP 协议的服务器推送技术. 只允许从服务端到客户端的单向推送.
使用场景
JS 通过 EventSource 对象与服务端建立连接
const url = "xxxx";
// 1. 建立连接
const eventSource = new EventSource(url);
// 2. 消息事件
eventSource.addEventListener("message", this.handleMessage); // 还可以使用 onmessage 方法
// 3. 错误事件
eventSource.addEventListener("error", this.handleError); // 还可以使用 onerror 方法
// 4. 关闭 SSE 连接
eventSource.close();
@GetMapping(path = "/stream-flux", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<ServerSentEvent<MessageData>> streamFlux(@RequestParam("id") String id) {
return Flux.interval(Duration.ofSeconds(1))
.map(sequence ->
ServerSentEvent.<MessageData>builder()
.id(id) // id
.event("periodic-event") // 事件
.retry(Duration.ofSeconds(30)) // 重连时间
.data(new MessageData( // 自定义数据
UUID.randomUUID().toString(),
"heartbeat",
LocalDateTime.now(),
Map.of("clientId", UUID.randomUUID(),
"status", "connected"
)))
.build()
)
.take(1)
;
}
服务器会设置三个响应头:
Context-Type: text/event-stream; charset=utf-8：响应的内容类型是事件流Cache-Control: no-cache：禁止缓存响应内容，确保客户端每次都能接收到最新的数据。Connection: keep-alive 保持 HTTP 连接打开， 以便服务器可以持续向客户端推送数据。如果使用到了 Nginx, 一般还会加上 x-accel-buffering: no, 让 Nginx 不缓冲后端服务器的响应
服务端响应报文:
: 注释\n
id: xxx\n
retry: 5000\n
event:message\n
data: xxxx\n
\n
\n: 注释id: 消息 idretry: 设置断线重连等待的时间event: 设置事件名data: 数据当 HTTP 长连接因网络波动, 服务器重启或者其他异常断开时， EventSource 会自动在一段固定的间隔(未设置 retry 时，默认是 3000ms)后重新发起连接请求。
重连等待时间: 可以通过服务端响应的事件流设置 retry 字段告知客户端下次重连等待的时间。 如 retry: 10000, 等待 10s 再重新连接.
断点续传：Last-Event-ID, 如果发生了重连, 浏览器会把最近接收到的 id 通过 Last-Event-ID 请求头传给服务端. 服务端可以根据这个字段续传, 避免数据丢失.
异常处理，EventSource.onerror 可以监听异常事件。
const source = new EventSource(url);
在出现异常情况之后, 客户端会自动重连.
下面几种情况, 浏览器端在连接断开后会重新建立连接请求。
emitter.complete())SSE 会无限次重连，直到成功或被手动关闭。
不会重连的情况
错误处理, 不同类型的错误需要使用不同的处理策略
服务端通过设置 retry 来控制客户端在断连之后等待重连的时间.
通过监听 EventSource.onerror 事件来实现断线重连机制。
const source = new EventSource(url);
// 在 onerror 中实现断线重连
source.onerror = function (event) {
setTimeout(() => {
source = new EventSource(url);
}, 1000);
};
服务器端可以通过发送特定事件(如 reconnect )来要求客户端重新连接。
// 服务器端设置重连延迟
emitter.send(SseEmitter.event()
.reconnectTime(5000L) // 5秒后重连
.data("数据"));
上面代码对应的报文
retry: 5000\n
data: 数据\n
\n
// 客户端
eventSource.addEventListener("reconnect", function (e) {
console.log("收到重连指令：", e.data);
eventSource.close(); // 关闭当前连接
setTimeout(() => {
connect(); // 重新连接
}, 5000);
});
执行这段代码后，客户端会先断开连接，然后在 5s 后重新连接。
同源, 会直接携带 cookie
跨源, (处于同一主域名的情况下可以使用 withCredentials 来是跨源请求携带 cookie)
const eventSource = new EventSource("https://api.myapp.com/sse", {withCredentials:true})
使用 npm event-source-polyfill 包提供的 EventSourcePolyfil 来携带请求头
const headers = {
"Authorization": "..." // somewhat can update this token when it's refreshed
}
const eventSource = new EventSourcePolyfill("/sse", { headers })
需要注意的是, EventSourcePolyfil 会将 Last-Event-ID 作为请求参数传递,而不是请求头
如果使用 Nginx 配置需要将 proxy_buffering 关闭
proxy_buffering off;
设置响应头 x-accel-buffering 也可以让 Nginx 不缓冲后端服务器的响应
x-accel-buffering: no
防止 XSS 攻击: 一般来说, SSE 接收到数据大多数情况下会显示到前端, 因此需要防范 XSS 攻击
验证连接请求: 检查 Referer 头或使用身份验证令牌.
限制连接数据, 避免资源耗尽
应用层面: 对每个连接计数
Nginx 层面: 限制每个 IP 的连接数
# /etc/nginx/nginx.conf 或站点配置文件
# limit_conn_zone 用于定义连接限制的存储区域
# $binary_remote_addr 使用客户端 IP地址的二进制格式作为 key
# sse_conn 共享内存区域的名称(这个是自定义的)
# 10m 分配 10MB 内存,大概可以存储 160,000 个 IP 地址的连接状态
limit_conn_zone $binary_remote_addr zone=sse_conn:10m;
# 请求速率限制
# rate=10r/s, 单 IP 每秒限制 10 个请求
limit_req_zone $binary_remote_addr zone=sse_req:10m rate=10r/s;
server {
listen 80;
server_name example.com;
location /events {
# 每个 IP 最多 10 个连接
# limit_conn 应用连接限制指令
# sse_conn 前面定义的共享内存区域
# 10 每个 IP 最大连接数
limit_conn sse_conn 10;
# 请求速率限制
# burst=20 令牌桶容量 20, 允许短时间内处理 20 个请求
limit_req zone=sse_req burst=20;
# SSE 特殊配置
proxy_pass http://localhost:3000;
proxy_set_header Connection '';
proxy_http_version 1.1;
chunked_transfer_encoding off;
proxy_buffering off;
proxy_cache off;
proxy_read_timeout 24h;
}
}
系统层面
修改文件描述符 (默认是 1024)
# 临时将当前 Shell 会话的文件描述符限制到 65535
# -n 指定文件描述符(nofile)参数
ulimit -n 65535
# 永久修改 /etc/security/limits.conf
echo "* soft nofile 65535" | sudo tee -a /etc/security/limits.conf # 软限制
echo "* hard nofile 65535" | sudo tee -a /etc/security/limits.conf # 硬限制
# 修改系统级别限制
echo "fs.file-max = 2097152" | sudo tee -a /etc/sysctl. conf # 内核参数
cat /proc/sys/fs/file-max # 查看系统限制
cat /proc/sys/fs/file-nr # 查看当前使用情况
sudo sysctl -w fs.file-max=2097152 # 直接修改（临时）
sudo sysctl -p # 从文件加载（永久）
优化 TCP 连接参数
# /etc/sysctl.conf
# 客户端连接请求 → [SYN队列] → [Accept队列] → accept()处理
net.core.somaxconn = 4096 # 设置listen() 系统调用的最大连接队列长度
net.ipv4.tcp_max_syn_backlog = 4096 # 设置 SYN 半连接队列的最大长度
net.ipv4.ip_local_port_range = 1024 65535 # 可使用的临时端口范围
net. ipv4.tcp_tw_reuse = 1 # 允许将处于 TIME_WAIT 状态的 socket 用于新的 TCP 连接
监控和日志记录
访问控制,只有授权用户才能接受敏感数据
: heartbeat (以冒号开头表示在注释,会被 EventSource API 忽略)问题: 在接口响应的实体类的字段上加 @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss") 发现这个注解没有生效.
@DateTimeFormat 使用的场景是: 用于 Spring MVC 的数据绑定和格式化.
@RequestParam 的字段上@PathVariable 的字段上@ModelAttribute 的实体类字段上原因: @DateTimeForma 不生效的原因是 @DateTimeForma 不支持 @RequestBody 的反序列化.
解决方案: 改用 @JsonFormat 注解
@JsonFormat 是 Jackson 提供的注解, 用于 JSON 序列化和反序列化.
@RequestBody@ResponseBody / @RestControllerFeign Client 调用Redis 序列化MQ 消息Websocket 消息问题：在 Docusaurus 在 static 文件夹下添加一个自己写的 html 文件，在浏览器访问会出现乱码
解决方法：
添加 <meta charset="UTF-8" />
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
</head>
道(核心原理)AI 替代的过程是逐步的.
一般具体技能的生命周期仅为 5~6 年.
广博且多元的知识储 备.
需要掌握的知识真的变多了.
写作能力还是很重要的(逻辑清晰表达的能力,以及运行统计视角分析和解读数据的能力.).
有观点,并从事实去论证这个观点.
中国产业工人不到 2 亿人, 让 2 亿人放开量生产，两倍的地球人都消费不完.
有了 AI 之后,学习知识的门槛在变低.
未来更需要驾驭 AI 的人.
未来的活会越来越难. 以前十个人干的话现在一个人就能干. 但现在一个人干的活,未来需要十个人干(因为功能/需求复杂了).
未来,创新类工作会增加. 因为人们的精神消费需求会越来越多.
写作需要阅读, 研究, 思考和修订.
https://www.aadillpickle.com/blog/post-more
Z 世代(Gen Z: 指 1997-2012 出生的一群人)是被记录和观察得最彻底的一代。你的人生就是场真人秀，永远有观众在盯着看。
想要做出好东西，你必须先跨过尴尬这道坎。
若在真空中创作，你将无从进步。私下里，我做的每件作品都是杰作。只要我不示于人前，就无人能否定这一点。反之亦然。有时我会觉得自己做的东西一文不值，因为距离太近，所有瑕疵都清晰可见；但旁观者保持适当距离审视，反而可能比我自己更懂其价值。无论你对自己作品的评判标准严苛还是宽松，你永远是自己作品最糟糕的裁判。
你发内容的唯一标准，就是觉得至少会有一个人喜欢。
反复发布垃圾意味着你永远不会进步，但从不发布 任何东西也一样。
要让内容真正见效，通常需要三次曝光。
What's this? 这是什么?
建立认知, 吸引注意力.
What's is saying? 说了什么?
用户再次看到广告, 会思考这个广告说了什么.
I need it? 我是否需要
- 第三次看到广告时,用户基本了解产品. 此时会与自己的需求进行匹配.
一个被百万人浏览的网络梗，对世界的影响几乎为零。而你倾注心血的东西，哪怕只有一百个人看到，却可能真正触动某个人，甚至改变他的人生。或者改变你的人生。或者，改变你们俩的人生。
应该发布更多的内容. 这个内容应该对于至少一个人是有价值的/需要的. 不要发布垃圾.
发布的内容应该需要至少三次曝光. 因此, 需要修改你所发布的内容.
快照类比为一张照片.
镜像类比为一个胶卷, 可以生成多个照片.
快照主要用于保护现有服务器的数据, 便于回滚. 镜像主要用于复制环境或批量部署多台相同配置的服务器.