蚂蚁金服一面:分布式架构 50分钟
1、个人介绍加项目介绍20分钟
微服务架构:就是将单个的整体应用程序分割成更小的
项目关联的
独立的服务。一个服务通常实现一组独立的特性或功能,包含自己的业务
逻辑。各个微服务之间的关联通过暴露api
来实现。这些独立的微服务不需要部署在同一个虚拟机,同一个系统和同一个应用服务器中。每个服务有自己的数据库,甚至可以使用不同的架构(当然一般情况下需要保持统一方便维护)
优缺点:
单一架构模式在项目初期很小
的时候开发方便,测试方便,部署方便,运行良好。可是当应用随着时间的推进,加入的功能越来越多,最终会变得巨大,一个项目中很有可能数百万行的代码,互相之间繁琐的jar包。
1、 不再适用敏捷开发,过于复杂,任何开发者都不能够完全理解,修复漏洞和实现新功能变得困难和耗时。
2、 规模越大,启动时间越长,自然会拖慢开发进度,一个小功能的修改部署起来变得困难,必须重新部署整个应用。
3、 系统的不同的模块的需要不同的特定的虚拟机环境时,由于是整体应用,那么只能折中选择。
4、 任意模块的漏洞或者错误都会影响这个应用,降低系统的可靠性
5、 还有一个如果想整体应用采用新的技术,新的框架或者语言,那是不可能的。
优点
如果采用微服务架构模式,则可以解决单一架构模式带来的系统复杂性。主要包括以下几个好处:
1、 由于每个服务都是独立并且微小的,由单独的团队负责,仍然可以采用敏捷开发模式,自由的选择合适的技术,甚至可以重写老服务,当然都要遵守统一的API约定。
2、 每一个微服务都是独立部署的,可以进行快速迭代部署,根据各自服务需求选择合适的虚拟机和使用最匹配的服务资源要求的硬件。
3、 整体应用程序被分解成可管理的模块和服务,单个的服务可以更快的开发、更简单的理解和维护。
4、 一些需要进行负载均衡的服务可以部署在多个云虚拟机上,加入NGINX这样的负载均衡器在多个实例之间分发请求,这样不需要整个应用进行负载均衡了。
每个后端服务暴露一套REST API,大部分服务调用其他服务提供的API。每个服务都有自己的数据库模式,而不是共享单个数据库模式。尽管这会造成某些数据的冗余,但是对于微服务架构这个独立数据库模式是必要的,确保了独立服务之间的松散耦合。
缺点
1、 微服务应用作为分布式系统带来了复杂性。当应用是整体应用程序时,模块之间调用都在应用之内,即使进行分布式部署,依然在应用内调用。可是微服务是多个独立的服务,当进行模块调用的时候,分布式将会麻烦。
2、 多个独立数据库,事务的实现更具挑战性。
3、 测试微服务变得复杂,当一个服务依赖另外一个服务时,测试时候需要另外一个服务的支持。
4、 部署基于微服务的应用也很复杂,整体应用程序部署只需要部署在一组相同的服务器上,在这些服务前面加入传统的负载均衡器即可。独立服务的不是讲变得复杂,需要更高的自动化形式。
事务的4大特性(ACID)
事务的隔离级别从低到高
隔离级别设置不当引发的问题:
添加
和删除
。
例如:系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条具体分数的记录,当系统管理员A改结束后发现还有一条记录没有改过来,就好像发生了幻觉一样。这就叫幻读。
解决办法:把数据库的事务隔离级别调整到SERIALIZABLE_READ
注意:
脏读、不可重复读、幻读的级别高低是:脏读 < 不可重复读 < 幻读
。所以,设置了最高级别的SERIALIZABLE_READ就不用在设置REPEATABLE_READ和READ_COMMITTED了
不可重复读重点修改
;幻读重点是新增、删除
CAP原理 在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer’s theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:
CAP原理指的是,CAP的三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行分布式架构设计时,必须做出取舍。而对于分布式数据系统,分区容忍性是基本要求,否则就失去了价值。
因此设计分布式数据系统,就是在一致性和可用性之间取一个平衡。对于大多数web应用,其实并不需要强一致性,因此牺牲一致性而换取高可用性,是目前多数分布式数据库产品的方向。
当然,并不是完全不管数据的一致性。牺牲一致性,只是不再要求关系型数据库中的强一致性,而是只要系统能达到最终一致性即可,考虑到客户体验,这个最终一致的时间窗口,要尽可能的对用户透明,也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的,“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。
一致性模型
上述最终一致性的不同方式可以进行组合,例如单调读一致性和读己之所写一致性就可以组合实现。并且从实践的角度来看,这两者的组合,读取自己更新的 数据,和一旦读取到最新的版本不会再读取旧版本,对于此架构上的程序开发来说,会少很多额外的烦恼。
BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。Redis等众多系统构建于这个理论之上。
BASE和ACID的区别与联系
ACID,是指数据库管理系统(DBMS)在写入/更新资料的过程中,为保证事务(transaction)是正确可靠的,所必须具备的四个特性:原子性(atomicity,或称不可分割性)、一致性(consistency)、隔离性(isolation,又称独立性)、持久性(durability)。
ACID是传统数据库常用的设计理念, 追求强一致性模型。BASE支持的是大型分布式系统,提出通过牺牲强一致性获得高可用性。
ACID和BASE代表了两种截然相反的设计哲学,分处【一致性-可用性】分布图谱的两极。
5、RPC过程
6、服务注册中心宕机了怎么办?
7、微服务还有其他什么组件
8、分布式架构与微服务的关系
9、你有什么问题要问我的。
蚂蚁金服二面:1个小时
上来不用自我介绍,项目介绍,直接开始
算法来两道
1、各种排序算法、未排序常规数据查找第K大的数,时间复杂度。
2、二叉树的深度
操作系统来两道
3、虚拟内存分页了解不?
4、进程和线程区别?
独立的地址空间
,而线程没有
,线程必须依赖于进程而存在。
资源共享方面:进程之间不能共享资源
,而线程共享
所在进程的地址空间
和其它资源
。同时线程还有自己的栈和栈指针,程序计数器等寄存器。
开销方面。进程切换的开销较大。线程相对较小。(前面也提到过,引入线程也出于了开销的考虑。)
5、第一二三范式是什么?
6、一个表一千个列值为true和false,写sql 查询 有300个列值为true的行。
select * from your_table as yt inner join ( select id as id, col1+col2+...+col1000 as s from your_table ) as t on [yt.id](http://yt.id/) = [t.id](http://t.id/) and t.s = 300
7、脏读和幻读是什么?
回滚前
的脏数据。比如事务B执行过程中修改了数据X,在未提交前,事务A读取了X,而事务B却回滚了,这样事务A就形成了脏读。JVM
8、什么对象会从新生代晋升到老年代
多线程
9、一个任务分成十个任务,最后汇总计算,不能用fork/join
10、开源框架源码了解不?
11、数据建模两道、个人题开放性题
安全方面的问题
12、对安全方面了解多少?
13、 安全协议有哪些 、https是啥?
介绍你做的项目和其中的难点。
三面
个人感觉着重技术深度。
1、从ConcurrentHashMap一路问到锁&锁优化->LongAdder->伪共享->缓存行填充->cas等诸多技术细节;
2、从hystrix一路问到原理->自己如何实现->如何优化->响应流编程(reactive streams);
3、从简单的生产者消费者模式设计到如何高效健壮实现等等。
四面
1、如何倒序输出单向链表?
2、个人直接想法是用栈先进后出的特点,把链表数据读到栈里然后输出。
3、有更好的实现方式吗?
4、主要问项目情况,然后根据一个项目,问如果量级扩大1000倍,你会怎么做?有哪些优化措施?高性能&高可用措施?
五面:HR面
给大家抛出几大深坑问题:
1、个人的职业规划是什么
2、你遇到的最大问题或者是困难是什么
3、你如何看待阿里
4、你能为阿里带来什么
5、你的优缺点是什么
这几个问题,大家深思啊,不多说。
面试总结:
1.技术基础必须扎实:算法、数据结构、操作系统等,蚂蚁金服面试对技术的基础非常重视,基础扎实的同学有利于在前两轮突出重围。
2.技术宽度:主要集中在高并发、多线程、分布式架构,大以及常用中间件(缓存等)的选型和比较。
3.技术原理深入:重点还是提前准备好JVM、多线程高并发这块。
4.参与的项目总结:你需要清楚你所做项目的关键细节、优化、特点、原理。
5.很多所用第三方库&中间件等的原理,即使你不知道,也要有自己的想法能够说出如何代替实现,比如单点登录的替代方案。
6.最好,提前准备一个大数据访问,比如pv扩大1000倍,你的架构或者技术方案应对措施。
7.最后,千万不要倒在HR面试环节,避重就轻是重点,特别是优点和缺点,如果问到你的规划是什么,请记得一定告诉HR你想成为一名优秀的技术专家!
以上就是我的6总结,这些都是不断面试积累来的经验,分享出来避免更多同学少走弯路,早日进入BAT等一线互联网公司!