Java面试题_第四阶段

1.1 电商行业特色

1.分布式

  垂直拆分:根据功能模块进行拆分

  水平拆分:根据业务层级进行拆分

2.高并发

     用户单位时间内访问服务器数量,是电商行业中面临的主要问题

3.集群

  抗击高兵发的有效手段,同时集群内部实现高可用

4.海量数据处理

  随着公司数据的不断积累.自身的数据量很庞大.若是高效的处理数据/分析

1.2 框架调用流程

 

1.3 EasyUI后台调用流程

 

1.4 分布式项目的设计思想

为了实现架构之间的松耦合,将项目根据分布式的思想进行拆分.

1.项目的垂直拆分

根据功能模块的不一样将项目进行拆分.

2.项目的水平拆分

在大型项目中,因为开发的人数众多,项目复杂度高.为了保证项目开发的耦合性低.实现项目的水平拆分.

将一个大型项目根据层级模块进行拆分.Controller项目/Service项目Mapper项目

项目建立时采用聚合项目的方式进行管理

 

1.5 分布式项目的jar包如何管理

将项目中用到公共的jar包使用服务支撑项目jt-parent进行添加,其余的项目只须要继承jt-parent后获取对应的jar包所有依赖.从而实现了jar包的统一管理

1.6 介绍一下通用Mapper

1. 早期使用JDBC操做数据库.该操做特别的繁琐,而且全部的数据须要本身手动的封装.
2. JPA:是java持久化的API(用面向对象的方式操做数据库)思想

User user = new User(); setXXXX 
User.setId(1);
User.setName(tom);
工具API.insert(user);  JPA内部将对象自动转化为sql语句
Insert into …….

　　3.Haibernate框架.号称是自动化的(ORM)

程序员只须要操做对象,从而完成了对数据库的操做.

缺点:

1. 作新增/删除/修改会产生一些冗余的sql(出于安全性性考虑)
2. 若是作多表关联操做(CRUD) ,须要装备配置文件,经过配置文件进行数据关联设定.同时须要学习Hql(语句)
3. 早期数据库容量是有限,超过500万后查询效率开始变低.

4.Mybatis，优势:继承ORM,摈弃了冗余的sql(本身手写),

  5.通用Mapper插件基于mybaits的效果，能够实现单表CRUD使用对象操做.(反射机制)

1.7 Nginx是什么,有什么做用？

Nginx (engine x) 是一个轻量级的是一个高性能的HTTP和反向代理服务器,其特色是占有内存少，并发能力强

主要是用来反向代理和实现负载均衡.

1.8 谈一下反向代理和负载均衡

说明:

1. Nginx首先须要监听特定的域名.
2. 当用户根据域名进行资源访问时.首先会访问nginx
3. 以后nginx代替请求者根据内部的配置文件,实现反向代理.将请求转化为特定的请求路径进行资源访问.
4. 当Nginx获取资源后将数据返回给用户.完成请求的正确的响应.

负载均衡:访问量高时,可让服务器尽可能分摊压力,

实现策略:轮询,权重,IP_HASH(通常不用)

1.9 Nginx的健康监测机制

当后台的服务器出现宕机的现象,当时nginx中的配置文件并无改变时,请求依然会发往故障的机器.须要人为的维护配置文件,这样的操做不智能.那么采用健康检测机制.能够实现故障的自动的迁移.

属性介绍:

1.max_fails=1  当检测服务器是否正常时,若是检测失败的次数达到规定的次数时,则判定该服务器故障,在规定的时间周期内,不会将请求发往该机器.

2.fail_timeout=60s定义时钟周期

 

1.10 Nginx如何保证请求参数不丢

在nginx中添加请求头的参数,表示每次请求时,携带请求者的请求头信息,访问服务器.

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

1.11 数据库数据如何备份(数据备份策略)

1. 冷备份:按期将数据库中的文件进行转储,按期进行数据备份.
2. 热备份:搭建数据库主从结构,当主库数据发生改变时,从库根据主库的二进制日志文件进行备份.
3. 双机热备:数据库互为主从,数据库代理服务器对主库进行心跳检测,实现数据的高可用,为了防止主库宕机后发生雪崩现象

1.12 数据库压力大时,怎么实现高可用

1.用数据库代理服务器搭建数据库的读写分离进行分流.读取从库数据,写数据在主库

可用的数据库代理服务器有Amoeba和Mycat

