您的位置:首页 > 其它

路由查找算法优化心得

2010-04-28 19:57 344 查看
项目代码中有一个基础类库,用于解析client到server的路由配置文件,同时管理长连接。路由配置文件格式大致如下所示:

<info mod="1000">

<routetable>

<route begin=0 end=499 ip="192.168.1.100" port="1800" />
<route begin=500 end=999 ip="192.168.1.101" port="1800" />

<routetable/>


大概含义表示,路由算法是使用用户id%1000,然后看落到[begin, end]的对应区间,找到对应的ip和port即是对应的server信息。

【当前方案】

类库把路由信息和长连接对象保存在vector中,每一条route记录对应vector中一个结点,那上面的配置在vector共保存两条记录。

记录对应的结构体如下所示:

struct stRouteNode{
int modid;
int begin;
int end;
string ip;
int port;
CServer obj;
};


类库初始化时,每读到一条route记录,就初始化一个stRouteNode对象,建立长连接并push_back到vector中。

当上层请求一个uin对应的server时,首先根据uin%1000得到modid,再逐个和vector中的对象进行比较,看是否在对应的区间中。

【改进方案】

优化前的方案缺点十分明显,那就是顺序查找,并且每次查找要进行2次比较,最坏的效率是2o(n),改进方案有很多,我这里采用的方案是使用空间换时间的方式,底层存储仍然使用vector,但是查找使用下标直接索引的方法,以上面的路由配置方案为例,vector中保存1000条记录,其中0-499指向同一个server对象,这样即不会建立重复的长连接,又可以保证查找时o(1)的效率。这样记录对象的结构体调整如下:

struct stRouteNode{
string ip;
int port;
CServer *obj;
};


【总结】

改进后效率提升了很多,性能测试,在vector中记录数到3000个的情况下,优化后方案的耗时约为优化前的1%,性能提升十分明显,由此可见算法优化对应系统性能提升的巨大影响,同时也给大家一点建议,一定要注意避免顺序查找,尽可能使用下标索引的方案,现阶段机器在的内存与cpu相比而言,cpu资源更加宝贵,而内存一般不太容易成为瓶颈(缓存或文件系统类除外),对于大的配置还可以使用文件映射的方式,因此,建议大家对于配置文件可以采用下标直接索引的方式,即使是使用map也不太推荐。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: