高级招聘题目

系统工程师：

题目1 很简单，某mysql数据库服务器A，出现mysql链接过多，导致前端web服务器无法打开数据库连接，现在，由你来解决这个问题。

题目1之问题1：你会以怎样的步骤来处理这个事情。请注意，步骤

题目1之问题2：如何分析这一问题，共有几种可能性，每种可能性的分析方式，判别标准是什么。

题目1之问题3：针对不同可能性，给出尽可能完整的解决途径。

不要告诉我您会修改mysql链接参数，如果您只想到这一条，不要来信了。

 

题目2： 某linux服务器平时负载很轻，cpu在10%-20%之间，但是每周都会有几天在不定时间突然跃升到100%，然后导致该服务器拒绝一切响应（包括ssh链接在内），无奈之下只能电话通过机房重启。

现在，负载飙升时无法连接ssh，暂时无法确认负载飙升原因，请给出你想到的处理步骤和解决思路。

不要告诉我您会设置一个24小时短信提醒，那是最基本基本的了。

题目3：某linux 服务器一直负载很轻，但是会突然拒绝正常的服务，此时仍然可以登录，仍然看到在线很轻的负载，请告诉我你分析排查的思路。

 

开发工程师：

1：概述题

都知道数据库使用索引能够提高效率，为什么，用自己的理解简单描述。

这道题是后面n多题的基础。

2：实战题

2.1 借了一道据说是腾讯面试的题目，和我当年在某公司商业分析部招聘的题目几乎一样，这道题很有代表性，拿出来说一下。

现在有个文件里有40亿条无重复整型数，为4字节无符号数，或者说，0 到 2的32次方。下面要求你写一个程序，列出所有 0 -2的32次方里，该文件不存在的整数。注意你的系统可用内存是有限的，也许只有1G或2G。如果这40亿条有重复，有什么区别？

2.2 一个很典型常见问题，对用户做地区判定，比如新浪首页，百度新闻首页，会根据不同地区用户显示当地的新闻；比如百度，谷歌搜索结果会根据不同用户地区显示不同广告。这个是基于用户ip地址的，ip地址区间是国际组织分配的，非常散列，并不是严谨的顺序， 现在已知有10万段的ip地址对应段。在高并发情况下，如何在用户访问的时候快速返回该用户对应的地区，给出你的方法和要点。注意，效率是考核的关键，如果一秒钟无法实现超过1000次不同ip的查询结果（单台双至强服务器只做该查询的情况下），效率肯定不行的。

2.3 又一个典型问题，目前政府有屏蔽词表，每个网站都要遵守，发帖的时候会自动替换屏蔽词；另一个场景是诸如新浪新闻等媒体往往有商业词表，发新闻的时候会自动建立关键词铆接。这个相当于一个简单的基于词典的分词系统，下面的问题就是，如何实现一个快速有效的，基于自定义词典精确匹配的分词系统，一是要满足每天几万篇，几十万篇文章发布的要求；另一个必须的要求是，当词库倍增扩展时（比如10万词），效率的影响不允许是线性降低的。

 

运营总监：
1： 请用你的理解点评zynga与facebook 的走势。

2： 请用你的理解讲述百度贴吧

3： 如果你只有3个员工，却要运营一个日活跃200万的社区，你怎么运营？如果是30个，怎么运营？你希望是3个还是30个，还是其他数字？

4： 社交游戏，网页游戏，小游戏，各列出你所认为前20个流行的，并给出各分类前三流行游戏的点评和趋势判断。

5： 白社会抢房女事件，按照你的理解简单点评。

6： 如果在资源有限的情况下，你来负责组建运营团队（游戏社区），你希望招聘什么背景的人，以及如何培养。

 

 

 

系统分析师：
caoz考核，一看意识，二看思路，三看方法

前言 ： 其实考试这种东西本身是不平等的，因为出题人肯定有优势，所以有些人水平比caoz高很多，答caoz的题目也只能得到七八十分而已，如果换过来出题，caoz可能及格都是问题，而且这些题目其实更适合面试进行，因为可以层层递进剖析问题，从一个大问题引申提出更多子问题，这是caoz面试常用的习惯，很多趾高气扬的人进来，灰头土脸的出去，当然，还是那句话，考核本身是不平等的。也许您答的和caoz期望的相差不少，但是不代表caoz比你水平高。

回过头来说，意识是第一位的

1:数据链接过多，这是最常见的问题，但是其实也是这里最重点的问题

子问题1，为什么提到步骤，很少有人告诉我，第一步是尽快临时恢复线上应用，这就是意识！

