
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 如果必须要并发访问,就利用EC2这样的,提前launch多个instance。数据也可以用instance作cache。峰值过去后,在关闭,也很节省。(24个instanche,1小时,相当于,1个instance一天) |
12 GreenHand 2014-03-27 16:29:30 +08:00 如果只是推送后服务器无法承载访问压力,建议部署在云主机上。 如果买主机,可能导致平时资源浪费。 或者,没必要集中推送嘛,如果实时性要求不高的话。 |