对于在我们平台上为大量用户提供的类似ELO分数的计算问题，我很难下定决心。
例如。对于大量用户中的每个用户，基于可变数量的“完成的事情”，一个复杂的公式将为每个用户提供类似匹配原则的得分。
对于我们来说，它取决于发布的帖子数量，接受的连接，发送的消息，一个月内的会话数量，..其他已完成的事情等。
我有两个想法可以做到这一点：
我对这两个方面的担忧：
实时：对于用户执行的每个操作，查询和计算都是过大的。如果说有500个用户处于活动状态，他们所有人都在执行操作，那么我认为数据库将很难。他们还会运行一个脚本来重新计算不活跃用户的得分（以降低他们的得分）
每周一次：如果我们有5.000个用户（对于我们的第一阶段），那么这将导致运行计算公式5.000次，可能会花费很长时间，并且当更多的用户加入时，时间会增加
在大约12个变量的整个公式中，单个变量的计算查询大部分是一个简单的“ COUNT FROM table”，但是有些则类似于对“我的连接的所有连接”进行计数，这需要进行一些连接。 / p>
为此，我首先将每个操作“记录”到表中，只需将计数器值添加到每个操作中就可以增加/减少它们，并使用这些值运行公式（每周记录一次）。此方法有效，但不能应用于每个变量（例如连接的连接）。
注意：我们的服务器端基于PHP和MySQL。
我们也在运行Redis，但是我不确定这是否可以改善这些点点滴滴。
如果需要，我们可以选择将数据导出/推送到其他服务器/数据库。
我的主要示例是应用程序“ Tinder”，该应用程序使用类似排序的算法进行匹配（也许数据变量不太复杂，因为它们未使用您可以加入的组和社区）
我想知道他们是否在每次滑动，每次设置更改时都实时运行该脚本，或者它们是否像脚本一样每次连续为一小批用户连续运行。
所有内容归结于此。记住这一点，例如有一会儿我们有50.000个用户，这是最有效的/非数据库表锁定方式？
答案 0 :(得分：0)
我将如何处理此问题：
如果您现在有5000个用户，请确保它在5000个用户中运行良好。您不会在一夜之间增长到50.000，因此请随着问题的变化进行调整并进行投资。您可能会对性能问题感到惊讶。
测量是关键。如果您真的想立即支持5万用户，请进行仿真和测量。