今天給大家講下Java面試培訓(xùn)-企業(yè)常問的數(shù)據(jù)庫方面問題：為什么用自增列作為主鍵

如果我們定義了主鍵(PRIMARY KEY)，那么InnoDB會選擇主鍵作為聚集索引、如果沒有顯式定義主鍵，則InnoDB會選擇第一個不包含有NULL值的唯一索引作為主鍵索引、如果也沒有這樣的唯一索引，則InnoDB會選擇內(nèi)置6字節(jié)長的ROWID作為隱含的聚集索引(ROWID隨著行記錄的寫入而主鍵遞增，這個ROWID不像ORACLE的ROWID那樣可引用，是隱含的)。

數(shù)據(jù)記錄本身被存于主索引（一顆B+Tree）的葉子節(jié)點上。這就要求同一個葉子節(jié)點內(nèi)（大小為一個內(nèi)存頁或磁盤頁）的各條數(shù)據(jù)記錄按主鍵順序存放，因此每當有一條新的記錄插入時，MySQL會根據(jù)其主鍵將其插入適當?shù)墓?jié)點和位置，如果頁面達到裝載因子（InnoDB默認為15/16），則開辟一個新的頁（節(jié)點）

如果表使用自增主鍵，那么每次插入新的記錄，記錄就會順序添加到當前索引節(jié)點的后續(xù)位置，當一頁寫滿，就會自動開辟一個新的頁

如果使用非自增主鍵（如果身份證號或?qū)W號等），由于每次插入主鍵的值近似于隨機，因此每次新紀錄都要被插到現(xiàn)有索引頁得中間某個位置，此時MySQL不得不為了將新記錄插到合適位置而移動數(shù)據(jù)，甚至目標頁面可能已經(jīng)被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增加了很多開銷，同時頻繁的移動、分頁操作造成了大量的碎片，得到了不夠緊湊的索引結(jié)構(gòu)，后續(xù)不得不通過OPTIMIZE TABLE來重建表并優(yōu)化填充頁面。

為什么使用數(shù)據(jù)索引能提高效率

數(shù)據(jù)索引的存儲是有序的

在有序的情況下，通過索引查詢一個數(shù)據(jù)是無需遍歷索引記錄的

極端情況下，數(shù)據(jù)索引的查詢效率為二分法查詢效率，趨近于 log2(N)

B+樹索引和哈希索引的區(qū)別

B+樹是一個平衡的多叉樹，從根節(jié)點到每個葉子節(jié)點的高度差值不超過1，而且同層級的節(jié)點間有指針相互鏈接，是有序的

哈希索引就是采用一定的哈希算法，把鍵值換算成新的哈希值，檢索時不需要類似B+樹那樣從根節(jié)點到葉子節(jié)點逐級查找，只需一次哈希算法即可,是無序的

哈希索引的優(yōu)勢：

等值查詢。哈希索引具有絕對優(yōu)勢（前提是：沒有大量重復(fù)鍵值，如果大量重復(fù)鍵值時，哈希索引的效率很低，因為存在所謂的哈希碰撞問題。）

哈希索引不適用的場景：

不支持范圍查詢

不支持索引完成排序

不支持聯(lián)合索引的最左前綴匹配規(guī)則

通常，B+樹索引結(jié)構(gòu)適用于絕大多數(shù)場景，像下面這種場景用哈希索引才更有優(yōu)勢：

在HEAP表中，如果存儲的數(shù)據(jù)重復(fù)度很低（也就是說基數(shù)很大），對該列數(shù)據(jù)以等值查詢?yōu)橹?，沒有范圍查詢、沒有排序的時候，特別適合采用哈希索引，例如這種SQL：

select id,name from table where name=’李明’; — 僅等值查詢

而常用的InnoDB引擎中默認使用的是B+樹索引，它會實時監(jiān)控表上索引的使用情況，如果認為建立哈希索引可以提高查詢效率，則自動在內(nèi)存中的“自適應(yīng)哈希索引緩沖區(qū)”建立哈希索引（在InnoDB中默認開啟自適應(yīng)哈希索引），通過觀察搜索模式，MySQL會利用index key的前綴建立哈希索引，如果一個表幾乎大部分都在緩沖池中，那么建立一個哈希索引能夠加快等值查詢。

