Actor模型：从原理到实战，搞懂无锁高并发

_nemophlia

458人浏览 · 2026-03-19 18:00:19

_nemophlia · 2026-03-19 18:00:19 发布

1. 开篇：当锁成为噩梦

如果你写过多线程程序，下面这段代码一定让你似曾相识：

std::mutex mtx;
int shared_counter = 0;

void increment()
{
    std::lock_guard<std::mutex> lock(mtx);
    shared_counter++;
}

看似简单，但当系统规模增大，事情就开始失控了：

痛点一：锁的地狱。 一个mutex不够？那就两个。两个还不够？那就嵌套。嵌套之后呢？——恭喜，你得到了死锁（deadlock）。两个线程互相等对方释放锁，谁也不让谁，系统直接卡死。

痛点二：竞态条件（Race Condition）。 你忘了给某段代码加锁，或者锁的粒度不够细，两个线程同时读写同一块内存，结果就是数据错乱。更可怕的是，这类bug往往在测试环境跑不出来，上了生产环境才爆炸。

痛点三：性能瓶颈。 锁本质上是串行化——你用并发的语法写了串行的逻辑。热点锁（hot lock）会让几十个核心的机器退化成单核性能。

痛点四：心智负担极高。 每次写并发代码，你都需要在脑子里模拟所有线程的交错执行顺序，稍有不慎就是一个隐蔽的并发bug。代码review时也极难发现问题。

传统共享内存并发的本质是：多个人在同一张桌子上抢着写字，靠互相喊"等一下"来协调。 人少还行，人一多就全乱了。

那有没有一种方式，从根本上消灭共享内存、消灭锁，让并发变得可预测？

答案就是——Actor模型。

Actor模型的核心思想可以用一句话概括：

不要通过共享内存来通信，而要通过通信来共享数据。

这不是什么新概念。1973年，Carl Hewitt就提出了Actor模型。后来Erlang把它用到了电信系统中（爱立信的AXD301交换机，号称99.9999999%可用性——9个9）。如今，Akka（JVM）、Microsoft Orleans（.NET）、Ray（Python）等框架都在用Actor模型驱动大规模分布式系统。

那它到底是什么？往下看。

2. Actor模型的核心原理

2.1 一个类比：Actor就是一个"收快递的人"

想象一下你运营一个公司，每个员工都有：

自己的工位和文件柜（私有状态，别人不能直接翻）
自己的做事方式（行为逻辑）
门口的收件箱（邮箱/Mailbox，消息都放这里，一封一封处理）

员工之间不能走到对方工位上直接改文件，只能发内部邮件。收到邮件后，员工按顺序处理，处理完可以：

回复邮件（发消息给其他Actor）
雇一个新员工（创建新Actor）
更新自己文件柜的内容（修改自身状态）

这就是Actor模型。没有抢桌子，没有喊"等一下"，大家各干各的，靠发邮件协调。

2.2 Actor的三要素

要素	说明	类比
State（状态）	Actor内部的私有数据，只有自己能读写，对外完全封装	员工文件柜里的资料
Behavior（行为）	Actor收到消息后如何处理的逻辑，可以根据当前状态动态切换	员工的岗位职责/工作流程
Mailbox（邮箱）	一个消息队列，接收来自其他Actor的消息，保证FIFO顺序	门口的收件箱，先到先处理

2.3 Actor的三大基本行为

当一个Actor收到一条消息时，它只能做以下三件事（可以同时做）：

① Send —— 发送消息给其他Actor

Actor通过目标Actor的地址（ActorRef）发送消息，这个过程是异步的——发完就走，不等回复。这就像发快递，你把包裹交给快递员就完事了，不需要站在门口等对方签收。

② Create —— 创建新的Actor

Actor可以动态地创建子Actor，形成层级结构（Actor Hierarchy）。父Actor可以监督子Actor的生命周期。这一机制在Erlang/Akka中被称为Supervision Tree（监督树），是Actor模型容错的基石。

③ Become —— 修改自身行为

Actor可以指定下一条消息到来时应该用什么行为来处理。这让Actor天然支持**有限状态机（FSM）**模式。比如一个订单Actor：收到"支付"消息后，行为从"待支付"切换到"已支付"，后续消息就会用新逻辑处理。

2.4 核心原则

