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...