注意：在某些工作負載下，通過哈希索引查找?guī)淼男阅芴嵘h大于額外的監(jiān)控索引搜索情況和保持這個哈希表結(jié)構(gòu)所帶來的開銷。但某些時候，在負載高的情況下，自適應(yīng)哈希索引中添加的read/write鎖也會帶來競爭，比如高并發(fā)的join操作。like操作和%的通配符操作也不適用于自適應(yīng)哈希索引，可能要關(guān)閉自適應(yīng)哈希索引。

B樹和B+樹的區(qū)別

B樹，每個節(jié)點都存儲key和data，所有節(jié)點組成這棵樹，并且葉子節(jié)點指針為nul，葉子結(jié)點不包含任何關(guān)鍵字信息。

B+樹，所有的葉子結(jié)點中包含了全部關(guān)鍵字的信息，及指向含有這些關(guān)鍵字記錄的指針，且葉子結(jié)點本身依關(guān)鍵字的大小自小而大的順序鏈接，所有的非終端結(jié)點可以看成是索引部分，結(jié)點中僅含有其子樹根結(jié)點中最大（或最?。╆P(guān)鍵字。 (而B 樹的非終節(jié)點也包含需要查找的有效信息)

為什么說B+比B樹更適合實際應(yīng)用中操作系統(tǒng)的文件索引和數(shù)據(jù)庫索引？

B+的磁盤讀寫代價更低B+的內(nèi)部結(jié)點并沒有指向關(guān)鍵字具體信息的指針。因此其內(nèi)部結(jié)點相對B樹更小。如果把所有同一內(nèi)部結(jié)點的關(guān)鍵字存放在同一盤塊中，那么盤塊所能容納的關(guān)鍵字數(shù)量也越多。一次性讀入內(nèi)存中的需要查找的關(guān)鍵字也就越多。相對來說IO讀寫次數(shù)也就降低了。

B+-tree的查詢效率更加穩(wěn)定由于非終結(jié)點并不是最終指向文件內(nèi)容的結(jié)點，而只是葉子結(jié)點中關(guān)鍵字的索引。所以任何關(guān)鍵字的查找必須走一條從根結(jié)點到葉子結(jié)點的路。所有關(guān)鍵字查詢的路徑長度相同，導(dǎo)致每一個數(shù)據(jù)的查詢效率相當。

MySQL聯(lián)合索引

聯(lián)合索引是兩個或更多個列上的索引。對于聯(lián)合索引:Mysql從左到右的使用索引中的字段，一個查詢可以只使用索引中的一部份，但只能是最左側(cè)部分。例如索引是key index (a,b,c). 可以支持a ? 、 ? ?a,b ? 、 ?a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側(cè)字段是常量引用時，索引就十分有效。

利用索引中的附加列，您可以縮小搜索的范圍，但使用一個具有兩列的索引 不同于使用兩個單獨的索引。復(fù)合索引的結(jié)構(gòu)與電話簿類似，人名由姓和名構(gòu)成，電話簿首先按姓氏對進行排序，然后按名字對有相同姓氏的人進行排序。如果您知 道姓，電話簿將非常有用；如果您知道姓和名，電話簿則更為有用，但如果您只知道名不姓，電話簿將沒有用處。

什么情況下應(yīng)不建或少建索引

表記錄太少

經(jīng)常插入、刪除、修改的表

數(shù)據(jù)重復(fù)且分布平均的表字段，假如一個表有10萬行記錄，有一個字段A只有T和F兩種值，且每個值的分布概率大約為50%，那么對這種表A字段建索引一般不會提高數(shù)據(jù)庫的查詢速度。

經(jīng)常和主字段一塊查詢但主字段索引值比較多的表字段

MySQL分區(qū)

一. 什么是表分區(qū)？

表分區(qū)，是指根據(jù)一定規(guī)則，將數(shù)據(jù)庫中的一張表分解成多個更小的，容易管理的部分。從邏輯上看，只有一張表，但是底層卻是由多個物理分區(qū)組成。

