这是一个创建于 2964 天前的主题，其中的信息可能已经有所发展或是发生改变。
很简单，但是也很复杂。
之前几百人的时候经常服务器 gg ，现在一个商场想做微信抢红包活动，求有经验的说说，可以直接外包。
之前几百人的时候经常服务器 gg ，现在一个商场想做微信抢红包活动，求有经验的说说，可以直接外包。
 |
1
torbrowserbridge 2016-11-16 08:51:40 +08:00 via iPhone
我觉得并发数据更重要
|
 |
2
k9982874 2016-11-16 08:54:05 +08:00  1
这样的场景考虑用 c/c++写服务器吧，理论单台 1W ，实际单台 5000 可以，最少 2000 。
|
 |
3
000wangxinyu000 2016-11-16 09:00:40 +08:00
直接用微信红包不可以么~
|
 |
4
wukongkong OP @k9982874 有兴趣接外包么ʘᴗʘ
|
|
5
wukongkong OP @000wangxinyu000 微信红包没有这个场景啊…摇一摇的微信红包已经关闭了…
|
|
6
000wangxinyu000 2016-11-16 09:30:50 +08:00
奥奥~有接外包的可以带我一个么，坐标北京
|
 |
7
justfindu 2016-11-16 09:32:08 +08:00
摇周边那个 直接物理设备链接 提前服务器设置
|
 |
8
lj0014 2016-11-16 09:33:49 +08:00
openresty+redis ，直觉单机可以 HOLD 住
|
 |
9
allce231 2016-11-16 09:36:57 +08:00
理论上摇一摇 2 秒一次 就是每个人 2 秒一次请求 每一秒 10000/2 = 5000 次并发 也不是很高〜
|
 |
10
stiekel 2016-11-16 09:40:34 +08:00
其实还好吧，有可能长链接都不需要。用个 Redis Memcached 之类，应该问题不大。
|
|
11
wukongkong OP @justfindu 恩，需要讨论就是服务器怎么配置，之前用的 we7 的微擎老有问题，这次想外包的。
|
|
12
stiekel 2016-11-16 09:49:03 +08:00
@wukongkong 服务器的配置要求不太高，直接弄个云服务器，普通配置， SSD ，内存稍大点，应该就行了。
(Node or Go) + Redis + MongoDB 应该没问题。 |
 |
13
heyli 2016-11-16 10:00:34 +08:00
有兴趣 怎么联系
|
 |
14
qiayue 2016-11-16 10:01:37 +08:00 1
用 iBeacon 接入微信摇一摇周边，用户开启蓝牙，打开微信摇一摇界面就可以摇，摇出来之后进入一个 HTML5 页面，获取用户 openid 之后，调用微信红包接口给用户发红包。
2015 年我帮某企业做外包，在北大某个会场，五百人同时摇红包（对于程序来说，并不是同时），没毛病。 你一万人肯定不可能在同一秒摇吧，所以其实也没那么大的并发。 |
|
15
wukongkong OP @qiayue 客户想基本同一时刻进行活动，抢红包…
|
|
16
wukongkong OP @heyli cXE1MjQyNzkwMjQ=
|
|
17
justfindu 2016-11-16 10:05:48 +08:00
@wukongkong 摇周边那个红包是预下单了多少个红包交给了微信后台, 也就是你需要先充值, 然后分好红包个数以及价格...到时候开放给用户摇, 基本跟服务器就没多少关系了...这是线下解决方案 可以看看 wiki...
= = 摇一摇周边这个摇红包关闭了? |
|
18
wukongkong OP @justfindu 九月份关闭了…不然方便的要死要死
|
|
19
qiayue 2016-11-16 10:10:34 +08:00
@wukongkong 即使是现场 1 万人做好准备了，支持人一声令下，大家同时摇，对于程序来说，也不是同一秒发生的，尤其是用了微信摇一摇周边之后，同一秒进入 HTML5 界面的有 1000 人就很不错了。
而这个方案，对于服务器来说，只需要收到前端发来的 openid 之后，随机一个数字，然后调用微信红包接口发红包，服务器要做的很少。 |
 |
