在分布式系统中，让多个节点对一组操作达成一致（Consensus）是难题。Diego Ongaro 在 2014 年的博士论文《Consensus: Bridging Theory and Practice》中提出 Raft 算法，专门为了可理解性而设计。相比 Paxos 的晦涩，Raft 用工程化的方式描述了 leader 选举、日志复制等机制。本文从原理到 etcd 的实现，逐步拆解 Raft。

为什么需要一致性协议

分布式 KV 存储（如 etcd、Consul）需要在多副本之间复制写操作：

• 单 leader 强一致性：写必须等大多数副本确认，延迟高但强一致
• 多 leader 最终一致性：写入本地即返回，后台异步复制，吞吐高但不保证顺序
• 无 leader：Dynamo 风格 quorum 读写

Raft 是单 leader 强一致性算法的代表，目标是让 3/5 个副本的集群能容忍 1/2 个节点故障。

Raft 三种角色

stateDiagram-v2
    [*] --> Follower

    Follower --> Candidate: 超时无心跳<br/>开始选举
    Candidate --> Leader: 获得多数票
    Candidate --> Follower: 发现更高 term
    Leader --> Follower: 发现更高 term

    Follower --> Follower: 收到合法心跳
    Leader --> Follower: 主动 step down

每个节点在任意时刻处于三种状态之一

1. iOS 中使用 Protocol Buffers

2. Laravel 模型事件实现原理

3. Install PEAR and PECL on Mac OS X

4. GNU Linux和Unix Darwin BSD等

5. 编译器的工作过程

1. 聊聊加密那点事——PHP加密最佳实践

2. etcd：从应用场景到实现原理的全方位解读

3. 大家的公司 Code Review 都是怎么做的？

4. gRPC 和 restful 转换

5. protobuffer、gRPC、Restful 相互转换

6. PHP 7.2 使用 openssl 扩展实现 des 加解密

Laravel 自带错误和异常处理，App\Exceptions\Handler 负责上报异常和如何返回内容，以及未登录的处理。

Paul Graham 的《黑客与画家：来自计算机时代的高见》（Hackers and Painters: Big Ideas from the Computer Age）是我读过的最具「叛逆气质」的计算机类书之一。

它不是一本讲编程的书，也不是讲创业的书——它是一本讲**“黑客的思维方式”**的书。Paul Graham 把他对编程、设计、财富、不平等、教育的所有思考写成 15 篇短文。每一篇都在挑战一个主流观点。

Go 的并发口号"通过通信来共享内存"（Don’t communicate by sharing memory; share memory by communicating）依赖的核心原语就是 channel。理解 channel 的内部实现，对于写出不泄漏、不死锁的并发程序至关重要。本文从数据结构入手，逐步剖析 channel 的工作机制。

channel 的三种类型

ch1 := make(chan int)        // 无缓冲
ch2 := make(chan int, 10)    // 有缓冲，容量 10
ch3 := make(chan<- int)    // 只读（单向 channel）
ch4 := make(<-chan int)     // 只读

无缓冲 channel 同步通信、有缓冲 channel 异步通信——这是面试常考的点。

hchan 数据结构

Go 源码 src/runtime/chan.go 中：

type hchan struct {
    qcount   uint          // 当前队列中元素数量
    dataqsiz uint          // 环形队列容量
    buf      unsafe.Pointer // 环形队列指针
    elemsize uint16        // 元素大小
    closed   uint32        // 是否关闭
    elemtype *_type        // 元素类型
    sendx    uint          // 发送索引
    recvx    uint          // 接收索引
    recvq    waitq         // 接收等待队列（sudog 列表）
    sendq    waitq         // 发送等待队列
    lock     mutex         // 互斥锁
}

type waitq struct {
    first *sudog
    last  *sudog
}

graph TB
    subgraph hchan
        Q[qcount]
        D[dataqsiz]
        B[buf 环形队列]
        S[sendx]
        R[recvx]
        SQ[sendq]
        RQ[recvq]
        LK[lock]
    end

    SQ --> SUD1[sudog goroutine A]
    SQ --> SUD2[sudog goroutine B]
    RQ --> SUD3[sudog goroutine C]

环形缓冲

有缓冲 channel 的底层是固定大小的环形数组：

1. Windows Subsystem for Linux 之体验

2. 探索 Laravel 里的加解密实现

3. 用 JSON 构建 API 的标准指南

4. Redis Pipeline 原理分析

5. Laravel 队列监控面板 – Horizon

HTTP/2（RFC 7540，2015 年发布）解决了 HTTP/1.1 时代前端工程师无数痛点：多路复用替代串行请求、头部压缩、服务器推送。本文从二进制帧入手，逐步拆解 HTTP/2 的核心机制，并分析它的局限——TCP 层的 Head-of-Line 阻塞问题。

HTTP/1.1 的痛点

HTTP/1.1 默认每个连接只能处理一个请求-响应。这种串行模型导致：

