9.6 KiB
加餐2 ｜答疑精选：这些问题你都清楚吗？
你好，我是陶辉。今天是期中周的第2篇加餐，按照约定，这节课我从1～15课的留言区精选出了15个问题，这里一部分是与内容强相关的，还有一部分是属于拓展型的问题，选择标准就是是否存在增量信息以及问题价值，希望你能从别人的疑问中进行一次自检，引发更多的思考。
第1课
鲤鲤鱼：我们集群有一个问题，某一台物理机的CPU会被Hadoop yarn的查询任务打满，并且占用最多的pid在不停的变化，我查看了TIME_WAIT的个数好像也不是很多，在顶峰的时候还没达到一万，能够持续一两个小时。这个问题您有没有什么思路呢？
作者：解决性能问题，一般有两种方法：经验派和“理论”派。前者就是基于自己的经验概率，将能想到的优化方法都试一遍，这种方式通常又有效又快速，但无法解决复杂的问题。而所谓理论派，就是沿着固定的思路，使用二分法，从高至低慢慢下沉到细节。
具体到你的问题，我建议你先看看，CPU占用的是用户态还是系统态，用户态的话就要分析代码了，系统态还要进一步分析。火焰图通常是个很好的办法，虽然搭能画火焰图的环境很麻烦，但这种底层方法很有效（第19课会具体讲到火焰图的用法）。
第2课
alan：老师好，这节课真好，第一次了解到内存池也是有层次的。我遇到一个问题想请教一下：我有一个和数据库交互的Groovy程序，运行起来后会占用很大内存，启动时，将Xmx设置为多少，该程序的内存占用就不会超过Xmx指定的上限。比如，Xmx=10g，程序就稳定占10g内存，但如果不限制的话，最高见过占用30G左右。这个您觉得有什么可能的原因吗？
作者：每种Java虚拟机都有自己独特的垃圾回收机制，有时为了时间更快就会牺牲更多的内存空间，这是正常的。我建议在服务器上长时间运行的Java进程，一定要通过Xmx去明确内存占用，否则内存不可控会很麻烦。
第3课
杨文宇：链表的内存地址不连续是如何影响序列化的？老师能具体说一下吗？
作者：当数组外还有链表中的元素时，序列化就必须遍历所有元素，比如，至少要做1次循环，把每1个遍历到的元素的值，序列化写入至另一段内存中。而使用闭散列时，可以直接将这个数组占用的内存作为序列化后的数据来直接落地或使用。
第4课
helloworld：“第二，读取磁盘数据时，需要先找到数据所在的位置，对于机械磁盘来说，就是旋转磁头到数据所在的扇区，再开始顺序读取数据。其中，旋转磁头耗时很长，为了降低它的影响，PageCache 使用了预读功能。”那是不是使用SSD这类固态硬盘（不用旋转磁头），PageCache就没有很大的影响？
作者：对的！其实，当下的操作系统对SSD磁盘的支持还不够，当SSD广泛应用时，文件系统还需要跟上，得获得很大的性能提升才可以。
第5课
Robust：“然而，共享地址空间虽然可以方便地共享对象，但这也导致一个问题，那就是任何一个线程出错时，进程中的所有线程会跟着一起崩溃。”这里的出错应该表示一些特殊的错误吧，或者是说和共享内存有关的错误，比如申请不到内存等。老师，我理解得没错吧？
作者：这里指无法恢复的错误，不仅是内存申请错误，比如访问已经释放的资源，且没有捕获异常或者无法捕获异常，进而操作系统只能杀死线程时，进程里的其它线程也会被杀死。
第6课
范闲：用户态的协程不能用互斥或者自旋，会进入内核态与其设计初衷相悖，Python里面用的yield。
作者：是的，用户态协程需要用户态的代码将锁重新实现一遍，其中实现时不能用到内核提供的系统调用。
第7课
重返归途：广播功能属于双工吗？当多个客户机向主机响应时，会有性能瓶颈吗？
作者：广播不是双工，因为广播是由网络设备实现的，所以服务器无法感知到每个客户端的响应，因此客户端对服务器的响应，与本次广播消息链路无关，它必须是另一个通道。
第8课
龙龙：“因此，哪怕有 1 千万并发连接，也能保证 1 万 RPS 的处理能力，这就是 epoll 能在 C10M 下实现高吞吐量的原因。”老师，这段话我不太理解，1千万的并发连接，只有1万的RPS这能算高吞吐量吗？相当于每秒只有1000个人中的1个人得到响应。还是我理解错了，您表述的是另一层意思？
作者：这里有2层意思，都是服务于epoll的设计思想这一个目的。
- 这段话的上下文，是指单次获取网络事件时，你可以理解为调用epoll_wait系统调用，它的速度与并发连接总数无关，相对于之前的select/poll系统调用（它们都与并发连接总数相关），因此epoll_wait速度很快，这是实现高吞吐量的关键。
- 有些应用会长时间保持TCP长连接，但并没有消息通讯（比如GPS等IoT设备与服务器之间的通讯），此时1千万并发连接下，如果能够维持1万RPS，这也是只有epoll才能做到的，poll/select是不可能做到的。
第9课
Geek_007：看评论区，很多同学都说是长连接，普通的HTTP keep-alive会不会有坑，三大运营商或者中间网络设备都会将超过一定时间的链接drop掉。如果没有H2这种ping保活的机制，有可能客户端长链接莫名其妙的就被drop掉，客户端只能依赖超时来感知异常，反倒是影响性能了。
作者：是的，不只网络设备，一些代理服务器为了减轻自己的负担，也会把长连接断掉，比如Nginx默认关闭75秒没有数据交互的keep-alive长连接。
第10课
安排：TTL每一跳减少1，这些怎么和MSL对应起来呢？每一跳减少的1相当于1秒？
作者：不是，这是一个预估值，所谓每一跳，是指每经过一个路由器网络设备，将IP头部中的TTL字段减少1，并不等于1秒，通常推荐的TTL的初始值是64。
第11课
Trident：带宽时延积如何衡量呢？网络时延不是固定的，是要多次取样计算平均网络时延，然后估算出这个时延积吗？
作者：是的，需要多次取样做估算，再乘以带宽，得到带宽时延积。
第12课
妥协：为什么报文5之后的ack都是ack6呀？
作者：TCP是有序的字符流，因此接收方收完报文5后，只能接收报文6，但现在却接收到了报文7、8、9、10，此时接收方该怎么办呢？
当然，它可以当做不知道，什么也不做，坐等报文6的到来。报文6什么时候会到呢？RTO时间超时后，发送方会重发报文6，因为发送方一直没收到ACK7！但是，RTO是很长的时间，接收方直接反复地传递ACK6，这样发送方就能明白，报文6丢了，它可以提前重发报文6。这叫做快速重传！
第13课
有铭：“寻找宕机服务时，只要看队列首部最老的心跳包，距现在是否超过 5 秒，如果超过 5 秒就认定宕机。”这里的逻辑无法理解。如果要用这种方式检测心跳，那么肯定要不停地把队列首部的心跳包移除，让新的心跳包从尾部加入，那么如果这个加入的过程卡一点，岂不是就会误判？
作者：这种设计下，还必须限制每次移除心跳包的数量（分多次执行），以防止加入过程长时间得不到执行。而且，在这种极限场景下，必须监控CPU的使用率，如果长期维持在高占用率（可能你的集群规模已经超大，要每秒处理数百万心跳包），那么应当通过扩容更多的CPU核、分布式系统等其它方案来解决，这已经不是单台机器能解决的了。
第14课
东郭：请问老师，我在Nginx配置中，不管ssl_certificate和ssl_certificate_key是否配置ecc证书，抓包查看服务器的server hello响应中的Cipher Suite字段都是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，这是正常的吗？
作者：这是正常的，TLS握手阶段Nginx的Cipher Suite，要通过ssl_ciphers指令来配合支持的suites，并可通过ssl_prefer_server_ciphers指定优先选用的算法。证书只是包含了密钥、身份等信息，它们与密钥协商方式、对称加密算法并无关系。
第15课
Geek_007：FB也搞了一套压缩算法ZSTD，对比起来也比gzip性能强很多，不清楚这些压缩算法的原理是啥？怎么对比？另外普通的JSON和PB有不同适合的压缩算法吗？怎么比较呢？
作者：
-
压缩算法的原理都是基于香农的信息论，将高频出现的信息用更少的比特编码。虽然原理是一致的，但实现上却有很大的差别，比如Huffman通过建立Huffman树来生成编码，而LZ77却是通过滑动窗口，这就造成了压缩比、压缩速度都很不相同。
-
比较它们的优劣，主要看3个指标：
- 压缩比，比如Brotli的压缩比好于ZSTD；
- 压缩与解压的速度，比如ZSTD比gzip速度快；
- 浏览器等中间件的支持程度，现在几乎所有浏览器都支持Brotli（即br），但ZSTD少有支持。
- 普通的JSON和PB没有最适合的算法，还是要针对具体场景，比较方法参见我刚刚说的那3个指标。
今天的答疑精选就到这里，期待大家能一如既往的在留言区进行交流，如果有更多问题，也欢迎一并提出。