Orlion

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

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 时间差这么多 可能是有慢查询导致连接池满了，请求线程都在等连接。

还是上监控吧😄