1
mailunion 2014-03-26 23:28:54 +08:00
分时段
|
2
ovear 2014-03-26 23:39:04 +08:00
queue
|
5
9hills 2014-03-26 23:45:40 +08:00 via iPad
按照最大流量重新计算资源,该买机器的买机器
|
6
huijiewei 2014-03-27 00:08:02 +08:00
分时间推送啊。
固定时间点开始推送最大可负载的用户量,比如10W。监控这10W用户的访问,然后再根据监控1W,1W的再进行分段推送即可 |
7
ericFork 2014-03-27 00:18:35 +08:00
如果使用的是弹性云主机,可以根据历史监控数据推断即将到来的峰值,在给出一定冗余的基础上暂时升级配置,然后根据实时监控数据降低配置
|
8
yinxingren 2014-03-27 00:21:02 +08:00
最经济的办法就是分时段推送了吧
|
9
Ricepig 2014-03-27 00:43:15 +08:00
redis模拟一个Queue,推动时把消息enqueue,另外起一个service,有节奏地dequeue并通知.
短信群发都这么做,哈哈 |
10
huafang 2014-03-27 00:50:39 +08:00
腾讯已经推出一个推送服务了
|
11
openroc 2014-03-27 10:55:46 +08:00 1
如果必须要并发访问,就利用EC2这样的,提前launch多个instance。数据也可以用instance作cache。峰值过去后,在关闭,也很节省。(24个instanche,1小时,相当于,1个instance一天)
|
12
GreenHand 2014-03-27 16:29:30 +08:00
如果只是推送后服务器无法承载访问压力,建议部署在云主机上。
如果买主机,可能导致平时资源浪费。 或者,没必要集中推送嘛,如果实时性要求不高的话。 |