因为大量的用户的数据库操做都须要经过数据库来完成.形成数据库负载太高.由于数据库操做中查询的操做占很大的比重.

2.数据库实现双机热备.

1.13 数据库的优化策略

1. 优化sql语句(多表操做)  where 左链接 右链接 内链接

原则:尽量根据主键查询,尽量少用关联查询.

1. 建立索引(对常常查询的数据建立索引)
2. 添加缓存(Redis/MemCache)
3. 按期进行数据转储(将一些查询较少的数据保存到历史表,让当前表维护可控的数据量)
4. 分库分表(须要大量的数据库服务器)

1.14 什么是Mycat

是一个数据库中间件,实现读写分离,分库分表和数据库故障迁移.

1.15 什么是Redis,运行在哪里

开源的内存中的数据结构存储系统,能够用作数据库,缓存和消息中间件

基于C语言开发,运行时在内存中,运行速度很快

https://mp.weixin.qq.com/s/0Fqp2aGq7c_x_bEK9pOeeg

1.16 Redis中的数据持久化策略

若是使用时容许丢失部分数据(少许的)则使用RDB模式,它的效率高,也是redis默认的策略,若是不容许丢失数据则采用AOF模式,它的安全性高,可是效率较低.

1.17 Redis中的内存维护策略

问题:若是数据都存储到redis中,若是内存占满了,redis如何维护?

解决方案:

1. 动态的扩容redis节点(不科学)
2. 为数据设定超时时间
3. 动态的将不用的数据删除.(LRU算法)

  算法介绍:

内存管理的一种页面置换算法，对于在内存中但又不用的数据块（内存块）叫作LRU，操做系统会根据哪些数据属于LRU而将其移出内存而腾出空间来加载另外的数据。

1.18 redis为何要分片

特色:实现动态内存扩容

数据存储机制:

 

1.19 Hash一致性

1.均衡性：尽量均匀分片节点中的数据

2.单调性：实现数据的动态迁移

3.分散性：因为分布式缘由,致使不能获取所有节点信息,使得一个key有多个位置

4.负载：是分散性另外一种表现形式.表现为一个位置有多个key

1.20 知道哨兵机制吗,怎么实现的,实现了什么功能

功能:实现redis高可用

机制:心跳检测

 

1.21 哨兵和分片的优缺点

优势:

1. 分片可使redis动态内存扩容.
2. 分片能够将数据均匀的分配到不一样的节点中,使数据分散保存.
3. 哨兵能够实现redis高可用.

  缺点:

1. 分片若是有一个节点出现宕机则整个分片都不能正常使用.
2. 哨兵若是发生宕机现象,则影响整个redis服务.

升级:

1. 使用多台redis实现内存空间的动态扩容.
2. 实如今redis内存实现高可用(再也不使用哨兵机制)使用组件(ruby)

搭建集群,实现分片和高可用的所有功能.

1.22 Redis集群

使用ruby工具建立集群.集群中所有的节点相互之间互相通信.在redis内部实现高可用.redis集群是分片和哨兵的集合体.

1.23 伪静态技术

动态页面不能被搜索引擎收录.为了保证搜索引擎的友好性.则以.html的静态页面形式展示动态页面数据

1.24 跨域问题

说明:在www.jt.com中调用manage.jt.com时访问不成功.缘由该操做是一个跨域请求.

 

浏览器不容许进行跨域请求.会将成功返回的数据进行拦截.不予显示.一切出于安全性的考虑.

1.25 同源策略

规则：请求协议/域名/端口号是否相同,若是三者都一致,那么是同域访问.(即同源策略)浏览器能够正常执行.除此以外的所有的请求都是跨域请求.

1.26 怎么解决跨域问题?

利用javascript中src属性实现跨域.

客户端定义回调函数 callback=hello

服务端程序封装特定的JSON格式   callback(JSON)  执行回调函数

 

JSONP就是基于这个原理实现的.

JSONP(JSON with Padding)是JSON的一种“使用模式”，可用于解决主流浏览器的跨域数据访问的问题。因为同源策略，通常来讲位于 server1.example.com 的网页没法与不是 server1.example.com的服务器沟通，而 HTML 的<script> 元素是一个例外。利用 <script> 元素的这个开放策略，网页能够获得从其余来源动态产生的 JSON 资料，而这种使用模式就是所谓的 JSONP。用 JSONP 抓到的资料并非 JSON，而是任意的JavaScript，用 JavaScript 直译器执行而不是用 JSON 解析器解析

 

