二面还是电面

前段去了趟丽江，好久不更新了。

说来也巧，到达丽江第一天，正好是周五，中午正在古城的KFC吃东西，结果接到一个010开头的电话，通知我周一电话二面，好吧。旅行的第一天额亲。

木有办法，周六、周日、周一都屯在了屋里，准备二面。由于第一面是问的项目，猜想二面是不是问点常规的，算法数据结构神马的。结果，二面问的还是项目。搞不清某度的套路了。连内推的师姐也大呼诡异。

入正题了：

第一个，问做的那个教学DBMS怎么实现表的存储的？由于设计比较简单，所有的表，单个存储为.tbl文件。字段设为定长。有基本的tableinfo.tbl, indexinfo.tbl, viewinfo.tbl，这三个表作为数据字典。在用户创建表内，定长字段存储数据。

接着，问如果有给表加所有，那加的索引怎么存？表名-index.tbl。也看做一个表。由于设计的局限，不考虑复杂的情况，只支持给一个表加一个索引。在索引表里面，两列<索引列内容，原数据offset>。

又问，对于select * from student where sid='1001'，这条语句处理的时候，系统怎么去实现，sid已经创建了索引：先从索引表里面找索引列，即sid='1001'的记录，这里要扫描整个索引表了。同时，就得到了对应记录的原数据的offset。然后，从数据表里面，直接通过偏移，读取数据。

然后，又问了个网络的，tcp和udp的区别。这个好久不接触了，依稀记得。tcp是有保证的，在传数据之前，需要三次握手，保证传输的数据一定送达。udp是无保证的，只负责传，能否收到不保证。所以tcp慢一些，udp快一些。根据不同的应用，对速度，对传输可靠性的不同需求，作出合适的选择。

接下来，问了个文件删除的问题，用delete删除文件后，能否再恢复？文件系统，维护了一个目录表，所有文件系统的存储信息，首先是写到目录表里面，然后在目录表中保存的指定位置，存储实际的数据。删除文件的时候，出于效率的考虑，只是从目录表中，将对应表项删除，实际存储位置的数据并未擦除，通过软件可以恢复。

又问了个关于进程的问题，具体记不清了，大概是说，有没有可能两个进程会同时访问同一块物理内存的空间。开始，我说不行，操作系统课上，罡哥说过，每个进程，从自己的角度看来，都有慢慢的4g的内存可以用，进程间互相隔离的。后来说着觉得不对，有可能会访问到同一物理内存。可惜，没说出个合理的技术方面的解释，只是举了个暗黑2的例子：在游戏运行中，可有跳出来，用外挂，修改武器的属性，显然是外挂的进程，修改了游戏进程的某一块内存的数据。额，现在想来，这个回答的不好。。。

后来又问我对linux的文件系统了解多少？一下子真的一点都想不起来了。。。悲剧个。。。

接着，哥们拐着玩，问了个存储空间的碎片问题，问有哪些策略，以及怎么处理这些碎片？这个依稀记得一些，有最早遇到优先的，只要找到能存下的就停止；有最适应优先的，尽可能找和文件大小相匹配的；有最少浪费优先的，找一个写入文件后，浪费最少的。又问怎么样减少这些碎片，我说定期空间紧缩，移动文件。哥们说，服务器不可能停下来让你去做这些文件移动的，而且大数据紧缩一次，耗费太大。又说使用什么样的策略，在新文件写入的时候，尽可能低在写入之处，减少碎片的产生？我当时说，给定大小，放入若干不定大小的文件，使浪费最少，这是个背包问题额，用动态规划吧。

哥们说，用一些简单的办法。我说，维护一个链表，按照碎片从小到大把这些碎片串起来。有新文件写入的时候，根据新文件大小，从头一次匹配，直到找到合适的，这样应该是浪费最少的。哥们又问，说链表一次遍历，还是太慢。而且，一次写入后，链表要更新，怎么办，耗费大。我说，那就空间换时间，开一个数组，维护这些信息。当时一些想到这样一个策略：数组维护一个升序的碎片信息a0-an，在一开始，生成一个随机数r1，作为索引，直线碎片信息数组，如果指向的碎片比新文件小，就从r1到an中间随机抽一个再试，否则就从a0到r1再次随机抽取。这是一个带随机的2分查找。然后，哥们问，说要这样2分多少次呢？会不会次数太多，我说，可以指定一个阈值，比如4次、10次，应该能够找到一个比较好的结果，不一定是最优的，兼顾效率的情况下，好很多就ok了。哥们说，数组也有一些问题，数组信息，也是要更新的， 而且可能更麻烦。。。我说，那折中下吧，先维护一个链表，然后维护一个小于链表长度的数组，作为链表的影子，按照类似lru的策略，定期更新影子数组。新文件写入的时候，再影子数组上做随机二分。

上面这个，问了好久。。。后来哥们说这个就这样吧。

最后问了一个应用程序的问题。有些应用程序，只允许运行一个实例。开了一个，再开一个的时候，会警告说，程序正在运行，问这样怎么实现。我开始说，用配置文件，程序启动时，先读取配置文件，通过配置文件指定项的置位、复位来实现开关功能。哥们说，如果应用程序奔溃的话，没有及时设置配置文件，这种方法就不行了。我说，那用加锁的办法吧。程序中设置一个桩变量，启动后边加锁，当程序关闭，或者程序奔溃的时候，会自动将锁释放。哥们问，这个加锁，是程序自己的，还是操作系统提供的。我说，是操作系统的，自己没办法做。哥们说，确实操作系统能提供这样的加锁机制，也是这么实现的。

面了一个多小时，有些可能漏掉了，就这些了。哥们说，二面后过了就通知三面。。。

这都多久了，担心啊。。。bless