静态链表在优化中的应用.pdfVIP

静态链表在优化中的应用 静态链表的基本结构网上到处都是，大学课本里也很详细，不熟悉的同学请看下面我大学时课件抓图， 在此感谢楼老师。（说实话，大学那么多课，只有您的课仔细听过 ） 数据结构课程设计帮同学做过好几个静态链表的题，没想到毕业两年多来用这东西做过好几个优化， 分别如下： 1、DES 密钥缓存 金融交易安全类项目，存储的就是普通的Key-Value 结构，Key 是密钥名，Value 是DES 密钥，都为 短字符串，原来的方案是开个共享内存做数组，按Key 排序，折半查找还算说的过去，但插入和删除就是 O(n)了，所以在业务高峰时期就悲剧了…… 有些同学可能想“为什么要用共享内存？直接用一个STL map/unordered_map 就直接搞定。为什么不 用现有的memcached/redis……解决方案……”，记得后来和coolshell 的陈皓老师email 交流过，他也有 这类疑问；原因大概有这样几个：  是一个完完全全的纯C 项目。  有历史原因，必须沿用原来的Sys V 共享内存方式；另一方面最初用共享内存也是为防止程序挂掉后 业务数据不丢失。  做过银行电信的同学可能知道，银行不可能信任memcached/redis……，他们更多的是认小型机 /AIX/DB2/Oracle……甚至MySQL 都信不过，所以更不可能采用时下互联网流行的解决方案。 故只能在原来的方案上优化，而且设想的是要将密钥数据和所用查询机制的索引之类的东西分开存放； 大概如下： 1、 开2 块共享内存A、B；A 用来存放索引信息，B 用来存放实际的密钥数据。 2、 A 中就是普通的散列表，线性再散列法，存储密钥名对应的密钥在B 中的静态链表中的下标值。 3、 共享内存内不可能用传统的链表结构，所以在B 中使用双向静态链表存储密钥数据。 A 中散列表存的是数据在B 中静态链表中的下标值为关键，实现O(1)访问；如果不把密钥数据和索引 数据分开存放，就不用B 共享内存，直接用A 存储密钥即可。 1 这也算是我第一次将静态链表使用于应用中。课本中告诉我们静态链表一般用于没有指针的如 BASIC/FORTRAN 之类的语言，它和普通链表一样，插入删除不需要移动元素，无法随机存储等等…… 什么？ 无法随机访问？如果我们直接拿数据在静态链表中的下标不就可以直接访问了么？ 2、通信层和应用层映射 有些同学会在通信层接受连接后生成一个类似可读的client_id之类的值作为通信层和应用层之间交 互的映射，映射的方法是通过查hash map 实现，但是这里的查询是非常频繁的，哪怕是hash map 也会带 来一定的效率损耗。 熟悉Reactor 机制实现的同学知道底层通信可以使用一个max_fd 大小的数组作为fd 到 Event_Handler 结构的映射，在C++中的写法如下: std::vectorEvent_Handler * fd_map(max_fd(), (Event_Handler *)0); epoll_wait 返回的fd 集合可以直接以O(1)的效率映射到对应的Event_Handler，fd 和client_id 都 存在Event_Handler 中。 好，现在解决了fdEvent_Handlerclient_id 的映射，那反过来client_idEvent_Handlerfd 呢？ 简单的生成client_id 的方法可能是一个int 从0 递增，通过client_id 去hash map 查询 Event_Handler；可能为如下结构： std::unordered_mapint, Event_Handler * fd_client_id_map (max_fd()); 但即便是hash map 也比数组下标访问有一定效率损失；说道这里可能大家也知道了，如果以静态链 表存放Event_Handler *，client_id 就是Event_Handler *在一个静态链表中的下标，那么就可以直接通 过下标取得Event_Handler *，也就以O(1)打通了client_idEvent_Handlerfd 这条路。 Event_Handler *存储在一个静态链表中，它所在的下标作为其client_id，这个静态链表用STL vector 实现，可做成动态增