1.27 JQuery中怎么使用JSONP

跨域的缺点:回调的函数须要提早定义.程序员本身定义.

解决方案: 采用jQuery中的JSONP实现跨域的请求.

语法:

        $.ajax({
            url:"http://manage.jt.com/web/testJSONP",
            type:"get",
            dataType:"jsonp",       //返回值的类型 JSONP必须添加不然不能回调 函数
            jsonp: "callback",   //指定参数名称
            jsonpCallback: "hello",  //指定回调函数名称
            success:function (data){
                alert(data.id);
                alert(data.name);
                //转化为字符串使用
                //var obj = eval("("+data+")");
                //alert(obj.name);
            }    
        });

1.28 HttpClient

HTTP 协议多是如今 Internet 上使用得最多、最重要的协议了，愈来愈多的 Java 应用程序须要直接经过 HTTP 协议来访问网络资源。虽然在 JDK 的 java net包中已经提供了访问 HTTP 协议的基本功能，可是对于大部分应用程序来讲，JDK 库自己提供的功能还不够丰富和灵活。HttpClient 是 Apache Jakarta Common 下的子项目，用来提供高效的、最新的、功能丰富的支持 HTTP 协议的客户端编程工具包，而且它支持 HTTP 协议最新的版本和建议。HttpClient 已经应用在不少的项目中，好比 Apache Jakarta 上很著名的另外两个开源项目 Cactus 和 HTMLUnit 都使用了 HttpClient。如今HttpClient最新版本为 HttpClient 4.5 (GA) （2015-09-11）

总结:HttpClient是java为了远程请求开发的http请求工具包.

1.29 HttpClient和JSONP的区别

1. JSONP是基于浏览器的,解决跨域问题的.而httpClient是基于代码.模拟http请求.获取服务端的参数的,功能上相似,可是通过的环节不一样.
2. 安全性不一样：JSONP的所有信息均可以经过浏览器进行监控.可是HttpClient浏览器不能监控.

　　3.代码调用层级不一样：Jsonp须要调用服务端业务逻辑,最多3层，HttpClient须要调用5层

适用场景：若是从服务端获取数据,js能够直接解析.使用JSONP,若是服务端的程序的返回值,须要进一步处理.这时使用HttpClient

1.30 你的单点登陆是怎么调用的

流程图:

 

原理:

实现步骤:

当用户登录时,经过nginx访问jt-web中任意的服务器以后输入用户名和密码访问JT-SSO单点登陆服务器.

获取用户的登录信息查询数据库,校验用户名和密码是否正确.若是用户名和密码是正确的,将用户信息转化为JSON串.以后生成加密的秘钥TOKEN(MD5(盐值+随机数)).将token:userJSON保存redis中.而且将token信息返回给客户端(jt-web).

Jt-web接收到服务端数据时首先校验数据是否有效.若是数据准确无误,将token信息写入到浏览器的Cookie(4K)中

当用户再次访问jt-web时,首先应该获取用户的Token信息,以后查询redis缓存服务器获取userJSON数据,以后将userJSON转化为User对象进行使用.实现免密登陆.若是token数据为null,那么则让用户访问登录页面.

1.31 同一线程内的数据怎么实现共享(ThreadLocal)

名称:本地线程变量

做用:在同一线程内实现数据共享.

原理:

 

说明:ThreadLocal是线程安全的,在同一个线程内实现数据的共享.

注意:使用完成后,切记销毁threadLocal对象,不然gc不能回收.致使JVM内存泄漏.

public class UserThreadLocal {
    //若是保存数据有多个,则使用Map集合
    private static ThreadLocal<User> userThread = new ThreadLocal<User>();
    public static void set(User user){
        userThread.set(user);
    }
    public static User get(){
        return userThread.get();
    }
    //线程销毁方法
    public static void remove(){
        userThread.remove();
    }
}

 

1.32 如何实现的单点登陆SSO

问题:由于后台的服务器采用的是集群的部署方式,确定有多台服务器.若是将用户的登录信息保存到服务器端,由于多个服务器之间不能共享session.因此相互之间不一样实现Session共享.致使用户频繁登录.

初级:使用Nginx提供的IP_Hash

高级:

1. 当用户登录操做时,首选访问时单点登陆服务器.进行登陆操做.
2. 若是登陆正确.则生成用户的秘钥token.将用户信息转化为JSON串和token一块儿保存到redis缓存中.