无共享内存（Share Nothing）：每个Actor的状态完全私有，不存在任何共享变量。因此，不需要任何锁。
消息传递是异步的：发送者不会阻塞等待接收者处理。
单个Actor内消息处理是顺序的：Mailbox保证FIFO，一个Actor同一时刻只处理一条消息。这意味着Actor内部天然是线程安全的。
Actor是最小的并发单元：不是线程，不是协程，是Actor。你可以有百万个Actor运行在几十个线程上。

一句话总结：Actor = 私有状态 + 消息驱动 + 异步通信。锁的问题不是"解决了"，而是"不存在了"。

3. Actor vs 传统并发：一张表看清差异

对比维度	传统共享内存模型	Actor模型
通信方式	读写共享变量	异步消息传递
同步机制	锁（mutex/semaphore/rwlock）	不需要锁
状态可见性	所有线程可见共享状态	状态完全私有，对外封装
并发单元	线程/协程	Actor（比线程轻量得多）
数量级	通常数百到数千线程	可达数百万Actor
死锁风险	高（嵌套锁、锁序不一致）	极低（没有锁就没有死锁）
调试难度	极高（非确定性执行）	较低（消息流可追踪）
容错性	需要手动处理（try-catch）	天然支持监督树（let-it-crash）
适合场景	计算密集型、低延迟	IO密集型、高并发、分布式
代表技术	pthreads, std::thread, OpenMP	Erlang/OTP, Akka, Ray, Orleans
心智模型	“多人抢一支笔写字”	“每人一支笔，写好传纸条”

关键洞察：Actor模型并不是要取代所有并发方式，它是在特定场景下用架构手段消除并发复杂性。当你的系统是"大量独立实体互相通信"（如用户会话、游戏角色、IoT设备）时，Actor模型如鱼得水。

4. Actor工作流程详解

4.1 文字描述

一条消息从发送到处理的完整生命周期：

Step 1: Actor A 构造一条消息（Message），指定目标地址（Actor B 的 ActorRef）
Step 2: 消息被投递到 Actor B 的 Mailbox（消息队列）尾部
Step 3: Actor A 继续执行自己的逻辑（异步，不阻塞等待）
Step 4: Actor B 的调度器检测到 Mailbox 中有待处理消息
Step 5: 调度器将 Actor B 分配到一个工作线程上
Step 6: Actor B 从 Mailbox 头部取出一条消息
Step 7: Actor B 根据当前 Behavior 处理该消息
Step 8: 处理过程中，Actor B 可能：
        - 修改自身 State
        - 发送消息给其他 Actor（回到 Step 1）
        - 创建新的子 Actor
        - 通过 Become 切换自身行为
Step 9: 处理完毕，Actor B 回到空闲状态，等待下一条消息

4.2 伪代码表示

class Actor:
    state: PrivateState
    mailbox: Queue<Message>
    behavior: Function(Message) -> void

    method receive(msg):
        mailbox.enqueue(msg)

    method run():               // 由调度器调用
        while mailbox.not_empty():
            msg = mailbox.dequeue()
            behavior(msg)       // 处理消息，可能修改 state、send、create、become

class ActorSystem:
    actors: Map<ActorRef, Actor>
    thread_pool: ThreadPool(N)  // N个工作线程

    method send(target: ActorRef, msg: Message):
        actor = actors[target]
        actor.receive(msg)
        thread_pool.schedule(actor.run)  // 调度执行

    method create_actor(behavior) -> ActorRef:
        actor = Actor(behavior)
        ref = generate_unique_ref()
        actors[ref] = actor
        return ref

4.3 流程图描述

发送者 Actor A                   接收者 Actor B
    |                                |
    |--- send(msg, B_ref) ---------->|
    |   (异步，不阻塞)                 |
    |                          [msg 入 Mailbox 队列]
    |                                |
    |                          [调度器分配线程]
    |                                |
    |                          [从 Mailbox 取出 msg]
    |                                |
    |                          [执行 behavior(msg)]
    |                                |
    |                          [可能: 修改 state]
    |                          [可能: send 新消息]
    |                          [可能: 创建子 Actor]
    |                          [可能: become 新行为]
    |                                |
    |                          [处理完毕，等待下一条]

重要细节：一个Actor同一时刻只在一个线程上运行，但不同时间可以被调度到不同线程。这就是为什么Actor内部不需要锁——不存在两个线程同时操作同一个Actor的情况。

5. 实战代码：用C++手写一个Actor框架

运行环境：C++17 标准，Linux/macOS

