这是一个创建于 3907 天前的主题，其中的信息可能已经有所发展或是发生改变。
那红包像土拨鼠一般冒出来，真的是你手快点出来的？
我觉得肯定不是吧。那一秒钟得要多多少少http连接啊。肯定是你连上那会儿，就给你id赋值了一个随机数，，有就有，没有就没有吧。
就像双十一挂卡，肯定是每次刷新服务器返回一个随机数，然后这个随机数有个布尔属性。
我又想了一下，今天这个数据结构设计可能还不是我上面所说的。应该返回一个key，value对应一个大数组，数组存的全是布尔量，就一个1，其他全是零，对应一个个红包。你要没点到1的红包，奖金再返回奖池。
不知道是不是这样设计的，大家来讲一讲这个具体问题的数据结构实现，不要水嘛~~~
我觉得肯定不是吧。那一秒钟得要多多少少http连接啊。肯定是你连上那会儿，就给你id赋值了一个随机数，，有就有，没有就没有吧。
就像双十一挂卡，肯定是每次刷新服务器返回一个随机数，然后这个随机数有个布尔属性。
我又想了一下，今天这个数据结构设计可能还不是我上面所说的。应该返回一个key，value对应一个大数组，数组存的全是布尔量，就一个1，其他全是零，对应一个个红包。你要没点到1的红包，奖金再返回奖池。
不知道是不是这样设计的，大家来讲一讲这个具体问题的数据结构实现，不要水嘛~~~
 | 1 djchurch007 2015-02-11 16:23:08 +08:00 前端数据是不可信的～～ |
| 2 djchurch007 2015-02-11 16:24:16 +08:00 长链接耗资源～～ |
 | 3 jason52 OP @djchurch007 那你说应该是怎么实现这个问题呢 |
 | 4 learnshare 2015-02-11 16:27:33 +08:00 进去之后，就已经确定你是否能拿到了。然后就是让你花点时间在客户端自己玩玩游戏 |
 | 5 acros 2015-02-11 16:27:50 +08:00 应该开抢前就随机决定本地有没有实际红包了吧，没点开就视作放弃？ |
| 6 djchurch007 2015-02-11 16:31:14 +08:00 |
 | 7 AssKicke 2015-02-11 16:35:02 +08:00 @learnshare 这位哥们正解 |
| 8 djchurch007 2015-02-11 16:37:06 +08:00 @learnshare 如果是这种思路，是不是得加个万一不高兴玩的判断>_< |
 | 9 brightzhang 2015-02-11 16:39:46 +08:00 @learnshare 如果进去就确定了有没有，如果不在屏幕上戳到那个小人，红包还会给吗？ |
| 10 learnshare 2015-02-11 16:45:31 +08:00 @brightzhang 可以去试验一下，不过不一定能试出来 |
| 11 jason52 OP @djchurch007 对啊。。我觉得对付外挂就是https保护一下。而且很有可能是在key这里就决定了你拿到的那组value 里面有可能一个红包都没。 而且这次就只有一次机会么，上次那个刮刮卡可是无限次数的，我都想写个脚本了。。。 |
 | 12 TFNotGiven 2015-02-11 16:47:11 +08:00  1 其实设计无非就两种吧， 一种比较简单，就像上面说的在你访问时已经返回结果了，游戏部分只是逗你玩。 第二种在你访问时服务器传回一组数据（总钱数及钱的分布情况参杂混淆数据）通过js渲染成游戏，根据你点击的结果返回一组数据到后台校验。 猜测后者可能性大些。总感觉他们做这种事情其实也是变相让用户测试他们的服务的稳定性，方便未来做一些其他的事情。 |
 | 13 dangbiao1991 2015-02-11 16:48:41 +08:00 楼上说的有理 |
| 14 jason52 OP @TFNotGiven 后者万一抓包了协议被破解岂不悲剧，确定权不能再用户手上啊 |
| 15 TFNotGiven 2015-02-11 16:56:32 +08:00 @jason52 其实从业务上来说控制这个很简单，比如你抽到红包时总钱数是固定了的。 比如你这次抽到了总钱数是10.85，好，我把这个给你拆分成20份小红包在游戏里您能点着多少就看你运气了，你说我破解了你的校验方式，没事，我全给你了就10.85。也就这样了，你说呢？你的抽奖次数又不是无限的，就那么几次而已。 |
| 17 jason52 OP @TFNotGiven 这到也行，程序员很有做上帝的感觉有没有。。。。你命里这个过年活动就只能抽这么多钱。。。。哈哈哈 我还考虑为啥有的人在微博上抽到100多。。。从人人有份大家开心的角度讲，应该把钱平分出来，每人拿个小单子。。。。但是从传播学的角度讲，给几个幸运儿特别多的大单子，他们在社交网络分享出来，反而激励其他人去参与这个活动。 程序员真是机智~~ |
| 18 jason52 OP @zjuster 是啊，所以你不是在和阿里抢，是在和其他用户抢。提高你抢中几率，不过我也认为针对具体某个用户会有一定阈值的。。 |
 | 19 jyz19880823 2015-02-11 18:24:09 +08:00 估计也就是玩个游戏，把点到了几个当参数发过去，抽个奖什么的 |
 | 20 Bearox 2015-02-11 18:27:25 +08:00 @jyz19880823 这样应该没这么快吧，看它点开一个直接就出来了，有没有抢到。 |
 | 21 liuchang0812 2015-02-11 20:53:42 +08:00 你会发现，你在有网的时候进去，没网的时候还可以抢。。。 |
| 22 jason52 OP @liuchang0812 如果是这样，那就说明玩游戏纯粹是偏偏小朋友啊 |
 | 24 jucelin 2015-02-11 22:11:05 +08:00 利用redis + lua解决抢红包高并发的问题 http://blog.csdn.net/hengyunabc/article/details/19433779 |
 | 25 typcn 2015-02-11 22:28:50 +08:00 一旦服务器繁忙且连接失败，自动让你抢不到 |
 | 26 lingrel 2015-02-11 22:31:44 +08:00 正在搞活动发红包。。。。 |
 | 27 smileawei 2015-02-12 08:39:26 +08:00 via iPhone 有营销考虑，不然进去就点一下，然后告诉你，你没抢到。客户体验buhao |
 | 28 SuujonH 2015-02-12 14:25:46 +08:00 应该是获取一个红包总量，然后前端分配是否分割，分割到哪个小人。然后玩游戏。 不为0时上传数据，然后判定是否有效什么的。 我在想是不是红包总量可能不是10点传的，可能是晚上后台传什么的。服务器压力可能没这么大。 |
Select Language