今天去某公司面试的状态,大家怎么看?

2015-07-08 16:46:31 +08:00
 szopen
技术面试的人问了其中几个问题:
1. 设计一款订单推送系统,然后要保证推送是实时的,因为我说先缓存一下订单来应对访问量,再推送,我说推送有点延迟没问题吧,出题的说我们的订单推送没延迟,下完单后,客户端立马收到推送,那我就说你就直接写库呗(虽然我不知道为什么这样做了就没延迟了)

2.设计抓100亿页面然后分析,我给出了方案,出题的又问需要多长时间,我说没做过,然后出题的又说你不知道就不说时间了吗?然后我胡扯了一个时间.......

3.有个问题涉及到缓存数据问题,这次我说先memcache缓存,然后面试官立马说memcache会丢数据,我就说,你用的redis也是延迟的,此时对方没说话了,我只好说那就直接写库,集群,效率嘛服务器上固态硬盘(虽然我知道直接写库也是有延迟的,只时频率不一样的,我在想99.99%与99.999%这两个概率有啥区别)
6278 次点击
所在节点    职场话题
30 条回复
Ison
2015-07-08 17:18:19 +08:00
其实有时候俺也怀疑
到底面试的想要什么人
是要问什么都能达得上的呢
还是要问什么都能提供思路的呢
显然应该是后者
但为毛有时候面试官会给人是着重前者的感觉呢
就像lz遇到的情况。。。
jones
2015-07-08 17:23:13 +08:00
第一个问题一般做法订单提交然后把订单ID写队列,然后推送处理程序从队列中拿出来处理,队列用Redis的发布订阅功能实现延迟应该在接收的时间范围内,

我猜测面试官想让你这么回答,,
mhycy
2015-07-08 17:55:14 +08:00
怎么从这个答案上看提问者有点傻逼的感觉。。。

第一题
对于用户的信息推送,客户端必定会存在一个延迟,这个延迟不是内部产生的,而是由于网络产生必定会存在的一个延迟。因为不可能现在与客户端有一个即时可用的长连接用于推送。所以无延迟是不可能的。

第二题
100亿的页面分析,具体需求如果有说清楚的话时间还是可以估算的,但是这个与机器的配置,数目,网络带宽有极大的关系,随便问一个时间是不可能准确回复的,当然你可以说说时间是怎么算的。。

第三题
缓存,延迟,丢数据。。。
越看越觉得面试者是个傻逼,因为缓存总会有容量限制,那么缓存必定会有一个失效期。
如果要处理延迟尽可能的低,可以另开一个缓存进程,由应用通知进程进行数据缓存操作。
那么每次读取去取就行了,但这并不能保证数据的一致性。
(后台更新了,缓存依旧没更新,但只读缓存,这样其实和数据库从库的表现是一致的)
glasslion
2015-07-08 18:57:59 +08:00
以前面试时遇到过推送的问题,为了用户体验, 创业公司一般会选第三方推送的SDK, 所以既不能让推送的延迟过大, 又要让尽可能多的信息一起推送
FrankFang128
2015-07-08 19:01:56 +08:00
就题论题有啥意思,面试官抓不住重点。
lincanbin
2015-07-08 19:49:49 +08:00
1. 要保证无延时,开socket或者Long Poll,订单处理完成后回调推送程序。
只有异步回调可以做到无延时,但是并不常见。

2.这跟网络、CPU、硬盘I/O性能关系都很大的,没给足条件自然没有答案。