编译命令：g++ -std=c++17 -pthread actor_demo.cpp -o actor_demo

依赖：仅标准库，无第三方依赖

下面我们从零实现一个可运行的微型Actor框架，包含完整的Actor定义、消息传递、状态修改和调度。

// actor_demo.cpp
// 一个简约但完整的 Actor 模型演示
// 编译: g++ -std=c++17 -pthread actor_demo.cpp -o actor_demo

#include <iostream>
#include <queue>
#include <mutex>
#include <condition_variable>
#include <thread>
#include <functional>
#include <memory>
#include <unordered_map>
#include <any>
#include <string>
#include <vector>
#include <atomic>
#include <sstream>
#include <chrono>

// ============================================================
// 第一部分：基础设施 —— 消息与 ActorRef
// ============================================================

// 消息：用 std::any 包装，支持任意类型
struct Message {
    std::string type;    // 消息类型标签（用于分发）
    std::any    payload; // 消息载荷（任意类型）
};

// Actor 的唯一标识
using ActorRef = std::string;

// ============================================================
// 第二部分：Actor 基类
// ============================================================

// 前向声明
class ActorSystem;

class Actor {
public:
    explicit Actor(ActorRef self_ref, ActorSystem* system)
        : self_ref_(std::move(self_ref)), system_(system), running_(true) {}

    virtual ~Actor() = default;

    // 外部调用：将消息投递到 Mailbox
    void enqueue(Message msg) {
        {
            std::lock_guard<std::mutex> lock(mailbox_mtx_);
            mailbox_.push(std::move(msg));
        }
        mailbox_cv_.notify_one();
    }

    // Actor 的主循环：由调度线程驱动
    void run() {
        while (running_) {
            Message msg;
            {
                std::unique_lock<std::mutex> lock(mailbox_mtx_);
                mailbox_cv_.wait(lock, [this] {
                    return !mailbox_.empty() || !running_;
                });
                if (!running_ && mailbox_.empty()) break;
                msg = std::move(mailbox_.front());
                mailbox_.pop();
            }
            // 在单线程中顺序处理消息 —— 无需锁保护 state
            on_receive(msg);
        }
    }

    // 停止 Actor
    void stop() {
        running_ = false;
        mailbox_cv_.notify_one();
    }

    ActorRef self() const { return self_ref_; }

protected:
    // 子类实现：定义收到消息后的行为
    virtual void on_receive(const Message& msg) = 0;

    // 向其他 Actor 发送消息（异步）
    void send(const ActorRef& target, Message msg);

    // 创建子 Actor（委托给 ActorSystem）
    template<typename T, typename... Args>
    ActorRef create_child(const std::string& name, Args&&... args);

    ActorRef    self_ref_;
    ActorSystem* system_;

private:
    std::queue<Message>     mailbox_;       // Mailbox: 消息队列
    std::mutex              mailbox_mtx_;   // Mailbox 的锁
                                            // （注意：这个锁保护的是 Mailbox 的入队操作，
    std::condition_variable mailbox_cv_;    //  不是 Actor 的 State！State 无需锁。）
    std::atomic<bool>       running_;
};

// ============================================================
// 第三部分：ActorSystem —— Actor 的管理与调度
// ============================================================

class ActorSystem {
public:
    explicit ActorSystem(const std::string& name) : name_(name) {
        std::cout << "[ActorSystem '" << name_ << "'] 启动\n";
    }

    ~ActorSystem() {
        shutdown();
    }

    // 创建一个顶层 Actor 并启动其调度线程
    template<typename T, typename... Args>
    ActorRef create_actor(const std::string& name, Args&&... args) {
        ActorRef ref = name_ + "/" + name;
        auto actor = std::make_shared<T>(ref, this, std::forward<Args>(args)...);
        {
            std::lock_guard<std::mutex> lock(registry_mtx_);
            actors_[ref] = actor;
        }
        // 每个 Actor 拥有一个独立的调度线程
        // （生产级框架会用线程池 + work-stealing，这里为了清晰用 1:1 映射）
        threads_.emplace_back([actor]() {
            actor->run();
        });
        std::cout << "[ActorSystem] 创建 Actor: " << ref << "\n";
        return ref;
    }

    // 发送消息给指定 Actor
    void send(const ActorRef& target, Message msg) {
        std::shared_ptr<Actor> actor;
        {
            std::lock_guard<std::mutex> lock(registry_mtx_);
            auto it = actors_.find(target);
            if (it == actors_.end()) {
                std::cerr << "[ActorSystem] 目标 Actor 不存在: " << target << "\n";
                return;
            }
            actor = it->second;
        }
        actor->enqueue(std::move(msg));
    }

