@a33291 所有客户端都可以连上。确实需要内网有一台机器能暴露 http 端口，我们是在内网有一台机器，被 nginx 监听，我用 nginx 转发请求到内网的 hersql transport 服务上。

跟我司开发环境差不多，专门写了个用 http 转发 mysql 包的工具方便从本地连接测试环境的 mysql 。大概原理就是在本机伪装出一个“假 mysql server”，本机 mysql client 连接到本地的假 mysql server ，然后这个假 mysql server 将数据包通过 http 转发到测试环境的一台机器上，这台机器将数据包转发给真正的 mysql server 。

https://github.com/Orlion/hersql

不知道能否解决你的问题

在 x86_64 上 atomic.LoadInt32 实际源码就是直接取数据，对应源码如下：
```
func Load(ptr *uint32) uint32 {
return *ptr
}
```
而 WriteInt32 有所不同，其中使用了 XCHGL ，这个指令有 LOCK 指令前缀的效果，可以保证可见性。
```
TEXT ·Store(SB), NOSPLIT, $0-12
MOVQ ptr+0(FP), BX
MOVL val+8(FP), AX
XCHGL AX, 0(BX)
RET
```

因此在 x86_64 平台上不使用 atomic 包也能保证原子性，但是保证不了可见性，如果程序中对可见性没有要求，以我的认知我觉得可以不使用 atomic 包，话虽如此实际工作中并发场景中该加还是加吧，说不准认知之外还有什么别的坑呢？

btw ，多年前我对这个问题也有过一段时间疑问与探索，整理了一篇博客： https://blog.fanscore.cn/a/34/ 可以参考一下。

确定 ApplicationCollection.Release()调用时机是正确的吗? Release()之后是否还使用到了 ApplicationCollection 或者里面的元素?建议将 Release()的调用代码也发出来。

2. 先扩容保证服务可用，根据业务选择合适的缓存淘汰策略，如果是上线后引起的，能回滚先回滚，然后排查代码看下是否是正常内存占用（过期时间设计是否合理等等）
3. 个人认为是性能与事务（一致性）的 tradeoff

leetcode 338 原题，动态规划的转移方程：bits[i] = bits[i >> 1] + (i & 1)。

https://blog.fanscore.cn/ 更新的不多，但追求高质量

https://blog.fanscore.cn/a/51/ 看下我这这篇文章吧，不知道对你有没有帮助，大概思路是取出一个坐标点附近九宫格所有坐标点，然后在程序中计算每个点距离该坐标点的距离，过滤掉不符合距离条件的点。

虽然文章中使用的是 redis ，但换成 mysql 应该是通用的吧。

1. 依靠索引列缩小扫描行数后再进行复杂查询
2. 查备库

doris 好像也有过期

code: 方便排查问题，根据用户返回的 code 找到问题发生地
msg: 出现了问题，告知用户发生了什么以及如何解决

不仅通过闷头学和造轮子提升了技术、丰富了简历，还得了毕业礼包，这老哥头脑很清晰啊（手动狗头）

unix 响应时间比 tcp 快，因此 python 脚本 cpu 利用率更高？

提个醒 exists 命令在 4.0.11 以下版本的 redis 主从架构中是有 bug 的，详情请看： https://www.cnblogs.com/mysql-dba/p/15870868.html

闭包其实挺好理解的，比如你有一个函数，会返回一个回调函数，这个回调函数中会持有一些自己的局部变量
function bar() {
return function() {
int tmp = 1;
print(tmp);
}
}
callback = bar();
callback();

你当然也可以不返回回调函数，而是返回一个 class,就像下面这样：
class C {
private int tmp;

public C(int tmp) {
this.tmp = tmp;
}

public callback() {
print(tmp);
}
}

function foo() C {
c = new C(1);
return C;
}
foo().callback();

达成的效果其实是一样的，返回的闭包函数其实就等价于一个带有私有属性和一个 method 的 class 。

1. 协程解决的问题
java 实现一个支持并发的 http server,最简单的方案可能就是拿到一个连接就创建一个线程来执行，即一个多线程的 server 。这个 server 连接数高了性能就会非常差，因为线程数会很高，线程切换开销比较大。

现在有个协程，因为协程开销比较小，你仍然可以用这个简单的思路去实现，即拿到一个连接就创建一个协程来执行。go 标准库中 http server 就是这么实现的，简单粗暴。在 go 中实际是封装了 epoll(linux 平台)，由 runtime 调度协程跑在很少数量的线程上，实际上压根就不是原始的多线程方案了，应该是 epoll 方案，所以对于用户来说能以很简单的方式就能实现高性能并发，这就是协程解决的问题之一。

网易云课堂有个视频： https://study.163.com/course/introduction/1002830012.htm ，可以跟着敲一遍代码应该就懂了，再回头看各种编译原理的理论就好懂了。by the way，前端学完了感觉就那么回事，无非就是一些算法，真正的星辰大海还是后端😄。

Navicat 和微服务查询同一条 SQL 时间差这么多 可能是有慢查询导致连接池满了，请求线程都在等连接。

还是上监控吧😄

进到 swap 了？