3.memcached的数据持久化也是可以自己轻易实现的。
wy315700
2015-07-08 19:52:56 +08:00
@szopen
99.99%与99.999%这两个概率有啥区别
用1减一下就会发现这两个概率差了10倍
wy315700
2015-07-08 19:53:45 +08:00
@Ison
其实,面试和老师给学生打分是不一样的,
面试的目的是,面试官在挑同事,
gamexg
2015-07-08 21:07:39 +08:00
第一个推送很好搞啊,收到订单后把订单数据存数据库,然后推到推送队列里面去。推送服务取出来通过推送系统推到客户端即可。
推送系统现在有很多了,可以使用第三方的,也可以自己建,做好长连接心跳不拼单机带客户量的话很容易搭建。实测一般2秒内可收到推送。
sivacohan
2015-07-08 23:17:42 +08:00
抛开问题。其实就是你和面试官不在一个频道上。
对你来说,这样的公司还是不要去的好。
因为如果不能流畅沟通,那以后一起工作会非常的麻烦。
sophie2805
2015-07-08 23:20:18 +08:00
哪个公司的??
以后绕道~
szopen
2015-07-08 23:36:15 +08:00
@wy315700 我理解的在故障问题这里,概率10倍与100是没有多大区别的,因为故障只有一次,就如同10个数字中只有一个数字是你要选择的数字一样,他和其他数字被命中的机会是一样的,就像魔兽世界刷凤凰坐骑,有的刷了三年不出,有的一次就出是一个道理

@gamexg @jones 我当时的思路其实就大批量订单先缓存,然后在处理,我说可能会有一点延迟,面试的指出不能有延迟,所以队列肯定不行,
szopen
2015-07-08 23:41:42 +08:00
@sivacohan 想想的确不在一个频道

这次面试让我想起另一次去大公司面试,故事是这样:我说我用PHP做了一个web服务器,然后面试的一脸蔑视地说你做这些有什么用!我当时就愣住了
wy315700
2015-07-08 23:50:00 +08:00
@szopen

则个属于概率论里一个悖论,就是概率再低,也会发生,概率再高,也有不会发生的。

因为如果样本足够大,即使概率再低都会发生。

所以这个时候要考虑的是后验概率,已知平均故障率的情况下,发生一次故障的概率,发生两次故障的概率,今天发生故障的概率,这周发生故障的概率。
10和100倍的差距就在这里体现了。
Cloudee
2015-07-09 00:28:01 +08:00
@szopen 这个时候应该一脸鄙视地回答“Because I can”
akira
2015-07-09 01:11:34 +08:00
1. 实时的意思应该是在数秒之内。客户端和服务器端保持长连应该可以做到。另外应该会用到消息队列。
2. 这种题目自己做条件假设。假设服务器系统内存带宽等必要参数,然后根据这些参数计算个结果出来。
3. 写缓存确实有这个问题。读缓存的话,丢了重新读就是了呗。
helloworld00
2015-07-09 07:22:37 +08:00
我在想99.99%与99.999%这两个概率有啥区别

举个简单的例子,如果1-99.99%=0.0001是一台服务器A一个礼拜至少crash一次的概率;
1-99.999%=1.0e-5是一台服务器B一个礼拜crash至少一次的概率。

一个50,000台服务器A的clusters,平均每个礼拜就有5台服务器至少会crash一次,每个月就有20台机子至少会crash一次,每年就会有240台服务器至少会crash一次。

另外一个50,000台服务器B的clusters,稍微好点,平均每个礼拜会有0.5台服务器至少会crash一次,每个月2台,每年24台至少会crash一次。
helloworld00
2015-07-09 07:31:31 +08:00
UPDATE 楼上

不是一个50,000台服务器的clusters,是包含50,000 台服务器的clusters

一般一个大cluster可能10,000左右的服务器.
(参考 google borg)
http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43438.pdf
morethansean
2015-07-09 09:17:09 +08:00
一个网站,你们的 API 设定全年可用性为 99.99%:
365*24*60*(1-.9999) = 52.556 就是说一年之中只能挂最多53分钟

可用性 99.999%:
365*24*60*(1-.99999) = 5.25599999997608 一年中只能挂5分钟

这10倍的差距,后者你可能连问题都来不及修复吧。
morethansean
2015-07-09 09:18:07 +08:00
楼上精神恍惚打成 A 了……

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/204248

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX