【财报速递】收入增长从高两位数到个位数,再到下滑,在四季度罕见亏损,虎牙在最近两年内算是遭遇了“过山车”;不禁让投资者对它的未来表示忧虑。
虎牙(HUYA.NYSE)在3月22日美股开盘前发布的财报显示,去年总净营收为28.1亿元,而2020年同期为29.9亿元,同比减少6.1%。
虎牙直播服务营收26.13亿元,而2020年同期为28.15亿元,同比减少7.2%;广告和其他收入为1.96亿元,和2020年同期1.76亿元相比增长11.6%。
直播业务在虎牙总收入占比近93%,广告等业务占比大约7%,即便有两位数增长,也挡不住总收入下滑。另外,去年一季度到三季度,虎牙收入增长分别为8%、9.8%、5.7%,乃至下滑6.1%,似乎“水到渠成”。
虎牙四季度运营亏损4.57亿元,而2020年同期运营利润为1.87亿元。最终四季度虎牙净亏损3.13亿元,从去年同期的盈利2.53亿元转为亏损。虎牙上一次亏损还要追溯到2018年第二季度。
2021年全年,虎牙总净营收为113.51亿元,较2020年的109.14亿元仅仅增长4%。对比2020年,收入增速高达30%,虎牙这是摸到了天花板?去年净利润为5.84亿元,而2020年净利润为8.84亿元,下滑34%。
当前虎牙的大股东是腾讯,持股47%;腾讯也持股斗鱼36%;虎牙曾筹划和斗鱼合并,但因为市场集中等原因而被叫停。据MobTech估计,虎牙与斗鱼合计市占率达80%,二者一旦合并,将完全主导游戏直播行业。
2021年2月,虎牙股价曾高达36.33美元,上周一度跌至3.2美元,回撤9成,最新股价为5美元左右,市值12亿美元。
上周一,来自武汉的直播平台的大数据架构,作为一个在 2 年多时间里崛起的公司,其流量经历了从 0 到 PB 级别的飞跃。
刚好今年 3月,斗鱼的大数据团队负责人参加过简寻主办的首届武汉开发者峰会,分享了一些经验和坑,结合一些资料,小寻整理了这个帖子,供有志于大数据的同学参考和借鉴。
关于吴瑞诚:2014年加入斗鱼,成为斗鱼大数据团队第一人,经历了斗鱼的用户从 十万级别大千万级别的飞跃,并从0 搭建了斗鱼的大数据实时计算平台。入职斗鱼前,我吴瑞诚在淘宝干过三年,主要做HBase。这是斗鱼非常典型的直播间,55开,游戏打得好,牛吹得好,在斗鱼比较好,大家看到密密麻麻的字,就是弹幕,视频直播最火的场景,弹幕。很火的时候,上面会有礼物,用户给主播赠送火箭,鲨鱼骑着火箭的礼物飘过,这个火箭价值还挺高。
右下角这些图标是礼物,用户赠送给主播的礼物,鱼翅可以充值购买,鱼丸赠送,右边是土豪的贡献排行榜,贡献越多排名越高,右边是弹幕区。内容和形态就是这样,但是现在很火,有时候我们没办法预料现象级现象。
第一,日志检索,日志全局检索。后面会展开,这个地方主要是以NginxPHP日志做事例。
第二,实时CEP系统,类KV的处理系统。
第三,实时流计算,流计算。 strong text
这是一个现在的大数据的架构图,这个图最近才整理出来,越整就觉得体会越深,这个图里面看一下红红绿绿有一些方块,看PPT看得多的同学,可能司空见惯了,大数据架构图到最后可能都是这个样子,但是图上的每一个块都是踩过无数个坑,付出了血的教训才成为现在这样。
我加入斗鱼,当时是一个人负责整个这一大块的东西,后来就是因为网站量上来了,个人吞吐量到了上限,招了第一批人。我第一批是组内培养的,会有一些java开发,生拉硬拽凑到大数据团队,从最开始的小系统越做越大,做到现在这个架构。
最下面一层是数据源一层,Nginx、PHP日志,公司技术栈比较多,处理起来会越来越蛋疼,现在统一接入层是是Kafka,现在还没有完全接入。
上面一层就是数据清洗和格式转换包括初步的结算。
再上面一层就包括依赖MySQL实现的归档数据,最大一块是离线计算基于Hadoop,YARN。去年上线Spark,现在应用的范围还比较小,主要还是在风控和个性推荐这一块。
另外实时计算是Hbase,是之前经验比较熟悉,Hbase大家觉得有很多替代的产品,我觉得Hbase在第一层兜住海量热数据,我觉得Hbase的优势还是非常明显的。所以我这一块一直会保持Hbase在这个地方使用,在快速查询,可以相对于自助查询走的presto。
右侧实时计算主要基于Storm,今年大目标把spark作为重点引入。对于新框架的考量,小公司二次的开发能力或者定制能力弱一些,我们现在主要应用短平快的一些方式,比如,主流的有一些大公司BAT、京东、美团把坑踩完了我们再上,这样我们成本会小很多,我们会跟进spark,spark社区活跃得让人没办法忽视它,它现在活跃程度比Hadoop强一个量级。
最右边是Elastic,最开始引入的时候只是做一个搜索引擎,后来越用越觉得爽,真的是一个神器,后面会具体展开。
再就是上面的服务数据层,前端网站和服务层使用,再就是Dashboard,监控、个性推荐、用户行为分析、风控系统、搜索引擎、其它数据应用。
这是Lambda架构,这三层架构,P处理层,再是上面的加速层到服务层,这三层架构,应该可以覆盖绝大多数的大数据团队架构的场景。
我们最开始,只有几个PHP实例,出了问题,我就上去grep、awk,然后规模上来了,机器和应用实例突增,就用rsync和HiveUDF的方式,把日志收集起来,按照时间粒度切碎了拖过来,然后用Hive进行一些匹配,形成这么一个非常初级的系统。
到了现在,ELK,用的很爽的系统,能支持的量很大,可扩展,全文检索,很多时候包括技术团队定位问题非常方便,有这几个特性能满足基本使用。如果再能够帮他们做一些告警,包括量的告警,文本的告警,有更好,这也是我们现在在做的。
这是实时日志检索的架构图,大家可以看到应用场景,当时flume用得最多,应用场景变得比较快,我们的业务调整也非常迅猛,新场景中发现flume有两个场景没办法满足,一个场景是C++场景,它的量太大,他们的日志按实例文件夹写本地;一个是,Java太耗资源,包括CPU、包括内存,后来我们觉得这一块要做一些改变。
最开始的方案,因为我们有C++的团队做服务化,他们觉得我们可以自己造轮子,这个轮子比较简单,后来我做了一圈对比,发现Logstash新版本中,有一个Beats组件,是golang实现的。
架构图中间以Elastic技术栈为主,包括中间汇聚层在不久将来会被替换掉,但是现有的一些场景,如果一直稳定的话先保持现状。因为我们在这个阶段它比较稳定。
Flume 的Memory channel在量大的时候会OOM,这个时候把溢出的量落地到disk上面,这样可以在保证效率的同时能增大Flume能承受的吞吐量,这样让flume很稳定,一直沿用到现在。
现在还是用Flume做了汇聚层,我们后续会使用Kafka做汇聚层,有很多场景,有些日志可能回头还要再消费或者说要做Pub-sub,现在模式很难实现,必须要用到Kafka。
日志数据在图的下方走了Elastic,用Kibana做的UI,Kibana 2.0以后使用上会有很多不顺畅,我这一块其实建议大家二次开发,二次开发的成本不大,比较容易上手,所有的接口都可以走API,定制起来方便,图上方是走的Hdfs出报表。
再说一下踩过的一些坑。
首先Flume的选型。我最开始看中还是因为他是Apache的产品,觉得它稳定,在很多公司PPT里面,我稍微估计一下,flume出现的概率比其它产品出现频率高很多,所以做一些压测做了对比,差不太多,就选了flume,现在要新用或者要换型需要更详细的压测。
channel这一块,最开始内存到disk到现在两个方案混搭在一起,但是占资源特别耗资源。
flume的监控,一定要先考虑监控再上新的技术栈。
ES 插件:KOPF集群监控:hesd 索引操作;
独立小集群解决慢查询;
最热的查询中避免使用 Range 查询;
在Elastic上,我们跟Solr做对比,大家可以看一下纯开源的组建跟有商业团队支撑的开源产品,社区活跃度和产品迭代不是在一个量级上,Elastic现在已经开始注重使用体验了,这一点是Solr还没有纳入考量的点。
因为Elastic除了我们最开始最传统的搜索引擎、文本搜索,现在更大的一块可以当作我们的多维自助查询,水平扩展能力非常强,因为数据结构的天热优势,就有一些场景,包括多维的及时查询这一块有非常强悍的性能。
ES插件上,我们使用了Kopf做监控,head来操作索引。
ES读写分离。ES集群拓扑越来越大,如果按照默认的拓扑来使用的话,可能量上没法满足很多场景,比如,如果读写不做分离,查询极有可能把线上写的节点直接压垮,这样就建议有一个专门的节点来负责读。
对于资源隔离,我们使用了几个小的Elastic的集群来满足各个功能。因为,Elastic是P2P的,无主。无主有一个问题,有时候没有办法很强的控制某些节点行为,这时候要做一些隔离,最见效的方式就是按照小集群直接做隔离。
避免索引过大。这一点大家如果能注意把不必要的字段建到索引能解决大部分。
最热的查询中避免用range查询。
JVM heapsize设置,我们现在一直使用32G,Hbase集群也是这样,尽管集群配置很高,Hbase的配置还是32G。
GC方面,我们使用的是CMS,在线上使用、压测表现看的话,G1稳定性和用户体验看来都会差一些。
最开始我们做一个指标统计,大家把数据推到我们这边来做一些统计,然后借助redis做统计并最后把结果数据保存在Redis,简单的统计场景OK了,后来业务场景复杂了,产品线多了,redis单个实例肯定不够,可扩展性和数据规模是redis暂时无法越过的门槛,所以我们又很自然用到了Hbase。
Hbase使用有两大点需要注意:
第一,rowkey的设计,Hbase中除了rowkey没有索引可供使用。
第二,数据压缩,历史数据的压缩很关键。一个指标两个指标做抽样做一些归档很好做,但是怎么做到统一,而且还很简单,我们能直接拿来用,这个时候碰到open TSDB,一个时间序列存储方案。
最开始也用了InfluxDB,感觉有时候只要压力上来了之后,它可以没有征兆挂机,后来干脆就考虑到open TSDB。数据揣拽产生图形,基于OpenTSDB,能满足很大的量。
这个系统中真正性能考验的其实还是Hbase,Hbase OK,opentTSDB也就没有问题,我们会一直把这个方案做下去,基于open TSDB,我们可以很灵活做定制,它本身就是基于Hbase做了定制的特性,包括我刚刚说到对rowkey的设计。
对数据压缩,每一个指标每一个小时会有一个row,open TSDB帮我们做了。后面有定制需求我们从头开始做,这一块是比较简单的,底层Hbase性能是没有问题,越往后看,Hbase有很多地方它会做得越来越通用。因为它的性能这一块显性能没有问题,后面卡顿的问题会有明显的提升。
回到刚刚上面的图这是CEP系统,这个图上面,大家可以看一下。
从数据收集,第一个parser会走到Kafka,从spark走到Hbase,走到这一步就走到了业务系统,包括我们的监控系统,这是有一个业务流程,现在可以简单理解成某些指标大于阈值就觉得它的是一个嫌疑事件,需要告警的,简单理解就是这样,这一块马上引入规则引擎,这一块业务变化频率太快了,发布速度拖了后腿,在已经测试上了。
到后面有一些结果的存储,再有告警的推送,这个地方也是直接走到Hbase。后面有一些统计好的指标可以拿来用的,这个地方我们走到了open TSDB,这个图就没有重新再画,直接从Cloudera Blog上面借用,这个架构图和我们的系统是一模一样的。
Open TSDB,业务指标非常灵活,我们现在有一些CPU指标,打出来我们收集起来,各个指标汇集在一起,而且是秒级的力度,这个力度因为指标量大,时间粒度比较细,我们服务机器的服务数越来越大,现在还碰不到瓶颈。
不适宜多维度索引、需要事务、稳定性要求极高;
关于Hbase使用。现在用Hbase的公司越来越多,2011年淘宝这一块就已经开始在线上大规模使用,Hbase这一块很稳定,从0.96之后就已经可以说到非常稳定,1.0有一些变化,1.0之后的Hbase是值得大家使用的。
rowkey设计可以写一本书,这里只做简单介绍。Hbase没有索引,所以rowkey非常关键,我们通过rowkey定位到数据,如果通过rowkey能约精确定位到数据,查询效率越高,用这个思路看看业务场景和看看使用,可以做一些相应的优化,做一些提升。
HBase不适宜的场景,包括多维度索引、需要事务、稳定性要求极高。
关注写热点,一般,按照默认的Region Split方案,上线后如果写压力比较大,都会有写热点的问题,这时需要考虑预建region。再就是写压内考虑writebuffer、WAL、autoflush,我写的要求很高,数据一致性要求很高那这事就不好办,只有做权衡,写性能上和数据一致上做权衡,下面三个参数只要你调了或者关了,可用性就会丢,有这个风险择,这是预先告诉大家。
对日志类的表化考虑关闭compact,手动触发GC。
Open TSDB表设计和原数据和数据表。这是官方图,讲得非常透,大家看一下怎么保证维的很多,数据量很大的时候,能够基于open TSDB把这么一个系统做得高效,就是通过一套rowkey,还有右图按照时间力度做row的压缩,我觉得主要这两个特性保证它的性能。
这是跟open TSDB密切相关的两个点。
这一块我们现在斗鱼用得规模比较大,和大公司比可能就有一点小巫见大巫,但是我还是想分享一下,从0到1的过程,包括第三点,从1到1.1的过程。
流计算。比如,我们上了一个专题或者我刚开始提到,英雄联盟有一个决赛,线上有量,量有多大,只能根据卡不卡,只能主观上感觉卡不卡做一个评估。后台服务器的一些数据指标比较延时,刚开始靠猜,靠感觉,感觉要上机器了,要调一些流或者压力到另外一部分机上,靠感觉。
包括有一些上专题,比方说有一些活动,锤子或者魅族、乐视新品发布,他们的量,有时候没有能想象的大,有时候会非常大,但是我们没有办法做一些预案,所以这个时候我们就慢慢有了这个,这是我们最开始的一个迫于压力有了这样一个方案,redis实时统计的量。
用户多了,鸟就多了,各种羊毛党就越多,这一块有了一个风控,再一个个性推荐,用户多了之后,用户群体户越来越多样化,这一块就考虑个性推荐,千人千面,这一块是后来第二阶段的需求。就有了现在storm加spark Streaming的方案在跑。
这是数据流的架构,最开始只有最上面的架构,web、APP,在Nginx Lua,这是锤子2发布会捐赠的一个项目,他把世界上最快的两个系统,一个是Nginx和Lua,加在一起性能非常好强悍。基于Lua和redis,性能好,又好用又稳定,又不吃资源。
到了Kafka这一层,就有了另外的一些数据,比方用户行为数据接入进来,关系表MySQL,我们没有其它的关系存储。到了Kafka出来之后就是storm,是线上规模用得最大,我刚才说的数据产品都是基于storm,后面简单介绍一下storm踩过一些坑。
Spark吞吐量是非常好的,因为两个数据模型就决定了他们两个侧重业务场景是不一样的,后面离线计算,这个中间有一个是数据应用层,我们可以从实时计算到数据应用层,会写到中间离线层,又有另外一批数据到前面的应用层,实时数据监控和其它应用。
刚刚讲了数据收集这一块,尤其用户行为数据,包括另外有一些服务层的服务,开始堆PHP,太耗资源,我们就发现OpenResty。
再用Storm,我先把这个罗列在这个地方,Storm优化主要就是基于这两个逻辑对象图。
Storm的新版本中,已经剥离了对ZK的依赖。我们所有的调优调这几个对象的参数,比方提高并行度,我们要提高时间时效,就是基于这个图。
这个图中,数据流怎么从这个流程里面最快的流入,最快流出,这就是实时流计算的初衷或者说包括最终的解决方案,也就是一直在优化。就比方说我们在第一级Kafka或者redis出来之后进到storm,越简单越快把消息弄进来最好。弄进来之后越快把消息处理完统计完把数据推走,越快推走对压力越小,处理时效吞吐量越大。
如果我们做优化,会去分析在第一个bolt1或者bolt2,如果里面有堆积,是在哪一个逻辑里面堆积,会考虑增加并行度或简化它的逻辑,让数据流尽快从第一级到 第二级到第三级,流出数据流程,我们整个优化的思路就是这样。
bolt1、2到bolt3,想跟大家分享,我们很多时候优化Storm忽略一个点,Storm依赖外部资源会成会我们的瓶颈,我们的数据没办法往外面推,没办法落地,后面一层堆积也会直接制约我们优化的一个瓶颈。
我们最后往redis写,性能强悍,你一个storm没问题,当时用一个redis做一些hush,做分散,还是解决不了,后来把redis替换掉。
这是我们在storm优化整体的思路,比较简单,主要几大块。 spout数和Kafka中的话题的partition数相匹配。 监控每一个执行的时效,去做监控,及时发现某一些componet要不要做优化。
我们最开始上storm就有了spark流,流利用在时空监控的场景,这是今年2016年的大方向。
缓存需要经常使用的数据
这是流的简单使用有一些心得,踩过一些坑。批处理时间。换粗需要经常的使用的数据。集群task并行度,使用Kryo序列化。
这是我们踩过的巨坑,最后和大家强调一下。
第一个踩过的巨坑就是监控。
我们有很多量,现象级的,百万级的用户立马在一秒到十秒用涌入一个直播间,这个直播间放在和其它直播间放在一个server上面,立马卡顿不卡用,如果在监控这一块,可以解决很多的一些告警和预警。包括有一些业务的指标监控,监控这一块非常重要。
今年做了比较大的一块,就是在做统一监控平台,现在我们也是在花主要的开发资源做这一块,因为我们前端有网站端后端有C++服务端,语言异构排查起来就存在,没法定位,第一反应大家很本能甩锅,就需要统一监控平台。
最开始太粗放,我们最开始做网络隔离,我们的集群是第一次做了网络上的隔离,然后后来就包括人员越来越大,因为不可能是我一个人干,也不可能做这么多业务场景,用的人越来越多,包括其它团队,业务分析师做数据分析用到线上环境,这个地方安全非常重要。
预估业务、提需求,上机器这么一套下来,就一两个月,小公司不要扣这部分的成本,起码预留20%的量。
探索式数据集市、推荐系统、风控系统,这是我们今年最大的三块目标。
LZ本硕某985,专业是电子信息相关,秋招找的工作都是Java后端相关方向,投了有几十家,情况大致如下:
可以看出来,秋招成绩很垃圾,投了这么多公司,offer屈指可数,且公司几乎都是末流互联网或国企,说实话最后结果虽然差强人意,但是留下了诸多遗憾,在这里也想给能看到我帖子的学弟学妹们一些经验,少走弯路。
LZ本硕都是电子信息相关,本科时候没怎么好好学习,大四匆匆忙忙考了本校的研究生,还是专硕,两年,基本上入学到你找工作就一年的时间,本来时间就不太充裕,加上一些学习策略出了问题,导致自己秋招找工作时,竞争力很弱,最后offer情况很稀烂。
LZ从18年7月份因为实验室项目开始接触安卓开发,下半年的时间都在学习Java语言,事实证明这是个非常非常错误的行为,因为浪费了太多宝贵的时间,基本上是从过年之后才开始学习并发编程,虚拟机,算法,项目等这些东西,时间明显不够,且这里策略也有问题,边学习,边找实习,实习找的情况很不如意,因为自身能力当时就很欠缺的,不如花时间好好准备复习,后面我会给大家列举出一些我自己踩过的坑并给出我的建议,希望对大家有用。
大小公司,这里主要针对互联网公司说,国企的话,谈大小没有意义。
对应届生来说,当然还是推荐去大公司,大公司像BAT这种,培训体系完整,流程规范,牛人众多,对自身的成长是十分有利的,小公司的话有可能当你第二年你入职时所在的部门就撤了,或者公司活不下去了等等,当然大公司也不是没裁过应届生,比如某东,某易,不过大厂裁员毕竟是小概率事件。去大公司不管是对技术的成长,人脉的拓展等各方面都是比较好的,推荐大家能去大公司尽量去大公司。
互联网的技术职位主要分这么几类:
前端、后端、客户端(Android&ios)、测试、算法、数据类(数据分析、数据库工程师等)
大家可以根据自己的情况选择岗位,进行针对性的复习。就今年的情况来看 算法岗及其惨烈,尤其是CV方向,然后算法转开发的较多,基本上也都转的后端,所以今年后端情况也比较惨,尤其是Java后端,C++后端情况相对更好。这里给大家一些选择岗位的建议:
总的来说,国企在面试时相对简单,比较看重学校学历,互联网的话面试更偏技术,但是每家公司每个面试官也有自己的风格,比如有的面试官喜欢问项目,有的则全程对基础,这两种各有利弊,自己的临场发挥也很重要。
下面是我的一些面试经历,想看的可以看看。
对一个学生要求经验确实不太应该,但是我上午面的其他三个人都 写了这些,你这一对比就吃亏了
面试体验:题目不难,面试官nice,说一定选好方向,不然你到时候跳槽都不好跳,一定把自己朝着专家去努力
面试官评价:基础不错,思路清晰,经验不足
一共半个小时左右,不算难,不会的是真不会。。最后说是不太符合岗位需求,但是纠结一下,应该就是挂了。。
2、项目介绍,难点(组织语言)
4、分布式锁,三个服务功能一样在不同的机器上,怎么调用,不知道,面试官说,使用一个数据库,使用某一个服务的时候先去获得锁,将某个字段置1,获得锁的命令,select…for update,
如果获得了锁,这个服务挂了,怎么办,加个超时时间,加在哪?数据库应该不能加,就加在业务逻辑,获得数据库锁之后,更新字段值之后设置超时时间
5、进程通信,控制对资源的访问,信号量,还有其他进程通信的方式吗,没说全
6、进程怎么管理文件,什么数据结构,数组。。。(这个不会)
9、设计模式,问了工厂、装饰器
10、平常用什么管理代码,git,stash用过没,了解没用过
11、面试官:IT技能只写了Java基础、数据库这些,开源软件(netty、redis这些)不了解
对一个学生确实不应该要求什么经验,但是别人简历写了,自己就吃亏
12、可能面试官做分布式的,让我选好方向。。
今年华为的难度明显提升了,不仅是面试流程面试难度上的,而且在简历筛选上也严格了,我当天面试的时候, 一个时间点的一批也就二十几个人吧,而且我的很多同学甚至都没收到面试通知
2、问项目,基本上自我介绍完,都会顺着你问项目,画了结构图(幸好提前准备了,线下面试一定会让你写写画画的),项目的话回答还算顺利,一面问的项目方面的,主要关注具体的实现以及所用的技术,只要是自己做的基本都没问题
3、撕代码,顺着项目问的,项目中用到了消息队列,就是“生产者-消费者”,面试官说你写一个线程安全的消费者和生产者模型吧,用了 队列对象的wait和notify实现,一个空,一个满,其实写的是有点问题的,应该使用synchronized + 对象的wait/notify,synchronized保证每次只能消费或生产
5、闲聊问答:代码量,Java自学,Java常用包(碰见很多次了,估计是测试你的熟练度),考研/保研,成绩,奖学金,专利,碰到问题怎么解决(看优质博客,关注优秀作者,google外网等)
一面很顺利,面试官很可能也不是做Java的
1、上来自我介绍,没说完,就开始问
2、基本还是项目为主,项目开始关注一些扩展,如何保证正确,如果通知失败的记录你们怎么处理的,重发到消息队列时队首还是队尾,还是业务技术为主,但是扩展了,回答的不是很好
3、手撕代码:题目比较简单,将一个数组中的全部0移动到数组末尾
很简单,但是没考虑完善,写的是先遍历一遍找出0的个数,再遍历一遍将所有的非零依次挪到数组前端,其实这个遍历就可以找出0的个数,只需一遍遍历,被面试官一眼看出,很尴尬
4、写代码的时候还被问到,另一个项目是不是用的现成的类库,问库名(SensorManager),我说忘了。。真的僵硬,说完忘了,面试官立即在简历上写了啥
二面不是很顺利,好几个问题回答的不好
1、盯着项目问,太宏观了,确实我也想过这些问题,但是没有途径了解,下周回公司争取弄清楚
“为什么做这个平台,之前是怎么通知的”
“服务商,能具体举个例子吗” 其实这个我也想过的,当时没说出来,可惜
“这个平台的交互方都是谁啊,调用方具体谁啊”
2、 证书(没有,还狡辩说看看书就行,被怼需要理论基础啊),竞赛(没有)
3、爱好,女朋友,城镇/农村,意向城市
等通知吧,一周内出结果
三面整体不太好,也有可能是所谓的压力测试吧,但是没有 竞赛、证书这些真的难受
希望评级不要太差,等消息!
8.7投递,8.10笔试,a了1.67,笔试未过,本身也不算大厂吧,投递的是第二批笔试,笔试还做得垃圾,没过也在意料之中,越早越有机会。。
群面,一组七八个人,上来是一分钟的自我介绍,感觉其他人介绍的都很猛,我就说了半分钟左右,介绍的时候不能
接下来是两到题目,放在投影上,第一个是如何设计互联网银行系统,主要说是客户多,并发高,朝这个思路去写,
网上博客很对,第二个题是 将两个有序数组nums1和nums2合并到nums1,代码不难,就是两个题加起来只有几分钟
的时间,所以我的建议是尽量写第一个,因为第二个可以口述思路,第一个是要求画什么架构的,当然题目可能会
变,题目使用马克笔写在白纸上的,写完还要举起来给面试官看
最后是面试官对个别学生进行提问,都会问到,但是可能问的题不一样,也是看你回答来问的,问到的有 MySQL如何
分表,垂直跟水平分的区别,mvc的处理流程,springboot是怎么回事,这些都是先问你项目的框架,再展开问的
问我的是消息队列的优点和缺点,这个我是在回答设计那个系统的时候写了,其他也问了项目的问题
为什么使用抽象类,因为可以方便地使用模板方法;ConcurrentHashMap中读是不需要加锁的,因为使用了volatile关键字
不知道还有没有后续,现在都9.11了
代码还是不能丢,保持手感!
上来开始问项目,简单介绍了下
线程的状态,六种,阻塞跟等待的区别,线程阻塞的方式,sleep join object.wait,
jvm的内存分布,线程由初始化到就绪,jvm内存做了什么(不知道。。。)
锁,synchronized实现非公平咋实现。。可重入不可重入
hashmap为什么推荐String做为key,我答hash冲突少吧。。其实是String是不可变类,更安全
mvc的处理过程(记得不太好),struct了解吗。。不会也没关系
数据库的索引,b+树,hash索引,各自使用的场景(再熟练点),事务的ACID,A还忘了,艹,最后想起来是原子性
隔离级别,怎么解决幻读(临键锁),临键锁是啥。。。(没仔细看。。),分布式事务了解吗,(不了解)
撸代码,剑指offer原题 二叉树的下一个节点 题目还是要再熟悉下,写了太长时间
最后面试官说我 条理不清晰,有些公司会看你条理清晰,表述清晰,二面如果有的话会更加要求广度深度。希望能有二面吧。