[独立开发] 单机 Rust 如何抗住 10w+ 在线行情推送?告别 Redis/Kafka,聊聊我的“极简主义”架构

1 月 22 日
 kai92zeng

大家好,我是《交易学徒》的独立开发者。

最近在重构后端行情网关,目标是支撑 10w+ 同时在线用户。在技术选型时,很多“标准答案”是微服务、Redis 集群、Kafka 消息队列。但作为独立开发者,维护这一套重型架构的运维成本和心智负担太高了。

于是我反其道而行之,选择了一种“极致单机”的方案:没有任何外挂组件( No Redis, No Kafka ),所有状态在进程内解决,纯 Rust 函数调用。

经过实战验证,这套架构不仅部署简单(就一个 Binary ),而且足够稳定。今天分享一下我是如何用 Rust 的特性“白嫖”性能的,欢迎 V 友们拍砖。

一、 核心理念:按需订阅,算一笔带宽的账 早期的 demo 喜欢大包大揽,客户端连上来就推 Top 20 币种。这在用户量大时是灾难。我的做法是“用户看哪里,就只推哪里”。

客户端停留在 BTC/USDT 的 15 分钟 K 线界面,服务端就只建立这一个订阅关系。一旦切换,立马移除旧订阅。

算一笔账( Resource Cost ): 假设一个行情包 Payload 是 200 Bytes ,推送频率 5 次/秒。

全量推送(推 Top 20 ):10 万用户 x 20 个币种 x 200B x 5 = 2 GB/s (带宽直接破产)。

按需订阅(推 1 个):10 万用户 x 1 个币种 x 200B x 5 = 100 MB/s 。

结论: 简单的逻辑改变,带宽节省 95%,单机千兆网卡轻松抗住。

二、 列表行情:Polling + 边缘计算(白嫖 CF ) 对于“行情列表”这种一屏显示几十个数据的页面,建立长连接维护成本太高。 我采用了 1 秒轮询 + Cloudflare 边缘缓存 的策略。

策略: 设置 HTTP 响应头,让 CF Edge Cache TTL = 1 秒。

效果:10 万人同时刷新列表,99% 的流量被 CF 的全球节点挡住了,真正打到我源服务器 Rust 进程的 QPS 只有个位数。

收益: 既利用了 CDN 的带宽,又保护了单机后端。

三、 架构做减法:进程内通信替代中间件 这是我这次重构最大的感悟:单机并发足够高时,不需要 Redis 和 Kafka 。

替代 Redis: 使用 Rust 的 DashMap (Concurrent HashMap)。数据就在内存里,读写是纳秒级,没有网络 IO 开销,没有序列化/反序列化成本。

替代 Kafka: 使用 tokio::sync::broadcast 和 mpsc::channel 。

优势: 传统的“发布-订阅”为了解耦上了 MQ ,但在单机 Rust 里,一个 Arc<Channel> 就能解决问题。部署时不需要操心 MQ 挂没挂,只要我的进程活着,消息系统就活着。

四、 信使模式 (Messenger Pattern) 与背压 在 Tokio 异步编程中,最忌讳 await 阻塞。 如果客户端网络卡顿(比如进电梯),socket.send().await 可能会阻塞,导致同个 Loop 下的心跳包处理被卡死,造成“假死”。

我的解法:

读写分离: 为每个连接 spawn 一个独立的 send_task ,通过 mpsc::channel(128) 通信。

严格背压 (Backpressure): 使用 try_send 。如果 Channel 满了(说明客户端来不及收),直接丢弃新行情。

理由: 实时行情旧数据无价值。这行代码是系统的“保命符”,防止慢客户端拖垮服务端内存( OOM )。

五、 极致性能:Zero-Copy (零拷贝) 在广播行情时,不要为 10 万个用户 copy 10 万份数据。

Rust // 内存中只有一份二进制 Payload let payload = Arc::new(Bytes::from(vec![...]));

