@henglinli #7 我补充一点吧

go runtime，严格来讲就是以 golang 下 以 goroutine 结合管道通信的并发模型，这个并发模型是基于 stackfull 的协程模型，相反的是 stackless 的协程模型，而传统其它语言可能是基于线程池以及锁的并发模型 ，有兴趣可以看 stackfull 跟 stackless 的区别，前者会占用空间，后者对内存空间友好，但是现在是 2021 年了，谁家老板买不起 2T 内存？ golang 选的是 stackfull 协程模型，当然这里比较简单，下面会详细介绍，有兴趣深入还是根据我的关键字去找书看。

然后 stackfull 的本质就是 每个协程有自己的栈幁，具体我没有关注过 goroutine 的栈幁结构，但是从我观察 goroutine 进入内核态的汇编代码，做了一次 go 的调用约定 到 amd64 fastcall 的调用约定转换，基本上可以确认 golang 内部的函数调用约定以及栈幁结构 应该是平台无关化的，另外 golang 貌似是不支持二进制 lib 编译的，是不是因为内部大版本之间的 ABI 是否从来未稳定过。

然后弄这个 stackfull 的协程模型是因为 golang 这个语言的野心很大，它希望能把操作系统内核态任务调度这个事情全权交给应用态的 go 调度系统来作，而之前所有的语言 包括 C++ Java C 都是将调度模型交给操作系统提供的线程抽象，这一点上 golang 是一个伟大的进步 配合管道跟非阻塞式 IO 以及 epoll 调用，可以在用户态实现一个无锁且按需调度的调度系统，可以说 go 它是专门为后端服务设计的，当然从语法上来看，目前不支持泛型，我暂时没有加大对 go 这门语言的投入，但是它这个设计理念是好的，那就是带有运行时的语言应该从操作系统那里拿回原本属于我们应用开发人员的调度功能。

这里可以提出两点

1. 管道模型为什么优于锁 monitor ？ 传统操作系统内核提供的监视器锁 存在惊群的问题，这是很难避免的，因为操作系统并不知道你要唤醒多少个线程，当然你也可以指定唤醒的数量，这里就要做到很精细化的锁唤醒操作，例如 Java 里面的 blockingQueue 当队列满了的时候 操作的线程会去 唤醒因为读等待的线程而不是去唤醒因为写等待的线程，当队列空了的时候，当前操作线程就会去唤醒因为写等待的线程而不是去唤醒因为读等待的线程，而之前我所说的这些操作，都需要对并发编程有很高的理解，你才能设计出一个多线程并发且线程安全的队列，这一点对开发人员要求很高，而且从因为监视器锁 Java 的线程会频繁进入内核 开销很大。

但如果使用管道，其实从 golang 调度器来看，当你想从一个管道读数据而挂起的时候，其实 golang 调度器只要把当前线程的几个寄存器换掉就能把对 CPU 的控制权转移到另外一个协程上，这中间无需进入内核调度，而且 golang 还可以做一些优化，把对 CPU 的控制器优先配给需要写这个管道的协程，或者把对同一个管道读写的协程都分配到一个 CPU 上，这样一来 golang 使用管道可以实现完全无锁化的协程之间的通信，但是从编写 golang 的协程代码的人来看，他的大脑负担就会少很多。

@young1lin #2 差不多就这样了，所谓的 JVM 调优 也是很菜的，一般不去改算法，很难做到 低延时 高吞吐量..

背模板，背题解啊.. 你还想自己能原创出思路来？做梦吧

REMEMBER
YOU ONLY LIVE ONCE
YOU ONLY DIED ONCE

还是华尔街赌场的老哥们看得清，YOLO，YOU ONLY LIVE ONCE, buddy !!!!!!!!!!!

你只活一次，兄弟。

@janxin #39 对的，确实是要基础知识储备足够，然后解决方案跟思路 只是一个顺延展开基础理论知识的过程

@young1lin #32 ryzen 的服务器版本还没流行吧，怎么 NUMA 已经成为标配了.. 不过多个物理 CPU 的服务器 确实存在 NUMA 的问题..

@liuxu #27 有几个人会自己用 非阻塞式 IO 配合 epoll 关键字 自己手写多路复用，而且还要考虑写的 buffer 满了一大堆问题，另外用异步的更少见，有的异步甚至就是用线程池模拟出来的，一般默认 5 个线程就是 5 个阻塞式的 IO

@liuxu #22 另外 bbr 这种快启动也不是万能的，最好的办法还是根据包的大小来设置窗口跟窗口扩大缩小的策略，不过大部分场景 基本上都是小包..

唬得住要 50k 唬不住要 5k

@liuxu #23 5 个线程并发能打垮的系统，我还没见过 https://i.v2ex.co/504J5BO2.png .. 我的垃圾树莓派 pi 都能 web 读并发到 100 以上 https://i.v2ex.co/504J5BO2.png

@liuxu #23 https://i.v2ex.co/oJ951Htz.jpeg 关键人家只有 5 个线程，并发能力只有 5.. https://i.v2ex.co/504J5BO2.png

@liuxu #18 另外饿了么下订单这种主流程 只能做分表去提升并发写的能力，然后做冷热分离去提升读的能力，否则用户一看，订单没下成功，饿肚子了 分分钟就打开你对手美团的 APP 去下单了

@liuxu #18 如果我不削峰呢？我就要实时性，你这边 5 个线程，可能人家发送短信的 IO 可能根本都没打满，削峰只有 IO 被打满的情况下 不得已才考虑的一种情况，而且代码的主流程 是没法削峰的，发优惠券发金豆这种你削峰就削峰了，用户不会在意到账的及时性，像饿了么这种下订单的主流程，你怎么削峰？进消息队列？人家几秒钟的等待或者看到 提示错误就准备打开美团外卖了。

@qwer666df #15 要随时能扩充服务实例，首先还是要考虑 服务的无状态化，例如以前单机的 session 就不能用了，session 得存放到 redis 里面，不然你扩充的实例 不知道 session 在哪里，用 token 令牌的现在也只能存到 redis 里面去，所有的服务本身不保存任何状态，这样就可以平滑的加机器 减少机器的数量.. 当然这种集群扩充减少大多只能解决 CPU 密集型问题，对于瓶颈在数据库 IO 的问题 没法解决

@qwer666df 扩展集群实例很简单的，一开始考虑好怎么负载均衡 然后用 k8s 加实例就好了，现在基本上这些都是运维做的，但是程序员要考虑负载均衡的算法，避免单个实例负载很大的情况

@qwer666df #12 不可能单机的，单机 CPU 都打满了，你再怎么优化都没用，通常来讲，所有的服务都是无状态的，服务本身不存储任何状态，这样高峰的时候，我们可以通过扩展集群实例数量来提升吞吐量，但是大部分互联网的业务其实瓶颈都在数据库，所以一般都会采取 水平拆分的操作 来提升写的并发能力，因为写的话 会分片写入多个 MySQL 实例，此时单机写入的压力就会降低，总体的写入性能就会提升。