较好的web消息通知机制

今天收到了一个新的需求，是完成一个安全性相对较高的财务系统，大体思路是给用户的帐号充值，其实就是用户表的一个字段修改工作；安全性主要是体现在

1. 任何交易过程均进行相关记录；

2. 并发交易时程序健壮性保证；

3. 交易过程出现在非正常现象（停电，网络断掉）的处理能力；

4. 防止黑客攻击；

对于第一个，那就是简单的任何数据都要存档可以解决；第二个由于系统同时对一个记录做修改的并发量不会太大，用普通的事物可以实现；第四个也可以通过sql参数过滤来实现；

回过头来看第3个 发现问题了，貌似不是很好处理；

 

仔细想了一下，在客户浏览过程中，出现非正常现象的无非是客户端出现或者服务器端出现；

咱们在这里就分析下；

1. 如果在客户端发生了，在假设客户现在没有提交成功呢，就不如说客户已经点了按钮了，浏览器也正要去请求，突然大事不好！断电了，这个请求就没有成功的发送过去，即服务器端没有正常的接受到；那这个时候怎么办呢，客户点按钮了，服务器没有接受到请求，所有的操作都没有执行，这时服务器就没有必要通知客户端该事件的执行情况了；

2. 如果说客户已经提交成功了，即服务器接收到了客户端的请求，用户正在客户端等反馈结果呢，突然大事不妙了；这时候客户就郁闷了，你这次到底执行成功了没有啊！针对这个情况，感觉服务器端得把这次事件的执行结果送给这个用户，要不然客户得一直郁闷；所以这个时候的情况应该是服务器照常执行，执行完毕后反馈给客户端，但是不行啊客户端没电啊，并且还不知道客户端啥时候来电，所以这个信息还得保存在服务器端，并且怎么实现数据的push也是个问题；麻烦！  不过总有解决方案的，前两天看了点支付宝的接口，发现这个倒是可以借用他们那个设计的；

•      服务器接收了请求后，完成了字段操作后，生成了另外的一个记录，这个记录就是要push的数据，信息被response到前台，但是存在问题了，服务器端并不知道该信息是否给用户看到了；所以服务器要收到客户端针对收到刚才response的回馈，相当于客户端要对服务器再说下“我刚才收到了”；这个好办，相当于客户端执行刚才response给他的脚本，重新发一个xmlHttp请求给服务器，服务器接收了，OK，根据参数就知道了，客户端已经收到了这个反馈结果了，那就没事了；如果还没收到，那好我就等你下次登录后，我再给你response过去就结了；

服务器端的话，基本也是这样一个过程；大家仁者见仁智者见智，笑纳了啊