恢复线上应用有几种场景，最简单的是show processlist 然后kill掉阻塞的processlist，其次是重启数据库，如果数据库重启后又会快速堵塞，那么要尽快从前端代码中找到阻塞点，临时屏蔽掉某些导致阻塞的功能，以及增加同时链接参数，为了保证在你彻底解决这个问题的这段时间里，你的前面网页是可以顺利打开的。

这里存在一个小问题，如果是面试我会单独提出来，你怎么保证连接过多的情况下，后面还能看到show processlist，这里的窍门是，前段务必不要使用root连接数据库，这样mysql后端root仍然会多出一个进程来满足查询要求。 之前我跟工程师说这个问题，他们果然换了一个账号，一个不叫root但是权限是root的账号在前端连接数据库，害的我郁闷了n多天找不到阻塞点。

第二步是确认阻塞点和阻塞方向，为什么说阻塞方向，因为数据库的阻塞，并不一定都是数据库造成的，连带影响非常多，通过show processlist ，如果看到大量的Lock，那么其一是代码优化，其二是改造数据引擎，如果Lock不多，而执行中查询很多，其一是索引优化，其二是数据库参数优化，有人说会看慢查询，慢查询很重要，但是不够的，对于高并发来说，一个常见SQL执行0.1秒都是不可容忍的，通常这是索引不彻底造成的，比如简单来说 ，如果有个同城速配的常见SQL select * from users where sex='女' and area='厦门' order by lastlogin desc ，这么一个查询，你会怎么建立索引？我告诉你，三键复合索引！少一个效率都不行. 而且顺序还必须保证！ 之前非常多发现因为复合索引不到位，导致数据查询执行0.05 -0.1秒的准慢查询，通过set profiling是可以分析的，优化后效率提升10-100倍。 此外，连带影响也是一个大问题，比如说，有时候你会看到大量SLEEP链接，那多半是前段执行完SQL没有及时关闭，之前我的博客如果有认真阅读的，会看到因为echo影响，因为memcache链接阻塞影响都会存在，当然还有一种，网络带宽阻塞影响，Waiting for net状态阻塞，

这里确认阻塞点和阻塞方向，最关键的是思路要足够发散，不要只看数据库配置，或者数据索引；前端程序，网络环境（曾经因为别人的外挂程序，以及代码不严谨，导致内网网卡阻塞，数据库连接过多）都需要考虑周全，所以有些答案caoz回复说思路不开阔，就是这个原因。这里具体分支场景很多，caoz也只是列举一二，仅仅配置优化，就有无数参数可以提出。

第三步是解决，这里通常要多向考虑，什么叫多向考虑，分析问题如果够全面，就会发现问题往往是伴生出现，比如出现阻塞，也许你优化后台参数的确可以解决，但是如果前端调用脚本也优化一下，可能就会得到更好的效果，那么这里要强调的是，解决问题必须给出明确的数字支持，比如升级后，性能提升多少，负载支撑提升多少，可支持多少并发，支持多少同时连接，由于经验问题，很多人估算不准，这不是问题，几次训练下来就准了，但是如果不去估算，那么永远都没有经验，永远估不准，这其实也是意识。

但是到了这里，事情还不算完，还有一步！

第四步是什么呢？无人值守脚本

千算万算，不能不算，无人值守情况下，数据链接过多怎么办，有几种解决方案，重启数据库未必明智，一个很简单的原因，如果是myisam，重启可能导致数据索引出错，如果是innodb，可能重启需要很长时间，最有效的，还是直接kill掉阻塞的查询进程。然后记录日志以备后续分析。

而且，按照caoz的经验，不要等链接阻塞再去kill掉查询进程，应该在链接数超过报警阈值的时候直接kill掉执行时间过长的SQL查询进程，有人会问，哪里有这样的系统？自己写一个cron脚本，花不了一个小时的。

第二个问题，在上头啰啰嗦嗦有罗列

第三个问题，场景很多，简单列如下

1：数据库读写锁，换成innodb引擎是最快的方法，那么读写分离做主从也是一种方案，不过要考虑成本还是蛮高的。此外就是读取数据多用缓存，写入过多怎么办？也用缓存！缓存回写，同主键写入合并，具体策略不多说了，这是caoz看家的本事。

2： sleep链接太多，前端代码检查，找到关联影响点，尽快释放mysql链接

3： 慢查询和准慢查询太多，索引优化，以及数据库拆分优化（忙闲拆分，主键hash拆分，还有其他拆分模式），索引碎片整理（数据索引优化或重建，半夜偷偷干吧）

4： 网络阻塞，减少控制数据库操作的数据流量，改代码去吧

5：i/o压力过大，有些参数可以设置的，比如innodb的数据提交不一定每次操作都提交的。

