自从进入金融相关的公司或业务开发之后，对流水号的应用开发就有了更深刻的认知。

那么，今天我们通过流水号来应用到实际开发中。解决我们开发中的问题。

一、流水号的特点：唯一性

流水号，对于整个系统而言是全局唯一。这算是流水号最基础最重要的特点。这个特点，能解决最根本实际开发中最实际的问题。

二、实际案例：卡券发放

A 系统属于核心系统。提供了各种各样的核心功能，以及暴露一些 API 接口。这些接口可以给围绕 A 系统做运营功能的系统使用。

假如，现在有一个 B 系统有一个需求：

制作一个导流的活动页面，在该页面输入手机号并接收验证码之后实现快捷注册，然后给这个手机号对应的账户赠送一张减免 10 元的卡券。

为什么不直接在导流的注册流程里面直接赠送呢？

因为，有以下几个原因：

（1）导流页面是调用 A 系统的注册接口。A 系统属于核心业务系统，不会经常为了这些活动而定制改动系统代码，影响系统稳定性。（2）B 系统只有 A 系统的可读权限或可读权限都没有。所以，无法直接干涉核心业务数据库的功能。（3）B 系统引流注册，如果用户此时只是注册，并不会去下载 App 登录的话。那么，这时赠送卡券将变得毫无意义。只会产生更多的垃圾数据。

那么，该如何做？

（1）A 系统提供快捷注册接口、短信发送接口、卡券发送接口。（2）B 系统制作一个注册导流 H5 页面。用户填写手机号，获取验证码，输入验证码点击，点击提交调用 A 系统快捷注册接口实现注册用户。（3）B 系统调用 A 系统的注册接口成功之后，在自己的系统存储手机号、用户ID、注册时间、导流 H5 的页面唯一标识（自己定一个）。（4）A 系统在系统当中实现一系列事件（登录、注册、下单、充值、提现）。并且写入队列。然后，把这些事件实时推送给 B 系统。（5）B 系统收到这些事件之后，根据自己是否有建立在这些事件上的后续功能。比如，我们这个导流功能，就需要导流注册成功之后，用户首次登录的时候赠送 10 元卡券。

上面的 （1）、（2）、（3）、（4）都很好实现。其中，第（4）步主要是为了实现系统解耦。并且这也是目前比较常用的方案。我们今天要讲的是怎样通过流水号来解决第（5）步的问题。

那么第（5）步会有什么问题？

比如，现在 B 系统收到了导流的用户成功首次登录的事件推送了。结果，去调用 A 系统提供的发送卡券功能赠送 10 元卡券。结果，调用卡券发送失败了。于是，准备在程序里面实现一个功能：失败之后重发。最后成功了。但是，真的成功了吗？

我们来分析一下。卡券发送失败的可能原因：

请求被 A 系统正确接收。但是，由于网络原因 B 系统中断了。请求没有被 A 系统接收。请求被 A 系统正确接收，也正确发送了卡券。但是， A 系统故障了。请求被 A 系统正确接收，也正确发送了卡券。B 系统自己故障了。

当然，情况不止上面这几种，还有其他原因。不管何种原因，当我们要重发的时候，问题就来了：会导致卡券发送多次。

这时候我们可以利用流水号的特性。每次导流注册成功之后，给每条入库的记录一个唯一的流水号。流水号一定要保证它的唯一性。该流水号在 A 系统当中的发送卡券接口也要实现防重发的功能。

怎样在 A 系统当中的发送卡券接口防重复呢？

很简单。我们正确接收到 B 系统的请求之后，以此流水号写入缓存。然后，接着处理卡券发送的业务。当第二次同样的请求发送过来的时候，检查这个流水号是否在我们的缓存当中，如果存在立即查询发送的状态。并返回发送的结果。

这样 A 系统不管因为何种原因导致发送失败，重发的时候都不会导致福利卡券发送失败。

当然，A 系统也有可能会发送失败。这时我们可以找到发送失败的原因修复代码。然后， B 系统重新处理就好了。

以上只是一个理论分析。没有给出具体的 PHP代码示例。在我司的金融产品当中，我们就用该思想理论，实现了诸如此类的重发问题。