近期将博客迁移至阿里云 Docker 环境后，网站出现流量激增与首页加载缓慢的问题。

经排查，瓶颈主要集中于图片资源与服务端缓存配置。通过一系列针对性优化，页面首次加载流量由 7 MB 显著优化至 500KB 左右，性能得到大幅提升。

本文结合 Linux 5.0.1 内核源码，浅析 Linux 进程管理中的完全公平调度器（CFS）工作原理。

最近接手的一个 Linux C++ 项目，编译速度把我折腾得怀疑人生。

—— 编译经过优化，源代码一行未改，全编译时间硬是从 半个小时 缩短到 3 分钟 ！！！（OMG，此处省略一万字…）

划重点，三板斧：

1. 多核并行编译： make -j N
2. 编译缓存工具： ccache
3. 分布式编译工具：distcc

谷歌验证码 采用基于共享密钥的动态验证机制。服务端与客户端使用相同的密钥，并据此分别生成匹配的动态验证码以完成校验。

尽管共享密钥本身并非绝对安全，但由于它仅在初次设置时低频次传输，且作为二次验证使用，因此仍能为核心账户安全提供一道坚实有效的屏障。

一致性哈希是后端系统中解决数据路由与负载均衡问题的关键技术。理解其工作原理，对于设计高扩展、高可用的分布式系统至关重要。本文将介绍其算法思想与经典应用场景。

最近阅读了 C++ 智能指针的部分实现源码，简单总结和记录一下 std::share_ptr/std::weak_ptr 内部结构和工作原理。

很多朋友以为 Redis 是单线程程序，事实上它是 多进程 + 多线程 混合并发模型，这样能利用多核优势，提高性能。

• 子进程持久化：重写 aof 文件 / 保存 rdb 文件。
• 多线程：主线程 + 后台线程 + 新增网络 IO 线程（Redis 6.0）。

通过 wireshark 抓取 HTTPS 包，理解 TLS 1.2 安全通信协议的握手流程。

重点理解几个点：

1. TLS 握手流程：通过 wireshark 抓取 HTTPS 包理解。
2. 协商加密：双方通过 ECDHE 椭圆曲线的密钥交换算法，协商出共享的 会话密钥 进行内容对称加密通信，避免传输会话密钥被中间人窃取。
3. CA 证书：证书用来验证服务端的合法性。证书类似于身份证，可以证明某人是某人，当然身份证可以伪造，一般人可能识别不出来，但是国家相关部门可以验证你的身份合法性。同理，服务端可以通过 CA 证书识别自身身份，客户端接收服务端发送的证书，并通过 证书链 验证该证书，以此确认服务端身份。

QT 的信号与槽技术，是一种用于对象间通信的机制。它允许一个对象发出一个信号，而其他对象可以通过连接到该信号的槽来接收并处理该信号。

本文将通过调试走读 QT (5.14.2) 信号与槽开源源码，理解它的工作原理。

C++ 有什么推荐的线程池库吗？…

最近翻阅侯捷先生的两本书：（翻译）《深度探索 C++ 对象模型》 和 《C++ 虚拟与多态》，获益良多。

要理解多态的工作原理，得理解这几个知识点的关系：虚函数、虚函数表、虚函数指针、以及对象的 内存布局。

• 深入探索 C++ 多态 ① - 虚函数调用链路
• 深入探索 C++ 多态 ② - 继承关系
• 深入探索 C++ 多态 ③ - 虚析构
• 深入探索 C++ 多态 ④ - 模板静态多态

std::sort 是标准库里比较经典的算法，它是一个复合排序，结合了几种算法的优点。

走读 Linux（5.0.1）源码，理解 TCP 网络数据接收和读取工作流程（NAPI）。

要搞清楚数据的接收和读取流程，需要梳理这几个角色之间的关系：网卡（本文：e1000），主存，CPU，网卡驱动，内核，应用程序。

本章整理了一下服务端 tcp 的第三次握手和 epoll 内核的等待唤醒工作流程。

惊群比较抽象，类似于抢红包 😁。它多出现在高性能的多进程/多线程服务中，例如：nginx。

探索惊群 系列文章将深入 Linux (5.0.1) 内核，透过 多进程模型 去剖析惊群现象、惊群原理、惊群的解决方案。

1. 探索惊群 ①（★）
2. 探索惊群 ② - accept
3. 探索惊群 ③ - nginx 惊群现象
4. 探索惊群 ④ - nginx - accept_mutex
5. 探索惊群 ⑤ - nginx - NGX_EXCLUSIVE_EVENT
6. 探索惊群 ⑥ - nginx - reuseport
7. 探索惊群 ⑦ - 文件描述符透传

走读网络协议栈 tcp 的内核源码（Linux - 5.0.1 下载）。通过 Linux 内核源码理解 tcp 三次握手状态变化。

因为我走读的是 Linux 5.0.1 源码，与旧版的 Linux 3.x 系列比较，新版的三次握手的状态已经发生改变，这个需要注意一下。

im - 即时通讯，支持功能：文字 + 音视频 + 文件传输。分布式服务架构，支持海量用户。

最近项目增加了一个模块，在 Centos 系统压测，进程一直不释放内存。因为新增代码量不多，经过排查，发现 stl + glibc 这个经典组合竟然有问题，见鬼了！

通过调试和查阅 glibc 源码，好不容易才搞明白它 “泄漏” 的原因：内存碎片！

碎片将大块的空闲连续内存块割裂，导致空闲内存块没有达到返还系统的阈值，内存回收失败！

深层原因：glibc 内部内存池管理空闲内存的策略问题，ptmalloc2 内存池的 fast bins 快速缓存和 top chunk 内存返还系统的特点导致。

co_kimserver 是笔者基于协程库 libco 开发的一个支持分布式微服务的高性能 TCP 网络通信框架。

详细请查看：github 。

协程“栈”空间，有独立栈和共享栈，重点理解一下协程共享栈。

火焰图是一种基于 SVG 格式的矢量图，由 Linux perf 性能分析工具采集的采样数据生成。它通过将软件在系统中的运行行为采样数据转化为图形化展示，为性能分析提供直观的可视化结果。

走读 Linux 内核源码（5.0.1），理解 epoll 的 lt / et 模式区别：

1. 两个模式，事件通知方式不同，lt 持续通知直到处理事件完毕，et 一般只通知一次，不管事件是否处理完毕。
2. et 模式，可以使得就绪队列上的新的就绪事件能被快速处理。
3. et 模式，可以避免共享 “epoll fd” 场景下，发生类似 惊群问题。

epoll 详细信息参考《[epoll 源码走读] epoll 实现原理》。

Nginx 内存池 (ngx_palloc.c) 专为优化小内存操作而设计。它通过将多次细碎的内存申请汇聚为少量批次请求，减少了与操作系统底层分配器的直接交互，以此提升整体性能。

该内存池作为一种轻量级实现，其小内存分配器采用了 下次适配 算法。该算法从上次成功分配的地址开始线性扫描，并选择第一个足够大的空闲内存块。这种策略旨在减少搜索开销，并利用缓存局部性原理。

即时通讯，消息有多种类型，单聊，群聊等等。

群组聊天消息管理比较麻烦，因为涉及到多个用户，尤其是千人群组，1 个人发送消息，999 个人接收，数据库针对每个用户存储一条记录吗？这个量级的数据存储是十分恐怖的，所以消息的存储策略显得十分重要。

客户端 <–> 文件服务器代理 <–> FDFS