最后
关于面试刷题也是有方法可言的，建议最好是按照专题来进行，然后由基础到高级，由浅入深来，效果会更好。当然，这些内容我也全部整理在一份pdf文档内，分成了以下几大专题：
- Java基础部分
- 算法与编程
- 数据库部分
- 流行的框架与新技术（Spring+SpringCloud+SpringCloudAlibaba）
这份面试文档当然不止这些内容，实际上像JVM、设计模式、ZK、MQ、数据结构等其他部分的面试内容均有涉及，因为文章篇幅，就不全部在这里阐述了。
作为一名程序员，阶段性的学习是必不可少的，而且需要保持一定的持续性，这次在这个阶段内，我对一些重点的知识点进行了系统的复习，一方面巩固了自己的基础，另一方面也提升了自己的知识广度和深度。
也许是数据库表结构不一致；也许是接口变化导致的通信失败；也许是配置错误导致 连接失败；也许是依赖的服务线上环境还没有准备好，这些问题都有可能导致应用故障。
因此在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发 布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行 一些典型的业务流程，确认系统没有问题后才正式发布。
预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的不同就是没 有配置在负载均衡服务器上，外部用户无法访问，如图5.15所示。
预发布服务器和线上正式服务器（应用服务器1, 2, 3 ）都部署在相同的物理环境（同一个数据中心甚至同一个机架上，如果使用虚拟机，甚至可能在同一个物理服务器上） 中，使用相同的线上配置，依赖相同的外部服务。网站工程师通过在自己的开发用计算 机上配置hosts文件绑定域名IP关系直接使用IP地址访问预发布服务器。如果在预发布 服务器上执行的测试验证是正确的，基本可以确保在线上正式服务器部署时也没有问题。
不过，也有可能会因为预发布验证而引入问题。因为预发布服务器连接的是真实的 生产环境，所有的预发布验证操作都是真实有效的数据，这些操作也许会引起不可预期 的问题。比如创建一个店铺，上架一个商品，就有可能有真的用户过来购买，如果不能 发货，会导致用户投诉。
一个真实的案例是某网站需要验证海外第三方支付功能，每件商品的售价本来是数 千美金，工程师不可能花数千美金去验证自己开发的功能，于是将金额改成一美元，验 证成功后，幸福地发布上线了，第二天上班后，发现大量商品以一美元的价格成交。
此外，在网站应用中强调的一个处理错误的理念是快速失败（fast failed ），即如果系 统在启动时发现问题就立刻抛岀异常，停止启动让工程师介入排查错误，而不是启动后 执行错误的操作。
4 代码控制
对于大型网站，核心应用系统和公用业务模块涉及许多团队和工程师，需要对相同 的代码库进行共同开发和维护。而这些团队对同一个应用的开发维护（开发周期和发布 时间点各不相同），如果代码控制环节岀了问题，可能将有问题的代码发布上线，将问题 带入生产环境，导致系统故障。
网站代码控制的核心问题是如何进行代码管理，既能保证代码发布版本的稳定正确,
同时又能保证不同团队的开发互不影响。
目前大部分网站使用的源代码版本控制工具是SVN, SVN代码控制和版本发布方式 般有以下两种。
- 主干开发、分支发布
代码修改都在主干（trunk ）上进行，需要发布的时候，从主干上拉一个分支（branch ） 发布，该分支即成为一个发布版本，如果该版本发现Bug,继续在该分支上修改发布，并
将修改合并(merge )回主干，直到下次主干发布。
- 分支开发，主干发布
任何修改都不得在主干上直接进行，需要开发一个新功能或者修复一个Bug时，从 主干拉一个分支进行开发，开发完成且测试通过后，合并回主干，然后从主干进行发布, 主干上的代码永远是最新发布的版本。
这两种方式各有优缺点。主干开发、分支发布方式，主干代码反应目前整个应用的 状态，一目了然，便于管理和控制，也利于持续集成。分支开发，主干发布方式，各个 分支独立进行，互不干扰，可以使不同发布周期的开发在同一应用中进行。
目前网站应用开发中主要使用的是分支开发、主干发布的方式，如图5.16所示。
可以想象，如果使用主干开发、分支发布，那么在同一个应用上，对于不同开发周 期，不同发布时间的项目，有可能A项目发布的时候，B项目只开发了一半，这时候的 主干代码是半成品，根本不能发布。而使用分支开发、主干发布的方式，只需要将A项 目的分支合并回主干即可发布，不受B项目发布时间的影响。
目前在开源技术社区，Git作为版本控制工具，正逐步取代SVN的地位。Git对分布 式开发，分支开发等有更好的支持，也更容易在各个开发分支上及时反映主干的最新更 新，避免SVN在最后提交分支代码时发现和主干代码差别太大难以merge成功。但是Git 的学习成本较高，如何和网站开发流程相结合还缺乏最佳实践和使用规范。不过相信Git 成为网站的标准版本控制工具是迟早的事。
5 自动化发布
网站的版本发布频繁，整个发布过程需要许多团队通力合作，发布前，多个代码分 支合并回主干可能会发生冲突（conflict）,预发布验证也会带来风险，每次发布又相当于 一次宕机事故。因此网站发布过程荆棘丛生，一不小心就会踩到雷。
对于有固定发布日期的网站（很多网站选择周四作为发布日，这样一周前面有三天时间可以准备发布，后面还有一天时间可以挽回错误。如果选择周五发布，发现文件就必须要周末加班了。），一到发布日，整个技术部门甚至运营部门就如临大敌，电话声此 起彼伏，工程师步履匆匆，连空气中的温度都仿佛升高了几度。即便如此，发布过程还 是常常岀错，发布日工程师加班到凌晨是常有的事。而且容易忙中岀错，因发布引发的 故障也居高不下。
据说国外某知名互联网公司的CTO就因为没有有效手段控制发布故障、减少发布日 的加班而引咎辞职。其继任者提出了一个火车发布模型：将每个应用的发布过程看作一 次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目 下车，剩下的项目继续坐着火车旅行，直到火车到达终点（应用发布成功）。但实际中， 有可能所有项目都下车了，开着空车前进是没有意义的，火车不得不回到起点，等待解 决了问题再重来一次。还有可能是车上有达官贵人（重点项目，CEO跟投资人拍胸脯的 项目），他不上车，谁也别想走，他出了错，大家都跟着回去重来。简化的火车发布模型 如图5.17所示。
由于火车发布模型是基于规则驱动的流程，所以这个流程可以自动化。采用火车发 布模型的网站会开发一个自动化发布的工具实现发布过程的自动化。根据响应驱动流程, 自动构造代码分支，进行代码合并，执行发布脚本等。正常流程下，可以做到发布过程无人值守，无需SCM （网站配置管理员）参与，每个项目相关人员基于流程执行相应的 操作，即可完成应用自动发布。人的干预越少，自动化程度越高，引入故障的可能性就 越小，火车准点到达，大家按时下班的可能性就越大。
6 灰度发布
总结
对于面试还是要好好准备的，尤其是有些问题还是很容易挖坑的，例如你为什么离开现在的公司（你当然不应该抱怨现在的公司有哪些不好的地方，更多的应该表明自己想要寻找更好的发展机会，自己的一些现实因素，比如对于我而言是现在应聘的公司离自己的家更近，又或者是自己工作到达了迷茫期，想跳出迷茫期等等）
Java面试精选题、架构实战文档
整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~
你的支持，我的动力；祝各位前程似锦，offer不断！
新讲解视频+实战项目源码】](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)收录**
3479
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
