设计Android客户端-服务端票务应用的最优实现方案咨询

各可选方案分析 #

• 短间隔轮询方案
  • 不推荐使用。你计算的请求量级无误：3000用户每5秒轮询的话，单日请求量确实超过5000万，对应峰值QPS约600，即使是接口逻辑非常轻量，对中小型服务端来说也会造成不必要的资源浪费。除此之外，安卓端长期运行前台服务会消耗用户额外的电量和流量，还很容易被系统后台机制杀死，同步可靠性非常低。
• Firebase Cloud Messaging（FCM）方案
  • 是当前场景下的优先推荐方案，完全适配你的需求。
  • 优势十分突出：服务端仅需要在「新票务新增」「票务达标关闭」两个事件触发时，向目标用户群推送通知即可，单日的推送请求量级最多仅为数百次，服务端几乎没有负载压力；安卓端不需要额外驻留自定义服务，功耗、流量消耗都极低，推送到达率有官方保障。
  • 仅需注意：如果你的目标用户以国内用户为主，部分国产ROM对FCM的后台推送有限制，可以后续补充接入对应厂商的系统推送通道做兼容；如果是面向海外用户，直接使用FCM即可满足需求。
• 其他可行方案
  • WebSocket长连接方案：如果不想依赖第三方推送服务，可以选择在安卓端和服务端之间建立持久WebSocket连接，事件触发时由服务端直接通过长连接下发同步通知。该方案可控性更高，不需要依赖第三方服务，但是需要自行处理长连接保活、断连重连、心跳校验等逻辑，开发成本比FCM略高，3000用户的长连接规模对普通配置的单台服务器来说完全没有压力。
  • 长间隔轮询兜底方案：可以将轮询间隔拉长到1~5分钟，仅作为推送/长连接方案的兜底补充，避免推送漏发导致的两端数据不一致。该场景下单日请求量仅为不到100万次，服务端完全可以轻松承载。

新手学习建议 #

首次实现相关功能可以先从FCM入手，官方开发文档的步骤非常清晰，按照指引即可快速跑通基础推送流程。如果面向国内市场，再根据目标用户的设备分布，逐步接入对应厂商的推送通道做兼容即可。

内容的提问来源于stack exchange，提问作者Dmitry Kurowsky