5-31面試準備

spring cloud
Eureka
先在配置文件中配置端口號以及服務名和註冊中心的地址
再在主啓動類上加上@EnableEurekaClent註解 配置中心相似

Ribbon
客戶端負載均衡便是當瀏覽器向後臺發出請求的時候，客戶端會向 Eureka Server 讀取註冊到服務器的可用服務信息列表，而後根據設定的負載均衡策略（沒有設置即用默認的），抉擇出向哪臺服務器發送請求。
在主啓動類中新建一個方法，返回值爲RestTemplate對象，並用@bean標籤將向容器注入該方法，同時經過@LoadBalanced標籤開啓負載均衡的功能。

Feign
首先添加依賴
而後在主啓動類上加上@EnableFeignClients 開啓對Feign clent的掃描加載處理
定義Feign接口並在接口上用@FeignClients註解指定服務名和url
在controller層注入接口，當接口中的方法被調用時Feign會爲每一個接口生成一個RequestTemple對象
該對象封裝了HTTP請求須要的所有信息包括參數名請求方法等；
而後由RequestTemplate對象生成請求，再將請求交給Client去處理
最後Client被封裝到LoadBalanceclient類，這個類結合Ribbon負載均衡發起服務間的調用。

Hystrix
在主啓動類上配置@EnableCiruitBreaker斷路器
而後在須要用到斷路器的方法上加上@HystrixCommand註解
在括號中填入fallbackMethod=預先準備好的返回結果

Zuul
Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器.
能夠用來作反向代理，也能夠用來篩選和過濾請求
過濾請求：在yml中配置路由規則

nginx服務器
概念：Nginx是一個web服務器的反向代理服務器，用於HTTP、HTTPS、SMTP、POP3和IMAP協議。
特性：跨平臺、配置簡單、非阻塞、高併發鏈接、內存消耗小、性能好
用處：反向代理、負載均衡（輪詢、權重、iphash）、動靜分離
實現高併發原理：
一個主進程，多個工做進程，每一個工做進程能夠處理多個請求，每進來一個request，會有一個worker進程去處理。遇到阻塞時，去處理其它請求，一旦上游服務器返回則觸發事件，繼續處理。
兩個進程：
Master進程：讀取及評估配置和維持
Worker進程：處理請求
配置：
server{
listen : 要監聽的端口號;
server_name : 要監聽的域名;
location / {
proxy_pass 須要轉向的主機名和端口號;
}
}

配置負載均衡策略
upstream name{
server 主要轉向的主機名和端口號;
server 主要轉向的主機名和端口號;
server 主要轉向的主機名和端口號;
}
經常使用的有三種策略（輪詢，權重，ip_hash）
權重（server 主機名端口號+weight=n）
IPHash（在首行寫ip_hash;） 每個請求固定落在一個上游服務器，可以解決ip會話在同一臺服務器的問題。
fair（在尾行寫fair;）配置 按上游服務器的響應時間來分配請求。響應時間短的優先分配。
url_hash配置

mycat中間件
MyCat關鍵特性
遵照Mysql原生協議，跨語言，跨平臺，跨數據庫的通用中間件代理。
基於心跳的自動故障切換，支持讀寫分離，支持MySQL主從，支持分庫分表
基於Nio實現，有效管理線程，高併發問題。

mycat基本配置（service.xml,rule.xml,scherma.xml）：
service.xml主要配置mycat服務的參數，好比端口號，myact用戶名和密碼使用的邏輯數據庫等
role.xml主要配置路由策略、拆分規則等；
schema.xml主要配置物理數據庫的信息，邏輯數據庫名稱以及表和路由策略之間的關係等

分庫分表
水平拆分（以表爲切分粒度）和垂直拆分（以行爲切分粒度）

redis
支持五種數據類型(String,Hash,List,Set,zset)

String字符串：
格式: set key value
string類型是二進制安全的。意思是redis的string能夠包含任何數據。好比jpg圖片或者序列化的對象 。
string類型是Redis最基本的數據類型，一個鍵最大能存儲512MB。

Hash（哈希）
格式: hmset name key1 value1 key2 value2
Redis hash 是一個鍵值(key=>value)對集合。
Redis hash是一個string類型的field和value的映射表，hash特別適合用於存儲對象。

List（列表）
Redis 列表是簡單的字符串列表，按照插入順序排序。你能夠添加一個元素到列表的頭部（左邊）或者尾部（右邊）
格式: lpush name value
在 key 對應 list 的頭部添加字符串元素
格式: rpush name value
在 key 對應 list 的尾部添加字符串元素
格式: lrem name index
key 對應 list 中刪除 count 個和 value 相同的元素
格式: llen name
返回 key 對應 list 的長度

Set（集合）
格式: sadd name value
Redis的Set是string類型的無序集合。
集合是經過哈希表實現的，因此添加，刪除，查找的複雜度都是O(1)。

zset(sorted set：有序集合)
格式: zadd name score value
Redis zset 和 set 同樣也是string類型元素的集合,且不容許重複的成員。
不一樣的是每一個元素都會關聯一個double類型的分數。redis正是經過分數來爲集合中的成員進行從小到大的排序。
zset的成員是惟一的,但分數(score)卻能夠重複。
什麼是Redis持久化？Redis有哪幾種持久化方式？優缺點是什麼？
持久化就是把內存的數據寫到磁盤中去，防止服務宕機了內存數據丟失。
Redis 提供了兩種持久化方式:RDB（默認） 和AOF
搭建redis集羣：
複製多個redis
用ruby腳本語言啓動reids羣
用哨兵機制監控各個節點，實現高可用和自動故障遷移
哨兵機制：
用心跳檢測機制去監控各個節點是否正常運行
當被監控的某個節點出現問題時, 哨兵向管理員發送通知
當一個主節點不能正常工做時，哨兵會開始一次自動故障遷移操做
自動故障遷移：
當一個主節點不能正常工做時，它會將失效的主節點的其中一個從節點升級爲新的主節點
並讓失效的主節點的其餘從節點改成複製新的主節點;
當客戶端試圖鏈接失效的主節點時,集羣也會向客戶端返回新Master的地址,使得集羣可使用Master代替失效Master。

什麼是緩存穿透？如何避免？什麼是緩存雪崩？何如避免？
緩存穿透
通常的緩存系統，都是按照key去緩存查詢，若是不存在對應的value，就應該去後端系統查找（好比DB）。一些惡意的請求會故意查詢不存在的key,請求量很大，就會對後端系統形成很大的壓力。這就叫作緩存穿透。
如何避免？
1：對查詢結果爲空的狀況也進行緩存，緩存時間設置短一點，或者該key對應的數據insert了以後清理緩存。
2：對必定不存在的key進行過濾。能夠把全部的可能存在的key放到一個大的Bitmap中，查詢時經過該bitmap過濾。
緩存雪崩
當緩存服務器重啓或者大量緩存集中在某一個時間段失效，這樣在失效的時候，會給後端系統帶來很大壓力。致使系統崩潰。
如何避免？
1：在緩存失效後，經過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。好比對某個key只容許一個線程查詢數據和寫緩存，其餘線程等待。
2：作二級緩存，A1爲原始緩存，A2爲拷貝緩存，A1失效時，能夠訪問A2，A1緩存失效時間設置爲短時間，A2設置爲長期
3：不一樣的key，設置不一樣的過時時間，讓緩存失效的時間點儘可能均勻。

數據庫優化
1.1儘量根據主鍵查詢
1.2 儘量單表查詢,將訪問的壓力交給tomcat服務器,能夠經過集羣的方式解決,極大減輕數據庫的開銷
①選擇最有效率的表名順序
數據庫的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫在最後的表將被最早處理
②WHERE子句中的鏈接順序
數據庫採用自右而左的順序解析WHERE子句,根據這個原理,表之間的鏈接必須寫在其餘WHERE條件之左,那些能夠過濾掉最大數量記錄的條件必須寫在WHERE子句的之右。
1.3 若是進行關聯查詢時,應該提前肯定數據,以後關聯查詢,減小笛卡爾積(關聯的次數)
1.4 少用數據庫函數 max/min 分組 hive
2.添加索引和視圖(續表)
3.添加緩存(Redis/MemCache)
3.1非關係型數據庫
3.2讀寫速度快,10萬吞吐每秒
4.按期進行數據轉儲(將不用的數據,存儲到歷史表中(銀行的流水))
5.可使用高性能非關係型數據庫儲存.(redis/hbase),讀寫速度快
6.分庫分表(貴/運維)

數據庫防止數據的丟失？
在archivelog mode(歸檔模式)只要其歸檔日誌文件不丟失，就能夠有效地防止數據丟失。