• 浏览器只能并发开 6 个 TCP 连接（Chrome 默认），每个连接还得排队
• 想绕开必须用域名分片、雪碧图、CSS 合并、JS 合并
• 头部每次都重复传输（特别是 cookie），浪费带宽
• 没法主动推送资源，得等客户端解析 HTML 后再请求

HTTP/2 的设计目标正是消除这些工程上的丑陋 hack。

二进制分帧层

HTTP/2 最大的变化是引入了二进制分帧层（Binary Framing Layer），所有信息都用 Frame 传输：

graph LR
    subgraph Frame
        L[Length: 24 bits]
        T[Type: 8 bits]
        F[Flags: 8 bits]
        S[Stream ID: 31 bits]
        P[Payload: 可变长]
    end

    L --> T --> F --> S --> P

关键的 10 种帧：

1. PHP : 令人困惑的 strtotime

2. 彻底弄懂 Laravel 中间件原理

3. Redis 事务与 Redis Lua 脚本

4. 如何开发、本地测试、发布 Laravel 扩展包

5. 数据库设计中的流程思路

6. Laravel DB::table() 源码分析

Redis 的 list 数据结构常用来做消息队列，通常使用的命令有 lpop/rpop ，还有带阻塞版的 blpop/brpop 等。blpop 的优点是避免一直轮询占用资源，而且支持多个列表作为参数并按照顺序弹出数据，如 blpop high low 30，可以更方便实现队列的优先级。

Laravel 的中间件机制提供了一种管道的方式，每个 HTTP 请求经过一个又一个中间件进行过滤，Laravel 内置了很多中间件，比如 CSRF 机制，身份认证，Cookie 加密，设置 Cookie 等等。

1. GoLang: When to use string pointers

2. PHP 7.3 中的 JSON 错误处理

3. 如何设计、开发和部署微服务（Nginx 官方文章翻译）

4. 理解 Laravel 中的 pipeline (①) ②

5. Redis 哈希对象编码方式

6. 哈希表原理介绍

1. 初探 Go 的编译命令执行过程

2. 高效的数据压缩编码方式——Protobuf

3. 浅谈消息队列及常见的消息中间件

4. 深入理解 PHP 的输出缓冲区

5. 异步、并发、协程原理

6. Golang版protobuf的安装与使用

7. Protocol Buffer 语法详解

8. Golang context 初探

Linux 下 IO 处理方式的选择直接决定了网络服务的并发能力。从早期的 accept + recv 阻塞循环，到 select、poll，再到 epoll/kqueue，再到 Node.js / Redis / Nginx / Netty 共同采用的 Reactor 模式——这是一条清晰的能力升级路线。本文逐层拆解。

一个具体场景

服务端伪代码：

fd = listen()
while True:
    client = accept(fd)         # 阻塞 1：等待连接
    while True:
            req = recv(client)   # 阻塞 2：等待数据
            resp = handle(req)
            send(client, resp)  # 阻塞 3：等待发送完成

每个连接都阻塞在某个操作上，要支持 1 万并发就要 1 万个线程。这就是 C10K 问题的根源。

五种 IO 模型

POSIX 标准定义了五种 IO 模型，对比维度是等待数据 vs 等待内核。

graph TB
    subgraph "blocking IO"
    A1[recv 调用] --> A2[数据未到达]
    A2 --> A3[阻塞等待]
    A3 --> A4[数据到达 + 内核拷贝]
    A4 --> A5[用户进程处理]
    end

    subgraph "non-blocking IO"
    B1[recv 调用] --> B2[数据未到达]
    B2 --> B3[立即返回 EAGAIN]
    B3 --> B4[轮询]
    B4 --> B5[数据到达 + 内核拷贝]
    B5 --> B6[用户进程处理]
    end

    subgraph "IO multiplexing"
    C1[select/epoll] --> C2[阻塞等待任意 fd 可读]
    C2 --> C3{指定 fd 准备就绪}
    C3 -->|是| C4[recv 调用]
    C4 --> C5[数据到达 + 内核拷贝]
    C5 --> C6[用户进程处理]
    end

    subgraph "signal-driven IO"
    D1[sigaction 注册 SIGIO] --> D2[继续做其他事]
    D2 --> D3[内核数据到达发出信号]
    D3 --> D4[recv 阻塞等待内核拷贝]
    D4 --> D5[用户进程处理]
    end

    subgraph "async IO"
    E1[aio_read] --> E2[立即返回]
    E2 --> E3[进程继续运行]
    E3 --> E4[内核完成后发信号]
    E4 --> E5[用户进程处理已就绪数据]
    end

关键区分点：同步 vs 异步。判断标准是"真正的 I/O 拷贝阶段是否由内核完成并通知我们"。

1. 深入浅出 TCP/IP 协议栈

2. 中国工业 4.0 之路

3. MySQL 查询缓存机制

4. MySQL 体系结构

5. Swoole 和 Swoft 的那些事

6. WebP 相对于 PNG、JPG 有什么优势？