3.将token信息返回给客户端.将数据保存到客户端浏览器中的cookie中.

4.当用户进行其余操做须要用到用户信息时,首先检测Cookie中是否有token,第二步检测redis中的数据是否为null.若是一切正确,则容许跳转到指定页面中.若是其中有一项有误,则表示用户登录异常.让用户从新登录.

 

1.33 当zk若是宕机后,消费者可否正确消费?????

说明:

答案:能够

由于zk会动态的向客户端更新服务列表信息.当zk宕机后,因为以前已经同步了zk的服务列表信息,因此客户端能够按照本身已经缓存的清单进行访问.若是在这个期间服务端程序发现宕机现象,那么则访问故障机时因为不能通讯,则等待超时时间,则访问下一台服务器.

若是这时,全部的服务端程序都宕机,则整个服务陷入瘫痪.

1.34 微服务治理方案(ZooKeeper)

说明:增长服务器或者减小服务器都是自动完成

 

业务逻辑说明:

1. 当服务的提供者启动时,会将服务的名称:IP:端口会写入注册中心.
2. 注册中心内部会维护服务列表
3. 当消费者须要访问服务时,须要先访问注册中心获取服务列表信息.以后将服务列表保存到本地缓存中.方便后续的访问.在客户端内部有负载均衡的算法,筛选出一台服务器,以后进行访问.
4. 若是后台服务器出现宕机现象.这时注册中心经过心跳检测的方式判断服务器是否宕机.若是服务器宕机则会将该服务器信息从服务列表中删除.以后将新的服务列表发送消费者(客户端)进行更新.

1.35 你怎么理解SOA(面向服务)

面向服务的架构（SOA）是一个组件模型，它将应用程序的不一样功能单元（称为服务）经过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操做系统和编程语言。这使得构建在各类各样的系统中的服务能够以一种统一和通用的方式进行交互。

 

1.36 知道RPC协议吗

总结:RPC调用的规则能够传输java对象.底层实现时将数据转化流,而且该流通过加密处理.而且rpc内部使用UTF-8编码格式

要求:传输的java对象必须序列化

 

1.37 什么是Dubbo框架

Dubbo是 [1]  阿里巴巴公司开源的一个高性能优秀的服务框架(SOA)，使得应用可经过高性能的RPC实现服务的输出和输入功能能够和Spring框架无缝集成。

1.38 Nginx和ZK的区别

 Nginx:

1. Nginx主要是为了反向代理(Http)
2. 负载均衡
3. Nginx主要搭建在公司网关服务器上

Zk:经过RPC进行远程方法调用,是服务端程序

主要做用是实现服务端的高可用.搭建在内网中.

1.39 知道什么是消息队列吗,并说出几种经常使用的

消息队列能够缓解服务器的访问压力,请求在在访问服务器时,先写入消息队列中,能够实现请求的异步操做,起到平峰削骨的做用

可是缺点是消耗了用户的实际等待时间.

常见的消息队列产品有activeMQ(apache的),RabbitMQ(爱立信的)

1.40 消息队列有几种工做模式

1.简单模式2.工做模式3.发布订阅模式4.路由模式

5.主题模式 6.RPC模式

1.41 倒排索引

倒排索引源于实际应用中须要根据属性的值来查找记录。这种索引表中的每一项都包括一个属性值和具备该属性值的各记录的地址。因为不是由记录来肯定属性值，而是由属性值来肯定记录的位置，于是称为倒排索引(inverted index)。带有倒排索引的文件咱们称为倒排索引文件，简称倒排文件(inverted file)。

 

1.42 Solr介绍/ES

Solr是一个独立的企业级搜索应用服务器，它对外提供相似于Web-service的API接口。用户能够经过http请求，向搜索引擎服务器提交必定格式的XML文件，生成索引；也能够经过Http Get操做提出查找请求，并获得XML格式的返回结果.

基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，而且提供了一个完善的功能管理界面，是一款很是优秀的全文搜索引擎。

特色:

1. solr能够根据数据库表自动生成索引文件.
2. Solr能够动态的按期自动更新索引(对更新的数据进行索引的修改)

1.43 Docker介绍

 

Docker 是一个开源的应用容器引擎，让开发者能够打包他们的应用以及依赖包到一个可移植的容器中，而后发布到任何流行的Linux机器上，也能够实现虚拟化，容器是彻底使用沙箱机制，相互之间不会有任何接口。