二. 表分區(qū)與分表的區(qū)別

分表：指的是通過一定規(guī)則，將一張表分解成多張不同的表。比如將用戶訂單記錄根據(jù)時間成多個表。

分表與分區(qū)的區(qū)別在于：分區(qū)從邏輯上來講只有一張表，而分表則是將一張表分解成多張表。

三. 表分區(qū)有什么好處？

分區(qū)表的數(shù)據(jù)可以分布在不同的物理設(shè)備上，從而高效地利用多個硬件設(shè)備。 2. 和單個磁盤或者文件系統(tǒng)相比，可以存儲更多數(shù)據(jù)

優(yōu)化查詢。在where語句中包含分區(qū)條件時，可以只掃描一個或多個分區(qū)表來提高查詢效率；涉及sum和count語句時，也可以在多個分區(qū)上并行處理，最后匯總結(jié)果。

分區(qū)表更容易維護。例如：想批量刪除大量數(shù)據(jù)可以清除整個分區(qū)。

可以使用分區(qū)表來避免某些特殊的瓶頸，例如InnoDB的單個索引的互斥訪問，ext3問價你系統(tǒng)的inode鎖競爭等。

四. 分區(qū)表的限制因素

一個表最多只能有1024個分區(qū)

MySQL5.1中，分區(qū)表達式必須是整數(shù)，或者返回整數(shù)的表達式。在MySQL5.5中提供了非整數(shù)表達式分區(qū)的支持。

如果分區(qū)字段中有主鍵或者唯一索引的列，那么多有主鍵列和唯一索引列都必須包含進來。即：分區(qū)字段要么不包含主鍵或者索引列，要么包含全部主鍵和索引列。

分區(qū)表中無法使用外鍵約束

MySQL的分區(qū)適用于一個表的所有數(shù)據(jù)和索引，不能只對表數(shù)據(jù)分區(qū)而不對索引分區(qū)，也不能只對索引分區(qū)而不對表分區(qū)，也不能只對表的一部分數(shù)據(jù)分區(qū)。

五. 如何判斷當前MySQL是否支持分區(qū)？

命令：show variables like ‘%partition%’ 運行結(jié)果:

mysql> show variables like ‘%partition%’;+——————-+——-+| Variable_name ? ? | Value |+——————-+——-+| have_partitioning | YES ? |+——————-+——-+1 row in set (0.00 sec)have_partintioning 的值為YES，表示支持分區(qū)。

六. MySQL支持的分區(qū)類型有哪些？

RANGE分區(qū)： 這種模式允許將數(shù)據(jù)劃分不同范圍。例如可以將一個表通過年份劃分成若干個分區(qū)

LIST分區(qū)： 這種模式允許系統(tǒng)通過預(yù)定義的列表的值來對數(shù)據(jù)進行分割。按照List中的值分區(qū)，與RANGE的區(qū)別是，range分區(qū)的區(qū)間范圍值是連續(xù)的。

HASH分區(qū) ：這中模式允許通過對表的一個或多個列的Hash Key進行計算，最后通過這個Hash碼不同數(shù)值對應(yīng)的數(shù)據(jù)區(qū)域進行分區(qū)。例如可以建立一個對表主鍵進行分區(qū)的表。

KEY分區(qū) ：上面Hash模式的一種延伸，這里的Hash Key是MySQL系統(tǒng)產(chǎn)生的。

四種隔離級別

Serializable (串行化)：可避免臟讀、不可重復(fù)讀、幻讀的發(fā)生。

Repeatable read (可重復(fù)讀)：可避免臟讀、不可重復(fù)讀的發(fā)生。

Read committed (讀已提交)：可避免臟讀的發(fā)生。

Read uncommitted (讀未提交)：最低級別，任何情況都無法保證。

關(guān)于MVVC

MySQL InnoDB存儲引擎，實現(xiàn)的是基于多版本的并發(fā)控制協(xié)議——MVCC (Multi-Version Concurrency Control) (注：與MVCC相對的，是基于鎖的并發(fā)控制，Lock-Based Concurrency Control)。MVCC最大的好處：讀不加鎖，讀寫不沖突。在讀多寫少的OLTP應(yīng)用中，讀寫不沖突是非常重要的，極大的增加了系統(tǒng)的并發(fā)性能，現(xiàn)階段幾乎所有的RDBMS，都支持了MVCC。

