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