4.1.1 请解释什么是C10K问题或者知道什么是C10K问题吗？
网络服务在处理数以万计的客户端连接时，往往出现效率低下甚至完全瘫痪，这被称为C10K问题。随着互联网的迅速发展，越来越多的网络服务开始面临C10K问题，作为大型网站的开发人员有必要对C10K问题有一定的了解。(本文的主要参考文献是 http://www.kegel.com/c10k.htmls。) C10K问题的最大特点是：设计不够良好的程序，其性能和连接数及机器性能的关系往往是非线性的。举个例子：如果没有考虑过C10K问题，一个经典的基于select的程序能在旧服务器上很好处理1000并发的吞吐量，它在2倍性能新服务器上往往处理不了并发2000的吞吐量。这是因为在策略不当时，大量操作的消耗和当前连接数n成线性相关。会导致单个任务的资源消耗和当前连接数的关系会是O(n)。而服务程序需要同时对数以万计的socket进行I/O处理，积累下来的资源消耗会相当可观，这显然会导致系统吞吐量不能和机器性能匹配。为解决这个问题，必须改变对连接提供服务的策略。
4.1.2 Nginx简介，可参考《Nginx简介》
4.1.3 正向代理和反向代理.
可参见本博之前的文章
正向代理，代理的是用户;反向代理，代理的是服务器
4.1.4 Nginx几种常见的负载均衡策略
1、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
2、指定权重 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
3、IP绑定 ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
4、fair（第三方） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。
5、url_hash（第三方） 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
4.1.5 Nginx服务器上的Master和Worker进程分别是什么
master进程 :监控进程充当整个进程组与用户的交互接口，同时对进程进行监护。它不需要处理网络事件，不负责业务的执行，只会通过管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。
worker进程 :worker进程的主要任务是完成具体的任务逻辑。其主要关注点是与客户端或后端真实服务器（此时nginx作为中间代理）之间的数据可读/可写等I/O交互事件，所以工作进程的阻塞点是在像select()、epoll_wait()等这样的I/O多路复用函数调用处，以等待发生数据可读/写事件。当然也可能被新收到的进程信号中断。
master进程如何通通知worker进程去做某些工作呢？采用的是信号。 当收到信号时，信号处理函数ngx_signal_handler()就会执行。
4.1.6 使用“反向代理服务器”的优点是什么?
可以将优化的负载均衡策略和代理服务器的高速缓存技术结合在一起，提升静态网页的访问速度，提供有益的性能；由于网络外部用户不能直接访问真实的服务器，具备额外的安全性
###4.2、分布式其他 4.2.1 谈谈业务中使用分布式的场景
一、提供多个对外的接口，按照一定规则，分派不同请求由不同接口来处理。
二、把一个功能拆分成多个功能，不同功能分布部署到不同服务器上
对外功能的拆分
n层架构，其中的一些层分布到不同服务器上
4.2.2 Session 分布式方案
第一种：粘性session原理：粘性Session是指将用户锁定到某一个服务器上，比如上面说的例子，用户第一次请求时，负载均衡器将用户的请求转发到了A服务器上，如果负载均衡器设置了粘性Session的话，那么用户以后的每次请求都会转发到A服务器上，相当于把用户和A服务器粘到了一块，这就是粘性Session机制。
第二种：服务器session复制原理：任何一个服务器上的session发生改变（增删改），该节点会把这个 session的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要session，以此来保证Session同步。
第三种：session共享机制使用分布式缓存方案比如memcached、Redis，但是要求Memcached或Redis必须是集群。
第四种：session持久化到数据库原理：就不用多说了吧，拿出一个数据库，专门用来存储session信息。保证session的持久化。
优点：服务器出现问题，session不会丢失
缺点：如果网站的访问量很大，把session存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。
第五种terracotta实现session复制原理：Terracotta的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点。可以看成是对第二种方案的优化。
参考链接：集群/分布式环境下5种session处理策略
4.2.3 Session 分布式处理
4.2.4 分布式锁的应用场景、分布式锁的产生原因、基本概念
分布式锁，是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。
4.2.5 分布式锁的常见解决方案
zookeeper分布式锁，基于自增节点 redis分布式锁，基于setnx命令， memcache分布式锁，基于add函数参考链接：聊一聊分布式锁的设计
4.2.6 分布式事务的常见解决方案
a、两阶段提交（2PC）
b、补偿事务（TCC）
c、本地消息表（异步确保）
d、MQ 事务消息
e、Sagas 事务模型
参考链接：聊聊分布式事务，再说说解决方案
使用消息队列实现分布式事务-公认较为理想的分布式事务解决方案
4.2.7 集群与负载均衡的算法与实现
4.2.8 说说分库与分表设计，可参考《数据库分库分表策略的具体实现方案》
4.2.9 分库与分表带来的分布式困境与应对之策
4.3.1 什么是Dubbo，可参考《Dubbo入门》
Dubbo入门—搭建一个最简单的Demo框架
4.3.2 什么是RPC、如何实现RPC、RPC 的实现原理，可参考《基于HTTP的RPC实现》
4.3.3 Dubbo中的SPI是什么概念
SPI 全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制。 目前有不少框架用它来做服务的扩展发现， 简单来说，它就是一种动态替换发现的机制， 举个例子来说， 有个接口，想运行时动态的给它添加实现，你只需要添加一个实现，目前Dubbo框架就基于SPI机制提供扩展功能。我们首先需要一个目录，META-INF\services 如下，最终的目录路径就像这样：文件名字为 接口/抽象类： 全名 文件内容： 接口/抽象类 实现类 就像这样：com.spi.impl.TextHellocom.chaochao.spi.impl.ImageHello
dubbo的扩展机制和java的SPI机制非常相似，但是又增加了如下功能：
1 可以方便的获取某一个想要的扩展实现，java的SPI机制就没有提供这样的功能
2 对于扩展实现IOC依赖注入功能：
4.3.4 Dubbo的基本原理、执行流程
参考链接：Dubbo基本原理机制
Dubbo注册到发布执行流程（原理）
5.1.1 前后端分离是如何做的？
1、 一般来说，要实现前后端分离，前端就需要开启一个本地的服务器来运行自己的前端代码，以此来模拟真实的线上环境，并且，也是为了更好的开发。因为你在实际开发中，你不可能要求每一个前端都去搭建一个java(php)环境，并且在java环境下开发，这对于前端来说，学习成本太高了。但如果本地没有开启服务器的话，不仅无法模拟线上的环境，而且还面临到了跨域的问题，因为你如果写静态的html页面，直接在文件目录下打开的话，你是无法发出ajax请求的(浏览器跨域的限制),因此，你需要在本地运行一个服务器，可是又不想搭建陌生而庞大的java环境，怎么办法呢？nodejs正好解决了这个问题。在我们项目中，我们利用nodejs的express框架来开启一个本地的服务器，然后利用nodejs的一个http-proxy-middleware插件将客户端发往nodejs的请求转发给真正的服务器，让nodejs作为一个中间层。这样，前端就可以无忧无虑的开发了
2、 由于前后端分离后，前端和后台同时开发时，就可能遇到前端已经开发好一个页面了，可是却等待后台API接口的情况。比如说A是负责前端，B是负责后台，A可能用了一周做好了基本的结构，并且需要API接口联调后，才能继续开发，而此时B却还没有实现好所需要的接口，这种情况，怎么办呢？在我们这个项目里，我们是通过了mock来提供一些假数据，我们先规定好了API接口，设计出了一套API文档，然后我们就可以通过API文档，利用mock(http://mockjs.com)来返回一些假数据，这样就可以模拟发送API到接受响应的整一个过程，因此前端也不需要依赖于后端开发了，可以独立开发，等到后台的API全部设计完之后，就可以比较快速的联调。
参考链接：实现前后端分离的心得
5.1.2 微服务哪些框架
Spring Boot：这可能是最好的Java微服务框架了，它适用于控制反转、面向切面编程等等。Jersey：这个开源框架支持Java的JAX-RS API，使用起来非常容易。Swagger：在为你提供开发门户网页的同时，能帮助你生成API文档，以允许用户测试你的API。参考链接：Java微服务框架一览
5.1.3 Spring Could的常见组件有哪些？可参考《Spring Cloud概述》
服务注册发现 - Netflix Eureka 配置中心 - spring cloud config 负载均衡-Netflix Ribbon 断路器 - Netflix Hystrix 路由(网关) - Netflix Zuul5.1.4 领域驱动有了解吗？什么是领域驱动模型？充血模型、贫血模型
贫血模型：贫血模型中包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出，贫血模型中的领域对象是不依赖于持久层的。
充血模型：充血模型中包含了所有的业务逻辑，包括依赖于持久层的业务逻辑。所以，使用充血模型的领域层是依赖于持久层，简单表示就是 UI层->服务层->领域层<->持久层。
5.1.5 JWT有了解吗，什么是JWT，可参考《前后端分离利器之JWT》
5.1.6 你怎么理解 RESTful
5.1.7 说说如何设计一个良好的 API
5.1.8 如何理解 RESTful API 的幂等性
5.1.9 如何保证接口的幂等性
5.1.10 说说 CAP 定理、BASE 理论
5.1.11 怎么考虑数据一致性问题
5.1.12 说说最终一致性的实现方案
5.1.13 微服务的优缺点，可参考《微服务批判》
微服务优点: 1、通过分解巨大单体式应用为多个服务方法解决了复杂性问题，每个微服务相对较小
2、每个单体应用不局限于固定的技术栈，开发者可以自由选择开发技术，提供API服务。
3、每个微服务独立的开发，部署
4、单一职责功能，每个服务都很简单，只关注于一个业务功能
5、易于规模化开发，多个开发团队可以并行开发，每个团队负责一项服务
6、改善故障隔离。一个服务宕机不会影响其他的服务
微服务缺点： 1.开发者需要应对创建分布式系统所产生的额外的复杂因素(目前的IDE主要面对的是单体工程程序，无法显示支持分布式应用的开发；测试工作更加困难；需要采用服务间的通讯机制；很难在不采用分布式事务的情况下跨服务实现功能；跨服务实现要求功能要求团队之间的紧密协作)
2.部署复杂
3.内存占用量更高
5.1.14 微服务与 SOA 的区别
微服务架构是一种构造应用程序的替代性方法。应用程序被分解为更小、完全独立的组件，这使得它们拥有更高的敏捷性、可伸缩性和可用性。
SOA将应用程序的功能公开为更容易访问的服务接口，使得在下一代应用程序中使用它们的数据和逻辑变得更容易。
5.1.15 如何拆分服务、水平分割、垂直分割
5.1.16 如何应对微服务的链式调用异常
5.1.17 如何快速追踪与定位问题
5.1.18 如何保证微服务的安全、认证
5.2.1 如何防范常见的Web攻击、如何方式SQL注入
5.2.2 服务端通信安全攻防
5.2.3 HTTPS原理剖析、降级攻击、HTTP与HTTPS的对比
5.3.1 性能指标有哪些
5.3.2 如何发现性能瓶颈
5.3.3 性能调优的常见手段
5.3.4 说说你在项目中如何进行性能调优
6.1.1 说说你在项目中使用过的UML图
6.1.2 你如何考虑组件化、服务化、系统拆分
6.1.3 秒杀场景如何设计
可参考：《秒杀系统的技术挑战、应对策略以及架构设计总结一二！》
6.2.1 说说你的开发流程、如何进行自动化部署的
6.2.2 你和团队是如何沟通的
6.2.3 你如何进行代码评审
6.2.4 说说你对技术与业务的理解
6.2.5 说说你在项目中遇到感觉最难Bug，是如何解决的
6.2.6 介绍一下工作中的一个你认为最有价值的项目，以及在这个过程中的角色、解决的问题、你觉得你们项目还有哪些不足的地方
6.3.1 说说你的优缺点、亮点
6.3.2 说说你最近在看什么书、什么博客、在研究什么新技术、再看那些开源项目的源代码
6.3.3 说说你觉得最有意义的技术书籍
6.3.4 工作之余做什么事情、平时是如何学习的，怎样提升自己的能力
6.3.5 说说个人发展方向方面的思考
6.3.6 说说你认为的服务端开发工程师应该具备哪些能力
6.3.7 说说你认为的架构师是什么样的，架构师主要做什么
6.3.8 如何看待加班的问题
（转载本站文章请注明作者和出处 个人博客[www.ilovevismin.com]）
