Redis +“真相之源”数据库一致性

Question

我正在构建一个分析工具，但在基于时间序列的指标方面遇到了一些性能问题。我一直在尝试使用 Redis + bitmapist，这使我能够在数据库写入时急切地准备指标，并且对性能非常满意。

但是，我对如何确保我的数据库和 Redis 保持同步感到有些困惑。我的数据库是存储所有事件数据的“真实来源”，但用户仪表板将依赖 Redis 来显示指标。

我是否应该定期重新构建我的 Redis 指标以确保我的数据库和 Redis 之间没有差异？ （如：事件发生时，写入DB，写入Redis失败）

如果我的 Redis 服务器出现故障，重新处理所有事件并重建指标将需要很长时间。即使特定指标的数据库查询逻辑与 Redis 查询逻辑完全不同，我的仪表板是否应该将数据库作为备份计划进行查询？

Answer 1

本质上你在这里指的是保持缓存一致性的问题。

首先，您需要确定仪表板的陈旧程度。一旦你有了它，就用它作为你的限制，并为存储在 Redis 中的数据设置一个过期时间。请注意，您如何做到这一点与您选择在 Redis 中存储结果的方式紧密相关。

接下来让您的仪表板执行“获取或存储”序列。这意味着您首先查询 Redis 设置以获取数据，如果找到，则显示它。如果未找到，则查询源数据库，将结果存储在 Redis 中，设置适当的过期时间并显示它。对于重新启动或重新启动缓存预热，让 Redis 持久保存到磁盘（默认情况下会这样做），并且您不会在重新启动时丢失条目 - 当然过期的条目除外。

此过程将最大限度地降低数据过时的风险，同时根据请求提供数据的直接更新。另一种选择是将存储在原始数据库中的事件也存储在 Redis 中。但是，该选项将意味着完全复制数据，而不是仅保留 Redis 仪表板中的“热”或选择项以提高仪表板性能。

Answer 2

应使用可靠的服务总线在 Redis 上写入，以便可以根据需要重试多次以执行写入：

• Azure Service Bus。
• RabbitMQ

这样，您的系统将更加可靠，因为消息队列或服务总线可以提供设置来定义消息可以不成功地出列 1、2 或 1K 次。如果由于 Redis 宕机而将指标写入 Redis 失败，则没有问题：异步进程将尝试再次写入 Redis，依此类推。

您的 Redis 数据库可能会在几秒钟、几分钟甚至一小时内保持不同步，但您知道，一旦临时问题得到解决，您的系统就会尝试恢复其正常状态。

另一方面，从 Redis 3.0 开始，您就有了 Redis Cluster，这是 Redis 的内置分片方法。也就是说，您可以将数据分区到两个或多个 Redis 服务器中。这对于避免单台服务器停机可能影响对您客户的整个服务非常重要。

另外，Redis 有数据persistency to disk。

我相信我已经提供了足够多的提示和工具来实现您应该能够可靠地同步您的最终存储与基于 Redis 的 fast 存储。