一个完整的Docker有如下几个部分组成：

DockerClient客户端        

Docker Daemon守护进程   客户端和Docker容器交互的媒介

Docker Image镜像        应用程序的模板

DockerContainer容器     启动后的应用程序

1.44 Docker调用原理

 

模块描述:

1.docker

Docker客户端程序

2.daemon

通常在宿主主机的后台运行,做为服务端接收客户端的请求,而且处理这些请求(建立/运行/分发容器).

    客户端和服务器既能够运行在一个主机中,也能够经过socket/RESTful来实现通讯

3.image:

Docker中的镜像文件, 为应用程序的模板,通常都是只读的不容许修改

Docker的镜像文件来源有两种:

　　1.Docker官网中的镜像文件

　　2.本地的镜像文件

 

4.Container:

Docker容器,经过image镜像建立容器后,在容器中运行应用程序(相似于new一个对象)

5.Repository:

管理镜像的仓库,相似于Maven仓库管理jar包文件

调用原理:

1.Docker客户端经过Daemon请求建立Docker容器

2.Daemon接收请求后,从Repository中查找须要的Image镜像文件

3.找到对应的镜像文件后,建立Docker容器

4.调用容器完成具体任务(redis/nginx/tomcat/mysql等)

1.45 Docker镜像拉取过程

 

1.当客户端获取镜像文件时,会向服务器发起请求.

2.Docker引擎首先会检查本地是否含有镜像文件,若是没有则会联网下载镜像文件

3.从共有云中获取Image镜像文件后,保存到本地

4.当用户须要使用该应用是,经过镜像文件建立容器,为用户提供服务

Dockerfile难

1.46 京淘项目人员分配

开发周期:开发4个月可是不停的更新迭代

　　购物车商品展示页面 商品规格

　　评价系统

　　订单物流系统  京东物流/调用菜鸟裹裹 调用第三方接口获取数据进行展示(http)

　　支付系统:银行接口/第三方支付 http

　　推荐系统:….

产品经理：3人，肯定需求以及给出产品原型图

项目经理：1人，项目管理。

前端团队：5人，根据产品经理给出的原型制做静态页面。

后端团队：20人，实现产品功能。

测试团队：5人，测试全部的功能。2人  3人 脚本 shell

运维团队：3人，项目的发布以及维护。

1.47 日活量/并发量

 

日活量:200万
并发量:1500-2300左右
单点并发压力 18台tomcat服务器
服务器划分
Mysql                        2
Mycat服务器                   1
Solr                         3
Redis                        3
图片服务器                     2
Nginx                        2
注册中心                      3
RabbitMQ                     2
18台服务器

Jt-manage                    5
Jt-web                       10
Jt-sso                       3
Jt-cart                      5
Jt-order                     5
Jt-search                    5
33台tomcat

1.48 SpringBoot全新开发方式特色

l 建立独立的Spring应用程序

l 嵌入的Tomcat，无需部署WAR文件

l 简化Maven配置

l 自动配置Spring

l 提供生产就绪型功能，如指标，健康检查和外部配置

1.49 什么是微服务架构？

“微服务”源于Martin Fowler的博文 Microservices。

Martin说：微服务是系统架构上的一种设计风格，它的主旨是将一个本来独立的系统拆成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间经过基于HTTP的RESTful API进行通讯协做。被拆分红的每个小型服务都围绕着系统中的某一项或者某些耦合度较高的业务功能进行构建，而且每一个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。因为有了轻量级的通讯协做基础，因此这些微服务可使用不一样的语言来编写。

1.50 核心功能

l configuration management 配置中心

l service discovery 服务发现

l circuit breakers 断路器

l intelligent routing 智能路由

l micro-proxy 微代理

l control bus 控制总线

l one-time tokens 一次性令牌

l global locks 全局锁

l leadership election 选举算法

l distributed sessions 分布式会话

l cluster state 集群状态

1.51 核心组件架构图

 

1.52 拓展：CAP定理

 

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。它是分布式系统中最核心最重要的理论。

分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了以下概括：

l 一致性（C）：在分布式系统中的全部数据备份，在同一时刻是否一样的值。（等同于全部节点访问同一份最新的数据副本）

l 可用性（A）：在集群中一部分节点故障后，集群总体是否还能响应客户端的读写请求。（对数据更新具有高可用性）