LBCC：Lock-Based Concurrency Control，基于鎖的并發(fā)控制。

MVCC：Multi-Version Concurrency Control，基于多版本的并發(fā)控制協(xié)議。純粹基于鎖的并發(fā)機制并發(fā)量低，MVCC是在基于鎖的并發(fā)控制上的改進，主要是在讀操作上提高了并發(fā)量。

在MVCC并發(fā)控制中，讀操作可以分成兩類：

快照讀 (snapshot read)：讀取的是記錄的可見版本 (有可能是歷史版本)，不用加鎖（共享讀鎖s鎖也不加，所以不會阻塞其他事務(wù)的寫）。

當前讀 (current read)：讀取的是記錄的最新版本，并且，當前讀返回的記錄，都會加上鎖，保證其他事務(wù)不會再并發(fā)修改這條記錄。

行級鎖定的優(yōu)點：

當在許多線程中訪問不同的行時只存在少量鎖定沖突。

回滾時只有少量的更改

可以長時間鎖定單一的行。

行級鎖定的缺點：

比頁級或表級鎖定占用更多的內(nèi)存。

當在表的大部分中使用時，比頁級或表級鎖定速度慢，因為你必須獲取更多的鎖。

如果你在大部分數(shù)據(jù)上經(jīng)常進行GROUP BY操作或者必須經(jīng)常掃描整個表，比其它鎖定明顯慢很多。

用高級別鎖定，通過支持不同的類型鎖定，你也可以很容易地調(diào)節(jié)應(yīng)用程序，因為其鎖成本小于行級鎖定。

MySQL觸發(fā)器簡單實例

CREATE TRIGGER <觸發(fā)器名稱> ?–觸發(fā)器必須有名字，最多64個字符，可能后面會附有分隔符.它和MySQL中其他對象的命名方式基本相象.

{ BEFORE | AFTER } ?–觸發(fā)器有執(zhí)行的時間設(shè)置：可以設(shè)置為事件發(fā)生前或后。

{ INSERT | UPDATE | DELETE } ?–同樣也能設(shè)定觸發(fā)的事件：它們可以在執(zhí)行insert、update或delete的過程中觸發(fā)。

ON <表名稱> ?–觸發(fā)器是屬于某一個表的:當在這個表上執(zhí)行插入、 更新或刪除操作的時候就導(dǎo)致觸發(fā)器的激活. 我們不能給同一張表的同一個事件安排兩個觸發(fā)器。

FOR EACH ROW ?–觸發(fā)器的執(zhí)行間隔：FOR EACH ROW子句通知觸發(fā)器 每隔一行執(zhí)行一次動作，而不是對整個表執(zhí)行一次。

<觸發(fā)器SQL語句> ?–觸發(fā)器包含所要觸發(fā)的SQL語句：這里的語句可以是任何合法的語句， 包括復(fù)合語句，但是這里的語句受的限制和函數(shù)的一樣。

什么是存儲過程

簡單的說，就是一組SQL語句集，功能強大，可以實現(xiàn)一些比較復(fù)雜的邏輯功能，類似于JAVA語言中的方法；

ps:存儲過程跟觸發(fā)器有點類似，都是一組SQL集，但是存儲過程是主動調(diào)用的，且功能比觸發(fā)器更加強大，觸發(fā)器是某件事觸發(fā)后自動調(diào)用；

有哪些特性

有輸入輸出參數(shù)，可以聲明變量，有if/else, case,while等控制語句，通過編寫存儲過程，可以實現(xiàn)復(fù)雜的邏輯功能；

函數(shù)的普遍特性：模塊化，封裝，代碼復(fù)用；

速度快，只有首次執(zhí)行需經(jīng)過編譯和優(yōu)化步驟，后續(xù)被調(diào)用可以直接執(zhí)行，省去以上步驟；

DROP PROCEDURE IF EXISTS `proc_adder`;

DELIMITER ;;

