APP做用户排队功能，是拉取还是推送？

APP功能概述：用户打开APP有一个领取排队号的功能，领取到号后进入等待，等待的过程会显示你排到第几名，大概等待多久，用户会实时的看到排队的信息变化。有点像去银行排队办业务。

遇到的问题：我目前采用的是APP通过定时轮询请求服务端接口，如果APP突然断网，就会卡住队伍，后面的人排不到前面来。我这边写了一个计划任务在后台清理这些异常的用户，个人感觉不是十分理想，请教各位大牛，如果采取推送的方式是否比客户端轮询更有优势？（排队的人数肯定不会超过1000),如果采用推送是用计划任务还是通过某个用户服务完毕或刚加入队伍的用户进行触发推送，或者说有没有其他的方式？

目前还有一种情况就是如果采用APP轮询请求接口，一旦APP进入后台，也就是按了home键之类的，就不会继续请求我的接口，也会被后台程序认为是异常用户清除掉了。

回复内容：

APP功能概述：用户打开APP有一个领取排队号的功能，领取到号后进入等待，等待的过程会显示你排到第几名，大概等待多久，用户会实时的看到排队的信息变化。有点像去银行排队办业务。

遇到的问题：我目前采用的是APP通过定时轮询请求服务端接口，如果APP突然断网，就会卡住队伍，后面的人排不到前面来。我这边写了一个计划任务在后台清理这些异常的用户，个人感觉不是十分理想，请教各位大牛，如果采取推送的方式是否比客户端轮询更有优势？（排队的人数肯定不会超过1000),如果采用推送是用计划任务还是通过某个用户服务完毕或刚加入队伍的用户进行触发推送，或者说有没有其他的方式？

目前还有一种情况就是如果采用APP轮询请求接口，一旦APP进入后台，也就是按了home键之类的，就不会继续请求我的接口，也会被后台程序认为是异常用户清除掉了。

我个人觉得是这样哈，看你业务需求里客户对即时性要求高不高；如果像滴滴打车那样，要一直看见变化的，可以轮询+推送；如果要求不高，可以只推送。感觉推送比轮询重要哈。

主要是不知道这个用户的排队策略；如果是他一进入后台，就视为自动放弃，那么轮询还可以；否则的话，等排到他了他不知道，你把他清掉了，这属于正确性的问题呀~ 还不是系统设计的问题。

我个人觉得一个常见的排队策略是，客户端发一个请求排到队列后面；轮到一个用户，发个推送给他，要求他确认；如果超时不确认，就轮到下一个人。如果用户需要能实时看见排队情况，就加个轮询定时更新；否则就手动更新或者进入界面的时候更新一下就行了。

不知道你们的业务需求是什么~ 系统设计应该贴合业务需求哈。

对即时性要求较高的话，可以采用轮询+推送的方式，优化轮询的方案可以采用'WebSocket'。
如果上面的方式还不能满足需求，建议采用'Socket'通知客户端刷新。
无论是'WebSocket'还是'Socket'，都只完成通知刷新的任务，获取数据的方式还是保持Http方式，这样可以在现有基础上降低开发量。

建议推送，轮询太耗服务器资源！

轮询+推送 吧~

推送估计你是用第三方的吧？所以不能太依赖第三方推送。android那么多机子，推送进程被杀毒软件什么的杀死，就扑街了....