这是一个创建于 3300 天前的主题，其中的信息可能已经有所发展或是发生改变。
很简单，但是也很复杂。
之前几百人的时候经常服务器 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 PRO 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 PRO @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 PRO @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