[独立开发] 带娃写代码的觉悟:删掉 Redis 和 Kafka,我用“喊一嗓子”解决了高并发

查看 4|回复 0
作者:kai92zeng   
大家好,我是《交易学徒》的作者。
简单介绍下背景:我现在的核心身份是带两个孩子的全职奶爸,副业才是趁着孩子睡着后,在键盘上敲敲打打的独立开发者。
对于我这种“碎片化时间”开发者来说,运维复杂度就是最大的敌人。
几年前写后端,我也迷信“标准答案”:做个服务,起手就是 Docker 编排,Redis 做缓存,Kafka 做解耦,微服务先分几个出来。结果往往是,功能没写几个,光是调网络、修连接超时、查中间件报错,就把孩子午睡的那宝贵两小时耗光了(那时候还没孩子)。
在开发后端时,我陷入了深思:
“对于一个追求极致性能、但只有一个人维护的系统,所谓的‘工业级架构’真的是解药吗?还是毒药?”
最终,我做了一个违背祖宗的决定:做减法。 我删除了 Redis ,移除了 Kafka ,把整个微服务集群塌缩成了一个 Rust 单体应用。
今天想聊聊这背后的思考过程。
一、 复杂度的守恒与转移
我的业务场景看似简单,实则牵一发而动全身。一个简单的“用户平仓”动作,就像推倒了第一块多米诺骨牌:
核心域:结算盈亏,改余额,写数据库。(必须马上做)
通知域:给前端发个弹窗通知“平仓成功”。(晚 0.1 秒没关系)
营销域:判断有没有触发“五连胜”、“以小博大”成就,发奖励。(晚 1 秒没关系)
统计域:计算交易评分,统计分数或者更新等级与交易报表。(晚几秒都行)
在“标准架构”里,我们需要引入 消息队列 (MQ) 来解耦这些逻辑。 但引入 MQ 本质上并没有消除复杂度,只是将“代码复杂度”转移成了“运维复杂度”。
对于团队,运维复杂度可以分摊给同事;但对于我,这意味着我不仅要写代码,还得修服务器。
Rust 给了我另一个选择:利用它极高的性能,把“运维复杂度”重新压回“架构设计”里,用最朴素的方式解决问题。
二、 内存即总线:构建“喊一嗓子”的架构
我利用 Rust 的内存通道特性,构建了一个“超光速大喇叭”。 我不请求数据,我只发布事实。
这个过程,可以用一个生活化的场景来描述:
[ol]
  • 定义世界的真相 (The Truth)
    我不写复杂的 XML 或 JSON 定义,我只是在代码里列了一张“事实清单”:
    [/ol]
    📄 事实 A:有人平仓了(包含:是谁、赚了多少、单号是多少)
    📄 事实 B:有人购买商品了
    📄 事实 C:AI 分析完成了
    编译器会盯着这张清单,保证我发出的每一个“事实”都是格式正确、童叟无欺的。
    [ol]
  • 极简的生产者 (Fire and Forget)
    在核心交易逻辑里,当数据库事务提交成功后,我只需要做一件事:拿着大喇叭喊一嗓子。
    [/ol]
    传统架构 (Kafka) 是这样的:
    交易模块 -> 打包数据 -> 建立 TCP 连接 -> 三次握手 -> 发送给 Kafka 集群 -> 等待 ACK -> 结束 (这中间任何一步网络抖动,都得处理异常)
    我的单体架构是这样的:
    交易模块 -> 喊:“老王平仓赚了 100 块!” -> 结束 (纯内存操作,纳秒级完成,快到像是没有发生过)
    [ol]
  • 静默的消费者 (Sidequest Logic)
    我把原本分散在微服务里的逻辑,变成了几个坐在角落里的“隐形工人”。
    [/ol]
    比如 “营销服务”,它就像一个在角落里旁听的记分员:
    它平时不说话,只听大喇叭。
    一听到 “老王平仓赚了 100 块”,它立马翻开小本本查历史。
    发现老王已经连赢 4 把了,加上这把正好 5 把。
    于是它默默地给老王发了一个“五连绝世”的徽章。
    整个过程,核心交易模块完全不知情,也完全不用等待,它喊完那一嗓子就去服务下一个用户了。
    三、 深度思考:关于“不可靠”的权衡
    很多朋友可能会问:“没有 Kafka 把消息存到硬盘里,万一服务器断电了,你喊的那一嗓子不就丢了吗?”
    是的,这是整个架构思考中最痛苦,也是最关键的取舍。 我问了自己两个问题:
    Q1:我的程序崩溃概率有多大? Rust 以安全著称,只要代码写得不离谱,它极难崩溃( Panic )。这比 Java 的内存溢出或 Python 的运行时错误要稳健得多。
    Q2:丢失数据的代价是什么?
    我们可以把数据分成两类:
    💰 钱(核心数据): 余额、订单状态。
    处理方式: 必须落袋为安。 直接写死在数据库里,绝不依赖“大喇叭”。
    🎁 气氛(衍生数据): 弹窗通知、成就徽章、达标奖励、统计报表。
    处理方式: 听天由命。 如果真的赶上万年不遇的服务器着火,用户少收到了一个“五连胜”的弹窗,或者报表少统计了一笔,天会塌吗?不会。
    结论: 为了 0.001% 的极端掉电风险,去让 99.99% 的时间里的系统背负沉重的中间件包袱,对于独立开发者来说,这是一笔亏本买卖。
    四、 结语
    当我们谈论“高性能”时,往往想到的是复杂的集群、昂贵的服务器。 但 Simple is fast. (简单即快)
    现在的《交易学徒》后端,就是一个 20MB 的小文件。
    ❌ 没有 Docker 容器编排
    ❌ 没有 虚拟机调优
    ❌ 没有 Redis 维护
    ❌ 没有 服务间通讯
    ✅ 只有一个跑在单机上的进程,CPU 占用极低,响应速度极快。
    这省下来的不仅仅是每年的服务器费用,更是我作为父亲陪伴孩子的宝贵时间。
    技术服务于生活,这大概就是独立开发的魅力吧。
    关于《交易学徒》
    这是我用这套“极简架构”打磨的作品,前端是 Flutter ,后端 Rust 。 希望能给交易员朋友们提供一个干净、流畅、无延迟的练习环境。
    官网: https://www.zgjiazu.top
    Google Play: https://play.google.com/store/apps/details?id=com.zengkai.jyxtclient
    欢迎 V 友们指正。如果你的孩子也吵着要抱抱,那我们就是异父异母的亲兄弟了。😄
  • 您需要登录后才可以回帖 登录 | 立即注册

    返回顶部