互聯網面試知識技術總結（javacore、jvm、redis、kafka、zookeeper、mysql、hystrix）-第四章

<3>Dubbo的負載均衡策略 負載均衡的實現是在客戶端實現的，當服務提供方是集羣的時候，爲了不大量請求一直落到一個或幾個服務提供方機器上，從而使這些機器負載很高，甚至打死，須要作必定的負載均衡策略。Dubbo提供了多種均衡策略，缺省爲random，也就是每次隨機調用一臺服務提供者的機器。 Dubbo提供的負載均衡策略 Random LoadBalance：隨機策略。按照機率設置權重，比較均勻，而且能夠動態調節提供者的權重。 RoundRobin LoadBalance：輪詢策略。輪詢，按公約後的權重設置輪詢比率。會存在執行比較慢的服務提供者堆積請求的狀況，好比一個機器執行的很是慢，可是機器沒有掛調用（若是掛了，那麼當前機器會從Zookeeper的服務列表刪除），當不少新的請求到達該機器後，因爲以前的請求尚未處理完畢，會致使新的請求被堆積，長此以往，全部消費者調用這臺機器上的請求都被阻塞。 LeastActive LoadBalance：最少活躍調用數。若是每一個提供者的活躍數相同，則隨機選擇一個。在每一個服務提供者裏面維護者一個活躍數計數器，用來記錄當前同時處理請求的個數，也就是併發處理任務的個數。因此若是這個值越小說明當前服務提供者處理的速度很快或者當前機器的負載比較低，因此路由選擇時候就選擇該活躍度最小的機器。若是一個服務提供者處理速度很慢，因爲堆積，那麼同時處理的請求就比較多，也就是活躍調用數目越大，這也使得慢的提供者收到更少請求，由於越慢的提供者的活躍度愈來愈大。 ConsistentHash LoadBalance：一致性Hash策略。一致性Hash，能夠保證相同參數的請求老是發到同一提供者，當某一臺提供者掛了時，本來發往該提供者的請求，基於虛擬節點，平攤到其餘提供者，不會引發劇烈變更

簡單總結：常見負載均衡策略有(權重)輪詢，隨機，最小鏈接數，一致性hash等等 參考：www.cnblogs.com/xhj123/p/90…

<4>Dubbo的核心角色 Provider: 暴露服務的服務提供方。 Consumer: 調用遠程服務的服務消費方。 Registry: 服務註冊與發現的註冊中心。 Monitor: 統計服務的調用次調和調用時間的監控中心。

調用關係說明： 服務容器負責啓動，加載，運行服務提供者。 服務提供者在啓動時，向註冊中心註冊本身提供的服務。 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。 <5>Dubbo支持的協議

dubbo：Dubbo缺省協議是dubbo協議，採用單一長鏈接和NIO異步通信，適合於小數據量大併發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的狀況。 反之，Dubbo 缺省協議不適合傳送大數據量的服務，好比傳文件，傳視頻等，除非請求量很低。 rmi:RMI協議採用阻塞式(同步)短鏈接和JDK標準序列化方式。適用範圍：傳入傳出參數數據包大小混合，消費者與提供者個數差很少，可傳文件。 hessian:Hessian底層採用Http通信(同步)，採用Servlet暴露服務。適用於傳入傳出參數數據包較大，提供者比消費者個數多，提供者壓力較大，可傳文件。 dubbo還支持的其餘協議有：http, webservice, thrift, memcached, redis

<6>若是Dubbo的服務端未啓動，消費端能起來嗎? <dubbo:reference id="" interface="" /> 備註:其中reference的check默認=true，啓動時會檢查引用的服務是否已存在，不存在時報錯，所以默認是起不來

<7>集羣容錯策略 正常狀況下，當咱們進行系統設計時候，不只要考慮正常邏輯下代碼該如何走，還要考慮異常狀況下代碼邏輯應該怎麼走。當服務消費方調用服務提供方的服務出現錯誤時候，Dubbo提供了多種容錯方案，缺省模式爲failover，也就是失敗重試。 Dubbo提供的集羣容錯模式： Failover Cluster：失敗重試 當服務消費方調用服務提供者失敗後自動切換到其餘服務提供者服務器進行重試。這一般用於讀操做或者具備冪等的寫操做，須要注意的是重試會帶來更長延遲。可經過 retries="2" 來設置重試次數（不含第一次）。 接口級別配置重試次數方法 <dubbo:reference retries="2" /> ，如上配置當服務消費方調用服務失敗後，會再重試兩次，也就是說最多會作三次調用，這裏的配置對該接口的全部方法生效。固然你也能夠針對某個方法配置重試次數。 Failfast Cluster：快速失敗 當服務消費方調用服務提供者失敗後，當即報錯，也就是隻調用一次。一般這種模式用於非冪等性的寫操做。 Failsafe Cluster：失敗安全 當服務消費者調用服務出現異常時，直接忽略異常。這種模式一般用於寫入審計日誌等操做。 Failback Cluster：失敗自動恢復 當服務消費端用服務出現異常後，在後臺記錄失敗的請求，並按照必定的策略後期再進行重試。這種模式一般用於消息通知操做。 Forking Cluster：並行調用 當消費方調用一個接口方法後，Dubbo Client會並行調用多個服務提供者的服務，只要一個成功即返回。這種模式一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。可經過 forks="2" 來設置最大並行數。 Broadcast Cluster：廣播調用 當消費者調用一個接口方法後，Dubbo Client會逐個調用全部服務提供者，任意一臺調用異常則此次調用就標誌失敗。這種模式一般用於通知全部提供者更新緩存或日誌等本地資源信息。 如上，Dubbo自己提供了豐富的集羣容錯模式，可是若是您有定製化需求，能夠根據Dubbo提供的擴展接口Cluster進行定製。在後面的消費方啓動流程章節會講解什麼時候/如何使用的集羣容錯。

Dubbo面試題：www.cnblogs.com/shan1393/p/…

50，Redis究竟是多線程仍是單線程？線程安全嗎 redis是單線程，線程安全 redis能夠可以快速執行的緣由： (1) 絕大部分請求是純粹的內存操做（很是快速），所以瓶頸在io (2) 採用單線程,避免了沒必要要的上下文切換和競爭條件 (3) 非阻塞IO - IO多路複用 redis內部實現採用epoll，採用了epoll+本身實現的簡單的事件框架。epoll中的讀、寫、關閉、鏈接都轉化成了事件，而後利用epoll的多路複用特性，毫不在io上浪費一點時間

51，數據庫常見引擎區別

InnoDB（b+樹，聚簇索引）：支持事務處理，支持外鍵，支持崩潰修復能力和併發控制。若是須要對事務的完整性要求比較高（好比銀行），要求實現併發控制（好比售票），那選擇InnoDB有很大的優點。若是須要頻繁的更新、刪除操做的數據庫，也能夠選擇InnoDB，由於支持事務的提交（commit）和回滾（rollback）（用於事務處理應用程序，具備衆多特性，包括ACID事務支持。(提供行級鎖)）

MyISAM（b+樹，非聚簇索引）：插入數據快，空間和內存使用比較低。若是表主要是用於插入新記錄和讀出記錄，那麼選擇MyISAM能實現處理高效率。若是應用的完整性、併發性要求比較低，也可使用（MyISAM類型不支持事務處理等高級處理，所以也不支持數據的回滾修復）。

MEMORY（hash結構）：全部的數據都在內存中，數據的處理速度快，可是安全性不高。若是須要很快的讀寫速度，對數據的安全性要求較低，能夠選擇MEMOEY。它對錶的大小有要求，不能創建太大的表。因此，這類數據庫只使用在相對較小的數據庫表。

52，mysql數據庫引擎的對應的索引數據結構

53，b樹和b+樹的比較，blog.csdn.net/z_ryan/arti… 1，在範圍查詢方面，B+樹的優點更加明顯，B樹的範圍查找須要不斷依賴中序遍歷。首先二分查找到範圍下限，在不斷經過中序遍歷，知道查找到範圍的上限便可。整個過程比較耗時，而B+樹的範圍查找則簡單了許多。首先經過二分查找，找到範圍下限，而後同過葉子結點的鏈表順序遍歷，直至找到上限便可，整個過程簡單許多，效率也比較高。（b+樹的數據都分佈在子節點上）

54，常見二叉樹 1，二叉查找樹，它保證全部節點的左子樹都小於該節點，全部節點的右子樹都大於該節點。就能夠經過大小比較關係來進行快速的檢索，在一棵滿二叉平衡樹的狀況下，檢索的效率能夠達到logn(相似二分檢索)，而後插入和刪除的效率也是穩定的logn

普通二叉查找樹的一些問題：二叉搜索樹是個很好的數據結構，能夠快速地找到一個給定關鍵字的數據項，而且能夠快速地插入和刪除數據項。可是二叉搜索樹有個很麻煩的問題，若是樹中插入的是隨機數據，則執行效果很好，但若是插入的是有序或者逆序的數據，那麼二叉搜索樹的執行速度就變得很慢。由於當插入數值有序時，二叉樹就是非平衡的了，排在一條線上，其實就退化成了一個鏈表……它的快速查找、插入和刪除指定數據項的能力就喪失了（blog.csdn.net/eson_15/art…

2，AVL樹不只是一顆二叉查找樹，它還有其餘的性質。若是咱們按照通常的二叉查找樹的插入方式可能會破壞AVL樹的平衡性。同理，在刪除的時候也有可能會破壞樹的平衡性，因此咱們要作一些特殊的處理，包括：單旋轉和雙旋轉 參考：www.cnblogs.com/zhuwbox/p/3… 3，紅黑樹：www.cnblogs.com/chenssy/p/3…

紅黑樹的特徵： 1.每一個節點不是紅色就是黑色的； 2.根節點老是黑色的； 3.若是節點是紅色的，則它的子節點必須是黑色的（反之不必定）； 4.從根節點到葉節點或空子節點的每條路徑，必須包含相同數目的黑色節點（即相同的黑色高度）。

使用場景：通常用於內存空間的數據排序，處理的數據量比較小（避免樹的深度變的很深，致使查找深度變大），大數據排序儘可能使用b+樹

4，紅黑樹和AVL樹的比較（www.cnblogs.com/aspirant/p/…

1. 紅黑樹並不追求「徹底平衡」——它只要求部分地達到平衡要求，下降了對旋轉的要求，從而提升了性能。 紅黑樹可以以O(log2 n) 的時間複雜度進行搜索、插入、刪除操做。此外，因爲它的設計，任何不平衡都會在三次旋轉以內解決。固然，還有一些更好的，但實現起來更復雜的數據結構，可以作到一步旋轉以內達到平衡，但紅黑樹可以給咱們一個比較「便宜」的解決方案。紅黑樹的算法時間複雜度和AVL相同，但統計性能比AVL樹更高。 固然，紅黑樹並不適應全部應用樹的領域。若是數據基本上是靜態的，那麼讓他們待在他們可以插入，而且不影響平衡的地方會具備更好的性能。若是數據徹底是靜態的，作一個哈希表，性能可能會更好一些。 紅黑樹是一個更高效的檢索二叉樹，所以經常用來實現關聯數組。典型地，JDK 提供的集合類 TreeMap 自己就是一個紅黑樹的實現

55，爲何Mysql用B+樹作索引而不用B-樹或紅黑樹（blog.csdn.net/xiedelong/a… B+樹只有葉節點存放數據，其他節點用來索引，而B-樹是每一個索引節點都會有Data域。因此從Mysql（Inoodb）的角度來看，B+樹是用來充當索引的，通常來講索引很是大，尤爲是關係性數據庫這種數據量大的索引能達到億級別，因此爲了減小內存的佔用，索引也會被存儲在磁盤上。 那麼Mysql如何衡量查詢效率呢？– 磁盤IO次數。 B-樹/B+樹 的特色就是每層節點數目很是多，層數不多，目的就是爲了就少磁盤IO次數，可是B-樹的每一個節點都有data域（指針），這無疑增大了節點大小，說白了增長了磁盤IO次數（磁盤IO一次讀出的數據量大小是固定的，單個數據變大，每次讀出的就少，IO次數增多，一次IO多耗時），而B+樹除了葉子節點其它節點並不存儲數據，節點小，磁盤IO次數就少。這是優勢之一。 另外一個優勢是： B+樹全部的Data域在葉子節點，通常來講都會進行一個優化，就是將全部的葉子節點用指針串起來。這樣遍歷葉子節點就能得到所有數據，這樣就能進行區間訪問啦。在數據庫中基於範圍的查詢是很是頻繁的，而B樹不支持這樣的遍歷操做。

B樹相對於紅黑樹的區別 AVL 數和紅黑樹基本都是存儲在內存中才會使用的數據結構。在大規模數據存儲的時候，紅黑樹每每出現因爲樹的深度過大而形成磁盤IO讀寫過於頻繁，進而致使效率低下的狀況。爲何會出現這樣的狀況，咱們知道要獲取磁盤上數據，必須先經過磁盤移動臂移動到數據所在的柱面，而後找到指定盤面，接着旋轉盤面找到數據所在的磁道，最後對數據進行讀寫。磁盤IO代價主要花費在查找所需的柱面上，樹的深度過大會形成磁盤IO頻繁讀寫。根據磁盤查找存取的次數每每由樹的高度所決定，因此，只要咱們經過某種較好的樹結構減小樹的結構儘可能減小樹的高度，B樹能夠有多個子女，從幾十到上千，能夠下降樹的高度。

由於B樹是平衡樹，每一個節點到葉子節點的高度都是相同的，這樣能夠保證B樹的查詢是穩定的

數據庫系統的設計者巧妙利用了磁盤預讀原理，將一個節點的大小設爲等於一個頁，這樣每一個節點只須要一次I/O就能夠徹底載入。爲了達到這個目的，在實際實現B-Tree還須要使用以下技巧：每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也存儲在一個頁裏，加之計算機存儲分配都是按頁對齊的，就實現了一個node只需一次I/O。

紅黑樹和平衡二叉樹區別以下： 一、紅黑樹放棄了追求徹底平衡，追求大體平衡，在與平衡二叉樹的時間複雜度相差不大的狀況下，保證每次插入最多隻須要三次旋轉就能達到平衡，實現起來也更爲簡單。 二、平衡二叉樹追求絕對平衡，條件比較苛刻，實現起來比較麻煩，每次插入新節點以後須要旋轉的次數不能預知。 3，紅黑樹的查詢性能略微遜色於AVL樹，由於其比AVL樹會稍微不平衡最多一層，也就是說紅黑樹的查詢性能只比相同內容的AVL樹最多多一次比較，可是，紅黑樹在插入和刪除上優於AVL樹，AVL樹每次插入刪除會進行大量的平衡度計算，而紅黑樹爲了維持紅黑性質所作的紅黑變換和旋轉的開銷，相較於AVL樹爲了維持平衡的開銷要小得多 4，紅黑樹的關鍵性質: 從根到葉子的最長的可能路徑很少於（<=）最短的可能路徑的兩倍長。結果是這個樹大體上是平衡的。由於操做好比插入、刪除和查找某個值的最壞狀況時間都要求與樹的高度成比例，這個在高度上的理論上限容許紅黑樹在最壞狀況下都是高效的，而不一樣於普通的二叉查找樹 參考：www.jianshu.com/p/37436ed14…

總結：實際應用中，若搜索的次數遠遠大於插入和刪除，那麼選擇AVL，若是搜索，插入刪除次數幾乎差很少，應該選擇RB（red black tree）

紅黑樹每每出現因爲樹的深度過大而形成磁盤IO讀寫過於頻繁，進而致使效率低下的狀況在數據較小，能夠徹底放到內存中時，紅黑樹的時間複雜度比B樹低。 如linux中進程的調度用的是紅黑樹，反之數據量較大，外存中佔主要部分時，B樹因其讀磁盤次數少，而具備更快的速度。

補充： 1，因爲b+樹的子節點（節點結構是數組，爲了二分查找提交效率）存儲了全部的數據（而且各個子節點的數據是有指針關聯造成的鏈表），所以只須要第一次遞歸查詢就能夠肯定查找的起始位置，再遍歷子節點就能夠獲取到指定範圍的數據了 2，b+樹和b樹都是多叉樹，所以能夠減小由於文件過大，致使樹的深度愈來愈深（廣度換深度）。 3，AVL數和紅黑樹基本都是存儲在內存中才會使用的數據結構（好比hashMap），總體存儲的數據量少，查找數據量小，要求的性能更高。

56，hashmap，爲何用紅黑樹？鏈表（長度大於8）升級爲紅黑樹以後，查找效率更高（二分查找），那爲何不用普通二叉查找樹？紅黑樹自己就是二叉查找樹，紅黑樹自身保持平衡，避免樹變成了單鏈表，致使深度變大，查找性能下降。爲何不用b樹？節點的插入效率沒有紅黑樹高（紅黑樹不須要保持徹底平衡，翻轉次數較少，b樹須要保持徹底平衡，翻轉次數比較多，致使耗時較長）， 爲何不用b+樹？節點的插入效率沒有紅黑樹高，數據佔用的空間比較大（子節點存儲全部的數據），不利於在內存中作排序。 57，跳躍表：被問到如何讓鏈表的元素查詢接近線性時間，其實相似於二叉查找樹，時間複雜度是log（n）

58，二分查找（遞歸非遞歸），字符串倒序，鏈表倒序，鏈表交叉（減除多餘步長，同時開始遍歷）

59，mysql的聚簇索引和非聚簇索引的區別，聚簇索引（innodb）對應的b+樹的子節點存儲了主鍵索引和其它數據域（輔助索引和非索引數據），非聚簇索引對應的b+樹的子節點存儲了主鍵索引和輔助索引，對應的數據是另外存儲的，非聚簇索引比聚簇索引多了一次讀取數據的IO操做，因此查找性能上會差（blog.csdn.net/qq_27607965…

60，mysql的mvcc（多版本控制器） 阿里數據庫內核'2017/12'月報中對MVCC的解釋是: 多版本控制: 指的是一種提升併發的技術。最先的數據庫系統，只有讀讀之間能夠併發，讀寫，寫讀，寫寫都要阻塞。引入多版本以後，只有寫寫之間相互阻塞，其餘三種操做均可以並行，這樣大幅度提升了InnoDB的併發度。在內部實現中，與Postgres在數據行上實現多版本不一樣，InnoDB是在undolog中實現的，經過undolog能夠找回數據的歷史版本。找回的數據歷史版本能夠提供給用戶讀(按照隔離級別的定義，有些讀請求只能看到比較老的數據版本)，也能夠在回滾的時候覆蓋數據頁上的數據。在InnoDB內部中，會記錄一個全局的活躍讀寫事務數組，其主要用來判斷事務的可見性。

61，mysql，丟失更新，髒讀，幻讀，不可重複讀，幻讀（www.jianshu.com/p/d8bc0a843…

丟失更新：因爲事務A與事務B互相不知道對方的存在，致使更新不一致，解決方案：樂觀鎖的方式，執行修改時，加上先前獲取的數據做爲判斷條件。 髒讀：mysql中一個事務讀取了另外一個未提交的並行事務寫的數據（可能被回滾），那這個讀取就是髒讀。解決方案：一個事務只能讀取另外一個事務已經提交的數據。 不可重複讀：即不能屢次重複去讀，由於讀出來的結果不同，所以認爲存在不可重複讀的問題。解決方案：一個事務只能讀取另外一個事務已經提交的數據，這就會出現不可重複讀的問題。 幻讀：事務A一開始查詢沒有數據，可是插入記錄失敗，提示主鍵衝突，這種查詢明明沒有，插入卻提示已經存在的現象，叫作幻讀。解決方案：Repeatable read及以上級別經過間隙鎖來防止幻讀的出現，即鎖定特定數據的先後間隙讓數據沒法被插入

小結：不可重複讀的和幻讀很容易混淆，不可重複讀側重於修改，幻讀側重於新增或刪除。解決不可重複讀的問題只需鎖住知足條件的行，解決幻讀須要鎖表

62，mysql的事務隔離級別 事務隔離級別 髒讀 不可重複讀 幻讀 讀未提交（read-uncommitted） 是 是 是 讀已提交（read-committed） 否 是 是 可重複讀（repeatable-read） 否 否 是 串行化（serializable） 否 否 否

serializable級別是最高的 mysql默認的事務隔離級別爲repeatable-read

63，mysql的mvcc如何解決幻讀？ 參考樂觀鎖，每開啓一個事務，都獲取一個版本號，後續的操做根據版本號去對比，經過版本號控制是否正常操做 InnoDB的MVCC，是經過在每行記錄後面保存兩個隱藏的列來實現的。這兩個列，一個保存了行的建立時間，一個保存行的過時時間（或刪除時間）。固然存儲的並非實際的時間值，而是系統版本號（systemversionnumber）。每開始一個新的事務，系統版本號都會自動遞增。事務開始時刻的系統版本號會做爲事務的版本號，用來和查詢到的每行記錄的版本號進行比較。

舉例： 此時books表中有5條數據，版本號爲1 事務A，系統版本號2：select * from books；由於1<=2因此此時會讀取5條數據。 事務B，系統版本號3：insert into books ...，插入一條數據，新插入的數據版本號爲3，而其餘的數據的版本號仍然是2，插入完成以後commit，事務結束。 事務A，系統版本號2：再次select * from books；只能讀取<=2的數據，事務B新插入的那條數據版本號爲3，所以讀不出來，解決了幻讀的問題。

64，mysql四大特性 1.原子性 2.一致性 3.隔離性 4.持久性

65，mysql 七種傳播行爲：

1.PROPAGATION_REQUIRED：（支持事務）若是當前沒有事務，就建立一個新事務，若是當前存在事務，就加入該事務，該設置是最經常使用的設置。 2.PROPAGATION_SUPPORTS：（支持事務）支持當前事務，若是當前存在事務，就加入該事務，若是當前不存在事務，就以非事務執行。 3.PROPAGATION_MANDATORY：（支持事務）支持當前事務，若是當前存在事務，就加入該事務，若是當前不存在事務，就拋出異常。 4.PROPAGATION_REQUIRES_NEW：（支持事務）建立新事務，不管當前存不存在事務，都建立新事務。 5.PROPAGATION_NOT_SUPPORTED：（不支持事務）以非事務方式執行操做，若是當前存在事務，就把當前事務掛起。 6.PROPAGATION_NEVER：（不支持事務）以非事務方式執行，若是當前存在事務，則拋出異常。 7.PROPAGATION_NESTED：（不支持事務）若是當前存在事務，則在嵌套事務內執行。若是當前沒有事務，則執行與PROPAGATION_REQUIRED相似的操做

事務傳播特性例子講解：

//ServiveA
@Transactional (propagation = Propagation.REQUIRED )
public void dealA(){
Article a = new Article();
a.setTitlename("1");
this.sql.insert("com.faj.dao.ArticleMapper.insert",a);//插入

serviceB.dealB();//調用另外一個Service方法  
複製代碼

}

//ServiceB
@Transactional (propagation = Propagation.REQUIRED )
public void dealB(){
Article a = new Article();
a.setTitlename("3");
this.sqlSession.insert("com.faj.dao.ArticleMapper.insert",a);
throw new ApplicationException();
//ApplicationException是一個繼承RunTimeExcepiotn的異常處理類
}

REQUIRED是重可重入級別的，dealA調用了dealB，由於事務的傳播行爲是PROPAGATION_REQUIRED（若是有事務，那麼加入事務，沒有的話新建立一個），dealB加入到dealA的事務中，也就是兩個方法共享一個事務，由於是共享事務，因此兩條插入語句都會回滾。 參考：angelbill3.iteye.com/blog/193847…

66，mysql關聯插敘方式 1，內查詢（相似普通的聯合查詢），返回兩個表的交集，例子： select * from a_table a inner join b_table b on a.a_id = b.b_id; 2，左鏈接（左外鏈接），left join 是left outer join的簡寫，它的全稱是左外鏈接，是外鏈接中的一種。左(外)鏈接，左表(a_table)的記錄將會所有表示出來，而右表(b_table)只會顯示符合搜索條件的記錄。右表記錄不足的地方均爲NULL。例子：select * from a_table a left join b_table bon a.a_id = b.b_id; 3，右鏈接（右外鏈接），right join是right outer join的簡寫，它的全稱是右外鏈接，是外鏈接中的一種。與左(外)鏈接相反，右(外)鏈接，左表(a_table)只會顯示符合搜索條件的記錄，而右表(b_table)的記錄將會所有表示出來。左表記錄不足的地方均爲NULL。例子：select * from a_table a right outer join b_table b on a.a_id = b.b_id;

67，鏈接查詢（join on） 爲何比子查詢（in），聯合查詢（from table1，table2）效率高？ 錶鏈接的時候都要先造成一張笛卡爾積表，若是兩張表的數據量都比較大的話，那樣就會佔用很大的內存空間這顯然是不合理的。因此，咱們在進行錶鏈接查詢的時候通常都會使用JOIN xxx ON xxx的語法，ON語句的執行是在JOIN語句以前的，也就是說兩張表數據行之間進行匹配的時候，會先判斷數據行是否符合ON語句後面的條件，再決定是否JOIN，此時生成的笛卡爾積臨時表比較小。避免使用 FROM table1,table2 WHERE xxx 的語法，由於會在內存中先生成一張數據量比較大的笛卡爾積表，增長了內存的開銷。in子查詢也是先生成臨時表，再作一次笛卡爾積生成新臨時表，致使效率比較低。

68，mysql索引類別 1.普通索引 2.惟一索引 3.主鍵索引 4.組合索引 5.全文索引（目前只有MyISAM引擎支持，對搜索引擎稍微有點了解的同窗，確定知道分詞這個概念，FULLTEXT索引也是按照分詞原理創建索引的。西文中，大部分爲字母文字，分詞能夠很方便的按照空格進行分割。但很明顯，中文不能按照這種方式進行分詞。那又怎麼辦呢？這個向你們介紹一個Mysql的中文分詞插件Mysqlcft）

69，什麼是覆蓋索引 select的數據列只用從索引中就可以取得，沒必要從數據表中讀取，換句話說查詢列要被所使用的索引覆蓋。（經過explain命令能夠測試是否被索引命中「返回using index」）

70，爲何選用自增量做爲主鍵索引 mysql的innodb和myisam是mysql最多見的兩種數據庫引擎，底層實現都是使用了b+樹，b+樹的葉子節點都是存儲了有序片斷數據，若是順序自增鍵插入子節點更加高效，避免隨機插入頻繁致使節點的裂變。（非單調的主鍵會形成在插入新記錄時數據文件爲了維持B+Tree的特性而頻繁的分裂調整，十分低效，而使用自增字段做爲主鍵則是一個很好的選擇）

71，mysql死鎖的條件及應對措施 緣由：兩個事務執行邏輯，各自的內部邏輯相互等待另一個事務釋放鎖。

例子： 事務1 START TRANSACTION; UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4 and date = '2002-05-01';#（獲取行鎖） UPDATE StockPrice SET close = 19.80 WHERE stock_id = 3 and date = '2002-05-02';#（獲取行鎖） COMMIT;#釋放事務裏面的兩個行鎖 事務2 START TRANSACTION; UPDATE StockPrice SET high = 20.12 WHERE stock_id = 3 and date = '2002-05-02';#（獲取行鎖） UPDATE StockPrice SET close = 41.50 WHERE stock_id = 4 and date = '2002-05-01';#（獲取行鎖） COMMIT;#釋放事務裏面的兩個行鎖

解決辦法： 1，添加超時策略，超時回滾事務，避免鎖被持續競爭 2，以固定的順序訪問你的表和行。則事務造成良好定義的查詢而且沒有死鎖。 參考：blog.csdn.net/wwd0501/art…

72，談談sql查詢優化 1，要利用索引查詢。 2，儘可能利用主鍵查詢。 3，鏈接查詢代（join on）替子查詢（in）和聯合查詢（from t1，t2），避免在內存從造成巨大的笛卡爾積。 4，批量掃表時，每次查詢應該使用上次查詢返回的主鍵id做爲查詢條件，提升查詢效率。

73，mysql常見的集羣方案（blog.51cto.com/mingongge/2… a，一主多從 將master數據庫中的DDL和DML操做經過二進制日誌（BINLOG）傳輸到slave數據庫上，而後將這些日誌從新執行（重作）；從而使得slave數據庫的數據與master數據庫保持一致。 主從複製基本原理： 從庫生成兩個線程，一個I/O線程，一個SQL線程；i/o線程去請求主庫 的binlog，並將獲得的binlog日誌寫到relay log（中繼日誌） 文件中；主庫會生成一個 log dump 線程，用來給從庫 i/o線程傳binlog；SQL線 程，會讀取relay log文件中的日誌，並解析成具體操做，來實現主從的操做一致，而最終數據一致。 參考：blog.51cto.com/13266497/21…

mysql主從複製存在的問題: 1，主庫宕機後，數據可能丟失 2，從庫只有一個sql Thread，主庫寫壓力大，複製極可能延時

解決方法： 半同步複製---解決數據丟失的問題 異步複製----解決從庫複製延遲的問題 全同步複製：當主庫提交事務以後，全部的從庫節點必須收到、APPLY而且提交這些事務，而後主庫線程才能繼續作後續操做。但缺點是，主庫完成一個事務的時間會被拉長，性能下降。 異步複製，主庫將事務 Binlog 事件寫入到 Binlog 文件中，此時主庫只會通知一下 Dump 線程發送這些新的 Binlog，而後主庫就會繼續處理提交操做，而此時不會保證這些 Binlog 傳到任何一個從庫節點上。 半同步複製：一個事務在主服務器上執行完成後，必須至少確保至少在一臺從服務器上執行完成後，事務纔算提交成功。 主庫寫入一個事務commit提交併執行完以後，並不直接將請求反饋給前端應用用戶，而是等待從庫也接收到binlog日誌併成功寫入中繼日誌後，主庫才返回commit操做成功給客戶端。半同步複製保障了事物執行後，至少有兩份日誌記錄，一份在主庫的binlog上 ，另外一份至少在從庫的中繼日誌Relay log上，這樣就極大的保證了數據的一致性

Mysql的master和slave切換，心跳檢測程序檢測到master掛掉，slave之間會檢測binlog的最新操做記錄，肯定誰是最新的就成爲master，再回寫到配置中心（相似zk的實現lion），而且通知業務方主庫更新。

74，mysql三大範式（baijiahao.baidu.com/s?id=159195… 第一範式：全部屬性都不能在分解爲更基本的數據單位時，簡記爲1NF。知足第一範式是關係數據庫的最低要求。 第二範式：每一個非主鍵屬性徹底依賴於主鍵屬性，數據存在冗餘，或者部分數據沒法入表，如：學生表和課程表不該該整合在一塊，課程信息可能冗餘，也能夠插不進去。 第三範式：數據不傳遞依賴關係（屬性都跟主鍵有直接關係而不是間接關係），數據存在冗餘，如：（學號，姓名，年齡，性別，所在院校，院校地址，院校電話）可拆成（學號，姓名，年齡，性別，所在院校）和（所在院校，院校地址，院校電話）。 75，mysql索引最左原則 針對相似創建的索引是聯合索引（a，b，c），若是查詢使用a，ab，abc，ac都會調用索引查詢

76，mysql組合索引的b+樹結構（www.2cto.com/database/20… 聯合索引(col1, col2,col3)也是一棵B+Tree，其非葉子節點存儲的是第一個關鍵字的索引(第一列)，而葉節點存儲的則是三個關鍵字col一、col二、col3三個關鍵字的數據，且按照col一、col二、col3的順序進行排序，只有這樣作才符合最左原則的查詢

77，redis有哪些數據結構 string（普通的k-v存儲）， hash，常見的對象存儲，如存一個shopDTO list（底層實現是鏈表，存儲重複的數據），場景：好友最新消息，基於list能夠實現隊列或者棧，頭插或者尾插 set（HashMap實現的，Set只用了HashMap的key列來存儲對象，不容許有重複數據），集合有取交集、並集、差集等操做，所以能夠求共同好友、共同興趣、分類標籤等。 zset（有序集合，內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序），

79，redis常見面試題：blog.csdn.net/u010682330/…

80，Redis集羣最大節點個數是多少？ 16384個 81，Redis相比memcached有哪些優點？ memcached全部的值均是簡單的字符串，redis做爲其替代者，支持更爲豐富的數據類型 redis能夠持久化其數據 備註：  Memcached是多線程，非阻塞IO複用的網絡模型，分爲監聽主線程和worker子線程，監聽線程監聽網絡鏈接，接受請求後，將鏈接描述字pipe 傳遞給worker線程，進行讀寫IO, 網絡層使用libevent封裝的事件庫，多線程模型能夠發揮多核做用

Redis使用單線程的IO複用模型，本身封裝了一個簡單的AeEvent事件處理框架，主要實現了epoll、kqueue和select，對於單純只有IO操做來講，單線程能夠將速度優點發揮到最大，可是Redis也提供了一些簡單的計算功能，好比排序、聚合等，對於這些操做，單線程模型實際會嚴重影響總體吞吐量，CPU計算過程當中，整個IO調度都是被阻塞住的 參考：www.2cto.com/database/20…

82，redis什麼時候觸發淘汰數據的動做

一個客戶端執行指令，致使數據的增長時。 Redis檢測到內存的使用已經達到上限。 Redis自身執行指令時

補充：Redis爲了不反覆觸發淘汰策略，每次會淘汰掉一批數據。

