akka.net 是基于 actor 模型的并发与分布式开发工具包，核心是封装状态、行为和邮箱的轻量级 actor，通过消息驱动、隔离性和监督策略替代锁与共享内存。
什么是 Akka.NET？它不是 C# 原生框架，而是 JVM 上 Akka 的 .NET 移植
Akka.NET 是一个基于 Actor 模型的并发与分布式应用开发工具包，不是 Microsoft 官方库，也不依赖 .NET Core / .NET 5+ 特有机制（比如 System.Threading.Channels 或 Task 调度器），而是自己实现了一套轻量级 Actor 运行时。它最核心的抽象是 Actor —— 一个封装了状态、行为和邮箱（mailbox）的独立计算单元。
它的设计目标很明确：用“消息驱动 + 隔离性 + 监督策略”替代传统锁 + 共享内存的高并发编程方式。这意味着你不需要手动加 lock、不会遇到 NullReferenceException 因为状态被其他线程改掉、也不会因线程池耗尽而卡死整个服务。
Akka.NET 的 Actor 如何实际处理高并发？关键在“不共享、只发消息”
每个 Actor 实例在同一时刻只被一个线程执行（单线程语义），但整个系统可以有成千上万个 Actor 并发运行。真正的并发能力来自：消息批量入队 + 异步调度 + 无锁设计，而不是让一个 Actor 同时响应多个请求。
-
Actor不暴露任何 public 字段或可变属性，所有交互必须通过Tell()（异步发送）或Ask()（带超时的异步请求） - 消息进入
Mailbox后由Dispatcher分配线程执行，底层默认使用ThreadPool，但你可以配置为专用线程、同步上下文，甚至绑定到EventLoop - 没有阻塞调用：你不该在
OnReceive里写Thread.Sleep()或同步 I/O（如File.ReadAllText()），否则会卡住整个 Dispatcher - Actor 之间不共享内存，所以不用
volatile、Interlocked或ConcurrentDictionary来保护状态 —— 状态只在本 Actor 内部可变
public class CounterActor : ReceiveActor
{
private int _count = 0;
<pre class='brush:php;toolbar:false;'>public CounterActor()
{
Receive<Increment>(_ => _count++);
Receive<GetCount>(_ => Sender.Tell(new CountResult(_count)));
}}
上面这个 CounterActor 可以安全地被 10,000 个客户端同时 Tell()，因为每次消息都是排队、串行处理，_count 不会被并发修改。
常见踩坑点：你以为在并发，其实被 Dispatcher 卡住了
很多人以为只要起了很多 Actor 就自动高并发，结果压测时吞吐上不去，CPU 却不高 —— 很可能是因为所有 Actor 共享了一个慢速 Dispatcher，或者用了错误的 Mailbox 类型。
- 默认
Dispatcher是ThreadPoolDispatcher，但如果配置了太小的线程数（如throughput = 1），会导致消息积压 - 不要在
Receive中调用async/await后直接写后续逻辑（即不 await 返回 Task），Akka.NET 不会自动恢复上下文；要用ReceiveAsync<t></t>或显式ContinueWith - 避免在 Actor 中 new 大对象或做长耗时计算（如 JSON 序列化大集合），这会让 mailbox 积压，影响其他 Actor 响应延迟
- 远程 Actor（
akka.remote）或集群场景下，网络分区、序列化失败（如类型未标记[Serializable]或没注册JsonSerializer）会导致消息静默丢失，需配合AtLeastOnceDelivery或自定义重试
和 .NET 原生方案比，什么情况下该选 Akka.NET？
它不是银弹。如果你只是需要“多线程处理 HTTP 请求”，用 ASP.NET Core + IHostedService + ChannelReader 更轻量；但当你需要：
- 长时间运行、有内部状态的服务（如游戏房间管理、IoT 设备会话代理）
- 容错要求高（Actor 可配置
OneForOneStrategy，子 Actor 崩溃不影响父级） - 未来要横向扩展到多节点（Akka.Cluster 支持自动分片、位置透明）
- 业务逻辑天然适合“事件流”建模（如订单状态机、风控规则链）
那 Akka.NET 的抽象就比手写 ConcurrentQueue + Timer + CancellationToken 清晰得多。但它引入了新概念（supervisor、mailbox、dispatchers）、调试门槛更高（不能直接断点进某个 Actor 的某次接收），而且序列化、配置、测试都要额外适配。
真正难的不是启动一堆 Actor，而是设计好它们之间的消息协议、生命周期和错误传播路径 —— 这部分没标准答案，得靠对业务状态流转的理解。