CREATE DEFINER=`root`@`localhost` PROCEDURE `proc_adder`(IN a int, IN b int, OUT sum int)

BEGIN

#Routine body goes here…

DECLARE c int;

if a is null then set a = 0;

end if;

if b is null then set b = 0;

end if;

set sum ?= a + b;

END

;;

DELIMITER ;

set @b=5;

call proc_adder(0,@b,@s);

SELECT @s as sum;

create table tab2(

tab2_id varchar(11)

);

DROP TRIGGER if EXISTS t_ai_on_tab1;

create TRAILING t_ai_on_tab1

AFTER INSERT ON tab1

for EACH ROW

BEGIN

INSERT INTO tab2(tab2_id) values(new.tab1_id);

end;

INSERT INTO tab1(tab1_id) values(‘0001’);

SELECT * FROM tab2;

MySQL優(yōu)化

開啟查詢緩存，優(yōu)化查詢

explain你的select查詢，這可以幫你分析你的查詢語句或是表結(jié)構(gòu)的性能瓶頸。EXPLAIN 的查詢結(jié)果還會告訴你你的索引主鍵被如何利用的，你的數(shù)據(jù)表是如何被搜索和排序的

當只要一行數(shù)據(jù)時使用limit 1，MySQL數(shù)據(jù)庫引擎會在找到一條數(shù)據(jù)后停止搜索，而不是繼續(xù)往后查少下一條符合記錄的數(shù)據(jù)

為搜索字段建索引

使用 ENUM 而不是 VARCHAR，如果你有一個字段，比如“性別”，“國家”，“民族”，“狀態(tài)”或“部門”，你知道這些字段的取值是有限而且固定的，那么，你應(yīng)該使用 ENUM 而不是VARCHAR。

Prepared StatementsPrepared Statements很像存儲過程，是一種運行在后臺的SQL語句集合，我們可以從使用 prepared statements 獲得很多好處，無論是性能問題還是安全問題。Prepared Statements 可以檢查一些你綁定好的變量，這樣可以保護你的程序不會受到“SQL注入式”攻擊

垂直分表

選擇正確的存儲引擎

key和index的區(qū)別

key 是數(shù)據(jù)庫的物理結(jié)構(gòu)，它包含兩層意義和作用，一是約束（偏重于約束和規(guī)范數(shù)據(jù)庫的結(jié)構(gòu)完整性），二是索引（輔助查詢用的）。包括primary key, unique key, foreign key 等

index是數(shù)據(jù)庫的物理結(jié)構(gòu)，它只是輔助查詢的，它創(chuàng)建時會在另外的表空間（mysql中的innodb表空間）以一個類似目錄的結(jié)構(gòu)存儲。索引要分類的話，分為前綴索引、全文本索引等；

Mysql 中 MyISAM 和 InnoDB 的區(qū)別有哪些？

區(qū)別：

InnoDB支持事務(wù)，MyISAM不支持，對于InnoDB每一條SQL語言都默認封裝成事務(wù)，自動提交，這樣會影響速度，所以最好把多條SQL語言放在begin和commit之間，組成一個事務(wù)；

InnoDB支持外鍵，而MyISAM不支持。對一個包含外鍵的InnoDB表轉(zhuǎn)為MYISAM會失敗；

InnoDB是聚集索引，數(shù)據(jù)文件是和索引綁在一起的，必須要有主鍵，通過主鍵索引效率很高。但是輔助索引需要兩次查詢，先查詢到主鍵，然后再通過主鍵查詢到數(shù)據(jù)。因此，主鍵不應(yīng)該過大，因為主鍵太大，其他索引也都會很大。而MyISAM是非聚集索引，數(shù)據(jù)文件是分離的，索引保存的是數(shù)據(jù)文件的指針。主鍵索引和輔助索引是獨立的。

InnoDB不保存表的具體行數(shù)，執(zhí)行select count(*) from table時需要全表掃描。而MyISAM用一個變量保存了整個表的行數(shù)，執(zhí)行上述語句時只需要讀出該變量即可，速度很快；

Innodb不支持全文索引，而MyISAM支持全文索引，查詢效率上MyISAM要高；