Redis的內存淘汰策略 Redis的內存淘汰策略是指在Redis的用於緩存的內存不足時，怎麼處理須要新寫入且須要申請額外空間的數據。

83，redis內存淘汰策略（LRU算法） allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的key。 allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個key。 volatile-lru：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間中，移除最近最少使用的key。 volatile-random：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間中，隨機移除某個key。 volatile-ttl：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間中，有更早過時時間的key優先移除。 noeviction：當內存不足以容納新寫入數據時，新寫入操做會報錯。

Redis中同時使用了惰性過時（對cpu友好，對內存不友好，長期佔用內存才能，使用的時候檢查有效期），按期過時（集中使用cpu），過期立馬刪除（異步線程掃描全部數據），底層是有一個字典結構，在惰性刪除時，會掃描檢查key是否超時。

連接：www.jianshu.com/p/8aa619933…

84，MySQL裏有2000w數據，redis中只存20w的數據，如何保證redis中的數據都是熱點數據？ redis內存數據集大小上升到必定大小的時候，就會施行數據淘汰策略（計算一下 20W 數據大約佔用的內存，而後設置一下 Redis 內存限制便可）

85，Redis集羣會有寫操做丟失嗎？爲何？ Redis並不能保證數據的強一致性，這意味這在實際中集羣在特定的條件下可能會丟失寫操做。

8六、Redis集羣之間是如何複製的？ 異步複製

87，Reactor模式，參考：www.cnblogs.com/doit8791/p/…

88，Lucene倒排索引原理

倒排索引（hash表） 倒排索引在全文檢索（如單詞檢索）環境中的利器，而mysql的b+樹對於全文檢索很是困難，所以mysql的b+樹索引是基於數值排序（如主鍵索引）。

簡述正排索引和倒排索引 舉例：若有兩個文檔，doc1，doc2，裏面有不少單詞，咱們查找單詞」hello「出現的頻次

正排索引實現：doc1->每一個單詞->詞頻 檢索過程：先逐個遍歷文檔，再找單詞詞頻，若是是海量文件，查找效率很慢（須要遍歷全部的文件）

倒排索引實現：每一個單詞->{（doc1，10）,(doc2,13),...(文檔id，頻次)} 檢索過程：先找單詞，再找文檔，再找單詞詞頻，對於海量文件，查找效率很是高

備註：正排索引是文檔id到單詞，而倒排索引是單詞到文檔id

參考：www.cnblogs.com/zlslch/p/64…

88，Lucene倒排索引壓縮算法

爲了減少索引文件的大小，Lucene對索引還使用了壓縮技術。 首先，對詞典文件中的關鍵詞進行了壓縮，關鍵詞壓縮爲<前綴長度，後綴>，例如：當前詞爲「阿拉伯語」，上一個詞爲「阿拉伯」，那麼「阿拉伯語」壓縮爲<3，語>。 其次大量用到的是對數字的壓縮，數字只保存與上一個值的差值（這樣能夠減少數字的長度，進而減小保存該數字須要的字節數）。例如當前文章號是16389（不壓縮要用3個字節保存），上一文章號是16382，壓縮後保存7（只用一個字節）。

www.cnblogs.com/ygj0930/art…

89，Lucene&Solr&ElasticSearch <1>Elasticsearch是一個實時的分佈式搜索和分析引擎。能夠快速處理大規模數據。能夠用於全文搜索、結構化搜索和分析   利用zk實現分佈式實時文件存儲，並將每個字段都編入索引，使其能夠被搜索；   實時分析的分佈式搜索引擎；   能夠擴展到上百臺服務器，處理PB級別的結構化或非結構化數據

<2>Solr是Apache Lucene項目的開源企業搜索平臺。主要功能包括全文檢索、命中標示、分面搜索、動態聚類、數據庫集成，以及富文本的處理。是高度可擴展的，並提供了分佈式搜索和索引複製。是最流行的企業級搜索引擎。是一個獨立的全文搜索服務器，solr自帶分佈式實現的協調器。

Solr的缺點：創建索引時，搜索效率降低，實時索引搜索效率不高（實時創建索引時，Solr會產生io阻塞，查詢性能較差，Elasticsearch具備更明顯的優點）。 Solr的優勢：單純的對已有數據進行搜索時，Solr更快 Solr 是傳統搜索應用的有力解決方案，但 Elasticsearch 更適用於新興的實時搜索應用。 es內對對索引構建採起了多線程，效率比solr高不少

參考：blog.csdn.net/Ms_lang/art…

90，solr和es的一些面試題 blog.csdn.net/Ms_lang/art…

91，Elasticsearch集羣部署（整合zk） cluster：表明一個集羣，集羣中有多個節點，其中有一個爲主節點，這個主節點是能夠經過選舉產生的，主從節點是對於集羣內部來講的。es的一個概念就是去中心化，字面上理解就是無中心節點，這是對於集羣外部來講的，由於從外部來看es集羣，在邏輯上是個總體，你與任何一個節點的通訊和與整個es集羣通訊是等價的。

shards：表明索引分片，es能夠把一個完整的索引分紅多個分片，這樣的好處是能夠把一個大的索引拆分紅多個，分佈到不一樣的節點上。構成分佈式搜索。分片的數量只能在索引建立前指定，而且索引建立後不能更改。

replicas：表明索引副本，es能夠設置多個索引的副本，副本的做用一是提升系統的容錯性，當某個節點某個分片損壞或丟失時能夠從副本中恢復。二是提升es的查詢效率，es會自動對搜索請求進行負載均衡。

參考：www.cnblogs.com/aubin/p/801…

92，es集羣調優 www.cnblogs.com/guguli/p/52…

93，如何提升ElasticSearch 索引速度 由於ES裏大量採用線程池，構建索引的時候，是有單獨的線程池作處理的，加大線程池，提升併發處理能力

