数据在系统里跑来跑去，像不像一群流浪的旅人？有的住进数据库，有的搭上服务快车，有的组队完成工作流，还有的被塞进邮筒寄往四面八方。今天我们就当一回数据导游，看看它们都在玩什么花样。
数据库：写给过去和未来的信
还记得《解忧杂货店》吗？浪矢爷爷的杂货店有一个神奇的卷帘门——你把烦恼写成信投进去，第二天就能从牛奶箱里收到回信。这简直就是我们每天都在用的数据库：你把数据写进去，就像把信投进了卷帘门，未来的你（新版本的代码）会从牛奶箱里取出信来读。这就是向后兼容（Backward Compatibility）——新代码能读懂旧数据。
但故事里还有更绝的：未来的回信也能被过去的人收到。这不就是向前兼容（Forward Compatibility） 吗？旧代码得能看懂新数据。数据库里的数据可能比代码活得久，五年前的老数据还在磁盘里“沉睡”，而你的代码早已升级换代。如果旧代码想读新数据，就得像过去的人看懂未来的信一样，靠模式演化（Schema Evolution） 来帮忙——比如加个字段时设个默认值，就像在信封上多贴一张便利贴，老收件人也能明白：“哦，这是新添的备注。”
《解忧杂货店》里浪矢爷爷说：“人的心声是绝对不能无视的。”数据的心声也一样。当你修改模式时，就像给数据写了一封新信，但旧信还得留着，因为有人（旧代码）可能还会读。所以数据库得学会“时空穿梭”——既向前兼容，又向后兼容，比浪矢杂货店还厉害。
服务：点外卖还是打电话？
服务之间的沟通有两种主流方式：REST 和 RPC。
REST 像点外卖——你打开 App，浏览菜单，选中“宫保鸡丁”（资源），下单，然后坐等骑手送达。一切通过 HTTP 的 GET、POST 搞定，简单明了，适合公开 API。
RPC 像打电话——你拨通号码，直接对电话那头说“炒个宫保鸡丁”，假装对方就在你身边。这就是远程过程调用（Remote Procedure Call, RPC） 的抽象：让网络调用看起来像本地函数调用。但打电话有风险：你可能听不清（网络延迟），对方可能挂了（服务宕机），甚至你喊了两遍“炒菜”，结果对方炒了两份（重复执行）。这就是 RPC 的坑——它假装网络不存在，但网络是真实存在的，而且脾气古怪。
于是我们发明了幂等性（Idempotence）：保证即使你说两遍“炒菜”，也只会出一份菜。这就像外卖 App 的“防重复下单”机制，确保你不会收到两份宫保鸡丁。
为了应对网络的不确定性，我们还有负载均衡器（Load Balancer）、服务发现（Service Discovery），甚至服务网格（Service Mesh）。负载均衡像外卖调度中心，把订单分给空闲的骑手；服务发现像骑手实时位置跟踪，告诉你哪个骑手离你最近；服务网格则像给每个骑手配个对讲机，专门处理路况和沟通问题。
工作流：一场精心策划的退货行动
工作流就像策划一场行动，需要多个角色协同。比如电商退货流程：用户申请退货 → 审核 → 退款 → 重新入库。这四个步骤涉及订单系统、审批系统、支付系统、仓储系统。如果退款成功但入库失败，用户就既收到了钱又没退回商品，这不行！
graph LR
A[用户申请退货] --> B{审核是否通过}
B -- 不通过 --> C[流程结束]
B -- 通过 --> D[退款]
D --> E[重新入库]
E --> F[流程结束]
传统数据库事务管不了跨服务的事，于是我们需要工作流引擎（Workflow Engine），比如 Airflow 或 Temporal。它就像行动的总指挥，记录每一步的进展。如果某个步骤失败（比如仓储系统宕机），总指挥会暂停行动，等系统恢复后从断点继续，而不会重新退款。这就是持久化执行（Durable Execution）。
持久化执行的核心是恰好一次语义（Exactly-Once Semantics）：每个任务只执行一次，即使中间失败重试，也不会重复。这就像退货行动里，退款只能退一次，不能因为仓储系统抽风就退两次款。
但这里有个硬要求：确定性（Deterministic）。总指挥必须能准确重演每一步，不能有随机数、系统时间这些“即兴发挥”的东西。否则重演时会跑偏，就像行动队员突然改台词，整个计划就乱套了。所以工作流代码要像剧本一样，每句台词都固定，不能加戏。
事件驱动：数字邮政
最后登场的是事件驱动架构（Event-Driven Architecture, EDA）。这里的数据不直接找人，而是扔给一个中间人——消息代理（Message Broker），比如 Kafka 或 RabbitMQ。这就像你寄信：把信投进邮筒，剩下的交给邮政网络——分拣、运输、投递，最终送到收件人手中。你完全不需要知道信是怎么运输的，也不需要亲自送过去——异步、解耦、爽快。
邮政网络（消息代理）有两种常见模式：队列（Queue） 和 主题（Topic）。
- 队列 像挂号信：一封信只能寄给一个人，收件人凭通知领取。在系统里，这适合任务分发，比如处理订单——每个订单只需要一个处理者。
- 主题 像报纸订阅：报社出版报纸，邮局把报纸投递给所有订阅者，每个订阅者都能收到同一份报纸。在系统里，这适合广播通知，比如系统升级公告——所有服务都得知道。
邮政网络的魅力在于解耦：寄信人不需要知道收信人在哪，收信人也不需要知道信怎么来的。就算某个收信人搬家了（消费者宕机），邮局也能暂存信件，等人回来再投递。这就是消息持久化。
当然，邮政网络也不是万能的。如果信件太多（消息堆积），可能需要加派人手（增加消费者）；如果某个收信人一直不在（消费者长期离线），信件可能被退回（消息过期）。但总的来说，它让系统像现实世界的邮政一样，可靠、灵活、可扩展。
总结：数据流浪，兼容并包
数据流浪之旅结束了，我们看到了它们如何在数据库、服务、工作流、事件驱动之间穿梭。要让这场流浪顺畅，核心就是兼容性——向前兼容（Forward Compatibility） 和向后兼容（Backward Compatibility）。