20
codingkiller 2016-11-16 10:15:13 +08:00
还要搞清楚一点，客户需不需要获取微信用户的头像 /昵称这些数据。我们做了两年多的微信红包活动，上个负载均衡的方案就都解决了。
|
 |
21
grayon 2016-11-16 10:15:34 +08:00
好的 nosql 可以做到单台服务器百万的 tps ，抢红包应该不难吧
|
|
22
wukongkong OP @codingkiller 给个联系方式呢
|
|
23
wukongkong OP @qiayue 有没有兴趣接这个外包•ᴗ•
|
|
24
qiayue 2016-11-16 10:35:27 +08:00
@wukongkong 加我微信（ qiayue ）
|
 |
25
xhat 2016-11-16 10:37:46 +08:00
上面很多回答看起来都是理论回答，可能没有真正做过微信开发。
服务器不是问题， nosql 更不是问题，发红包也不是问题。最大的问题应该是获取 openid 时的时间成本。 几百人和上万人差的数量级很大。 万人同时，真实场景每人会摇很多次，即便分布在几分钟内，并发也会很高，如果这时去请求 openid ，即使做实时缓存，上万次的请求也有可能会让服务 down 掉。 所以，这种场景，一定要，提前收集用户 openid ，即便收集不完全，少数的即时请求压力不会太大。 |
 |
26
jccg90 2016-11-16 10:43:15 +08:00
之前看别人说上了云服务，有负载均衡，且架构好的话，搞活动的时候加几个小时带宽、加几台机器就行了，活动结束之后再把临时的机器和带宽关了。。。成本低得很
|
|
27
codingkiller 2016-11-16 10:44:55 +08:00
@wukongkong 微信（ codingkiller ）
|
|
28
codingkiller 2016-11-16 10:47:02 +08:00
@xhat 说的在理。我们实际开发中发现最容易阻塞的并不是业务本身，反而是去获取用户 openid 和基本信息。所以最后自建了一个本地微信用户信息缓存。
|
 |
29
fyooo 2016-11-16 11:42:39 +08:00
我跟你说，瓶颈在于当时的 wifi 和运营商网络，我们做过类似的活动，有打几百人同时发请求就导致我们部署的 wifi 处理不过来了。
|
 |
30
rainfox 2016-11-16 13:05:05 +08:00
微擎的模块或者微擎最大的问题就是 MySQL 优化问题，以使用阿里云为例，可以开单台 ECS ，然后创建负载均衡（按量付费），然后开启弹性伸缩功能（活动的时候自己可以提前手动创建若干台，结束后统一释放）， OSS 附件分离，用 RDS 实现数据库读写分离（ 1 台读写，多台只读）。这样可以有效提供并发率。
|
|
34
wukongkong OP @xhat 如果客户的目的就是加粉.....那么这个问题就避免不了了....
|
 |
35
sampeng 2016-11-16 16:13:25 +08:00
不知道业务逻辑复杂度，没办法判断。
简单的单台就够了。 redis+nginx 。轻轻松松 |
 |
36
tidewind 2016-11-16 17:23:34 +08:00 1
@wukongkong 在业务上加粉没必要在同一时间去摇红包来实现，可以在活动过程中通过各种方式叫大家先关注：“一会要摇红包，你关注晚了就错过了” 之类的
|
|
37
wukongkong OP @tidewind 是的……但是还是要一起摇红包啊…
|
|
38
tidewind 2016-11-16 18:26:41 +08:00
@wukongkong 前面说了嘛，获取每个用户 openid 是比较耗时的，所以尽量在摇红包之前比较长的时间尽可能让用户关注公众号获取 openid ，至于摇红包那个并发，并不是多不得了的事情。
|
 |
39
fashioncj 2016-11-16 20:26:25 +08:00
同意楼上的说法，其实获取 openid 也不怎么费时。。前提是你的网络要好。。我这个类似的项目都是阿里云开按流量付费的机器做的。红包发送用 ping++
|
 |
40
lygmqkl 2016-11-16 23:10:49 +08:00 via iPhone
扫了下关键词 只有 nosql 和 openid 。 最关键的应该是 restful 把链接变成 stateless 然后组分布式架构吧。
如果肯花钱想做好产品 可以联系我 1w 人还好并不是特别大的量级 |
Select Language