推送类App的服务器选型，核心不是买一台多贵的机器，而是围绕“长连接稳定性、高并发推送吞吐、消息送达率”这三个硬指标去搭。 没有一套固定配置能通吃所有场景，但选型逻辑是通用的：先算清你的用户规模和推送频率，再决定用云服务器还是物理机，最后把推送通道单独拆出来优化。
推送App的服务器，到底在扛什么活
很多人以为推送就是发个通知，服务器压力不大，实际恰恰相反，推送是最消耗服务器资源的场景之一，你的App要跟服务器维持一条常驻的TCP长连接（Android端尤其明显），几万甚至几十万设备同时在线，服务器得一直抱着这些连接不撒手,这比普通HTTP请求费劲多了。
一台服务器能扛多少并发连接，取决于两个东西：内存大小和业务线程模型，每个空闲连接大概要吃8KB到16KB内存（主要在内核socket缓冲区），照这个算，一台8GB内存的云主机，理论极限也就撑几十万空闲连接，但真到推送高峰期，业务逻辑一跑起来,内存和CPU立刻告急。
推送高峰期是瞬时并发，比如你定在上午10点推送一条全员消息，那几秒钟内，服务器要把消息同时塞给所有在线设备，这时候不光是网络带宽吃紧，服务器的CPU也得疯狂处理消息编码、加密、写日志这些杂活，如果架构上没做削峰,服务器直接被打挂都有可能。
推送通道的几个组成模块
一起推送行为,背后是这条链路在跑：
- 接入网关：负责接收App客户端的连接请求，验证身份，维持心跳,这是最基础也是最吃性能的模块。
- 消息队列：推送动作不是同步完成的，运营点一下“发送”，后台得先把任务扔进队列，再由推送服务从队列里拉出来批量下发,这能防止瞬间流量打崩数据库。
- 推送分发器：真正干活的核心，它负责从队列里取消息，然后遍历所有在线连接，把消息写进socket，这里的数据结构和并发控制做得不好,推送延迟会明显上升。
- 设备状态存储：记录哪些设备在线、哪些离线、离线了多久，离线用户数量大,这个库的读写压力会很高。
如果你用第三方推送服务（比如极光、个推），那上面这些你都不用管，但如果要自建推送系统,这些模块都得自己搭。
云服务器和物理服务器，推送场景选哪个更合适
关于服务器选型，业内有个很实际的判断标准：看你的推送量和预算弹性，自建推送系统为主、用户规模在百万级以下的，用云服务器更合适；到了千万级用户量、且对数据合规有硬性要求,才需要考虑物理机托管。
云服务器：绝大多数App的首选
云服务器最大的好处是弹性伸缩，推送这种场景，流量波峰波谷极其明显：平时在线连接数很平稳，一到推送时刻，CPU和带宽立刻飙高，推完又回落，用云服务器，起一台高配置的机器做推送网关，或者配合负载均衡搞三台，压力大时临时扩容，推完缩容,成本可控。
具体到配置参考（以简米云或酷番云为例）：
- 用户量10万级、日推送量几十万条：一台4核8GB的云服务器起步，带宽按峰值5Mbps到10Mbps算，系统盘用SSD，网络选独享带宽，别用共享,否则推送高峰容易跟其他用户抢带宽。
- 用户量50万到100万级：建议8核16GB，带宽提到20Mbps以上，并且加一台4核8GB的机器单独跑消息队列（用RabbitMQ或者Kafka）。
- 用户量300万以上：不要再单机硬扛，用负载均衡（SLB）挂至少三台8核16GB的推送网关节点，后面再接一套Redis集群存设备状态,消息队列也要独立集群。
物理服务器：什么时候才需要考虑
物理服务器的优势在于资源独享、性能稳定、无超售，但当你在云服务器上遇到CPU积分耗尽、邻居抢占带宽这类问题，换物理机能解决，不过物理机也有麻烦：扩容周期长（一般要1到3天），运维成本高（得自己处理硬件故障），没有弹性。
行业共识认为,只有这两种情况值得用物理机：
- 用户规模已经到千万级，推送量大且稳定,云服务器的带宽费用算下来比物理机托管还贵。
- 有严格的数据安全合规要求，比如金融、政务类App,数据不能出特定机房。
不然的话，混合架构是更稳的选择：核心的推送分发服务跑在物理机上，外围的消息队列、数据库、管理后台跑在云上。
推送App服务器怎么选，关键看这几个配置参数
到具体选配置时，别被云厂商的“通用型”“计算型”这些命名绕晕,抓准这几个参数就行。
CPU和内存：跟用户规模强相关
- 在线连接数：每个TCP连接空载时占用内存很小，但业务线程一旦处理推送任务，单个任务可能占用几十KB到几百KB内存，涉及消息体序列化、模板渲染的话更高。
- CPU核数：推送服务需要同时处理大量网络读写，IO密集型任务用多核CPU收益明显，4核是起步，8核体验会好很多，做消息加密（比如TLS握手）时,CPU消耗非常大。
带宽：推送瓶颈比CPU更容易先出现
一条推送消息的payload，即使精简到按几百字节算，给一万个用户推，就是几MB流量，看起来不多，但注意，这是瞬时并发的，假设你需要在5秒内推完，那带宽就得按每秒几十MB来换算，10Mbps的带宽，极限下载速度只有1.25MB/s，推一条包含图片URL的模板消息，一万人在线,得推十几秒甚至更久。
推送服务器的带宽预算要按峰值推送速率来算，而不是平均速率，经验值是：
10万在线用户、5秒内推完、每条消息5KB以下，带宽至少需要100Mbps,这是相当一部分团队容易低估的环节。
磁盘IO：别拖后腿
推送服务要写大量日志（推送记录、送达回执、设备上下线事件），用的是普通云盘，高峰期日志写入速度会卡住，进而拖慢整个业务进程。系统盘和日志盘分开，日志盘单独挂一块按量付费的SSD云盘,是个很实用的操作。
推送量级对应的服务器部署方案
自己搭推送系统的技术团队,可以参考下面这套分级方案。
小规模：日活1万以下，推送量不大
- 一台4核8GB的轻量或云服务器即可。
- 架构上用单机版Redis存在线状态，推送服务直接用Netty或Go的gRPC实现,不做集群。
- 这个阶段主要任务是验证推送功能,不用过度设计。
中等规模：日活10万到50万
- 两台8核16GB服务器组成一个小集群,前面挂负载均衡。
- Redis用主从模式,防止一台宕机导致整个推送服务不可用。
- 消息队列用RabbitMQ,可以简单做削峰。
- 数据库要单独一台,别跟推送服务混用。
大规模：日活100万以上
- 三到五台8核16GB或更高配的服务器组成推送网关集群。
- Kafka做消息队列,支撑高吞吐量。
- Redis用Cluster集群模式,多节点分担读写压力。
- 推送系统本身要支持分片，按用户ID的哈希值把设备分布到不同节点，这样扩容时只需加机器,不用重构。
部署推送服务器时，需要做哪些具体操作
选好服务器只是第一步，真正的坑在部署环节,有几个实操步骤值得照着检查一遍。
第一步：调整系统内核参数
Linux默认的内核参数不适合高并发长连接场景，照着下面改,能避免后续踩坑：
# 修改 /etc/sysctl.conf # 允许本地端口重用，防止大量TIME_WAIT连接耗尽端口 net.ipv4.tcp_tw_reuse = 1 # 加大TCP连接队列长度 net.core.somaxconn = 10240 # 加快TCP连接回收 net.ipv4.tcp_fin_timeout = 15 # 增加文件描述符上限 fs.file-max = 1000000
改完执行 sysctl -p 生效，把进程的ulimit也调大,推送服务进程能打开的文件描述符数量直接决定了它能维持多少长连接。
第二步：业务架构上做削峰处理
推送高峰期不能直接让运营系统的请求打到推送服务上,标准做法是：
- 运营提交推送任务,只写入数据库。
- 定时或实时任务扫描数据库，把任务投递到消息队列。
- 推送服务从队列中拉取任务，按批次（比如每批1000个用户）下发。
这样，即使运营同时发好几条全员推送,系统也不会立刻崩溃。
第三步：做推送通道的自动降级
如果某台伺服器压力过大，或某个运营商网络出现抖动，要有预案,比较通用的策略是：
- 设置超时重试,比如单条推送10秒没收到ACK就转离线推送通道。
- 把APNs、FCM（国外）、华为、小米、OPPO、vivo这些厂商通道作为保底，自建通道推不动的，自动轮询厂商通道发,这一步能显著提升送达率。
推送App服务器多少钱，预算怎么估
目前国内云服务商的价格,可以给你一个大概的参考范围。
- 入门级（用户1万以下）：一台轻量应用服务器，一年几百到一千元,够用。
- 成长级（用户10万到50万）：两台8核16GB的云服务器加负载均衡和Redis，一个月大概两千到四千元，算上带宽和存储，年成本两万到五万。
- 规模级（用户100万以上）：包含Kafka集群、Redis集群、多台推送网关，月成本上万甚至数万,具体看带宽和并发量。
数据来自主流云厂商官网的公开报价,不同地域价格会有差异。
这里要提醒一下：如果主要用户在国内，服务器需要选境内节点并完成备案，这会影响上线时间，域名备案通常需要一两周,这个流程要提前留好。
Q&A：推送服务器选型的几个常见问题
推送App服务器怎么选，直接买最高配能解决问题吗？
不能，高配机器解决了“计算能力”，但推送的瓶颈往往在架构设计上，你用单机模式硬扛海量长连接，即使买了32核64GB的机器，单条业务线程处理网络事件时，CPU利用率也很难跑满，更高配的机器只是拖延了问题爆发的时间点，该做的网关拆分、队列削峰、业务分片,一样都少不了。
用第三方推送服务，还需要自己买服务器吗？
需要，第三方推送服务（比如极光、个推、厂商通道）能帮你省掉维护长连接网关的麻烦，但你的服务器仍然要跑业务服务器的API接口，用来告诉推送服务“给谁推、推什么内容”，业务服务器需要做的是处理App的上报逻辑、生成推送令牌、调用第三方接口，这部分承载的压力不大，一台基础配置的云服务器就能搞定，真正复杂的是前端的推送令牌管理，如果服务器不上报、不刷新令牌，推送服务就不知道用户设备在哪,自然也就推不出去。
推送业务需要多大带宽才够
取决于你的推送速度和payload大小，用一条简单公式估算：带宽（Mbps）= 在线用户数 × 单条消息大小（KB） ÷ 目标推送耗时（秒） × 8，举个例子，10万在线用户、单条消息2KB、要求在10秒内推完，那带宽至少要 100000 × 2 ÷ 10 × 8 = 160Mbps，这个数字是峰值带宽，实际选购时建议在这个基础上再加30%到50%的余量，因为推送高峰时还有心跳包、回执包在走同样的带宽。
图片来源于AI模型，如侵权请联系管理员。作者：酷小编，如若转载，请注明出处：https://www.kufanyun.com/ask/805580.html
