Postgresql 与传统方法相比，用于实现消息传递系统（聊天）应用程序的Redis Streams

我正在实现一个聊天应用程序，它将支持一对一对话和小组对话

目前的方向是使用Redis Pub/Sub和PostgreSQL作为冷库，WebSocket作为传输工具。 每个用户在启动后（直到WebSocket+redis连接的时间戳之前）都会从postgresql获取历史记录，然后根据自己的用户id订阅频道

然而，每收到一条新消息就往返于DMBS听起来有点奇怪，但绝对是可行和合法的。 所以我决定研究其他方法。一种可能的方法是使用Kafka，完全不需要DBMS。 这听起来是可行的，而且有自己的一系列优势

但事实证明，街区里有一个新来的孩子——Redis Streams

据我所知，在这个特定的场景（聊天）中，它实际上与卡夫卡非常相似。 它有许多很好的特性，听起来很方便实现聊天系统

现在，我正试图了解流+磁盘持久性与Kafka与PostgreSQL+Redis pub/sub相比是否是明智的选择

考虑的主要方面有：

性能。Postgres和Kafka都在磁盘上运行，这意味着比redis的内存操作要慢。另一方面，显然，消息必须在任何时间和事件中都被持久化和可用，因此redis将被持久化到磁盘。这不会抵消整个内存性能增益吗？ 即使不是这样，在峰值负载和大数据库下的性能提升是否值得注意

内存/成本。有了redis，这两者紧密地联系在一起。作为一家小型初创企业，我们的工作重点是准备好应对突然出现的规模高峰（高达100万用户），但与此同时，成本应该最小化。 将数百万条消息存储在流中是否会导致内存开销过大，进而导致财务开销

恢复、可靠性和可用性、持久性。使用Postgres，即使是一个实例也可以处理巨大的流量负载，但它也可以提供主从设置和一致性。Redis能与之匹配吗？此外，有了DMBS，我可以确信数据会留在那里。用redis我能知道吗

缩放