@YouXia 文章里面的确是没有 master 的意思，因为每个节点都是 master。
@yidinghe 如果我没有理解错的话。也可以说这个分布式没有水平拓展性。因为单机解决不了的数据，上这个分布式方案也解决不了。

库没有说，默认线程不安全，自己 review 或者加锁

hash 表的实现各大算法书都有写，就算没写，也有 CPython 的源代码。
这个完全不需要讨论吧

@MeteorCat
![[email protected]]( https://i.loli.net/2018/09/18/5ba09d5d4879c.png)

没看出引起额外的析构

而且你想性能好些应该用 epoll 来监听 socket 是否可读，用另外一个线程去读

@userlol 如 3 楼所说，你必须先循环读出头部，然后才按长度去读剩下的部分。
还有就是你读到尾部，也有可能是一部分尾部，一部分是另外一个请求，记得将他们分开

你自己不 parse 就想读出来？ tcp 又不保证你一次就收到全部数据

@geekyoung 就是 3.7 的 python 不会在 /usr/local/Cellar/python3/3.6.1/bin/，brew 将旧的卸载了，但是你之前的路径是写的绝对路径，新的 3.7 是在 /usr/local/Cellar/python3/3.7.1/bin/之类的路径嘛

@jokerlee @tcsky 这样我觉得其实架构师需要背锅了。出来久了，面试多，项目做多了，我觉得一个合格的架构师的确是需要预估业务量的。然后选择合适的架构。以前还好觉得很多项目都很容易做烂，不过我现在觉得，刚开始选一个性能高一些的架构的确是好事。开发效率其实可以从外部库来提升的。比如现在基于 openresty 的东西他们的性能都不差，业务写起来其实跟其他的框架也不会差到哪里去。
因为以前自己也干过无脑加线程的事情，但是业务高上去的话，的确解决不了。自己后来也反省，并发这事情啊其实跟 IO 密不可分，比较好解决的一个就是用户态线程(erlang, golang)，二就是 IO 复用+非堵塞 IO+线程池即 one thread one loop + 线程池的架构。
无脑加线程的确可以解决一部分问题，但是假如业务是往上走的话，很快就会出问题的。因为单纯地加线程跟规模不是线性的关系。

升级了之后 3.6.1 之类的版本变了，导致 shell 无法从 PATH 里面找到 python3，你要不创建一个软连接，要不将现有的 python3 目录加到你的 PATH 变量中去。
至于你的 pycharm 里面环境无效了也是一样的道理，他们都是用的绝对路径，绝对路径指向的 python3 没有了，当然报错，你可以重新创建一个虚拟环境，或者用上面所述的创建软连接的方法替代

@rogerchen 你这样一说我倒是可以理解，不过这个始终不是长久之计，毕竟线程多了，上下文切换成本高，得不偿失。

@jokerlee 那两个模型理解啊，就是理解了我才觉得多线程没法很好地解决 IO 密集业务。linux 下线程上下文切换虽然成本低，但是多了也不少啊。
而且基本上所有 linux 的 IO 都能设置成非堵塞 IO，加上 IO 复用机制，这个不是将 CPU 更好地利用么？我是没法想象出一个不能用 IO 复用机制+非堵塞 I+线程池替代单纯多线程处理的场景。因此我才觉得这个场景比较奇怪，想问问当成为什么这样考量。

@sagaxu 为什么要开那么多线程呢？按照 nginx 的思路，要解决大并发以及 IO 密集型业务也不需要那么多的线程吧。过多线程之后徒增上下文切换的成本。毕竟 IO 又不占 CPU 时间片，用 IO 复用机制加非堵塞 IO 解决不好么？

@ittianyu 之前就有人做过测试，inner join 跟子查询的性能基本没有区别，在单机 mysql 的情况下更是如此。

@meik2333 你说的就是我说的，每个线程独自有一个 epoll 实例。你 master 里面的 epoll 监听的事件，是不会触发 worker 的 callback 的。意思就是这个意思。
这个我也是从陈硕的《 Linux 多线程服务端编程》里面看到的。加上自己看过一下 nginx 早期版本的代码。处理好网络 IO 剩下就是本地磁盘 IO 这些，这个 nginx 优化还真是厉害

@meik2333 nginx 我看了可是 One thread one loop。虽然都是 epoll，但是 worker 的 epoll 跟 master 的 epoll 不是一个实例

nginx 配置有问题，一般我都是直接 docker 启动

iPhone Xs Max 256G