l 分区容错性（P）：以实际效果而言，分区至关于对通讯的时限要求。系统若是不能在时限内达成数据一致性，就意味着发生了分区的状况，必须就当前操做在C和A之间作出选择。

CAP理论就是说在分布式系统中，最多只能实现上面的两点。而因为当前的网络硬件确定会出现延迟丢包等问题，因此分区容忍性是咱们必须须要实现的。因此咱们只能在一致性和可用性之间进行权衡，要么选择CP要么选择AP，没有分布式系统能同时保证这三点。

1.53 ZooKeeper和Eureka对比

Eureka自己是Netflix开源的一款提供服务注册和发现的产品，而且提供了相应的Java封装。在它的实现中，节点之间相互平等，部分注册中心的节点挂掉也不会对集群形成影响，即便集群只剩一个节点存活，也能够正常提供发现服务。哪怕是全部的服务注册节点都挂了，Eureka Clients（客户端）上也会缓存服务调用的信息。这就保证了咱们微服务之间的互相调用足够健壮。

Zookeeper主要为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。曾经是Hadoop项目中的一个子项目，用来控制集群中的数据，目前已升级为独立的顶级项目。不少场景下也用它做为Service发现服务解决方案。

对比

根据著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性CAP这三个特性在任何分布式系统中不能同时知足，最多同时知足两个CP或者AP）。

ZooKeeper

Zookeeper是基于CP来设计的，即任什么时候刻对Zookeeper的访问请求能获得一致的数据结果，同时系统对网络分割具有容错性，可是它不能保证每次服务请求的可用性。从实际状况来分析，在使用Zookeeper获取服务列表时，若是zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将没法得到数据。因此说，Zookeeper不能保证服务可用性。

诚然，在大多数分布式环境中，尤为是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是zookeeper设计成CP的缘由。可是对于服务发现场景来讲，状况就不太同样了：针对同一个服务，即便注册中心的不一样节点保存的服务提供者信息不尽相同，也并不会形成灾难性的后果。由于对于服务消费者来讲，能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下，也好过由于没法获取实例信息而不去消费。（尝试一下能够快速失败，以后能够更新配置并重试）因此，对于服务发现而言，可用性比数据一致性更加剧要——AP赛过CP。 

Eureka

而Spring Cloud Netflix在设计Eureka时遵照的就是AP原则。Eureka Server也能够运行多个实例来构建集群，解决单点问题，但不一样于ZooKeeper的选举leader的过程，Eureka Server采用的是Peer to Peer对等通讯。这是一种去中心化的架构，无master/slave区分，每个Peer都是对等的。在这种架构中，节点经过彼此互相注册来提升可用性，每一个节点须要添加一个或多个有效的serviceUrl指向其余节点。每一个节点均可被视为其余节点的副本。

若是某台Eureka Server宕机，Eureka Client的请求会自动切换到新的Eureka Server节点，当宕机的服务器从新恢复后，Eureka会再次将其归入到服务器集群管理之中。当节点开始接受客户端请求时，全部的操做都会进行replicateToPeer（节点间复制）操做，将请求复制到其余Eureka Server当前所知的全部节点中。

一个新的Eureka Server节点启动后，会首先尝试从邻近节点获取全部实例注册表信息，完成初始化。Eureka Server经过getEurekaServiceUrls()方法获取全部的节点，而且会经过心跳续约的方式按期更新。默认配置下，若是Eureka Server在必定时间内没有接收到某个服务实例的心跳，Eureka Server将会注销该实例（默认为90秒，经过eureka.instance.lease-expiration-duration-in-seconds配置）。当Eureka Server节点在短期内丢失过多的心跳时（好比发生了网络分区故障），那么这个节点就会进入自我保护模式。

 

总结

ZooKeeper基于CP，不保证高可用，若是zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将没法得到数据。Eureka基于AP，能保证高可用，即便全部机器都挂了，也能拿到本地缓存的数据。做为注册中心，其实配置是不常常变更的，只有发版（发布新的版本）和机器出故障时会变。对于不常常变更的配置来讲，CP是不合适的，而AP在遇到问题时能够用牺牲一致性来保证可用性，既返回旧数据，缓存数据。

因此理论上Eureka是更适合做注册中心。而现实环境中大部分项目可能会使用ZooKeeper，那是由于集群不够大，而且基本不会遇到用作注册中心的机器一半以上都挂了的状况。因此实际上也没什么大问题。

