@11138

贴一段之前的方案, 要十几秒不止, 你这个方案简直炸了! 不是提升 6 倍, 是提升了十几二十倍! 你牛逼!!

$redis = new Redis();
$redis -> connect('127.0.0.1', 6379);

$arrayName = array('test');
// $redis -> delete('test');
$sTime = microtime(true);
// $redis -> multi(Redis::PIPELINE);

$haomas = range(1, 1000000);

foreach ($haomas as $key => $value)
{
array_push( $arrayName , $value );
}

call_user_func_array([$redis, 'rpush'], $arrayName);

$eTime = microtime(true);

var_dump( ($eTime - $sTime)*1000 );

@11138
屌炸天!!! 性能比 call_user_func_array 快了 6 倍!

@500miles @BOYPT
非常感谢楼上两位, 这就是我要的

@500miles
如果是小件商品, 用户买 1 个,就临时生成一个, 买 100 个, 就临时生成 100 个, 可能问题不大
主要是大宗商品, 比如房车之类的, 用户会不会一次买个几十万难说, 但客户测试的时候,我估计必然会直接买个几十上百万的, 如果临时生成, 估计要等好几分钟, 这样体验不好

@cevincheung
有 php 的代码参考吗?

@500miles
这个测试结果就是用了以后的结果, 不用 pipeline 性能更糟

@lijinma
这个对于用户来讲就完全不可行的, 因为等于是后台可以随机指定一个数字作为幸运号码
也就是说, 后台想让谁中奖谁就中奖, 那这个产品就很难推广了

@liubo
真好玩, 直接如下是可以的
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
$redis -> rpush('test', '1', '2', '3');
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---



但是这样就不行:
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
$haomas = range(1, 3);

foreach ($haomas as $key => $value)
{
$str .= ','. $value;
}

$redis -> rpush('test', substr($str, 1));
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---



然后这样也不行:
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
$haomas = range(1, 3);
$redis -> rpush('test', $haomas);
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---



天呐, PHP 该怎样批量传递参数啊

@admol
不会, 这个要拉风投的, 所有数据都要公开透明, 这个客户有要求不能作弊不能留后门, 到时候会审查的

@ykrl089
估计是的, @lecher 也提到过可能是脚本时间限制;


但是现在的问题在于就算脚本不限时间, 每次生成几百万的号码都要花费好几分钟的话, 效率有点低

因为夺宝类目好多夺车的, 一辆车二三十万个号码, 一期结束了立马开始夺新一期, 等于立刻就要分配新号码, 几分钟的时间有点长

像网易一元夺宝, 他们的车子, 房子, 都是几十几百万的号码这么发放, 一期结束后立马就能开始夺取新的一期, 真不清楚网易是怎么解决这个问题的

@takashiki
很抱歉, 没明白, 比如有个商品, 有 10 个号码, 分别是 1 2 3 4 5 6 7 8 9 10
我如何用 crc32 随机生成这 10 个号码呢?

@zingl
现在其实卡在生成号码这一环节了, 生成 100W 个号码很费时, 我在想有没有什么聪明的办法可以解决

@takashiki
这.... 我要生成一百万个连续的号码, 别人夺宝一次就随机分配一个出去, 用 crc32 可以做到?

@just4test
1. 一个 10 块钱的商品, 分别对应 10 个号码
2. 用户花一块钱, 可以随机抽取一个号码
3. 10 个号码抽完后, 得出一个幸运号码, 谁拥有这个号码, 谁就可以获得商品


为什么不能固定按 1,2,3,4,5..这样分配?
因为计算幸运号码的公式是固定的, 那如果夺宝号码也是按固定顺序分配的话,那么依据幸运号码公式, 是可以反推出中奖号码的;
比如根据刚才那个 10 块钱的商品, 根据公式, 我大概可以推算它的幸运号码会在 4~6 之间产生
但如果号码是随机分配的, 那么即使我推算出幸运号码会出现在哪个数字区间, 我也很难作弊, 因为我不知道分配给我的号码是哪个
注:
这里的公式可以是任何公式, 比如常见的去最后 50 条参与记录的时间, 计算时间总和+最近一期时时彩开奖号码结果, 再除以参与人数, 得到余数就是幸运号码


所以现在的问题不在于如何生成幸运号码, 而是如何将连续的一百万个号码, 随机分配出去

@lecher
嗯实在不行, 我就开个 2 个 crontab:
第一个 crontab 每隔一秒就检查一次小商品, 哪些小商品的夺宝号码没有全部生成, 就生成 1K 个
第二个 crontab 每隔 10 秒就检查一次大商品, 哪些大商品的夺宝号码没有全部生成, 就生成 10W 个
这样应该就妥了

@11138
我 PHP 版本是 5.6.2 机器是 2.66 GHz Intel Core i7 8 GB 1067 MHz DDR3

@eecjimmy
已感谢


@just4test
这样可能不太符合业务需求,夺宝类的网站,号码基本上都是随机分配, 也就是说一个商品有 10 个号码的话, 就必须买一个, 随机分配一个出去, 如果第一个买的分配 1 号, 第十个买的分配十号, 那别人是完全可以根据这个规则来推算中奖号码的, 所以分配出去的号码必须随机

如果不给广电审核, 就不能上传 APPSTORE 了吗?

@lecher
@gamexg
@tigerstudent
@laoyuan
@xenme

非常感谢, 这几天黑白颠倒, 没顾得上上 V 站, 谢谢了


@xenme 你提到的这个方案, 请问方便提供案例教程吗?

@lecher 非常好, 我目前的方案,准备把你的和 Redis 结合, 事先在 Redis 里生成几百万夺宝号码, 然后夺宝一个, 就从 Redis 中读取一个, 存入 MySQL

这样安全性更高, 而且性能相信可以得到解决

@am241
用 @pubby 提到的方案, 是目前工作量最小, 最优的


@pubby
非常感谢, 这个思路很好


@debiann
我倒是这么想, 问题是客户那里死活不同意, 因为目前所有的主流夺宝平台, 都是随机分配数字的, 他说别人可以, 为什么我不可以?

@am241

我可否理解为, 原来的夺宝号码是 1000001, 1000003, 1000003..

现在变为 1, 2, 3

用户从 1, 2, 3 中取号码

然后 1 对应 1000001, 3 对应 1000003?