总之，优化方案之多，难以全面罗列，可以整理如下

优化分为架构优化，比如引入缓存层，引入主从架构，引入中间件，分库分表，都属于架构优化。

代码优化，减少重复和不必要的查询，合并重复查询，良好的代码习惯

DBA优化，索引优化，存储引擎优化，mysql参数优化，数据库版本优化

操作系统优化，文件系统优化，linux内核优化，

对系统架构的理解，有助于从不同层面分析问题，思路要发散，不要只看数据库

对数据查询的理解，多使用set profiling，对每一个停留状态，每一个耗时和资源分配，索引的每一次查询方式要心理有数。

对数据库参数的理解，要知道每个参数对i/o的影响，对查询执行的影响，对每个SQL进程执行步骤（set profiling可以分析SQL执行步骤）的影响是什么，

对程序的理解，要知道程序为什么请求数据，请求数据的目标和方法是否合理，是否有重复和无效的请求占用资源。请求数据后是否长期闲置链接，是否存在不合理的关联影响。

对系统的理解，是否存在系统配置短板，导致数据库性能无法发挥。

第二题

简单说，关键是无人值守脚本，无人值守脚本要

1：记录负载提升时的系统状态和进程列表，进程资源占用数据。

2：自动对突然增加负载的用户或系统进程进行处理，

3：记录处理结果和处理后的状态。

无人值守记录是系统维护的关键点，有很多人用第三方工具，当然很好，但是必要的时候必须亲自做一些监控脚本，这东西用什么写都可以，php,perl，ruby都无所谓，能记录，能执行关闭进程和启动进程的操作就可以。

第三，这种问题当然有很多种可能，分析日志也好，分析系统状态也好，不过根据caoz经验，出这种问题，80%以上是系统某参数越界，这种越界还蛮多的，比如最多文件打开数，系统最大连接数，syn_backlog，甚至最多文件节点数（看硬盘空间还有，其实inode没有了，大量琐碎小文件就会出这个问题！）还有，ip_contrack什么参数，可能导致网络丢包严重， 所以这个问题的关键是，对linux各项内核参数必须有深入了解，有时候你看服务器跑不动了，可能改一下参数马上就好了，但是改哪个参数，怎么改，这就只能是经验和搜索技巧了。

其实caoz想到的也不完整，后来有人给caoz很多提醒，比如前端mysql,memcache链接应该设置超时参数云云。不过总体来说

意识到位（先临时处理立即恢复线上应用，再彻底处理，处理要评估并且做出预判，优化与故障自动处理要并行，不能100%依赖优化结果）

思路开阔（dba的问题别死盯着dba，谢谢）

经验丰富，上述列到的，您列出了几个？

答案就此公开，谢谢各位的来信。真有不少人才，让caoz兴奋！

 

 

 

 

 

 

 

 

 

 

 

 

 

题目1

现在有两个日志文件，格式为

211.137.1.1

125.65.2.3

202.36.71.33

....

每条一个ip地址。每个日志文件各有100万左右条。文件中可能少部分ip是重复。

现在想知道文件1与文件2中，相同的ip有多少，请编写脚本实现。

小提示：第一，不要吧这个问题复杂化，这是这里最简单的问题。第二，注意程序效率。

答案，此题其实相当简单

将第一个文件遍历读取，存入数组，无须排序，存入即可。

$arr[$ip]=1;

然后遍历第二个文件，针对第二个文件中的每一个ip

查一下是否存在该数组下标

if (isset($arr[$nip])) $sum++;

然后输出$sum即可

其中无任何地方需要排序处理。

题目2

还是刚才那个日志文件，只有一个，100万条ip记录，少部分有重复

现在有一个ip地址库

格式为

ip地址1 - ip地址2 - 地区

这个库有15万条记录

现在请编写脚本，将这100万条记录的地区分布列出来。

小提示，这个题目的关键词是，效率。100万×15万，如果不用点窍门，是不可承受的系统开销，那么很多人都知道索引是提高效率的重要手段，但是基于区间的查询，是不能直接使用索引的，但是，想一下索引的实现原理和效率提升的原理，这个问题就会迎刃而解。很多时候，我们不仅仅要善于利用一些有效的工具，更要明白，这些工具背后的逻辑。

答案，

实际上是要点只有一条，将15万条地区库建立为有序的数组并格式化保存，这个数组会非常有用，做一次排序保存即可，在n多涉及地区查询的实际应用中都可以统一调用，无须每次重新排序。

之后就是最典型的二分查找法了，关键是编写一个二分查找的函数，可以通过不断的二分处理在15万条记录中快速找到该ip所对应的区间，理论每个ip的查找次数是log2(150000),