1.54 拓展：分布式对关系型数据库的冲击

对于web网站来讲，关系数据库的不少主要特性却每每无用武之地

l 数据库事务一致性需求

不少web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。容许实现最终一致性。

l 数据库的写实时性和读实时性需求

对关系数据库来讲，插入一条数据以后马上查询，是确定能够读出来这条数据的，可是对于不少web应用来讲，并不要求这么高的实时性，比方说发一条消息以后，过几秒乃至十几秒以后，个人订阅者才看到这条动态是彻底能够接受的。如：MQ消息队列机制，意义，能够解决瞬时的高并发，消峰填谷做用。

l 对复杂的SQL查询，特别是多表关联查询的需求

任何大数据量的web系统，都很是忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种状况的产生。每每更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

SNS：全称Social Networking Services，专指社交网络服务，包括了社交软件和社交网站。例如：脸谱facebook、腾讯QQ、微信等。

1.55 自我保护模式

 

什么是自我保护模式？默认配置下，若是Eureka Server每分钟收到心跳续约的数量低于一个阈值（instance的数量(60/每一个instance的心跳间隔秒数)自我保护系数），而且持续15分钟，就会触发自我保护。在自我保护模式中，Eureka Server会保护服务注册表中的信息，再也不注销任何服务实例。当它收到的心跳数从新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学前面提到过，那就是宁肯保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。该模式能够经过eureka.server.enable-self-preservation = false来禁用，同时eureka.instance.lease-renewal-interval-in-seconds能够用来更改心跳间隔。

1.56 Ribbon

Feign是netflix开发的声明式、模板化的http客户端，在使用时就像调用本地(服务消费者本身)的方法通常，帮助咱们更加优雅的调用服务提供者的API。Feign自身支持springMVC，还整合了Eureka、Ribbon，极大的简化了Feign的使用。就整合Euraka而言，只需和普通的服务配置Eureka server的信息便可。整合Ribbon，就意味着再也不须要经过标注@LoadBalanced的实例化后的RestTemplate去调用服务提供者方法了。Feign只需经过简单的定义一个接口便可实现负载均衡。

和nginx不一样，它是客户端侧负载均衡。

 

1.57 负载均衡策略

常见提供的负载均衡算法有三种：

l 第一种也是默认为轮询

l 第二种为random随机

l 第三种为WeightedResponseTimeRule，响应时间

1.58 Feigh概念

Feigh是一个声明式web服务客户端。它能让开发web服务变得容易。使用Feign须要建立一个接口并注解它。它拥有包括Feign注解和JAX-RS注解的可插拔支持。它还支持可插拔的编码器和解码器。Spring Cloud拥有Spring MVC支持，并使用Spring Web中默认一样的HttpMessageConverters。在使用Feign时，Spring Cloud集成了Ribbon和Eureka来提供负载均衡的HTTP客户端。

总结：Feign简化HttpClient开发，封装了JAX-RS和SprinMVC的注解，学习成本很低。

1.59 微服务设计引起新的问题

微服务的设计，服务分散在多个服务器上，服务之间互相调用，要调用的服务因为跨网络跨服务器调用，响应速度明显比传统项目单机调用慢不少，甚至因为网络涌动的不稳定的现象发生致使调用超时；还有相似级联失败、雪崩效应（依赖的基础服务宕机，关联的服务致使失败甚至宕机，就像滚雪球同样层层失败。）

如何解决这类新的问题呢？传统的机制就是超时机制。

1.60 熔断机制

家里电表都有个断路器（俗称电闸），当使用的电器不少，用电巨大（例如功率过大、短路等），当电流过载时，电路就会升温，甚至烧断电路，引发火灾。有了这个断路器，咱们及时拉闸，就不会形成严重后果了。

断路器能够实现快速失败，若是它在一段时间内检测到许多失败，如超时，就会强迫其之后的多个调用快速失败，再也不请求所依赖的服务，从而防止应用程序不断地尝试执行可能会失败的操做，这样应用程序能够继续执行而不用等待修正错误，或者浪费CPU时间去等待长时间的超时。断路器也可使应用程序可以诊断错误是否已经修正，若是已经修正，应用程序会再次尝试调用操做。

断路器模式像是那些容易致使错误的操做的一种代理。这种代理可以记录最近调用发生错误的次数，而后决定使用容许操做继续，或者当即返回错误。

 

ending...