1.缘起:
假设我们的会员管理系统有一个排行榜的功能,需要每隔一段时间就对系统中的所有会员(假设会员数有100万)的积分进行排序,然后对其中的前100名进行某些奖励。
这是一个典型的TopN算法――对巨大数量的对象进行排序,然后只需要取出最Top的前N名(N比对象总数小很多),作为排行榜的数据。
解决这样的问题,我们要注意一点,如果我们每次都对所有的对象进行完全排序,那无疑效率非常低下,而且非常不划算。因为我们只需要前N名,而不是所有对象的先后顺序。
我设计了ESBasic.ObjectManagement.TopNOrderedContainer来解决排行榜算法,TopNOrderedContainer只将资源花费在真正需要计算的地方,另外,TopNOrderedContainer支持在运行过程中,将不断新产生的对象加入到排行榜。
2.适用场合:
TopNOrderedContainer用于对巨大数量的对象进行TopN排序。其适用场合有如下特点:
(1)需要被排序的对象的数量非常巨大(如几百万、甚至几千万)。
(2)对系统有价值的排序结果只有前N名。
(3)N远小于总的对象数量。
3.设计思想与实现
TopNOrderedContainer的排行榜算法的思路是这样的,使用一个长度为N的数组,来存放最Top的N个对象,越Top的对象其在数组中的Index就越小。这样,每次加入一个对象时:
(1)首先,判断当前的排行榜的最后一名是否比新加入的对象更Top,如果是则丢弃它。
(2)其次,看新加入的对象是否比当前排行榜的第一名更Top,如果是,则新的对象应该被放置在index为0的位置。
(3)否则,就采用二分查找算法为新加入的对象找到合适的位置,并调整排行榜中位于插入位置后面的对象的位置。
当然,在具体实现的源码中,我们看到了还有一些边界条件的处理这里没描述出来。
TopNOrderedContainer的类图如下所示:
我们看到TopNOrderedContainer有一个泛型参数TObj,它是进行排序的对象的类型。TObj的泛型约束表明TObj必须实现IOrdered接口。IOrdered接口定义如下:
/// IOrdered 参与排行榜排序的对象必须实现的接口。
/// </summary>
/// <typeparam name="TOrderedObj"> 参与排行榜排序的对象的类型 </typeparam>
public interface IOrdered < TOrderedObj >
{
bool IsTopThan( TOrderedObj other);
}
关于这个接口要注意两点:
第一,该接口的唯一方法的名字为什么不是类似IsGreaterThan、IsSmallerThan等,而是IsTopThan?因为不同的应用有不同的需求,有的可能是要选择前N个最大的,有的是要选择前N个最小的,甚至有的可能选择前N个最著名的,等等。而IsTopThan可以覆盖所有这些情况,反正都是最Top的N个嘛。
第二,IOrdered接口之所以使用泛型参数TOrderedObj,是为了避免派生类在实现IsTopThan方法时,需要将参数other的类型进行向下转换。
现在我们在回到TopNOrderedContainer,关于其实现要注意以下几点:
(1)排行榜容器可以在多线程的环境中使用。TopNOrderedContainer使用SmartRWLocker来对Add方法进行同步,之所以选择读写锁而不是简单的lock,是因为使排行榜容器在应对多读/少写的状况时能支持更大的并发。
(2)排行榜的生成采用的是插入排序策略,排序的具体算法是二分查找排序。Adjust方法的实现就是二分查找算法的体现。
(3)GetTopN方法用于返回当前的排行榜的拷贝。之所以返回一个拷贝,是因为外部对返回的数组进行任何操作都不会影响到TopNOrderedContainer的内部集合。
(4)为何不将TopN排序直接实现为一个静态方法?如果以静态的方式实现,那我们就没有办法继续动态的Add新的对象进入排行榜,即使要达到这样的目的,也就只有构造新的list,再次调用static GetTopN方法,如此就浪费了前面的计算成果。
4. 使用时的注意事项
如果要排序的对象的数量与TopN的N值的差距并不大,那么使用TopNOrderedContainer并不一定是最佳的选择,这时我们可以采用一些高效的完全排序算法对所有的对象进行排序,然后再取出前N名,可能速度会更快。
当然,我们也可以使用最大最小堆的算法来实现TopN的排序,也是完全可行的。
5.扩展
TopN排行榜容器TopNOrderedContainer暂时没有任何扩展。
注: ESBasic已经开源,点击这里下载源码。
ESBasic开源前言