如何選擇：

是否要支持事務(wù)，如果要請選擇innodb，如果不需要可以考慮MyISAM；

如果表中絕大多數(shù)都只是讀查詢，可以考慮MyISAM，如果既有讀寫也挺頻繁，請使用InnoDB。

系統(tǒng)奔潰后，MyISAM恢復(fù)起來更困難，能否接受；

MySQL5.5版本開始Innodb已經(jīng)成為Mysql的默認引擎(之前是MyISAM)，說明其優(yōu)勢是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不會差。

數(shù)據(jù)庫表創(chuàng)建注意事項

一、字段名及字段配制合理性

剔除關(guān)系不密切的字段

字段命名要有規(guī)則及相對應(yīng)的含義（不要一部分英文，一部分拼音，還有類似a.b.c這樣不明含義的字段）

字段命名盡量不要使用縮寫（大多數(shù)縮寫都不能明確字段含義）

字段不要大小寫混用（想要具有可讀性，多個英文單詞可使用下劃線形式連接）

字段名不要使用保留字或者關(guān)鍵字

保持字段名和類型的一致性

慎重選擇數(shù)字類型

給文本字段留足余量

二、系統(tǒng)特殊字段處理及建成后建議

添加刪除標記（例如操作人、刪除時間）

建立版本機制

三、表結(jié)構(gòu)合理性配置

多型字段的處理，就是表中是否存在字段能夠分解成更小獨立的幾部分（例如：人可以分為男人和女人）

多值字段的處理，可以將表分為三張表，這樣使得檢索和排序更加有調(diào)理，且保證數(shù)據(jù)的完整性！

四、其它建議

對于大數(shù)據(jù)字段，獨立表進行存儲，以便影響性能（例如：簡介字段）

使用varchar類型代替char，因為varchar會動態(tài)分配長度，char指定長度是固定的。

給表創(chuàng)建主鍵，對于沒有主鍵的表，在查詢和索引定義上有一定的影響。

避免表字段運行為null，建議設(shè)置默認值（例如：int類型設(shè)置默認值為0）在索引查詢上，效率立顯！

建立索引，最好建立在唯一和非空的字段上，建立太多的索引對后期插入、更新都存在一定的影響（考慮實際情況來創(chuàng)建）。

Redis

Redis單線程問題

單線程指的是網(wǎng)絡(luò)請求模塊使用了一個線程（所以不需考慮并發(fā)安全性），即一個線程處理所有網(wǎng)絡(luò)請求，其他模塊仍用了多個線程。

為什么說Redis能夠快速執(zhí)行

絕大部分請求是純粹的內(nèi)存操作（非常快速）

采用單線程,避免了不必要的上下文切換和競爭條件

非阻塞IO – IO多路復(fù)用

Redis的內(nèi)部實現(xiàn)

內(nèi)部實現(xiàn)采用epoll，采用了epoll+自己實現(xiàn)的簡單的事件框架。epoll中的讀、寫、關(guān)閉、連接都轉(zhuǎn)化成了事件，然后利用epoll的多路復(fù)用特性，不在io上浪費一點時間 這3個條件不是相互獨立的，特別是第一條，如果請求都是耗時的，采用單線程吞吐量及性能很差。redis為特殊的場景選擇了合適的技術(shù)方案。

Redis關(guān)于線程安全問題

redis實際上是采用了線程封閉的觀念，把任務(wù)封閉在一個線程，自然避免了線程安全問題，不過對于需要依賴多個redis操作的復(fù)合操作來說，依然需要鎖，而且有可能是分布式鎖。

使用Redis有哪些好處？

速度快，因為數(shù)據(jù)存在內(nèi)存中，類似于HashMap，HashMap的優(yōu)勢就是查找和操作的時間復(fù)雜度都是O(1)

支持豐富數(shù)據(jù)類型，支持string，list，set，sorted set，hash

支持事務(wù)，操作都是原子性，所謂的原子性就是對數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行

豐富的特性：可用于緩存，消息，按key設(shè)置過期時間，過期后將會自動刪除

redis相比memcached有哪些優(yōu)勢？

memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富的數(shù)據(jù)類型

redis的速度比memcached快很多

redis可以持久化其數(shù)據(jù)

Redis支持數(shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。

使用底層模型不同，它們之間底層實現(xiàn)方式 以及與客戶端之間通信的應(yīng)用協(xié)議不一樣。Redis直接自己構(gòu)建了VM 機制 ，因為一般的系統(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會浪費一定的時間去移動和請求。

value大?。簉edis最大可以達到1GB，而memcache只有1MB

Redis主從復(fù)制

過程原理：

當從庫和主庫建立MS關(guān)系后,會向主數(shù)據(jù)庫發(fā)送SYNC命令

主庫接收到SYNC命令后會開始在后臺保存快照(RDB持久化過程),并將期間接收到的寫命令緩存起來

當快照完成后,主Redis會將快照文件和所有緩存的寫命令發(fā)送給從Redis

從Redis接收到后,會載入快照文件并且執(zhí)行收到的緩存的命令

之后,主Redis每當接收到寫命令時就會將命令發(fā)送從Redis，從而保證數(shù)據(jù)的一致

缺點：所有的slave節(jié)點數(shù)據(jù)的復(fù)制和同步都由master節(jié)點來處理,會照成master節(jié)點壓力太大,使用主從從結(jié)構(gòu)來解決

Redis兩種持久化方式的優(yōu)缺點

RDB 持久化可以在指定的時間間隔內(nèi)生成數(shù)據(jù)集的時間點快照（point-in-time snapshot）

AOF 持久化記錄服務(wù)器執(zhí)行的所有寫操作命令，并在服務(wù)器啟動時，通過重新執(zhí)行這些命令來還原數(shù)據(jù)集。

Redis 還可以同時使用 AOF 持久化和 RDB 持久化。當redis重啟時,它會有限使用AOF文件來還原數(shù)據(jù)集,因為AOF文件保存的數(shù)據(jù)集通常比RDB文件所保存的數(shù)據(jù)集更加完整

RDB的優(yōu)點：

RDB 是一個非常緊湊（compact）的文件，它保存了 Redis 在某個時間點上的數(shù)據(jù)集。 這種文件非常適合用于進行備份： 比如說，你可以在最近的 24 小時內(nèi)，每小時備份一次 RDB 文件，并且在每個月的每一天，也備份一個 RDB 文件。 這樣的話，即使遇上問題，也可以隨時將數(shù)據(jù)集還原到不同的版本。

RDB 非常適用于災(zāi)難恢復(fù)（disaster recovery）：它只有一個文件，并且內(nèi)容都非常緊湊，可以（在加密后）將它傳送到別的數(shù)據(jù)中心，或者亞馬遜 S3 中。

RDB 可以最大化 Redis 的性能：父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無須執(zhí)行任何磁盤 I/O 操作。

RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快

Redis常見的性能問題都有哪些？如何解決？

Master寫內(nèi)存快照，save命令調(diào)度rdbSave函數(shù)，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務(wù)，所以Master最好不要寫內(nèi)存快照。

Master AOF持久化，如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復(fù)速度。Master最好不要做任何持久化工作，包括內(nèi)存快照和AOF日志文件，特別是不要啟用內(nèi)存快照做持久化,如果數(shù)據(jù)比較關(guān)鍵，某個Slave開啟AOF備份數(shù)據(jù)，策略為每秒同步一次。

Master調(diào)用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會占大量的CPU和內(nèi)存資源，導(dǎo)致服務(wù)load過高，出現(xiàn)短暫服務(wù)暫?，F(xiàn)象。

Redis主從復(fù)制的性能問題，為了主從復(fù)制的速度和連接的穩(wěn)定性，Slave和Master最好在同一個局域網(wǎng)內(nèi)

Redis提供6種數(shù)據(jù)淘汰策略

volatile-lru：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰

volatile-ttl：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰

volatile-random：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰

allkeys-lru：從數(shù)據(jù)集（server.db[i].dict）中挑選最近最少使用的數(shù)據(jù)淘汰

allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰

no-enviction（驅(qū)逐）：禁止驅(qū)逐數(shù)據(jù)