    // 关闭系统：停止所有 Actor，等待线程结束
    void shutdown() {
        std::cout << "[ActorSystem '" << name_ << "'] 关闭中...\n";
        {
            std::lock_guard<std::mutex> lock(registry_mtx_);
            for (auto& [ref, actor] : actors_) {
                actor->stop();
            }
        }
        for (auto& t : threads_) {
            if (t.joinable()) t.join();
        }
        threads_.clear();
        actors_.clear();
        std::cout << "[ActorSystem '" << name_ << "'] 已关闭\n";
    }

private:
    std::string name_;
    std::unordered_map<ActorRef, std::shared_ptr<Actor>> actors_;
    std::mutex registry_mtx_;
    std::vector<std::thread> threads_;
};

// Actor 基类方法的实现（需要 ActorSystem 的完整定义）
void Actor::send(const ActorRef& target, Message msg) {
    system_->send(target, std::move(msg));
}

template<typename T, typename... Args>
ActorRef Actor::create_child(const std::string& name, Args&&... args) {
    return system_->create_actor<T>(self_ref_ + "/" + name,
                                     std::forward<Args>(args)...);
}

// ============================================================
// 第四部分：具体 Actor 实现 —— 银行账户示例
// ============================================================

// 场景：两个账户之间互相转账，展示无锁状态修改

class BankAccountActor : public Actor {
public:
    BankAccountActor(ActorRef ref, ActorSystem* sys, double initial_balance)
        : Actor(std::move(ref), sys), balance_(initial_balance) {}

protected:
    void on_receive(const Message& msg) override {
        // ----- 处理 "deposit" 消息 -----
        if (msg.type == "deposit") {
            double amount = std::any_cast<double>(msg.payload);
            balance_ += amount;      // 直接修改状态，无需锁！
            std::ostringstream oss;
            oss << "[" << self_ref_ << "] 收到存款 " << amount
                << "，余额: " << balance_;
            std::cout << oss.str() << "\n";
        }
        // ----- 处理 "withdraw" 消息 -----
        else if (msg.type == "withdraw") {
            double amount = std::any_cast<double>(msg.payload);
            if (balance_ >= amount) {
                balance_ -= amount;  // 直接修改状态，无需锁！
                std::ostringstream oss;
                oss << "[" << self_ref_ << "] 取款 " << amount
                    << "，余额: " << balance_;
                std::cout << oss.str() << "\n";
            } else {
                std::ostringstream oss;
                oss << "[" << self_ref_ << "] 取款失败，余额不足。余额: "
                    << balance_ << "，请求: " << amount;
                std::cout << oss.str() << "\n";
            }
        }
        // ----- 处理 "transfer" 消息 -----
        else if (msg.type == "transfer") {
            // payload 是 pair<ActorRef, double>
            auto [target, amount] =
                std::any_cast<std::pair<ActorRef, double>>(msg.payload);
            if (balance_ >= amount) {
                balance_ -= amount;
                // 给目标账户发存款消息
                send(target, Message{"deposit", amount});
                std::ostringstream oss;
                oss << "[" << self_ref_ << "] 转账 " << amount
                    << " -> " << target << "，余额: " << balance_;
                std::cout << oss.str() << "\n";
            } else {
                std::ostringstream oss;
                oss << "[" << self_ref_ << "] 转账失败，余额不足。";
                std::cout << oss.str() << "\n";
            }
        }
        // ----- 处理 "query" 消息 -----
        else if (msg.type == "query") {
            std::ostringstream oss;
            oss << "[" << self_ref_ << "] 当前余额: " << balance_;
            std::cout << oss.str() << "\n";
        }
    }

private:
    double balance_;   // 私有状态：账户余额
};

// ============================================================
// 第五部分：演示 Become 行为切换 —— 简易开关 Actor
// ============================================================