docker容器（瞭解） 基於 Go 語言
你可以在單臺機器上運行多個Docker微容器，而每一個微容器裏都有一個微服務或獨立應用，例如你能夠將Tomcat運行在一個Docker，而MySQL運行在另一個Docker，二者能夠運行在同一個服務器，或多個服務器上。
能夠直接把項目發佈在DocKer容器上面進行測試，當項目須要正式上線的時候咱們直接能夠把作好的DocKer 鏡像部署上去就好了，DocKer能夠在 雲、Windows、Linux 等環境上進行部署
啓動速度快

solr搜索引擎
solr是基於Lucence開發的企業級搜索引擎技術，而lucence的原理是倒排索引。那麼什麼是倒排索引呢？接下來咱們就介紹一下lucence倒排索引原理。
提供了中文分詞的功能。
schema.xml：配置域相關的信息
從數據庫中導入數據：
將對應版本的mysql-connector-java.jar包放到solr的索引庫目錄下的lib文件夾中
在solrconfig.xml文件中配置
<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config.xml</str>
</lst>
</requestHandler>
在當前目錄下新建一個data-config.xml文件
在文件中導入須要放入索引庫的表
<?xml version="1.0" encoding="UTF-8" ?>
<dataConfig>
<dataSource type="JdbcDataSource"
driver="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/Blog"
user="root" password="xuyiqing"/>
<document>
<entity name="user"
query="select * from blog_user" >
<field column="u_id" name="id"></field>
<field column="username" name="username"></field>
<field column="u_password" name="password"></field>
<field column="qq" name="qq"></field>
<field column="avatar" name="avatar"></field>
<field column="article_count" name="count"></field>
</entity>
</document>
</dataConfig>
最後在schema.xml中配置域：
<field name="username" type="text_ik" indexed="true" stored="true"/>
<field name="password" type="text_ik" indexed="false" stored="false"/>
<field name="qq" type="text_ik" indexed="true" stored="true"/>
<field name="avatar" type="string" indexed="false" stored="true"/>
<field name="count" type="float" indexed="true" stored="true"/>

rabbitMQ消息隊列和kafka
好處：
能夠用來解耦各個系統間的調用（解耦）
能夠用來保證讓系統間的調用由同步改成異步（異步）
當系統在處理高併發時，好比秒殺活動，每秒超過了2000個請求，也就時mysql的最大處理能力，若是不用消息隊列的方式，系統就會死（削峯）
缺點：
系統可用性下降：系統引入的外部依賴越多，越容易掛掉，原本你就是A系統調用BCD三個系統的接口就行了，人ABCD四個系統好好的，沒啥問題，你偏加個MQ進來，萬一MQ掛了咋整？MQ掛了，整套系統崩潰了，你不就完了麼。
系統複雜性提升：硬生生加個MQ進來，你怎麼保證消息沒有重複消費？怎麼處理消息丟失的狀況？怎麼保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已
一致性問題：A系統處理完了直接返回成功了，人都覺得你這個請求就成功了；可是問題是，要是BCD三個系統那裏，BD兩個系統寫庫成功了，結果C系統寫庫失敗了，咋整？你這數據就不一致了。

消息隊列中間件：
吞吐量 時效性 可用性
ActiveMQ：萬級 毫秒級
RabbitMQ：萬級 延遲最低（微秒級） 基於主從架構實現
RocketMQ：10萬級 毫秒級
Kafka：10萬級（通常配合大數據的系統進行實時數據計算、日誌採集等場景） 毫秒級之內 很是高，一個數據多個備份，少許宕機，不影響

Dubbo服務框架
Dubbo是阿里巴巴開源的基於 Java 的高性能 RPC 分佈式服務框架，現已成爲 Apache 基金會孵化項目。
Dubbo和Spring Cloud的區別：
註冊中心不一樣，Dubbo用的是強一致性的Zookeeper，Spring Cloud 用的是Eureka
Dubbo中沒有提供完善的斷路器，服務網關等功能。
Dubbo支持的協議：
dubbo://（推薦） http:// rest:// redis://
Dubbo不須要Web容器
推薦使用 Zookeeper 做爲註冊中心，還有 Redis、Multicast、Simple 註冊中心，但不推薦。

hadoop生態圈

經常使用的數據結構

商城項目
我主要是提供一些查詢接口，對商品進行分類查詢和模糊查詢，同時在系統中調用其它服務。

物業管理系統
租憑管理模塊
主要功能就是爲管理員提供房產信息狀態的跟蹤，將不一樣狀態（業主在住，待出租，已出租）的房產展現給管理員，管理員可經過分類查詢和模糊查詢調用查詢房產信息。提醒管理員近期將要到期的租憑合同以及房產信息。
管理員須要查看房產的使用狀態，我用的是爲房產表添加一個使用狀態字段，而後根據租憑狀態將信息進行分類統計；
管理員須要查看哪些租憑合同將在近一個月內過時，這就須要根據出租截止日期字段對房產信息進行查詢，彙總。

租憑合同管理模塊
主要是對租賃合同進行管理，合同的停止、續簽、延期、做廢、變動等進行管理，能夠進行實時查詢統計。
其實就是對租憑合同表進行增刪改查。

Eureka Client:
先在配置文件中配置端口號以及服務名和註冊中心的地址，而後再在主啓動類上加上@EnableEurekaClent註解 配置中心相似
Feign：
首先添加依賴，而後在主啓動類上加上@EnableFeignClients 開啓對Feign clent的掃描加載處理，定義Feign接口並在接口上用@FeignClients註解指定服務名和url，在controller層注入接口，當接口中的方法被調用時Feign會爲每一個接口生成一個RequestTemple對象，該對象封裝了HTTP請求須要的所有信息包括參數名請求方法等；而後由RequestTemplate對象生成請求，再將請求交給Client去處理，最後Client被封裝到LoadBalanceclient類，這個類結合Ribbon負載均衡發起服務間的調用。

Feign 工做原理
在開發微服務應用時，咱們會在主程序入口添加 @EnableFeignClients 註解開啓對 Feign Client 掃描加載處理。根據 Feign Client 的開發規範，定義接口並加 @FeignClients 註解。
當程序啓動時，會進行包掃描，掃描全部 @FeignClients 的註解的類，並將這些信息注入 Spring IOC 容器中。當定義的 Feign 接口中的方法被調用時，經過JDK的代理的方式，來生成具體的 RequestTemplate。當生成代理時，Feign 會爲每一個接口方法建立一個 RequetTemplate 對象，該對象封裝了 HTTP 請求須要的所有信息，如請求參數名、請求方法等信息都是在這個過程當中肯定的。
而後由 RequestTemplate 生成 Request，而後把 Request 交給 Client 去處理，這裏指的 Client 能夠是 JDK 原生的 URLConnection、Apache 的 Http Client 也能夠是 Okhttp。最後 Client 被封裝到 LoadBalanceclient 類，這個類結合 Ribbon 負載均衡發起服務之間的調用。

同步阻塞IO（JAVA BIO）：
同步並阻塞，服務器實現模式爲一個鏈接一個線程，即客戶端有鏈接請求時服務器端就須要啓動一個線程進行處理，若是這個鏈接不作任何事情會形成沒必要要的線程開銷，固然能夠經過線程池機制改善。

同步非阻塞IO(Java NIO) ： 同步非阻塞，服務器實現模式爲一個請求一個線程，即客戶端發送的鏈接請求都會註冊到多路複用器上，多路複用器輪詢到鏈接有I/O請求時才啓動一個線程進行處理。用戶進程也須要時不時的詢問IO操做是否就緒，這就要求用戶進程不停的去詢問。

異步阻塞IO（Java NIO）：
此種方式下是指應用發起一個IO操做之後，不等待內核IO操做的完成，等內核完成IO操做之後會通知應用程序，這其實就是同步和異步最關鍵的區別，同步必須等待或者主動的去詢問IO是否完成，那麼爲何說是阻塞的呢？由於此時是經過select系統調用來完成的，而select函數自己的實現方式是阻塞的，而採用select函數有個好處就是它能夠同時監聽多個文件句柄（若是從UNP的角度看，select屬於同步操做。由於select以後，進程還須要讀寫數據），從而提升系統的併發性！

（Java AIO(NIO.2)）異步非阻塞IO: 在此種模式下，用戶進程只須要發起一個IO操做而後當即返回，等IO操做真正的完成之後，應用程序會獲得IO操做完成的通知，此時用戶進程只須要對數據進行處理就行了，不須要進行實際的IO讀寫操做，由於真正的IO讀取或者寫入操做已經由內核完成了。