94，tair原理：

一個Tair集羣主要包括3個必選模塊：config server、data server和client，以及一個可選模塊：invalid server。

一般狀況下，一個集羣中包含2臺config server及多臺data server。兩臺config server互爲主備並經過維護和data server之間的心跳獲知集羣中存活可用的data server， 構建數據在集羣中的分佈信息（對照表）。Data server負責數據的存儲，並按照config server的指示完成數據的複製和遷移工做。 Client在啓動的時候，從config server獲取數據分佈信息，根據數據分佈信息和相應的data server交互完成用戶的請求。 Invalid server主要負責對等集羣的刪除和隱藏操做，保證對等集羣的數據一致。

從架構上看，config server的角色相似於傳統應用系統的中心節點，整個集羣服務依賴於config server的正常工做。但實際上相對來講， tair的config server是很是輕量級的，當正在工做的服務器宕機的時候另一臺會在秒級別時間內自動接管。 並且，若是出現兩臺服務器同時宕機的最惡劣狀況，只要應用服務器沒有新的變化，tair依然服務正常。 而有了config server這個中心節點，帶來的好處就是應用在使用的時候只須要配置config server的地址（如今能夠直接配置Diamond key）， 而不須要知道內部節點的狀況。

ConfigServer的功能 負責管理全部的data server, 維護data server的狀態信息。 經過維護和dataserver心跳來獲知集羣中存活節點的信息 根據存活節點的信息來構建數據在集羣中的分佈表。 提供數據分佈表的查詢服務。 調度dataserver之間的數據遷移、複製。

DataServer的功能 對外提供各類數據服務, 並以心跳的形式將自身情況彙報給config server。 提供存儲引擎 接受client的put/get/remove等操做 執行數據遷移，複製等 插件：在接受請求的時候處理一些自定義功能 訪問統計

InvalidServer的功能 接收來自client的invalid/hide等請求後，對屬於同一組的集羣（雙機房獨立集羣部署方式）作delete/hide操做，保證同一組集羣的一致。 集羣斷網以後的，髒數據清理。 訪問統計。

client的功能 在應用端提供訪問Tair集羣的接口。 更新並緩存數據分佈表和invalidserver地址等。 LocalCache，避免過熱數據訪問影響tair集羣服務。 流控

參考：blog.csdn.net/sunjin9418/…

tair的特色 <1> Tair有四種引擎：mdb, rdb, kdb和ldb。分別基於四種開源的key/value數據庫：memcached, Redis, Kyoto Cabinet和leveldb。Tair可讓你更方便地使用這些KV數據庫。 Tair默認包含兩個存儲引擎：mdb和fdb。 <2>Version支持，相似mysql的mvcc機制，支持寫入數據時對版本號控制。 <3>多機架和多數據中心的支持 對照表在構建時，能夠配置將數據的備份分散到不一樣機架或數據中心的節點上。Tair當前經過設置一個IP掩碼來判斷機器所屬的機架和數據中心信息。 好比你配置備份數爲3，集羣的節點分佈在兩個不一樣的數據中心A和B，則Tair會確保每一個機房至少有一份數據。假設A數據中心包含兩份數據時，Tair會盡量將這兩份數據分佈在不一樣機架的節點上。這能夠減小整個數據中心或某個機架發生故障是數據丟失的風險。 <4>tair實現了一個集羣多中心部署，這是redis 3.0沒有實現的。 <5>DataServer負責數據的物理存儲，並根據configserver構建的對照表完成數據的複製和遷移工做。DataServer具有抽象的存儲引擎層，能夠很方便地添加新存儲引擎。DataServer還有一個插件容器，能夠動態地加載/卸載插件

參考：www.jianshu.com/p/ccb17daed…

tair 的負載均衡算法是什麼 tair 的分佈採用的是一致性哈希算法， 對於全部的key，分到Q個桶中， 桶是負載均衡和數據遷移的基本單位。 config server 根據必定的策略把每一個桶指派到不一樣的data server上。 由於數據按照key作hash算法， 因此能夠認爲每一個桶中的數據基本是平衡的. 保證了桶分佈的均衡性， 就保證了數據分佈的均衡性。

tair擴容 數據遷移時data server對外提供服務的策略，假設data server A要把桶1,2,3遷移到data server B，由於遷移完成前，客戶端的路由表沒有變化，客戶端對1,2,3的訪問請求都會路由到A，如今假設1還沒遷移，2正在遷移，3已經遷移完成，那麼若是訪問1，則仍是訪問data server A，若是訪問3，則A會把請求轉發給B，而且將B的返回結果返回給客戶，若是訪問2，則在A上處理，同時若是是對2的修改操做，會記錄修改log，當桶2完成遷移的時候，還有把log發送給B，在B上應用這些log，最終AB數據一致纔是真正完成遷移。若是A是因爲宕機而引起的遷移，客戶端會收到一張中間臨時狀態的分配表，把宕機的data server負責的桶臨時指派給有其備份的data server來處理，此時服務是可用的，負載可能不均衡，當遷移完成後，又能達到一個新的負載均衡狀態

tair的數據備份： config server會發現哪些桶的備份數目減小了， 而後根據負載狀況在負載較低的data server上增長這些桶的備份，所以能夠理解某個data server的數據是備份在其餘的data server 若是是由於某data server宕機而引起的遷移，客戶端會收到一張中間臨時狀態的分配表。 這張表中，把宕機的data server所負責的桶臨時指派給有其備份data server來處理。這個時候，服務是可用的，可是負載可能不均衡。 當遷移完成以後，才能從新達到一個新的負載均衡的狀態。

參考：blog.csdn.net/death_kada/…

歡迎打賞