class SwitchActor : public Actor {
public:
    SwitchActor(ActorRef ref, ActorSystem* sys)
        : Actor(std::move(ref), sys), state_("OFF") {}

protected:
    void on_receive(const Message& msg) override {
        if (msg.type == "toggle") {
            // Become: 根据当前状态切换行为
            if (state_ == "OFF") {
                state_ = "ON";
                std::cout << "[" << self_ref_ << "] 状态切换: OFF -> ON\n";
                // 在真实框架中，这里可以替换整个 on_receive 函数指针
                // 实现完全不同的消息处理逻辑
            } else {
                state_ = "OFF";
                std::cout << "[" << self_ref_ << "] 状态切换: ON -> OFF\n";
            }
        }
        else if (msg.type == "status") {
            std::cout << "[" << self_ref_ << "] 当前状态: " << state_ << "\n";
        }
    }

private:
    std::string state_;  // 私有状态
};

// ============================================================
// 第六部分：主函数 —— 启动系统、发送消息、观察行为
// ============================================================

int main() {
    std::cout << "========== Actor 模型演示 ==========\n\n";

    // 1. 创建 Actor 系统
    ActorSystem system("MyBank");

    // 2. 创建两个银行账户 Actor
    auto alice = system.create_actor<BankAccountActor>("alice", 1000.0);
    auto bob   = system.create_actor<BankAccountActor>("bob",   500.0);

    // 3. 创建一个开关 Actor（演示 Become）
    auto light = system.create_actor<SwitchActor>("light");

    // 等待 Actor 线程启动
    std::this_thread::sleep_for(std::chrono::milliseconds(100));

    std::cout << "\n--- 开始发送消息 ---\n\n";

    // 4. 向 Alice 存款
    system.send(alice, Message{"deposit", 200.0});

    // 5. Alice 向 Bob 转账 300
    system.send(alice, Message{"transfer",
        std::make_pair(bob, 300.0)});

    // 6. Bob 取款 100
    system.send(bob, Message{"withdraw", 100.0});

    // 7. 查询两人余额
    system.send(alice, Message{"query", 0});
    system.send(bob,   Message{"query", 0});

    // 8. 演示 Become：切换开关
    system.send(light, Message{"status", 0});
    system.send(light, Message{"toggle", 0});
    system.send(light, Message{"status", 0});
    system.send(light, Message{"toggle", 0});
    system.send(light, Message{"status", 0});

    // 等待所有消息处理完毕
    std::this_thread::sleep_for(std::chrono::milliseconds(500));

    // 9. 关闭系统
    system.shutdown();

    std::cout << "\n========== 演示结束 ==========\n";
    return 0;
}

代码关键点解读

① Mailbox 的锁 ≠ State 的锁

你可能注意到 mailbox_mtx_ 这个互斥锁。这不矛盾——这把锁保护的是 Mailbox 队列的入队操作（因为多个 Actor 可能同时往一个 Mailbox 投递消息），而不是 Actor 的 State。Actor 的 balance_ 变量在 on_receive 中直接读写，完全不需要锁，因为 on_receive 在单线程中顺序执行。

② 消息类型用 std::any

生产环境中建议用 std::variant 或自定义消息基类来获得类型安全。这里用 std::any 是为了简洁。

③ 线程模型

这里用了 1:1 模型（每个 Actor 一个线程），这在 Actor 数量少时完全可行。生产级框架会使用 M:N 调度（M个Actor映射到N个线程），通常用线程池 + work-stealing 实现。

期望输出

========== Actor 模型演示 ==========

[ActorSystem 'MyBank'] 启动
[ActorSystem] 创建 Actor: MyBank/alice
[ActorSystem] 创建 Actor: MyBank/bob
[ActorSystem] 创建 Actor: MyBank/light

--- 开始发送消息 ---

[MyBank/alice] 收到存款 200，余额: 1200
[MyBank/alice] 转账 300 -> MyBank/bob，余额: 900
[MyBank/bob] 收到存款 300，余额: 800
[MyBank/bob] 取款 100，余额: 700
[MyBank/alice] 当前余额: 900
[MyBank/bob] 当前余额: 700
[MyBank/light] 当前状态: OFF
[MyBank/light] 状态切换: OFF -> ON
[MyBank/light] 当前状态: ON
[MyBank/light] 状态切换: ON -> OFF
[MyBank/light] 当前状态: OFF

[ActorSystem 'MyBank'] 关闭中...
[ActorSystem 'MyBank'] 已关闭

========== 演示结束 ==========

提示：由于异步特性，实际运行时消息处理的打印顺序可能略有不同——这恰恰体现了 Actor 模型的异步本质。但单个 Actor 内的消息顺序一定是 FIFO 的。

6. 适用场景与不适用场景

✅ Actor 模型的甜蜜区

场景	为什么适合	例子
高并发网络服务	每个连接/会话是一个Actor，天然隔离	IM聊天、WebSocket服务
游戏服务器	每个玩家/NPC/房间是一个Actor，状态独立	MMO服务端、棋牌游戏
分布式系统	Actor可以跨节点透明通信	微服务编排、集群调度
IoT设备管理	每个设备映射一个Actor（Digital Twin）	智能家居、车联网
流式数据处理	Actor组成DAG流水线，逐条处理	日志处理、实时ETL
有限状态机	Become机制天然适配状态转换	订单流程、审批流
容错系统	监督树 + let-it-crash策略	电信、金融交易网关

❌ Actor 模型不太擅长的场景

场景	为什么不太适合	更好的选择
极低延迟计算（纳秒级）	消息传递有序列化/反序列化开销，Mailbox入队出队有延迟	无锁数据结构、共享内存 + CAS（乐观锁）
强事务操作	跨多个Actor的原子性操作很难保证（没有内置的分布式事务）	数据库事务、2PC/Saga模式
大矩阵/科学计算	计算密集型任务不需要"通信"，而是需要数据并行	OpenMP、CUDA、MPI
简单的短生命周期任务	创建Actor的开销不值得，用线程池+任务队列更简单	std::async、线程池
强一致性读写	Actor模型天然是最终一致的，强一致需要额外协议	Raft/Paxos、锁

原则：当你的系统可以被建模为**"大量独立实体通过消息交互"时，用Actor；当你的核心瓶颈是纯计算或强事务**时，用别的。

7. 踩坑实录：真实开发中的血泪教训

🕳️ 踩坑案例一：Actor内做阻塞IO导致消息堆积

场景：某个游戏服务器，每个玩家是一个Actor。其中有一个Actor负责存档（Save），当玩家下线时发送"save"消息，这个Actor收到后直接调用 write_to_database()——这是一个同步阻塞操作。

后果：数据库偶尔慢查询（50ms → 2s），期间该Actor的Mailbox堆积了数百条消息。其他Actor发给它的消息全部排队，导致其他玩家的存档请求延迟飙升，系统级联雪崩。

根因：Actor的on_receive方法中做了阻塞操作。Actor模型的核心假设是消息处理是快速的。一旦某个Actor被阻塞，它的Mailbox就会变成一个不断增长的定时炸弹。

解决方案：

将阻塞IO委托给专门的异步Actor或线程池：Save Actor收到消息后，将IO任务提交给后台线程池，自己立即返回。IO完成后通过回调消息通知。
Mailbox设置背压（Backpressure）：当Mailbox超过阈值时，拒绝或丢弃低优先级消息。
超时+重试：给数据库操作设置超时，避免无限阻塞。

// 错误做法
void on_receive(msg):
    if msg.type == "save":
        database.write_sync(msg.data)  // ❌ 阻塞了Actor！

// 正确做法
void on_receive(msg):
    if msg.type == "save":
        async_pool.submit([data = msg.data, self_ref = self()] {
            database.write_sync(data)
            system.send(self_ref, Message{"save_done", ...})  // 完成后通知
        })

🕳️ 踩坑案例二：分布式Actor通信的"消息丢失"之谜

场景：一个基于Akka Cluster的分布式系统，两个节点上的Actor互相通信。开发阶段测试正常，上线后偶发"消息凭空消失"——Node A发了消息，Node B的Actor就是没收到。

后果：订单状态不一致，用户支付后系统显示"未支付"，引发客诉。

根因：Actor模型默认提供的是at-most-once语义——消息最多送达一次，不保证一定送达。在分布式环境下，网络分区、节点宕机、消息超时都可能导致消息丢失。很多开发者误以为"发出去了就一定收得到"。

解决方案：

使用可靠投递（at-least-once）：Akka提供 AtLeastOnceDelivery trait，通过重试+确认机制保证消息至少送达一次。
消息幂等设计：因为at-least-once可能导致重复消息，接收方必须做幂等处理（如根据消息ID去重）。
关键路径持久化：使用Event Sourcing将消息/事件持久化到日志中，即使Actor崩溃也能恢复。

教训：在分布式环境中使用Actor模型，必须明确你的消息投递语义，并在架构层面补偿可靠性。

8. 常见误区与避坑指南

误区一：Actor就是线程

