*req = *req.WithContext(...)

可以参考 k6 https://github.com/grafana/k6, 可以用 js 写压测逻辑，是内嵌了一个 go 写的 js 编译器 https://github.com/dop251/goja

上海房产税都收 10 年了，只针对 >= 2 套，还有个人均免征面积

确定上游没到极限的话，大概率是锁竞争过多导致 cpu 利用率上不去。
给个思路，runtime.SetMutexProfileFraction(5) 打开 mutex profiling
然后看 pprof 的 mutex 火焰图，看瓶颈在哪。

简单看了下代码 https://github.com/songquanpeng/one-api/blob/01f7b0186fae589e0e5fb83ab0e6d033ba5339aa/controller/relay-text.go#L376 比如这个地方直接用了一个全局的 httpClient, 里面是从连接池里取连接时候是有锁的，之前碰到过这个问题，优化办法是根据 cpu 核心数实例化多个 client, 每次随机挑一个发请求。

另外 http.Client 的 MaxIdleConnsPerHost 默认值是 2 ，conn 会被频繁回收，试试设置成几百。

AP 有个小细节挺不错的, 如果旁边有大车, 即使它没越线 AP 也不会傻傻的居中保持,会稍微往反方向偏一点, 通过时人不会那么紧张.

trigger 可以做一些 audit 的事，比如对核心数据表做了 CUD 操作时候自动记录或同步，在企业级应用里用的还挺多。之前碰到的一个具体例子是用户多端登陆的时候只保持最新 session 的有效性，在代码里当然能做，但当时场景特殊，客户那端不能部署新代码，但可以操作数据库，就用 pg 的 trigger 监听了 token 表的插入事件，将该用户所有 valid 的 token 全部置 false 。用 trigger 会导致逻辑分散，难以排查死锁问题，对表做 DDL/DML 操作时还要当心上面有 trigger ，在有一定并发量的互联网业务里都不推荐用。

view 在 OLAP 场景下用的很多，比如 materialized view 就很实用，对纯开发用处就不大。

马斯克最早做了家做线上支付的公司就是 x.com, 这公司后来和另一家公司合并成了 paypal

快拔，智齿因为在里面，刷牙不容易刷干净，很容易蛀的，不要等，容易变成牙髓炎

上海现在新房都不许外开的，全是内开，好一点的窗户是同时支持内开内倒的，只是透气内倒也够了，也不进雨

按我经验。。。验房师没啥用，他敲敲打打能看出来的问题你上 b 站看几个视频也能看出来，隐蔽工程的坑都没法检测的，要住了才知道。

开发商/物业如果负责，找没找验房师问题都会给你修的，不负责找不找验房师都不会给你修，想着等问题都解决了再签收基本没可能(上海这里)，大多都是先收房再验房(当然我觉得这并不合理)。

有的验房师为了夸大自己的作用会把一些问题说得很严重，比如瓷砖空鼓，人工贴的砖完全没空鼓是不可能的，关键看空鼓程度。

我邻居之前土巴兔团购的验房师就很坑，用油性笔在大理石上做标记，结果渗进去了，不赔钱也不退钱，那印记现在还在。

仅供参考，实在没经验几百块买个心安也未尝不可。

@yfwo 以前看<月曜夜未央>有一期特别搞笑, 去大阪路边采访，很多中国人排队吃鳗鱼饭，店主大爷就很困惑的说，我们鳗鱼明明都是从中国进口的，他们为什么跑来日本吃.

做过个类似的东西 https://github.com/monsterxx03/gospy

不过只能读 runtime 信息，不能动态注入指令, 用处是不很大，但挺好玩的, 具体原理可以看 https://blog.monsterxx03.com/2019/09/20/gospy-non-invasive-goroutine-inspector/

如果你的 BCD 确定都是 ssh 的话, 其实可以, 在 ProxyCommand 里用 openssl wrap 一下, 在 tengine 那边根据 sni 做分发. 如果是任意 tcp 协议不行，除非也能用 openssl 包一下. 参考: https://iyzico.engineering/proxy-ssh-using-tls-sni-and-nginx-8a18f93f709

LD_PRELOAD, eg: https://github.com/a2o/snoopy

@hxndg 他大概是想依靠一个内核机制来解决一个业务层的问题. tcp_syn_retries 是可以设置的, 不同发行版默认值不一样, 一般默认是 6 次

没有 tcp syn retry 不行, connect timeout 就是在规定时间内重复发 syn 包罢了, 没 syn 包不可能握手成功.

你想要的效果理论上通过同时增大 curl --connect-timeout 和 net.ipv4.tcp_syn_retries 实现, 但这么干很傻
1. 对面防火墙可能给你回 RST
2. tcp_syn_retries 最大 255, 理论最长超时时间大概几个小时吧.
3. tcp syn retry 的间隔时间类似 exponential backoff 的方式计算的, 上限好像是 2min? 不确定. 所以你可能对面 server 起来后过了 2 min 钟你才连上.

只能在业务层面轮询.

@avastms 块设备很成熟了啊, aws ebs, gce pv, aws 自己的 rds 和 aurora 也是基于 ebs 的, 动态扩容一直可以, 缩不行, 但就我经验, 大多数业务缩容并不是一个刚需. 多挂载算是个痛点, NFS 这种太弱了, 但大多数应用也不是刚需. 现有的 sds 块设备方案基本能解决我碰到的 90%问题, iops 性价比也算是个问题.