我需要为多个用户计算多个项目的“分数”。每个用户都有许多独特的分数，计算可能是时间/处理器密集型的。 （缓慢不在数据库端）。为了解决这个问题，我广泛使用了 memcached。如果没有 memcache，某些页面将需要 10 秒才能加载！ Memcache 似乎运行良好，因为分数是非常小的信息，但需要一段时间来计算。我实际上将密钥设置为永不过期，然后在分数发生变化的情况下将其删除。
我正在进入这个产品的新阶段，并且正在考虑重新设计整个产品。似乎有一种方法可以迭代计算值，然后将它们存储在本地字段中。它会和现在发生的事情有点相似，只是值更新会更快，缓存会在真实的数据库中，管理它会多一点工作（我想我还是会在上面使用 memcache不过）。
如果重要的话，一切都在 python/django 中。
打算像这种坏习惯一样使用缓存吗？可以吗？为什么？我应该尝试重新架构东西吗？
【问题讨论】：
标签： performance architecture memcached scalability
如果它没有坏...不要修复它;^）看来你的方法是有效的，所以我会说坚持下去。您可能会查看 memcachedb（或 tokyo cabinet），它是 memcache 的持久版本。这样，当 memcache 机器崩溃并重新启动时，它不必重新计算所有值。
【讨论】：
您在这里应用了几种架构模式，而且每种架构模式肯定都有一席之地。这里没有足够的信息让我评估您当前的解决方案是否需要重新架构，或者您的想法是否可行。在我看来，随着您对用户需求的了解不断加深，您可能想要改进一些东西。
与往常一样，原型设计、测量性能、考虑复杂性和性能之间的权衡 - 您不需要尽可能快，只要足够快即可。
各种形式的缓存通常是获得良好性能的关键。这里的问题是坚持计算的、经过计算的值是否有好处。如果它们随着时间的推移保持稳定，那么这通常是一种有效的策略。是在数据库模式中保留缓存还是为它们腾出空间可能取决于访问模式。我有各种查询路径，那么精心设计的数据库方案可能是合适的。
【讨论】：
与其使用 memcached，不如尝试将计算出的分数与其他数据存储在同一位置；这可能更简单，需要更少的盒子。
Memcached 不一定能解决所有问题；它适用于需要非常高读取规模的系统。听起来在你的情况下，它不需要，它只需要更高效一点。
【讨论】：