// 10 万次分发只是增加了 10 万次引用计数( Reference Counting ) // 几乎没有任何内存分配开销 for client in clients { client.tx.try_send(payload.clone()); } 利用 Rust 的 Arc 和 Bytes ,让 CPU 缓存极其友好。 六、 扫地僧:资源清理 长运行的单机服务最怕内存泄漏。 当 socket 断开时,必须像外科手术一样精准清理:

从 DashMap 移除 Client 。

清理反向索引 subscriptions 。

如果某个 Topic 无人订阅,立即 drop 掉对应的 channel 发送端,停止上游数据生产。

总结 作为独立开发者,资源有限。这套“Rust 单机 + 无外挂组件”的架构,让我用最低的成本(一台服务器)抗住了业务压力,而且睡得很安稳。

Simplicity is the ultimate sophistication.

🎁 V 友专属福利 软件名字叫 《交易学徒》,是一个辅助交易员复盘、模拟、练盘感的工具。前端也是我用 Flutter 写的( Rust + Flutter 真是全栈开发的绝配)。

官网下载: https://www.zgjiazu.top

Google Play: https://play.google.com/store/apps/details?id=com.zengkai.jyxtclient

回帖福利: 在本帖回复并附上 App 内的 ID (在‘我的页面’可以看到),我后台人肉送一个月 VIP 会员。

同时也欢迎大家在评论区提 Bug ,或者交流关于 Rust 后端与 Flutter 前端开发的坑!

4818 次点击
所在节点    程序员
35 条回复
drymonfidelia
1 月 23 日
不写 rust ,不过 C#的 MemoryCache 和 R3 用起来也超爽
Sawyerhou
1 月 23 日
A 股的话各大主流 app 和券商 app 都带模拟盘功能,但没怎么炒过币,不清楚币圈对此的需求情况。
visper
1 月 23 日
大佬 rust 高级优化,极限压榨性能。
kai92zeng
1 月 23 日
@Charlie17Li 网上找的公司接的,实时毫秒级详情,如果不是照顾服务器,我可以做到每秒推 5 次以上的报价,如果这个品种一秒报价能够跳动五次的话。
kai92zeng
1 月 23 日
@KyleRicardo 官网是 AI 写的,改过几版,后期还会改,只不过现在没时间,一个人经历实在有限
kai92zeng
1 月 23 日
@gongxuanzhang 感谢支持!对于个人开发者而言,极简就意味着稳定,更多的时间应该用在打磨产品功能,软件最终会给用户带来怎样的蜕变,然后就是运营了。酒香也怕巷子深……
kai92zeng
1 月 23 日
@drymonfidelia 立项的时候我也考虑过 C#,在资源占用和执行效率上还是对我的资金有压力,JAVA 第一时间就被我抛弃了,最后选择了 rust 。
kai92zeng
1 月 23 日
@Sawyerhou 我会打造差异化软件,基本的模拟交易就不谈了,我要做的是让用户从交易技巧到交易心理分析两方面进行提高,同时对整个交易群体的不同级别交易员有清晰的认识,这需要足够的用户量,软件要暴露足够多的数据信息,交易只是最基本的数据来源。
kai92zeng
1 月 23 日
@visper 还可以继续压榨,方方面面,不过,先获取用户才是最重要的。
freemoon
1 月 23 日
如果要打造个人影响力,可以直接开源
drank20L
1 月 23 日
只有安卓版,Mac 和 iOS 什么时候上线
kai92zeng
1 月 23 日
@lasuar 等有饭吃了,我考虑将数据源开出去
kai92zeng
1 月 23 日
@drank20L 今天准备斥巨资购买二手 mac mini ,估计半个月内上架。
FH0
1 月 24 日
加油加油!我刚开始接触 Rust 的时候也有这样的代码洁癖,后来变成需求能稳定满足就行,不知道是好事还是坏事。尤其是现在,定个框架,让 AI 去做,自己只负责每个模块去验收。
suckinbottle
3 月 27 日
OP 求个行情数据接口供应商

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1187618

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX