【发布时间】：2017-06-07 15:10:09
【问题描述】：
假设我们希望有一个按点范围划分的有状态服务， 目标是按点对每个分区进行排序（通常，我们希望在分区之间划分排序任务）。我们希望用户在分区之间分布良好。 理想的情况是在用户积分发生变化时更改每个分区的范围。但这是不可能的，因为我们不能动态改变分区的范围。
一个想法是有一个单一的有状态服务来管理点的范围，并使用地图告诉其他服务应该为特定点请求哪个分区。但这可能意味着对这项新服务的大量访问，这可能会使服务过载。
有没有更好的想法？
编辑 1：
目标 1：按排序块（分区）对排名进行排序，然后由另一个服务聚合。
目标 2：提供给定分数的临时位置。
【问题讨论】：
-
所以这就像在游戏中获得的积分一样？您想要单个分区中的最高点吗？我不确定这是否会奏效，因为最高点的用户也可能是最高的用户，因此将它们组合在一起在负载平衡方面似乎适得其反
-
@EricLizotte 是的，这就像在游戏中获得的积分。高分不是直接从这项服务获得的。完整的得分表（不仅是排名靠前的用户）将使用此分区服务计算，但以另一种方式提供。分区服务将仅用于 (1) 保存更新的用户积分和 (2) 获取特定积分数量的临时位置。
-
我知道您现在得到了什么，您希望分区按分数范围划分，以便更容易查询。将分数持久化到一个 sql 表中会更有意义，该表将用户 id + score 作为唯一同时索引的列，并让服务器查询 + 更新它。分区的主要用途是负载分散和扩展，而不是分组。我看不到让分区基于分数有任何架构上的好处。尝试按分数进行分区实际上会降低性能，因为用户将永远从一个分区移动到另一个分区。
-
另一种方式，如果你决定这样做，那就是预先确定你的分区数量，而不是让它们按实际分数#，而是按最高分数的百分比。因此，如果有 10 个分区，最高分将达到 91%，90% 达到 81，等等。将用户分区移动到分区的计算成本会很高。
-
否则，您只能真正采用您认为合理的分数分组，使您的初始设置具有那么宽的分区带，并让分数更新流经另一个服务，该服务将添加下一个更高的一组分数作为一个新的分区。不过，我仍然认为这是一种反分区模式。
标签： azure azure-service-fabric