在基于拉式通知与基于推送的通知之间选择折衷方案

时间:2019-05-21 13:00:52

标签: optimization push-notification architecture

我正在尝试解决以下问题。

我有许多N个客户端(该数目固定在50006000之间)和一个Server

此服务器具有本地cache个客户端,在其中存储每个客户端的一些数据。

public class Client
{
  public bool inGroup; 
}

此服务器定期查询一些数据库,并获取这些clients的列表,并更新其本地缓存。每当发现bool与数据库中的新数据之间存在差异(客户端数据只是cache)时,它都必须通知特定的客户端。

现在,我不知道应该实现基于PULL还是基于PUSH的解决方案。 如果选择PULL,则意味着每个客户端都将以固定间隔(约30分钟)询问服务器。那将意味着每个请求之间有30 / 6000 = 300 ms

如果选择基于PUSH的解决方案,则意味着服务器将按时间间隔询问数据库,并且仅推送到特定的客户端。现在的问题是每个客户端也都将成为服务器,因此该服务器还必须存储一个IP-s和Ports的表。

客户端的工作时间也相似,因此这也意味着在目标时间会有峰值,每个客户端将发送IPPORT供服务器检查服务器是否被修改。< / p>

还有其他中间解决方案吗?如果不是这样的话,一个好的解决方案正在考虑:

  • 客户数量相当稳定(5000-6000)
  • 客户端IPPORT通常不变。
  • 如果基于“拉”,则客户每30分钟查询一次服务器
  • 如果服务器基于推送,服务器将每1分钟查询一次数据库并推送到目标客户端

1 个答案:

答案 0 :(得分:1)

中间解决方案将使用long polling。客户端仍然发出轮询请求,如果有等待该客户端的通知,服务器将立即将其返回。但是,如果没有通知,请求将被阻止一段时间(例如两分钟)。如果在这段时间内有新的通知,则将解除客户端请求并返回新数据。否则,请求将在两分钟超时后返回空结果并发出新请求。

许多AWS SQS等高级服务都使用这种方法。