遍历100万条记录（这100万条记录无须做任何排序），对每个ip判断是否已进行过地区识别，如果没有，则调用二分查找，返回所属地区属性，然后

$sumarea[$return]++; 最后把sumarea排一下序输出即可。

这里唯一的排序是对15万条地区ip区段信息排序，而且只需要进行一次长期保存即可。考核的关键不是排序，而是二分查找，二分查找是最简单的快速索引算法，网上大量资料可查阅。

题目3

现在有2亿web服务的日志，假设就是apache日志或类似格式的日志，没说错，2亿条，格式大体为如下

ip地址,访问url,来路url,当前时间

假设就这些吧,这里可能涉及的是2万个不同的站点。

现在要求，做出每个站点的流量统计，包括这个站点的独立ip数，pv数，时间段分布，地区分布，来路分布，受访分布，Top进入url。

现在给你的电脑是一台双CPU，2G内存的服务器，请考虑实现方式。

小提示，这里的关键词除了效率，还有资源开销，如果我们不考虑数字，只考虑应用，这个题目并不复杂，只是罗嗦，但是当你考虑到要分析2亿个日志，而且对2万个站点每个站点都要做出统计，那么你程序时就可能会遇到一个天大的问题，按照一般的方式处理，内存肯定远远不够用。但是如果大量使用硬盘空间来替代内存，又存在巨大的i/o开销，如何寻找均衡的方式，这里考查的不是脚本编写，而是系统设计。

答案

这道题看上去很唬人，但是实际上只是一个日志切分的问题，不要把系统考虑太复杂

实际上组建一个二步处理的过程，第一步是遍历2亿的日志，然后将每条日志的站点主域取出来，作为文件名，处理到一定数量时批量储存为独立文件。

过程示例如下,处理函数略

$seed=0;

while ($str=fgets($fd))

{

$seed++;

$arr=checklog($str); //将日志切分,将日志中的各个字段切分

$site=$arr["site"];

$vstr["$site"]=$vstr["$site"].$str;

if ($seed>1000000) //假设以100万条日志为内存处理容量

{

    foreach($vstr as $key=>$value)

    {

    $fd=fopen("$path/$key","a");

    fwrite($fd,$value);

fclose($fd);

}

unset($vstr);

$seed=0;

}

}

这个程序执行后，2亿条日志就被分割为2万个文件，每个文件对应一个站点

然后再做一次针对站点的遍历，每个站点分析日志，就属于纯粹的罗嗦体力活了，过程略

该题目中不涉及任何排序操作及算法。这个模式只需要遍历日志两次，此外需要日至容量一倍的写操作，这些代价并不是不能承受的，至少系统设计上很简单。

题目4

小张是某大学的体育部主任助理，为了方便安排体育课程，他做了一个调查，发了1000份问卷，让所有人填写自己所期望的体育课程，这份调查是允许多选。

基本结果为，足球 500份，篮球350份，乒乓球200份，羽毛球200份，网球120份，棒球50份，....

然后小张做了另一个统计，针对每个项目，查看与它共同选择最多的项目，看看冷门项目中，有没有多个项目合并的可能，结果发现，所有选择冷门项目的人，最多的共同选择项几乎都是足球和篮球。那么，是不是说所有项目都与足球，篮球高度相关呢？是不是所有冷门项目都可以并入足球篮球呢？这里的问题在哪里？

如果你是小张，你是否能有更好的处理方法，如有可能，代码实现。

小提示，这是一个基本的关联模型和聚类模型的应用，关联模型中，考虑关联性的因素都包括哪些，共同选择的数字并非唯一的标尺。

答案：

关联模型中，我们不仅需要考虑支持度（共同推举数），也需要考虑置信度（相对比例），这里其实就是一种思维模式的考量，很多时候，我们设计关联模型时，针对不同应用，需要有不同的考量及评估模式，实际应用会比这个题目复杂。

总结

以上都是工作中遇到的实际问题，并非算法考试，和百度程序之星，google程序大赛的模式是不同的，这次招聘面向的目标是非技术部门的数据分析工作，因此并不十分特别强调高效算法，但是强调有解决实际问题的能力，所谓解决实际问题，核心的要求就是简洁高效，从收获的一些答案看，大部分应届生喜欢把问题复杂化，也许是题目描述的问题，不过希望年轻朋友们一定要记住，工作和做学术答辩不一样，一般学生做毕业论文的时候，喜欢化简为繁，简单的问题复杂化，显示卓越的学识和技能，但是工作要求的是化繁为简，用最短时间解决最多的问题，最短的时间不仅仅是程序执行的时间，也包括设计和编码的时间。