求助求助b/s架构,不知道问题出在哪里,求解决方法,有图,比较急！！

[nplive]

问题是这样的，用户A给用户B发了现金红包, 红包有个字段state字段值为0代表红包未被领取, 当用户B领取后state值更新为1, 用户每次点领取红包的时候都会判断是否已经被领取,可是这两天碰到一件很诡异的事情,就是有个用户可以多次领取相同的红包,而且是在1秒之内领取了好几次,按道理说他第二次点击红包的时候state值已经是1了的！！！
我自己多次测试都没问题的！ 要是用户使用并发器的话我后台也有验证state值的啊！！！

求大神解答，谢谢

[丰云]

呵呵，虽然不知道你的代码，因此无法具体判断哪里错了，但绝逼是你的设计有毛病被人乘虚而入了呗

[丰云]

红包这类应用，应该有一个完整而严谨的逻辑过程，不是指的普通的数据的上的严谨，而是指得数据、时间、事务等多个方面全面的严谨且完整。应该从红的生命周期考虑，从诞生到结束，只有一个入口，只有一个出口。该用事务的用事务，该用线程池的用线程池，总之不能留下明显的漏洞

[以专业开发人员为伍]

首先，同一用户一秒钟连续点击多次领红包操作，这本身应该有风险控制机制来立刻识别出是流氓来啦！ 其次，假设两个进程同时并发（快速在瞬间）同时读取一个银行账户的余额（假设100块钱）然后存进去10块钱，请问结果是110块钱还是120块钱？这是一个传统的数据库事务的基本概念问题。 第三，现代的分布式大数据系统，因为要应对大规模电信级高并发的业务场景，实际上不能用坑爹的关系数据库事务机制。用关系数据库事务来解决数据一致性问题在那个开发领域往往被认为的外行的。实际上分布式高并发的系统使用 Actor 模型来保证这类高并发下的一致性，使用“最终一致性”机制来保证连续异步事务的一致性。

[以专业开发人员为伍]

更具体地来说，就是，首先你应该有一个用户行为风险检测功能，能立刻识别出领取红包的操作太短促、是机器做的、而不是人发出的。 其次（假设你只有一台服务器的话）你应该对某个红包资源在内存中的对象的具体细节进行 lock 操作，保证凡是操作某个或者某组红包资源的线程，同一时间只有一个线程能进入 lock 的代码保护区去执行，不能并行。 如果不要求性能的话，那么你也可以使用关系数据库的事务保护机制。毕竟这是所有数据库编程的初学者都会的。

[以专业开发人员为伍]

一旦你写

if(!判断是否领走红包())
{
    领红包();
}

这类代码，就会看出来你可能根本没有对这两个操作进行数据库事务保护。 但是关系数据库事务实际上是现代的大数据高并发电信级操作的性能杀手，所以用数据库事务来保护这类数据的做法属于10年以前的做法，现在的服务器端程序员要多学点分布式、高并发、无事务锁的编程方法。

[本人QQ-554433626]

可参考数据库事务-脏读

[以专业开发人员为伍]

一个靠谱的系统，风险控制在于服务器端设计。客户端可能随时发来某种消息，比如在浏览器调试环境随时修改 js 变量甚至代码而引起的，那么都要服务器端识别风险。不可信客户端。 客户端是用来实现交互交互界面的，不是来控制业务的。一个产品的客户端可以送人，可以开放给第三方各种程序接入，而其服务器端才是控制的命脉所在。业务调整和风险控制，根本上都在服务器端设计来实现。

[以专业开发人员为伍]

至于说有的人说客户端随便发来 sql 语句或者低级的“增删改查”就被服务器端直接执行了，这种以为客户端控制业务逻辑的设计概念，更加要不得！

[小刘哈哈]

这样判断 如果跟服务器的网络不是很好 数据还没写到数据库 快速重复点击肯定会造成多次领取的，最简单的办法 在第一次点击后 过个10秒才可以第二次点击这个按钮 。

[以专业开发人员为伍]

引用 7 楼 小刘哈哈 的回复:

这样判断 如果跟服务器的网络不是很好 数据还没写到数据库 快速重复点击肯定会造成多次领取的，最简单的办法 在第一次点击后 过个10秒才可以第二次点击这个按钮 。

这是前端的控制思路，不是从服务器上主动控制的。

[nplive]

手机端没办法结帖的吗！

[吉普赛的歌]

引用 11 楼 nplive 的回复:

手机端没办法结帖的吗！

可以在手机浏览器上操作， 费劲点， 但不会有 app 上那么多的 bug .