真相：Actor ≠ 线程。Actor是逻辑上的并发单元，可以有百万个；线程是操作系统的资源，通常只有几百到几千个。生产级Actor框架使用M:N调度——将大量Actor复用在少量线程上。

避坑：不要为每个Actor创建一个线程（我们示例代码中的1:1模型仅用于教学），而应使用线程池调度。

误区二：消息一定会送达

真相：在单机环境下，消息投递通常是可靠的（除非系统崩溃）。但在分布式环境下，默认是at-most-once，消息可能丢失。即使是单机，如果Actor崩溃，Mailbox中未处理的消息也会丢失。

避坑：对于关键业务消息，使用持久化Mailbox + at-least-once投递 + 幂等接收。

误区三：Actor越多性能越好

真相：Actor数量增加会带来调度开销（上下文切换、Mailbox管理、内存占用）。盲目拆分只会增加消息传递的开销，不会提升性能。

避坑：Actor的划分应该基于业务边界（一个用户一个Actor、一个设备一个Actor），而不是"越细越好"。用性能测试来指导拆分粒度。

误区四：Actor模型不需要考虑并发问题

真相：Actor内部确实没有并发问题，但多个Actor之间的交互仍然需要设计。比如：消息顺序（跨Actor不保证顺序）、分布式事务（跨Actor原子性）、背压（Mailbox溢出）、活锁（两个Actor互相等对方回复）等。

避坑：Actor模型消除了低层级的并发问题（数据竞争、死锁），但高层级的并发设计（一致性、容错、流量控制）仍然需要你认真思考。

误区五：Actor模型可以替代所有并发方案

真相：Actor模型是一种并发范式，不是银弹。对于计算密集型任务、极低延迟场景、强事务场景，共享内存模型或其他方案可能更合适。

避坑：先理解业务特征，再选择并发模型。Actor适合"大量独立实体+异步通信"的场景，不适合"少量共享数据+高频同步"的场景。

9. 进阶话题：分布式Actor与容错

9.1 监督树（Supervision Tree）

Erlang/OTP提出了一个革命性的理念——let it crash（让它崩）。

传统思路是：出了错就catch住，写一大堆防御性代码。 Actor的思路是：出了错就让这个Actor死掉，由它的父Actor（Supervisor） 来决定怎么处理。

Supervisor的策略通常有：

重启（Restart）：干掉故障Actor，用初始状态重新创建
停止（Stop）：彻底停掉这个Actor
升级（Escalate）：自己也处理不了，往上抛给自己的Supervisor
恢复（Resume）：忽略错误，继续运行

这种层级式的容错机制，使得系统具备了自愈能力。

9.2 Location Transparency（位置透明）

在成熟的Actor框架中，发送消息时不需要关心目标Actor在哪台机器上。ActorRef 可以指向本地Actor，也可以指向远程节点上的Actor。框架底层自动处理序列化和网络传输。

这意味着：你可以先在单机上开发，然后几乎不改代码就扩展到集群。

9.3 Event Sourcing + Actor

将Actor接收到的每条消息（事件）持久化存储。当Actor崩溃或节点重启时，通过重放事件来恢复状态。这就是Event Sourcing模式，与Actor模型天然契合。

Akka Persistence、Microsoft Orleans的Grain Storage都是这种思路。

10. 结语与学习路径

核心价值回顾

Actor模型的本质是一种架构级别的并发抽象：

用消息传递取代共享内存，从根本上消除数据竞争
用Mailbox实现异步解耦，让系统具备弹性
用监督树实现自动容错，让系统具备自愈能力
用位置透明实现分布式扩展，让系统具备伸缩性

它不是银弹，但在正确的场景下，它能让你的并发代码从噩梦变成工程。

11. 参考资料

Carl Hewitt, Peter Bishop, Richard Steiger. A Universal Modular ACTOR Formalism for Artificial Intelligence. IJCAI, 1973.
Gul Agha. Actors: A Model of Concurrent Computation in Distributed Systems. MIT Press, 1986.
Joe Armstrong. Making reliable distributed systems in the presence of software errors. PhD Thesis, KTH, 2003.
CAF — C++ Actor Framework: https://www.actor-framework.org/
Akka (现 Apache Pekko): https://akka.io/ / https://pekko.apache.org/
Erlang/OTP: https://www.erlang.org/
Microsoft Orleans: https://learn.microsoft.com/en-us/dotnet/orleans/
Ray: https://www.ray.io/
Hewitt, Meijer, Szyperski 访谈: https://www.youtube.com/watch?v=7erJ1DV_Tlo

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

