@ruandao 零拷贝看上去高大上，其实效果远不如物理文件顺序读写，IO 读写才是性能损耗大头，数据内核拷贝的消耗相对来说就是个零头

1. 同一个文件从头都到尾
2. 该文件物理磁盘位置顺序，即写的时候是先申请大块存储空间，然后再在申请的空白空间上写文件，防止文件碎片的问题
3. 该文件不修改或少修改，避免文件碎片

@XDJI 跟事务没关系，我们猜测是 online ddl 对大表加索引时内存没管理好，出问题的 mysql 实例只有 4G 内存，但由于一些原因拿不到日志，所以只能猜测是 OOM 了

@securityCoding online ddl 对于小表可以，千万甚至上亿的大表慎用。
我们公司之前有个千万级的单表，用 online ddl 加索引后前十来分钟索引正常添加，看监控 IO 和 CPU 占用比较高，但十来分钟后 mysql 突然无响应，然后软重启，所有 mysql 线程被中断，客户端 TCP 连接全部中断，索引也加失败了。
这个现在能在 5.7 的版本稳定复现（没试过 8.0 ），所以对大表的索引操作还是需要谨慎使用 online ddl 的，这玩意不是银弹。

万年 1.8

老用户 2 核 4G6M 的轻量服务器，3 年 439 元，还是非常优惠的

末班车

* 的作用域是非 root 用户，你如果用的 root，作用域应该是 root，如下

* soft nofile 65537
* hard nofile 65537
root soft nofile 65537
root hard nofile 65537

请求拦截由网关处理，微服务不做拦截，各司其职

绝大多数系统用不上接口抽象，后来就很少用接口了，除非一开始就确定这快逻辑有多个实现类所以要抽象个接口出来。

这是睡眠太久线程给睡死了，所以我们一般是这么写的，阻塞操作给个最大睡眠时长，从而实现定时唤醒来防止线程睡死的情况。

```java
class Task implements Runnable {
@Override
public void run() {
while (true) {
try {
Object item = blokingQueue.poll(1, TimeUnit.MINUTES);
if (item == null) {
continue;
}
// TODO
} catch (Exception e) {
log.error(e.getMessage(), e);
}
}
}
}
```

应该是你的代理规则出问题了

应该是备案问题，备案没过会封 80 、443 端口

也有可能是楼上说的，伤口流脓导致创口贴不透气

不要用不透气的创口贴，尤其是防水创口贴，只会令伤口减缓愈合，伤口要用透气创口贴充分接触空气才能更快愈合。

OSS+CDN，再买个流量套餐，按量计费的话最后差不多 0.17 元 /G 。

一般都是用雪花 ID 直接作为主键，不需要额外再搞个字段做主键了。

因为 redis 性能高哇，ZK 跟 ETCD 在高并发场景试试，分分钟成为瓶颈。

垃圾文章确实，这几年垃圾文章暴增，各种复制粘贴水平低下，看着标题都懒得点了

2. 请求通过版本号分流