@@Anybody crazy about Lanvin for HM like me# Fashion - 美丽时尚
m*z
1 楼
小弟前段时间找工作，经常来本版，收益不少。在狂练了careercup和leetcode后摩拳
擦掌，牛刀小试去面了几家公司。面之前也没有太多看design的帖子，本以为自己七年
多内核经验咋也可以忽悠过去 。。。结果 。。。 下面是一段经典对话：
Q：你懂Hadoop吗？A：不懂
Q：你用过DB吗？A：没用过
Q：你用过Restful API吗？A：没用过（这时那家伙已经不耐烦…）
Q：那你用过WCF吗？A：WCF是啥。。。
Q：不好意思，我们还是决定要找比较junior的人。你的experience有点不太适合。
偶当时是那个汗呀，顿悟人坚不拆的道理。。。
总的来说，面试间同胞还是很照顾的，赞一个！
后来想想不学点新东东就是坐吃等死，所以就和另外一个兄弟一起边做边学弄了个小网
站（www.myappwiz.com），也过来分享一点经验吧：
1. 感觉数据大了，DB会很慢，我们最开始用DB，往里面插几万条数据就要用半个小时
。也有可能是我们DB没建对，不过想想对于很多startup来说design几乎每个星期都在
变，数据一变，以前的DB design就要换，这个还是很不方便滴。
2. 数据大了，内存还是不够用滴。偶以前有个错误的理解，内存不够买个内存条加上
呗，为啥要优化内存使用。此想法是不对滴。有一天，我突然发现程序跑不动了（out-
of-memory exception），小弟以前在kernel里面碰到这类情况一向都是直接give up。
不过在user mode不能这样玩呀，况且我的机器有16GB内存，我们的数据全放在内存里
面也就几个GB。后来在网上搜一下得知C#程序也就支持1GB左右的内存使用量。多了就
容易出out-of-memory exception。（不知道java有没有类似的问题，还望大侠指点）
3. Json是个好东东，但不能乱用。用Json serialize数据量比XML小很多。但是用Json
serialize/deserialize大文件对内存的压力还是很大的。所以要小心。当然，同样的
数据用XML肯定早死掉了。。。
4. 建ReadOnly的index还是和建R/W的index有很大区别滴。所谓建ReadOnly的index是
指index只建立一遍，以后就不改了，也就是说不会有新数据来，老的数据也不会变。
用Lucene建readonly的index简直快得惊人，而且search的performance也很好。但是一
旦改成R/W就顿时不行了。会有很多segment，且很容易out-of-memory。不知道solr会
不会好点。
5. Log很重要。我们60%的bug都是通过log发现的。有一个比较好玩的bug，是我们刚上
线的时候发现Search engine总是爬我们网站的死link。后来发现我们有个bug是不断的
向Search engine提供新的死link，这样下去就自然没完没了啦。我比较喜欢自己包装
log interface，这样以后改也很容易。多线程log还有个问题就是synchronization，
我后来想想没有必要因为log影响system perf，所以就就每个thread自己create一个
log channel。
其他的一时半会也想不起来了，大家随便提问，小弟在100楼开始回答。嘿嘿。希望对
大家面试有帮助，小弟献丑啦，牛魔王们轻拍。。。
下面是网站的简介：
网站的主旨是给广大手机玩家提供新鲜热辣的app推荐，密切关注各大手机应用商城的
限时免费app和给力打折，一言以概之，就是，来我们这里找您想要的app，各种给力，
保您满意。
您要是苹果手机的忠实粉丝，请重重点击这里，http://www.myappwiz.com/home/ios 。我们为您准备了十万应用，总有一款适合您。
各位爷，如果您要是Android用户，小的也准备了十万应用，请鼠标，戳这里：http://www.myappwiz.com/home/android
亲，如果您追求的是另类，个性，用的是高端大气上档次的Windows Phone, 这个这个
。。。虽然应用少点儿，但小的搜肠刮肚的也给您准备了六万应用，请放心点击http://www.myappwiz.com/home/wp
保您满意，惊喜随处可见。
当然，如果您是跨平台的骨灰玩家，左手iPhone，右手Android的土豪用户，小弟重点
推荐网站的跨平台app自动匹配的功能，简单说就是，您搜一个应用，我们除了告诉您
这个应用的下载地址，还告诉您这个应用在其他平台的match或similar。一箭三雕，事
半功倍。
擦掌，牛刀小试去面了几家公司。面之前也没有太多看design的帖子，本以为自己七年
多内核经验咋也可以忽悠过去 。。。结果 。。。 下面是一段经典对话：
Q：你懂Hadoop吗？A：不懂
Q：你用过DB吗？A：没用过
Q：你用过Restful API吗？A：没用过（这时那家伙已经不耐烦…）
Q：那你用过WCF吗？A：WCF是啥。。。
Q：不好意思，我们还是决定要找比较junior的人。你的experience有点不太适合。
偶当时是那个汗呀，顿悟人坚不拆的道理。。。
总的来说，面试间同胞还是很照顾的，赞一个！
后来想想不学点新东东就是坐吃等死，所以就和另外一个兄弟一起边做边学弄了个小网
站（www.myappwiz.com），也过来分享一点经验吧：
1. 感觉数据大了，DB会很慢，我们最开始用DB，往里面插几万条数据就要用半个小时
。也有可能是我们DB没建对，不过想想对于很多startup来说design几乎每个星期都在
变，数据一变，以前的DB design就要换，这个还是很不方便滴。
2. 数据大了，内存还是不够用滴。偶以前有个错误的理解，内存不够买个内存条加上
呗，为啥要优化内存使用。此想法是不对滴。有一天，我突然发现程序跑不动了（out-
of-memory exception），小弟以前在kernel里面碰到这类情况一向都是直接give up。
不过在user mode不能这样玩呀，况且我的机器有16GB内存，我们的数据全放在内存里
面也就几个GB。后来在网上搜一下得知C#程序也就支持1GB左右的内存使用量。多了就
容易出out-of-memory exception。（不知道java有没有类似的问题，还望大侠指点）
3. Json是个好东东，但不能乱用。用Json serialize数据量比XML小很多。但是用Json
serialize/deserialize大文件对内存的压力还是很大的。所以要小心。当然，同样的
数据用XML肯定早死掉了。。。
4. 建ReadOnly的index还是和建R/W的index有很大区别滴。所谓建ReadOnly的index是
指index只建立一遍，以后就不改了，也就是说不会有新数据来，老的数据也不会变。
用Lucene建readonly的index简直快得惊人，而且search的performance也很好。但是一
旦改成R/W就顿时不行了。会有很多segment，且很容易out-of-memory。不知道solr会
不会好点。
5. Log很重要。我们60%的bug都是通过log发现的。有一个比较好玩的bug，是我们刚上
线的时候发现Search engine总是爬我们网站的死link。后来发现我们有个bug是不断的
向Search engine提供新的死link，这样下去就自然没完没了啦。我比较喜欢自己包装
log interface，这样以后改也很容易。多线程log还有个问题就是synchronization，
我后来想想没有必要因为log影响system perf，所以就就每个thread自己create一个
log channel。
其他的一时半会也想不起来了，大家随便提问，小弟在100楼开始回答。嘿嘿。希望对
大家面试有帮助，小弟献丑啦，牛魔王们轻拍。。。
下面是网站的简介：
网站的主旨是给广大手机玩家提供新鲜热辣的app推荐，密切关注各大手机应用商城的
限时免费app和给力打折，一言以概之，就是，来我们这里找您想要的app，各种给力，
保您满意。
您要是苹果手机的忠实粉丝，请重重点击这里，http://www.myappwiz.com/home/ios 。我们为您准备了十万应用，总有一款适合您。
各位爷，如果您要是Android用户，小的也准备了十万应用，请鼠标，戳这里：http://www.myappwiz.com/home/android
亲，如果您追求的是另类，个性，用的是高端大气上档次的Windows Phone, 这个这个
。。。虽然应用少点儿，但小的搜肠刮肚的也给您准备了六万应用，请放心点击http://www.myappwiz.com/home/wp
保您满意，惊喜随处可见。
当然，如果您是跨平台的骨灰玩家，左手iPhone，右手Android的土豪用户，小弟重点
推荐网站的跨平台app自动匹配的功能，简单说就是，您搜一个应用，我们除了告诉您
这个应用的下载地址，还告诉您这个应用在其他平台的match或similar。一箭三雕，事
半功倍。
