做一个接近万人的微信摇一摇抢红包活动程序与服务器需要多少预算

[wukongkong]

很简单，但是也很复杂。
之前几百人的时候经常服务器 gg ，现在一个商场想做微信抢红包活动，求有经验的说说，可以直接外包。

[grayon]

好的 nosql 可以做到单台服务器百万的 tps ，抢红包应该不难吧

[wukongkong]

@codingkiller 给个联系方式呢

[wukongkong]

@qiayue 有没有兴趣接这个外包•ᴗ•

[qiayue]

@wukongkong 加我微信（ qiayue ）

[xhat]

上面很多回答看起来都是理论回答，可能没有真正做过微信开发。
服务器不是问题， nosql 更不是问题，发红包也不是问题。最大的问题应该是获取 openid 时的时间成本。
几百人和上万人差的数量级很大。
万人同时，真实场景每人会摇很多次，即便分布在几分钟内，并发也会很高，如果这时去请求 openid ，即使做实时缓存，上万次的请求也有可能会让服务 down 掉。
所以，这种场景，一定要，提前收集用户 openid ，即便收集不完全，少数的即时请求压力不会太大。

[jccg90]

之前看别人说上了云服务，有负载均衡，且架构好的话，搞活动的时候加几个小时带宽、加几台机器就行了，活动结束之后再把临时的机器和带宽关了。。。成本低得很

[codingkiller]

@wukongkong 微信（ codingkiller ）

[codingkiller]

@xhat 说的在理。我们实际开发中发现最容易阻塞的并不是业务本身，反而是去获取用户 openid 和基本信息。所以最后自建了一个本地微信用户信息缓存。

[fyooo]

我跟你说，瓶颈在于当时的 wifi 和运营商网络，我们做过类似的活动，有打几百人同时发请求就导致我们部署的 wifi 处理不过来了。

[rainfox]

微擎的模块或者微擎最大的问题就是 MySQL 优化问题，以使用阿里云为例，可以开单台 ECS ，然后创建负载均衡（按量付费），然后开启弹性伸缩功能（活动的时候自己可以提前手动创建若干台，结束后统一释放）， OSS 附件分离，用 RDS 实现数据库读写分离（ 1 台读写，多台只读）。这样可以有效提供并发率。

[liuhaige]

@rainfox 但是很费力啊。

[rainfox]

@liuhaige 什么很费力？你是说人比较累还是这样的架构跑起来吃力？

[tidewind]

@xhat 说得没错，这个很重要

[wukongkong]

@xhat 如果客户的目的就是加粉.....那么这个问题就避免不了了....

[sampeng]

不知道业务逻辑复杂度，没办法判断。
简单的单台就够了。 redis+nginx 。轻轻松松

[tidewind]

@wukongkong 在业务上加粉没必要在同一时间去摇红包来实现，可以在活动过程中通过各种方式叫大家先关注：“一会要摇红包，你关注晚了就错过了” 之类的

[wukongkong]

@tidewind 是的……但是还是要一起摇红包啊…

[tidewind]

@wukongkong 前面说了嘛，获取每个用户 openid 是比较耗时的，所以尽量在摇红包之前比较长的时间尽可能让用户关注公众号获取 openid ，至于摇红包那个并发，并不是多不得了的事情。

[fashioncj]

同意楼上的说法，其实获取 openid 也不怎么费时。。前提是你的网络要好。。我这个类似的项目都是阿里云开按流量付费的机器做的。红包发送用 ping++

[lygmqkl]

扫了下关键词 只有 nosql 和 openid 。 最关键的应该是 restful 把链接变成 stateless 然后组分布式架构吧。
如果肯花钱想做好产品 可以联系我 1w 人还好并不是特别大的量级