根据键结构的布局方式，我建议对zincr命令进行流水线处理。您有一个简单的“提交”触发器- 请求。如果您要遍历您的参数并为每个键添加锌，那么在请求结束时传递execute命令将非常快。我已经实现了一个像您描述为cgi和Django应用程序的系统。我按照以下步骤建立了一个关键结构：
YYYY-MM-DD：HH：MM->排序集
并且能够通过单个过程以每秒150000-200000的增量在Redis端进行处理，这对于您所描述的场景应该足够了。这种密钥结构使我可以基于时间窗口获取数据。我还为密钥添加了一个到期时间，以避免编写数据库清理过程。然后，我进行了一项cronjob，它将使用上述键模式的变体将操作设置为每小时，每天和每周“汇总”统计信息。我提出这些想法是因为它们是您可以利用Redis的内置功能来简化报告方的方式。还有其他方法可以执行此操作，但是这种模式似乎效果很好。
正如eyossi指出的那样，对于同时进行写入和读取的系统，全局锁定可能是一个真正的问题。如果您将其编写为实时系统，则并发性很可能是一个问题。如果它是“一天结束”日志解析系统，那么除非您在输入时运行解析器的多个实例或报告，否则它不太可能触发争用。关于保持快速读取，在Redis中，我将考虑建立一个从主实例派生的只读Redis实例。如果将其放在运行报告的服务器上并指向报告过程，则生成报告应该很快。
根据可用内存，数据集大小以及是否在Redis实例中存储任何其他类型的数据，您可能会考虑运行32位Redis服务器以降低内存使用量。32b实例应该能够在一小部分内存中保留大量此类数据，但是如果运行正常的64位Redis不会占用太多内存，则可以随意使用它。与往常一样，测试您自己的使用模式以进行验证
602392714
清零编程群