一个即时推送邀请功能的实现

最近业务中遇到一个场景，为促进用户邀请拉新，支持面对面邀请领红包，简单描述下，就是端内展示二维码，目标新人微信扫码授权，获取信息并引导下载，老用户获得奖励。由于是面对面的方式，对时效要求比较高。这里有两种方式，一种是客户端接口一直轮训或者长连接，获取是否有人扫码。这种方式效率比较低，而且如果量大的时候，请求开销会比较大。 好在对于客户端来说，存在另一种快捷方便的方式，即PUSH。 这里简单引用介绍下PUSH。

Push通知是对「用户界面」进行的主动且实时的消息推送。
业内使用比较多的是谷歌，小米等的push服务。

这个场景中我们用的是push的透传，说下过程。目标新人微信扫码后，通知了服务端后台，获取到对应信息，然后发送透传push给客户端，老用户客户端收到，做转发，给前端（这里是作为活动处理，由前端开发），前端响应，展示并请求奖励，整个链路完成。
补充下这里，会有个兜底的过程，比如有些情况因为网络、push服务延迟(第三方)等原因，新人扫码后，老用户没有即时收到push，在下次登录之后会做兜底，再次从服务端查询扫码用户集合，做对应处理。

在发奖励的最后，要把pop队列放到finally里，即使异常也保证pop出队列。否则逻辑是有问题的。

下面再说下服务端如何存储有人扫码的信息。很简单这里用了redis的消息队列，在有人微信扫码后，push（redis）到队列中，在发送push透传成功，前端请求奖励后，pop队列元素出来，完成奖励，完成链路。 而兜底就是在下次进来时，pop所有该用户队列中扫码信息，由前端依次处理。整个流程大致是这样。

最后说几点题外话，最近虽然开发任务比较多，难得也做了些思考，这里简单做个记录。以下：
1、业务中尽量使用一种统一的存储，这样逻辑较为严密，内聚性高，一致性容易保证，测试也较为方便。典型的如redis等kv的使用，很多会做标记状态，容易出现难以维护的情况。
2、多系统的交互，这里也不限系统，比如前后端交互中，最好能规范，以code做状态，关联操作，msg做提示和日志。
3、有些通用工具可以用其返回值状态做业务逻辑处理，如redis setnx 返回值，可以判断是否有存在。
4、眼睛观测到的异常，必须配合当时的现场，如返回，日志等情况，总和考虑排查，因为原因可能是复杂的情况。单纯依靠直观印象非常不靠谱。