将消息从实时聊天保存到MySQL或Dynmodb中的策略

Question

我正在编写一个实时聊天应用程序，该应用程序将被许多用户使用。我正在考虑使用Amazon的ElasticCache Redis管理我们的PUB / SUB和最新消息缓存。

我看到的唯一问题是有关将这些实时消息保存到数据库以供将来使用。关于可以使用哪些策略将这些消息从Elastic Cache保存到数据库中的任何建议。

是RDS首选还是应该使用NoSQL（例如Dynmodb）存储这些消息？我应该创建一个队列来存储来自缓存的这些消息还是实时保存它们也可以。

谢谢

Answer 1

此处的适当策略在很大程度上取决于数量，预期的查询模式和消息保留。假设您要支持永久保留并从那里迁移：

大型RDS实例可以轻松地每秒处理数千次写入，而读取从属节点将帮助有效地平衡读取负载。特别是Aurora对此非常有用，我建议您仔细研究一下，并将其与传统RDS进行比较。而且，由于不同的锁定策略更有利于整体吞吐量，因此用于底层机制的Postgres将比MySQL支持的实例具有更高的写入吞吐量。如果您的实时消息是通过pubsub系统中继的，则实际上不需要在redis中额外的“最新消息”缓存，并且如果卷的数量足够低，则可以由已读取的从属服务器或由主服务器处理。这也将取决于聊天系统的类型。一对一聊天与基于房间的聊天或全局聊天将具有明显不同的阅读特征。

SQL解决方案的最大问题将是消息随着时间的流逝，并且如果您的消息数达到10亿以上，则能够始终有效地显示所有消息。基于不同的聊天类型，这可能是可分割的，但是像NoSQL解决方案之类的东西可能更有意义。当然，他们并非没有警告。它们将更横向地扩展，并且能够处理每秒更高的每秒写入或消息数的增长，并且具有基于数据模型的更自然的分片能力，但是数据模型将更加严格且难以查询以某些方式。

话虽如此，为简单起见，如果您不打算通过十亿条消息标记或每秒几千条消息，从SQL开始可能会提供一些简单性和灵活性。从专业知识较少的NoSQL数据库开始，比起遇到意外警告或开发问题，更容易使您陷入麻烦。

就您实际使用的写入模式而言，我认为首先写入数据库，然后写入缓存，并在成功写入之后发布到pubsub主题，有助于确保历史一致性。那也取决于您想要做出的保证。如果实时交付比历史准确性更重要，则可能适用相反的顺序。但是，如果选择一个SQL数据库，则意味着您的吞吐量直接与单个SQL主数据库的写吞吐量相关联。Postgres最近引入了双向复制的可能性，它可以为您提供多主机支持，但是它有很多警告，而且我不认为RDS会支持它。

对于pub-sub redis可能就足够了，但这又取决于规模。在更高端，更分散和容错的东西可能更合适。例如，AWS 通过SNS拥有专用的pubsub服务。这将带来减轻管理的好处，并且就消息吞吐量而言，可能还有更多的增长空间。Redis很棒而且非常快，但是它也将是一个单点故障，受内存限制，并且最终会绑定到单个线程。但是，如果您是从低端开始的，并且不打算达到很高的吞吐量，那么Redis就足够了。

重要提示：但是，关于将redis用于pubsub的一件事是，redis不应暴露于外部连接。这是一个潜在的大规模安全性问题，因此，如果您的网络外部的客户端直接连接（例如，我认为您希望使用聊天系统），那么Redis将是一个糟糕的选择。应始终阻止外部连接。总是。

TL; DR：-对于较低的规模，RDS可能会在相当长的一段时间内使用传统的主从设置来满足您的需求，但是Dynamo或Cassandra之类的NoSQL解决方案将更好地满足长期增长，令人难以置信的高吞吐量或大量数据的需求体积。-由于安全方面的考虑，Redis不太可能是PUBSUB的理想选择，并且对于缓存层可能不是必需的，但是其他pubsub技术可能足以用于实时消息传递。