快速搭建安全支付二维码，用Redis实时记录扫码实收数据，简单又高效

前几天我在网上看到一个技术论坛里的讨论,有人问怎么快速做一个能让小商户用的收款二维码系统，要求很简单：用户扫码付钱后，老板能马上在自己的手机或电脑上看到谁付了、付了多少，数据不能丢，还得快，下面很多人给出了复杂的方案，比如用消息队列、用专门的支付中间件，听起来就头大，根据我过去做过的一个类似项目（灵感来源于CSDN博客上一位叫“码农小胖”的开发者分享的简易支付对账思路），用Redis这个内存数据库来做核心，事情可以变得非常简单直接，下面我就把这个方法原原本本地说一下，保证不绕弯子。

核心想法特别简单,我们不用把每次扫码支付的成功通知都急着写进像MySQL这样的传统数据库里，因为写数据库操作相对比较慢，尤其是在很多人同时付款的时候，数据库可能会成为瓶颈，我们改用Redis，它所有的数据都放在内存里，读写速度飞快，非常适合处理这种瞬间大量的简单数据记录。

具体怎么做呢？第一步，生成二维码，这个二维码本质上就是一个链接地址，比如你的系统为每一笔待支付的订单生成一个唯一的编号，ORDER_20231027_123456”，那么二维码里包含的链接就是类似于 https://your-payment-page.com/pay?order_id=ORDER_20231027_123456&amount=88.88 这样的，用户扫这个码，就会打开这个付款页面，看到订单信息和金额，然后选择支付方式完成支付。

重点在第二步,支付成功后的处理，当用户完成支付，微信支付或支付宝的服务器会向我们事先设置好的一个后台接口（我们称之为“支付回调接口”）发送一条通知消息，告诉我们“订单ORDER_20231027_123456已经支付成功，金额是88.88元”，我们的后台服务收到这个消息并验证无误后，关键操作来了：它不直接去操作数据库，而是做下面两件事：

第一件事,立刻把这个支付成功的信息写进Redis，怎么存呢？可以用Redis的Hash数据结构，就像一张表格，一个订单号对应一行数据，我们给这个订单在Redis里创建一个Key，比如叫 paid:ORDER_20231027_123456，然后在这个Key下面，存入几个字段：支付金额（amount）、支付时间（pay_time）、付款用户标识（openid或user_id）等，这个过程非常快，几乎瞬间完成，完成之后，我们就可以立即给支付平台的服务器返回一个“成功接收”的响应，避免对方因为超时而重复发送通知。

第二件事,实时让老板看到，既然数据已经进了Redis，老板用的那个管理端（可能是手机APP，也可能是网页）怎么实时获取更新呢？这里可以用Redis的“发布/订阅”（Pub/Sub）功能，这功能就像电台广播，当后台服务成功把支付记录存入Redis后，它紧接着就向一个特定的“频道”（Channel），比如叫 channel:payment_success， “广播”一条消息，内容就是那个订单号“ORDER_20231027_123456”，老板的管理端程序一直“订阅”着这个频道，只要这个频道有新的广播（即新订单支付成功），管理端就能立刻收到通知，收到通知后，管理端再根据收到的订单号，去Redis里取出这个订单的详细信息（金额、时间等），然后立刻显示在老板的屏幕上，这样，老板就能几乎在顾客付款完成的同时，听到“叮咚”一声，看到一条新的收款记录弹出来，体验非常好。

那万一服务器重启,Redis内存里的数据丢了怎么办？这就是第三步要解决的持久化问题，我们确实不能一直把数据只放在Redis里，毕竟内存是易失的，我们需要一个后台任务，定时地（比如每隔5分钟）或者当累积到一定数量的未保存记录时，把Redis里新增的支付记录“搬运”到MySQL这样的传统数据库里做永久保存，这个搬运过程可以很简单：扫描所有符合 paid:* 这种模式的Key，把它们的值读出来，批量插入到MySQL的订单表中，插入成功后，可以选择把这些Key从Redis里删除，也可以保留一段时间以备查询，这样，即使Redis发生故障，我们也只可能丢失最近几分钟的数据，绝大部分数据都已经安全地存进了硬盘，这种“内存加速写，硬盘保安全”的模式，在很多需要高性能的场景下都在用。

这个方法的好处就是直截了当,利用Redis的速度处理实时流水，利用它的发布订阅功能实现实时通知，然后再异步地把数据落地到数据库做持久化，对于一个小微商户来说，这套系统开发起来很快，运行起来也很高效，老板能获得实时的收款反馈，数据安全性也有保障，它可能不像大型电商平台那样功能繁杂，但完美地满足了“快速搭建”、“实时记录”、“简单高效”这几个核心要求，就像那位“码农小胖”在博客里说的，有时候最简单的工具用对了地方，效果反而最好。