人员异常行为检测YOLO格式检测数据集

AtomGit开源社区

如果 HTML 成为大模型标准输出格式，训练体系需要怎么变？

摘要随着AI代理系统越来越多地采用HTML作为标准输出格式，大模型训练体系面临根本性变革。评估指标需新增渲染正确性、视觉质量等维度；训练数据需从互联网低质量HTML转向语义化、响应式的高质量代码；对齐方法需升级标注员能力并开发AI评估工具；Tokenizer需优化HTML编码效率；模型架构可能演进为专用HTML生成器或多模态闭环系统。这一转变将重塑从数据准备到模型评估的整个训练流程，并可能最终影

AtomGit开源社区

AI Native 应用的 UI 层该怎么设计？从 AG-UI 到 Agent 直出 HTML 的思考

AI Native 应用的 UI 层设计正处于一个关键的分叉点。AG-UI 和 A2UI 代表的结构化协议路线提供了安全性、一致性和跨平台能力，Agent 直出 HTML 路线提供了灵活性和无限表达力。三者并非对立，而是服务于不同场景的互补方案。未来最可能的演进方向是分层融合：固定框架提供稳定性，结构化协议（AG-UI/A2UI）处理标准交互和跨平台需求，沙箱 HTML 释放 Agent 的全部表

AtomGit开源社区

所有评论(0)

查看更多评论

_nemophlia

@cookies_s_

已为社区贡献5条内容

Actor模型：从原理到实战，搞懂无锁高并发

_nemophlia

目录

1. 开篇：当锁成为噩梦

2. Actor模型的核心原理

2.1 一个类比：Actor就是一个"收快递的人"

2.2 Actor的三要素

2.3 Actor的三大基本行为

2.4 核心原则

3. Actor vs 传统并发：一张表看清差异

4. Actor工作流程详解

4.1 文字描述

4.2 伪代码表示

4.3 流程图描述

5. 实战代码：用C++手写一个Actor框架

代码关键点解读

期望输出

6. 适用场景与不适用场景

✅ Actor 模型的甜蜜区

❌ Actor 模型不太擅长的场景

7. 踩坑实录：真实开发中的血泪教训

🕳️ 踩坑案例一：Actor内做阻塞IO导致消息堆积

🕳️ 踩坑案例二：分布式Actor通信的"消息丢失"之谜

8. 常见误区与避坑指南

误区一：Actor就是线程

误区二：消息一定会送达

误区三：Actor越多性能越好

误区四：Actor模型不需要考虑并发问题

误区五：Actor模型可以替代所有并发方案

9. 进阶话题：分布式Actor与容错

9.1 监督树（Supervision Tree）

9.2 Location Transparency（位置透明）

9.3 Event Sourcing + Actor

10. 结语与学习路径

核心价值回顾

推荐学习路径

11. 参考资料

所有评论(0)

_nemophlia

Actor模型：从原理到实战，搞懂无锁高并发

_nemophlia

目录

1. 开篇：当锁成为噩梦

2. Actor模型的核心原理

2.1 一个类比：Actor就是一个"收快递的人"

2.2 Actor的三要素

2.3 Actor的三大基本行为

2.4 核心原则

3. Actor vs 传统并发：一张表看清差异

4. Actor工作流程详解

4.1 文字描述

4.2 伪代码表示

4.3 流程图描述

5. 实战代码：用C++手写一个Actor框架

代码关键点解读

期望输出

6. 适用场景与不适用场景

✅ Actor 模型的甜蜜区

❌ Actor 模型不太擅长的场景

7. 踩坑实录：真实开发中的血泪教训

🕳️ 踩坑案例一：Actor内做阻塞IO导致消息堆积

🕳️ 踩坑案例二：分布式Actor通信的"消息丢失"之谜

8. 常见误区与避坑指南

误区一：Actor就是线程

误区二：消息一定会送达

误区三：Actor越多性能越好

误区四：Actor模型不需要考虑并发问题

误区五：Actor模型可以替代所有并发方案

9. 进阶话题：分布式Actor与容错

9.1 监督树（Supervision Tree）

9.2 Location Transparency（位置透明）

9.3 Event Sourcing + Actor

10. 结语与学习路径

核心价值回顾

推荐学习路径

11. 参考资料

所有评论(0)

温馨提示：您尚未绑定手机号

_nemophlia