蚂蚁金服一面：分布式架构 50分钟
1、个人介绍加项目介绍20分钟
2、微服务架构是什么，它的优缺点？
微服务架构：就是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。每个服务有自己的数据库，甚至可以使用不同的架构（当然一般情况下需要保持统一方便维护）
优缺点：
单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。可是当应用随着时间的推进，加入的功能越来越多，最终会变得巨大，一个项目中很有可能数百万行的代码，互相之间繁琐的jar包。
1、 不再适用敏捷开发，过于复杂，任何开发者都不能够完全理解，修复漏洞和实现新功能变得困难和耗时。
2、 规模越大，启动时间越长，自然会拖慢开发进度，一个小功能的修改部署起来变得困难，必须重新部署整个应用。
3、 系统的不同的模块的需要不同的特定的虚拟机环境时，由于是整体应用，那么只能折中选择。
4、 任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性
5、 还有一个如果想整体应用采用新的技术，新的框架或者语言，那是不可能的。
优点
如果采用微服务架构模式，则可以解决单一架构模式带来的系统复杂性。主要包括以下几个好处：
1、 由于每个服务都是独立并且微小的，由单独的团队负责，仍然可以采用敏捷开发模式，自由的选择合适的技术，甚至可以重写老服务，当然都要遵守统一的API约定。
2、 每一个微服务都是独立部署的，可以进行快速迭代部署，根据各自服务需求选择合适的虚拟机和使用最匹配的服务资源要求的硬件。
3、 整体应用程序被分解成可管理的模块和服务，单个的服务可以更快的开发、更简单的理解和维护。
4、 一些需要进行负载均衡的服务可以部署在多个云虚拟机上，加入NGINX这样的负载均衡器在多个实例之间分发请求，这样不需要整个应用进行负载均衡了。
每个后端服务暴露一套REST API，大部分服务调用其他服务提供的API。每个服务都有自己的数据库模式，而不是共享单个数据库模式。尽管这会造成某些数据的冗余，但是对于微服务架构这个独立数据库模式是必要的，确保了独立服务之间的松散耦合。
缺点
1、 微服务应用作为分布式系统带来了复杂性。当应用是整体应用程序时，模块之间调用都在应用之内，即使进行分布式部署，依然在应用内调用。可是微服务是多个独立的服务，当进行模块调用的时候，分布式将会麻烦。
2、 多个独立数据库，事务的实现更具挑战性。
3、 测试微服务变得复杂，当一个服务依赖另外一个服务时，测试时候需要另外一个服务的支持。
4、 部署基于微服务的应用也很复杂，整体应用程序部署只需要部署在一组相同的服务器上，在这些服务前面加入传统的负载均衡器即可。独立服务的不是讲变得复杂，需要更高的自动化形式。
3、ACID CAP BASE理论
事务的4大特性（ACID）
- 原子性(Atomicity)：事务是数据库的逻辑工作单位，它对数据库的修改要么全部执行，要么全部不执行。
- 一致性(Consistemcy)：事务前后，数据库的状态都满足所有的完整性约束。
- 隔离性(Isolation)： 并发执行的N个事务是隔离的，一个不影响一个，一个事务在没有commit之前，被修改的数据不可能被其他事务看到（通过设置数据库的隔离级别）。
- 持久性(Durability)： 持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。持久性主要在于DBMS的恢复性能。
事务的隔离级别从低到高
- Read Uncommitted：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
- Read Committed：只有在事务提交后，其更新结果才会被其他事务看见。解决脏读问题。
- Repeated Read：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
- Serialization：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。通常，在工程实践中，为了性能的考虑会对隔离性进行折中。
隔离级别设置不当引发的问题：
-
脏读
脏读又称无效数据读出。一个事务读取另外一个事务还没有提交的数据叫脏读。
例如：事务T1修改了一行数据，但是还没有提交，这时候事务T2读取了被事务T1修改后的数据，之后事务T1因为某种原因Rollback了，那么事务T2读取的数据就是脏的。
解决办法：把数据库的事务隔离级别调整到READ_COMMITTED
-
不可重复读
不可重复读是指在同一个事务内，两个相同的查询返回了不同结果。
例如：事务T1读取某一数据，事务T2读取并修改了该数据，T1为了对读取值进行检验而再次读取该数据，便得到了不同的结果。
解决办法：把数据库的事务隔离级别调整到REPEATABLE_READ -
幻读
幻读是指同一个事务内，两个相同的查询返回了不同结果,只是它关注的是
添加和删除。例如：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样。这就叫幻读。
解决办法：把数据库的事务隔离级别调整到SERIALIZABLE_READ
注意：
脏读、不可重复读、幻读的级别高低是：脏读 < 不可重复读 < 幻读。所以，设置了最高级别的SERIALIZABLE_READ就不用在设置REPEATABLE_READ和READ_COMMITTED了
不可重复读重点修改；幻读重点是新增、删除
CAP原理
在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：
一致性（Consistence）
分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）可用性（Availability）
集群出现故障节点后，是否还能响应客户端的读写请求。（对数据更新具备高可用性）分区容忍性（Partition tolerance）
实际中通信产生延时。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C点和A点之间做出选择。
CAP原理指的是，CAP的三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。
因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。
当然，并不是完全不管数据的一致性。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。
一致性模型
强一致性
当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。但是这种实现对性能影响较大。弱一致性
系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。但会尽可能保证在某个时间级别（比如秒级别）之后，可以让数据达到一致性状态。最终一致性
弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS是一个典型的最终一致性系统。-
最终一致性模型的变种
- 因果一致性：如果A进程在更新之后向B进程通知更新的完成，那么B的访问操作将会返回更新的值。如果没有因果关系的C进程将会遵循最终一致性的规则。
- 读己所写一致性：因果一致性的特定形式。一个进程总可以读到自己更新的数据。
- 会话一致性：读己所写一致性的特定形式。进程在访问存储系统同一个会话内，系统保证该进程读己之所写。
- 单调读一致性：如果一个进程已经读取到一个特定值，那么该进程不会读取到该值以前的任何值。
- 单调写一致性：系统保证对同一个进程的写操作串行化。
上述最终一致性的不同方式可以进行组合，例如单调读一致性和读己之所写一致性就可以组合实现。并且从实践的角度来看，这两者的组合，读取自己更新的 数据，和一旦读取到最新的版本不会再读取旧版本，对于此架构上的程序开发来说，会少很多额外的烦恼。
BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。Redis等众多系统构建于这个理论之上。
基本可用（Basically Available）
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。软状态（ Soft State）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。最终一致性（ Eventual Consistency）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
BASE和ACID的区别与联系
ACID，是指数据库管理系统（DBMS）在写入/更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性：原子性（atomicity，或称不可分割性）、一致性（consistency）、隔离性（isolation，又称独立性）、持久性（durability）。
ACID是传统数据库常用的设计理念, 追求强一致性模型。BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。
ACID和BASE代表了两种截然相反的设计哲学，分处【一致性-可用性】分布图谱的两极。
4、分布式一致性协议，二段、三段、TCC，优缺点
5、RPC过程
6、服务注册中心宕机了怎么办？
7、微服务还有其他什么组件
8、分布式架构与微服务的关系
9、你有什么问题要问我的。
蚂蚁金服二面：1个小时
上来不用自我介绍，项目介绍，直接开始
算法来两道
1、各种排序算法、未排序常规数据查找第K大的数，时间复杂度。
2、二叉树的深度
操作系统来两道
3、虚拟内存分页了解不？
4、进程和线程区别？
-
进程与线程区别
定义方面：一个应用程序可以理解为一个进程，一个进程至少包含一个线程
角色方面：在支持线程机制的系统中，进程是系统资源分配的单位，线程是CPU调度的单位。独立性方面：进程有自己
独立的地址空间，而线程没有，线程必须依赖于进程而存在。资源共享方面：进程之间
不能共享资源，而线程共享所在进程的地址空间和其它资源。同时线程还有自己的栈和栈指针，程序计数器等寄存器。开销方面。进程切换的开销较大。线程相对较小。（前面也提到过，引入线程也出于了开销的考虑。）
数据库来三道
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就形成了脏读。-
[不可重复读]：事务A首先读取了一条数据，然后执行逻辑的时候，事务B将这条数据改变了，然后事务A再次读取的时候，发现数据不匹配了，就是所谓的[不可重复读]
也就是说，当前事务先进行了一次数据读取，然后再次读取到的数据是别的事务修改成功的数据，导致两次读取到的数据不匹配，也就照应了[不可重复读]
幻读：事务A首先根据条件索引得到N条数据，然后事务B改变了这N条数据之外的M条或者增添了M条符合事务A搜索条件的数据，导致事务A再次搜索发现有N+M条数据了，就产生了幻读。
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等一线互联网公司！