支付回调服务设计

最近游戏项目需要做一个充值支付回调服务。事关钱，最重要的就是正确性和可靠，其次需要考虑能 scale up 。这里先考虑正确和可靠。
支付流程大致如下：
1. 客户端通过第三方支付系统充值
2. 支付系统告知游戏支付回调服务器
3. 支付回调服务器通知游戏进程
                
                
支付回调进程与游戏服务进程是独立的，那么就需要考虑在连个点之间如何可靠地通讯。想起之前第一次使用 rpc 做全局邮件的时候，就非常纠结。 rpc 用起来好像很简单，实际想要做到非常可靠还是花了不少时间才想清楚。后来看到淘宝一篇关于分布式事务的文章，思路才清晰起来。在这次情景中大概是这样的：
1. 支付回调进程（下称支付进程）与游戏进程之间使用异步消息来通讯
2. 支付进程收到的每一笔交易会告知游戏进程，游戏进程需要处理成功后告知支付进程
3. 任意一笔交易，支付进程没有收到游戏进程的成功处理消息，那么会重试
4. 接收消息的进程收到重复的请求不会重复执行，但是会回馈执行成功
关键点在于：
支付进程会不断（实际会有最大尝试次数）重试直到收到游戏的已经处理的消息
对于同一笔交易，游戏进程可以收到多次通知，但是不会重复执行。
也就是说，同于一笔交易，游戏进程和支付进程都需要直到这笔交易是否已被处理。
对于支付进程来说，收到游戏服的反馈那就是已经处理完成。
对于游戏进程来说，处理完成就是一些游戏内的逻辑了，比如发放道具。