所以我正在考虑使用Google的Pub / Sub服务进行排队,但通过反复试验,我得出结论,我不知道它对实际应用程序有什么好处。
谷歌说这是实时可靠的消息传递和流媒体全球服务 数据
但它的工作方式对我来说真的很奇怪。它可以保存最长7天的订阅消息,如果订阅者重新订阅它将获得过去7天内的所有消息,即使它已经收到它们,也很可能会将已发送的消息再次发送给同一个已经收到它们的订阅者。也没有FIFO。
所以我真的不明白应该如何使用这项服务,如果它保证的唯一的事情是消息将至少一次传递给任何用户。这不能用于幂等操作,每个订阅者必须存储有关已经被激活的所有消息的信息,因此它不会多次处理消息等等......
答案 0 :(得分:2)
Google Cloud Pub / Sub有许多不同的应用程序,其中解耦系统需要发送和接收消息。 overview page提供了许多用例,包括平衡工作负载,日志记录和事件通知。确实,Google Cloud Pub / Sub目前不提供任何FIFO保证,并且可以重新传递消息。
然而,交付保证“至少一次”的事实不应被视为意味着当订户重新订阅时重新传递确认消息。重新发送已确认的消息是一种罕见的事件。这通常仅在由于网络问题,机器故障或某些其他异常情况而导致ack无法一直返回服务时才会发生。虽然这意味着应用程序确实需要能够处理这种情况,但这并不意味着它会经常发生。
对于不同的应用程序,邮件重新传递会发生的情况可能会有所不同。在概述页面中提到的诸如高速缓存失效的情况下,获取两个事件以使高速缓存中的条目无效仅意味着该值必须被重新加载额外的时间,因此不存在正确性问题。
在其他情况下,例如跟踪按钮点击或网站上的其他事件以进行日志记录或统计信息,不频繁的重新启动邮件重新传递可能不会影响以显着方式收集的信息,因此不必费心检查事件是否重复很好。
如果需要确保消息只被处理一次,那么必须在订户端进行某种跟踪以确保这种情况。可能是订户已经访问并更新底层数据库以响应消息,并且可以通过该存储检测重复事件。