youyichannel

在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：

• 半连接队列，SYN Queue
• 全连接队列，Accept Queue

在 MQ 中，「消息不丢」和「消息不重」一直都是一对孪生兄弟。消息不重复也是非常重要的，例如在金融场景，发送了一条给同一个账户扣减余额的消息，如果这条消息被重复消费了，多次扣除，这是无法容忍的。

一般性的思路是：只保证消息只发送一次不就好了嘛，也就是保证生产者对同一条消息仅发送一次给 Broker，然后消费者从 Broker 自然只能获取到一次消息，那么自然就能够保证消息不会重复。但是这种方案从目前 MQ 的实现来看是无法实现的，消息一定会出现重复的情况！下面就来分析下。

在我们日常业务使用 MQ 时，如何保证消息不丢失失一个特别需要关注的点。在某些业务场景下消息的丢失造成的影响可能不大，比如购物车，下单后删除购物车对应商品的消息丢失了还可以容忍，但是在金融场景下，消息丢失了往往代表着资产的损失，这是无法容忍的。

当然，即使在丢失影响不大的场景下，我们也要尽可能的保证消息不丢失，不然业务流程就会不完整。

综述，用到了 MQ，保证消息不丢失就很关键。那么如何保证呢？我们需要分析下 MQ 的整个链路。

文件的读写方式有很多，对于文件 I/O 的分类也有很多，常见的分类：

• 缓冲和非缓冲 I/O
• 直接和非直接 I/O
• 阻塞和非阻塞 I/O
• 同步和异步 I/O

HTTPS 可不是 HTTP 的复数形式哈🤣，HTTPS 是在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，那有了什么提升呢？

斐波那契作为动态规划入门题，大家肯定都会写，毕竟题目都把递推公式给出了，直接一个循环就结束了。

贴下题目链接：LCR 126. 斐波那契数

但是直接使用循环，时间复杂度是 O(N) 的，在数据量很大的情况下，也是会超时的。那能不能用 O(logN) 的做法来完成呢？可以！具体怎么做，接着看吧。

问题：如何改进 LRU 算法？

传统 LRU 算法存在的问题：

• 「预读失效」导致缓存命中率下降
• 「缓存污染」导致缓存命中率下降

那么 MySQL 和 Linux 是通过改进 LRU 算法来避免这两个问题导致的缓存命中率下降的。

Redis 是通过实现 LFU 算法来避免因为「缓存污染」导致的缓存命中率下降问题的。

进程状态

PS：挂起是指进程没有占用实际的物理内存空间的情况。

导致进程挂起的原因：

• 进程使用的内存空间不在物理内存
• 通过 sleep 让进程间歇性挂起
• 用户希望挂起一个程序的执行，比如 Linux 中使用 Ctrl+Z 挂起进程