在郑州一家连锁小吃项目里，我第一次直面“中午11:30一小时内同时下单2000单、库存错乱、收银异常”的痛点。前端点餐、收银和仓库独立系统，人工盘点造成频繁断档，既影响翻台率，也让食材损耗难以控制。那段时间的排查经验，至今影响着我对整个系统边界与一致性策略的判断。

      技术选型上，我把订单/收银服务与库存服务拆成独立的微服务：内部用gRPC承载同步调用，POS 端走REST/JSON，数据库选PostgreSQL做主存，Redis做热表与分布式锁，Kafka做事件总线，部署在Kubernetes上。实践中发现，架构不能盲从，必须根据并发模式优化单点：比如库存表设计为(sku_id, shop_id, qty, reserved, version, last_cost)，常用查询加联合索引，写操作走批量PreparedStatement以减少锁等待。

      核心问题是“扣库存”——我最终采用Redis Lua脚本做快路径：在Redis里原子地判断可售量并增加reserved，成功则向Kafka发出扣减事件；消费端异步落库并在失败时做补偿。为什么不选分布式事务？因为性能与可观测性更重要。为保证幂等，库存事件带有order_id和version；Postgres那端使用乐观锁(version字段)做二次校验，遇到冲突则回滚并触发告警。

      收银与支付整合环节同样讲究细节。对接支付宝/微信时，我把所有回调都实现为幂等操作：以out_trade_no为幂等键先写入交易表（事务内写入outbox），再发事件给订单服务。遇到回调重复或延迟通知时，系统能通过状态机确认最终态。调试技巧：用ngrok/本地日志模拟异步通知，配合数据库查询和消息重放定位差异。

      前端设备和打印机层有自成一套挑战。厨房打印通常用ESC/POS通过TCP直连，考虑到网络不稳，我在店内部署了轻量级Print Agent（基于Go），与后端保持双向心跳并支持离线队列。打印失败的订单会在本地重试并把错误上报到Kafka，方便集中统计与人工介入。实操教训：别把设备重试逻辑全扔给中心服务，边缘做缓冲更可靠。

      运维与故障排查是落地的试金石。我用OpenTelemetry埋点链路追踪，Prometheus采集关键指标（库存偏差、Kafka lag、Redis命中率），Grafana告警触发界面派单。压力复现靠k6和自定义脚本制造并发场景，遇到CPU热点就用pprof定位热点函数。个人建议是：先把幂等与监控做好，再考虑复杂补偿策略；迭代上线，灰度与回滚机制少不了。