jetty服务器作支付处理的问题

我们最近对账的时候发现，有一些和第三方支付公司的交易，没有被mysql数据库记录下来。查了下日志，只有请求，没有响应。想了想，应该是服务器重启的时候，第三方支付公司的请求还没有返回，原来执行的sql回滚了。原来用的weblogic服务器就没有这样的问题，因为在重启的时候，weblogic服务器会一直等待所有的请求都返回，所有的事务都处理好了，才会真正重启。但是jetty服务器告诉他重启，什么都不等，直接重启了。

用weblogic，老板不愿意掏钱，那就只能用其他的办法了。如果是其他的大公司，这么简单的等待功能很快就开发出来了，但是我们显然没有人手开发这个功能。那就想其他的方法了。我们可以在拦截器那里做文章，判断一个变量，如果不满足，就直接返回就可以拒绝新的请求了。等待一段时间后，程序再重启。沿着这个思路。首先在配置中增加一个properties文件，每次有新的请求过来，就先看看这个文件有没有，如果没有，则请求直接返回错误格式。我们前端每个请求都会判断返回的json格式是否正确，如果不正确，则会重新发起请求，最多5次。这样即使我的请求返回的不正确，再次请求的时候nginx有很大概率把请求送往其他正常的机器，总之用户感觉不出来。在重启的时候，我在脚本里面先把这个配置文件删了，然后等30秒后再重启服务器。貌似解决了这个问题。

在线上跑了几天，觉得30秒太长了，就改为15秒。悲剧出现了。一次代码发版本的时候，又丢数据了，觉得这种方式不靠谱，因为我们向第三方请求的时间是非常不确定的。这种方式不能百分百保证我们不丢数据。

然后就想出了先提交数据库再请求的方案。如果向第三方支付公司的请求失败了。再删除掉刚才插入，将修改的数据还原。这样配合之前的拒绝服务状态，就百分百不丢数据了。就算是在我们提交数据库后，请求支付的时候服务器重启了。依然是有支付中间状态的数据在数据库里面，通过轮询，我们就知道这笔交易第三方是否接收到，是否支付成功。