暑期實習--資料庫

資料庫知識

SQL語句分為哪幾種？

SQL語句主要可以劃分為以下幾類： 

DDL(Data Definition Language):資料定義語言，定義對資料庫對象(庫、表、列、索引)的操作。 

包括：CREATE、DROP、ALTER、RENAME、 TRUNCATE等 

DML(Data Manipulation Language): 資料操作語言，定義對資料庫記錄的操作。 

包括：INSERT、DELETE、UPDATE、SELECT等 

DCL(Data Control Language): 資料控制語言，定義對資料庫、表、字段、使用者的通路權限和安全級别。 

包括：GRANT、REVOKE等 

Transaction Control:事務控制 

包括：COMMIT、ROLLBACK、SAVEPOINT等

Delete、truncaate、drop都是删除語句，它們有什麼分别？

delete 屬于DML語句，删除資料，保留表結構，需要commit，可以復原，如果資料量大，很慢。 

truncate 屬于DDL語句，删除所有資料，保留表結構，自動commit，不可以復原，一次全部删除所有資料，速度相對較快。 

Drop屬于 DDL語句，删除資料和表結構,不需要commit，删除速度最快。

drop、delete與truncate分别在什麼場景之下使用？

• 不再需要一張表的時候，用drop
• 想删除部分資料行時候，用delete，并且帶上where子句
• 保留表而删除所有資料的時候用truncate

Where和having都是條件篩選關鍵字，它們有什麼分别？

WHERE是在資料分組前進行條件過濾， HAVING子句是在資料分組後進行條件過濾，WHERE子句中不能使用聚合函數，HAVING子句可以使用聚合函數。

資料庫事務

事務是最小的邏輯工作單元。

事務特性(ACID)

原子性:一個事務裡面的操作要麼不做,要麼都做;

一緻性:事務啟動之前和啟動之後要保持平衡狀态

例如完整性限制a+b=10，一個事務改變了a，那麼b也應随之改變。

隔離性:在一個會話裡面讀取不到另一個會話裡未送出的資料.

永久性:事務一經送出永不回退。

什麼是存儲過程？有哪些優缺點？

存儲過程是一些預編譯的SQL語句。

更加直白的了解：存儲過程可以說是一個記錄集，它是由一些T-SQL語句組成的代碼塊，這些T-SQL語句代碼像一個方法一樣實作一些功能（對單表或多表的增删改查），然後再給這個代碼塊取一個名字，在用到這個功能的時候調用他就行了。

• 存儲過程是一個預編譯的代碼塊，執行效率比較高
• 一個存儲過程替代大量T_SQL語句 ，可以降低網絡通信量，提高通信速率
• 可以一定程度上確定資料安全

如果你對存儲過程不熟悉，建議閱讀：存儲過程詳解-部落格園

資料庫的樂觀鎖和悲觀鎖是什麼？

資料庫管理系統（DBMS）中的并發控制的任務是確定在多個事務同時存取資料庫中同一資料時不破壞事務的隔離性和統一性以及資料庫的統一性。

樂觀并發控制(樂觀鎖)和悲觀并發控制（悲觀鎖）是并發控制主要采用的技術手段。

• 悲觀鎖：假定會發生并發沖突，屏蔽一切可能違反資料完整性的操作
• 樂觀鎖：假設不會發生并發沖突，隻在送出操作時檢查是否違反資料完整性。

如果你對兩種鎖還不太熟悉，建議閱讀：深入了解樂觀鎖與悲觀鎖

資料庫隔離級别有哪些，各自的含義是什麼，MYSQL 預設的隔離級别是是什麼。

·未送出讀(Read Uncommitted)：允許髒讀，也就是可能讀取到其他會話中未送出事務修改的資料

·送出讀(Read Committed)：隻能讀取到已經送出的資料。Oracle等多數資料庫預設都是該級别 (不重複讀)

·可重複讀(Repeated Read)：可重複讀。在同一個事務内的查詢都是事務開始時刻一緻的，InnoDB預設級别。在SQL标準中，該隔離級别消除了不可重複讀，但是還存在幻象讀

·串行讀(Serializable)：完全串行化的讀，每次讀都需要獲得表級共享鎖，讀寫互相都會阻塞

MYSQL預設是RepeatedRead級别

MYSQL 有哪些存儲引擎，各自優缺點。

MyISAM： 擁有較高的插入，查詢速度，但不支援事務 

InnoDB ：5.5版本後Mysql的預設資料庫，事務型資料庫的首選引擎，支援ACID事務，支援行級鎖定 

BDB： 源自Berkeley DB，事務型資料庫的另一種選擇，支援COMMIT和ROLLBACK等其他事務特性 

Memory ：所有資料置于記憶體的存儲引擎，擁有極高的插入，更新和查詢效率。但是會占用和資料量成正比的記憶體空間。并且其内容會在Mysql重新啟動時丢失 

Merge ：将一定數量的MyISAM表聯合而成一個整體，在超大規模資料存儲時很有用 

Archive ：非常适合存儲大量的獨立的，作為曆史記錄的資料。因為它們不經常被讀取。Archive擁有高效的插入速度，但其對查詢的支援相對較差 

Federated： 将不同的Mysql伺服器聯合起來，邏輯上組成一個完整的資料庫。非常适合分布式應用 

Cluster/NDB ：高備援的存儲引擎，用多台資料機器聯合提供服務以提高整體性能和安全性。适合資料量大，安全和性能要求高的應用 

CSV： 邏輯上由逗号分割資料的存儲引擎。它會在資料庫子目錄裡為每個資料表建立一個.CSV檔案。這是一種普通文本檔案，每個資料行占用一個文本行。CSV存儲引擎不支援索引。 

BlackHole ：黑洞引擎，寫入的任何資料都會消失，一般用于記錄binlog做複制的中繼 

另外，Mysql的存儲引擎接口定義良好。有興趣的開發者通過閱讀文檔編寫自己的存儲引擎。 

http://baike.baidu.com/item/%E5%AD%98%E5%82%A8%E5%BC%95%E6%93%8E

高并發下，如何做到安全的修改同一行資料。

使用悲觀鎖 悲觀鎖本質是目前隻有一個線程執行操作，結束了喚醒其他線程進行處理。 

也可以緩存隊列中鎖定主鍵。

樂觀鎖和悲觀鎖是什麼，INNODB 的行級鎖有哪 2 種，解釋其含義。

樂觀鎖是設定每次修改都不會沖突，隻在送出的時候去檢查，悲觀鎖設定每次修改都會沖突，持有排他鎖。 

行級鎖分為共享鎖和排他鎖兩種 共享鎖又稱讀鎖 排他鎖又稱寫鎖 

http://www.jianshu.com/p/f40ec03fd0e8

SQL 優化的一般步驟是什麼，怎麼看執行計劃，如何了解其中各個字段的含義。

檢視慢日志（show [session|gobal] status ），定位慢查詢，檢視慢查詢執行計劃 根據執行計劃确認優化方案 

Explain sql 

select_type:表示select類型。常見的取值有SIMPLE（簡單表，即不使用連接配接或者子查詢）、PRIMARY（主查詢，即外層的查詢）、UNION（union中的第二個或者後面的查詢語句）、SUBQUERY（子查詢中的第一個SELECT）等。 

talbe：輸出結果集的表。 

type:表的連接配接類型。性能由高到底：system（表中僅有一行）、const（表中最多有一個比對行）、eq_ref、ref、ref_null、index_merge、unique_subquery、index_subquery、range、idnex等 

possible_keys:查詢時，可能使用的索引 

key:實際使用的索引 

key_len:索引字段的長度 

rows：掃描行的數量 

Extra：執行情況的說明和描述 

http://blog.csdn.net/hsd2012/article/details/51106285

資料庫會死鎖嗎，舉一個死鎖的例子，mysql 怎麼解決死鎖。

産生死鎖的原因主要是：

（1）系統資源不足。 

（2） 程序運作推進的順序不合适。 

（3）資源配置設定不當等。

如果系統資源充足，程序的資源請求都能夠得到滿足，死鎖出現的可能性就很低，否則就會因争奪有限的資源而陷入死鎖。其次，程序運作推進順序與速度不同，也可能産生死鎖。

産生死鎖的四個必要條件：

（1） 互斥條件：一個資源每次隻能被一個程序使用。 

（2） 請求與保持條件：一個程序因請求資源而阻塞時，對已獲得的資源保持不放。 

（3） 不剝奪條件:程序已獲得的資源，在末使用完之前，不能強行剝奪。 

（4） 循環等待條件:若幹程序之間形成一種頭尾相接的循環等待資源關系。

這四個條件是死鎖的必要條件，隻要系統發生死鎖，這些條件必然成立，而隻要上述條件之一不滿足，就不會發生死鎖。 

這裡提供兩個解決資料庫死鎖的方法：

1）重新開機資料庫（誰用誰知道） 

2）殺掉搶資源的程序： 

先查哪些程序在搶資源：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX; 

殺掉它們：Kill trx_mysql_thread_id；

MYsql 的索引原理，索引的類型有哪些，如何建立合理的索引，索引如何優化。

索引是通過複雜的算法，提高資料查詢性能的手段。從磁盤io到記憶體io的轉變 

普通索引，主鍵，唯一，單列/多列索引建索引的幾大原則 

1.最左字首比對原則，非常重要的原則，mysql會一直向右比對直到遇到範圍查詢(>、<、between、like)就停止比對，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調整。 

2.=和in可以亂序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序，mysql的查詢優化器會幫你優化成索引可以識别的形式 

3.盡量選擇區分度高的列作為索引,區分度的公式是count(distinct col)/count(*)，表示字段不重複的比例，比例越大我們掃描的記錄數越少，唯一鍵的區分度是1，而一些狀态、性别字段可能在大資料面前區分度就是0，那可能有人會問，這個比例有什麼經驗值嗎？使用場景不同，這個值也很難确定，一般需要join的字段我們都要求是0.1以上，即平均1條掃描10條記錄 

4.索引列不能參與計算，保持列“幹淨”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很簡單，b+樹中存的都是資料表中的字段值，但進行檢索時，需要把所有元素都應用函數才能比較，顯然成本太大。是以語句應該寫成create_time = unix_timestamp(’2014-05-29’); 

5.盡量的擴充索引，不要建立索引。比如表中已經有a的索引，現在要加(a,b)的索引，那麼隻需要修改原來的索引即可

http://tech.meituan.com/mysql-index.html 

http://www.cnblogs.com/cq-home/p/3482101.html

聚集索引和非聚集索引的差別。

“聚簇”就是索引和記錄緊密在一起。 

非聚簇索引 索引檔案和資料檔案分開存放，索引檔案的葉子頁隻儲存了主鍵值，要定位記錄還要去查找相應的資料塊。

資料庫中 BTREE 和 B+tree 差別。

B+是btree的變種，本質都是btree，btree+與B-Tree相比，B+Tree有以下不同點： 

每個節點的指針上限為2d而不是2d+1。 

内節點不存儲data，隻存儲key；葉子節點不存儲指針。

http://lcbk.net/9602.html 

Btree 怎麼分裂的，什麼時候分裂，為什麼是平衡的。 

Key 超過1024才分裂B樹為甚會分裂？ 因為随着資料的增多，一個結點的key滿了，為了保持B樹的特性，就會産生分裂，就向紅黑樹和AVL樹為了保持樹的性質需要進行旋轉一樣！

ACID 是什麼。

A，atomic，原子性，要麼都送出，要麼都失敗，不能一部分成功，一部分失敗。 

C，consistent，一緻性，事物開始及結束後，資料的一緻性限制沒有被破壞 

I，isolation，隔離性，并發事物間互相不影響，互不幹擾。 

D，durability,持久性，已經送出的事物對資料庫所做的更新必須永久儲存。即便發生崩潰，也不能被復原或資料丢失。

Mysql 怎麼優化 table scan 的。

避免在where子句中對字段進行is null判斷 

應盡量避免在where 子句中使用!=或<>操作符，否則将引擎放棄使用索引而進行全表掃描。 

避免在where 子句中使用or 來連接配接條件 

in 和not in 也要慎用 

Like查詢（非左開頭） 

使用[email protected]參數這種 

where 子句中對字段進行表達式操作num/2=XX 

在where子句中對字段進行函數操作

如何寫 sql 能夠有效的使用到複合索引。

由于複合索引的組合索引，類似多個木闆拼接在一起，如果中間斷了就無法用了，是以要能用到複合索引，首先開頭(第一列)要用上，比如index(a,b) 這種，我們可以select table tname where a=XX 用到第一列索引 如果想用第二列 可以 and b=XX 或者and b like‘TTT%’

mysql 中 in 和 exists 差別。

mysql中的in語句是把外表和内表作hash 連接配接，而exists語句是對外表作loop循環，每次loop循環再對内表進行查詢。一直大家都認為exists比in語句的效率要高，這種說法其實是不準确的。這個是要區分環境的。

如果查詢的兩個表大小相當，那麼用in和exists差别不大。 

如果兩個表中一個較小，一個是大表，則子查詢表大的用exists，子查詢表小的用in： 

not in 和not exists如果查詢語句使用了not in 那麼内外表都進行全表掃描，沒有用到索引；而not extsts 的子查詢依然能用到表上的索引。是以無論那個表大，用not exists都比not in要快。 

1.EXISTS隻傳回TRUE或FALSE，不會傳回UNKNOWN。

2.IN當遇到包含NULL的情況，那麼就會傳回UNKNOWN。

資料庫自增主鍵可能的問題。

在分庫分表時可能會生成重複主鍵 利用自增比例達到唯一 自增1 2,3 等 

https://yq.aliyun.com/articles/38438

消息隊列

用過哪些 MQ，和其他 mq 比較有什麼優缺點，MQ 的連接配接是線程安全的嗎，你們公司的MQ 服務架構怎樣的。

根據實際情況說明 

我們公司用activeMQ 因為業務比較簡單 隻有轉碼功能，而amq比較簡單 

如果是分布式的建議用kafka 

http://blog.csdn.net/sunxinhere/article/details/7968886

MQ 系統的資料如何保證不丢失。

基本都是對資料進行持久化，多盤存儲

rabbitmq 如何實作叢集高可用。

叢集是保證服務可靠性的一種方式，同時可以通過水準擴充以提升消息吞吐能力。RabbitMQ是用分布式程式設計語言erlang開發的，是以天生就支援叢集。接下來，将介紹RabbitMQ分布式消息處理方式、叢集模式、節點類型，并動手搭建一個高可用叢集環境，最後通過java程式來驗證叢集的高可用性。

　　1. 三種分布式消息處理方式

　　RabbitMQ分布式的消息處理方式有以下三種：

　　1、Clustering：不支援跨網段，各節點需運作同版本的Erlang和RabbitMQ, 應用于同網段區域網路。

　　2、Federation：允許單台伺服器上的Exchange或Queue接收釋出到另一台伺服器上Exchange或Queue的消息, 應用于廣域網，。

　　3、Shovel：與Federation類似，但工作在更低層次。

　　RabbitMQ對網絡延遲很敏感，在LAN環境建議使用clustering方式;在WAN環境中，則使用Federation或Shovel。我們平時說的RabbitMQ叢集，說的就是clustering方式，它是RabbitMQ内嵌的一種消息處理方式，而Federation或Shovel則是以plugin形式存在。 

https://my.oschina.net/jiaoyanli/blog/822011 

https://www.ibm.com/developerworks/cn/opensource/os-cn-RabbitMQ/

Redis，Memcached

redis 的 list 結構相關的操作。

LPUSH LPUSHX RPUSH RPUSHX LPOP RPOP BLPOP BRPOP LLEN LRANGE 

https://redis.readthedocs.io/en/2.4/list.html

Redis 的資料結構都有哪些。

字元串(strings)：存儲整數（比如計數器）和字元串（廢話。。），有些公司也用來存儲json/pb等序列化資料，并不推薦，浪費記憶體 

哈希表(hashes)：存儲配置，對象（比如使用者、商品），優點是可以存取部分key，對于經常變化的或者部分key要求atom操作的适合 

清單(lists)：可以用來存最新使用者動态，時間軸，優點是有序，确定是元素可重複，不去重 

集合(sets)：無序，唯一，對于要求嚴格唯一性的可以使用 

有序集合(sorted sets)：集合的有序版，很好用，對于排名之類的複雜場景可以考慮https://redis.readthedocs.io/en/2.4/list.html

Redis 的使用要注意什麼，講講持久化方式，記憶體設定，叢集的應用和優劣勢，淘汰政策等。

持久化方式：RDB時間點快照 AOF記錄伺服器執行的所有寫操作指令，并在伺服器啟動時，通過重新執行這些指令來還原資料集。 

記憶體設定 maxmemory used_memory 

虛拟記憶體： vm-enabled yes 

3.0采用Cluster方式， 

Redis叢集相對單機在功能上存在一些限制， 需要開發人員提前了解， 

在使用時做好規避。 限制如下： 

1） key批量操作支援有限。 如mset、 mget， 目前隻支援具有相同slot值的 

ke 

y執 

行批量操作。 對于映射為不同slot值的key由于執行mget、 mget等操作可 

能存在于多個節點上是以不被支援。 

2） key事務操作支援有限。 同理隻支援多key在同一節點上的事務操 

作， 當多個key分布在不同的節點上時無法使用事務功能。 

3） key作為資料分區的最小粒度， 是以不能将一個大的鍵值對象如 

ha 

sh、 list等映射到不同的節點。 

4） 不支援多資料庫空間。 單機下的Redis可以支援16個資料庫， 叢集模 

式下隻能使用一個資料庫空間， 即db0。 

5） 複制結構隻支援一層， 從節點隻能複制主節點， 不支援嵌套樹狀複 

制結構。 

Redis Cluster是Redis的分布式解決方案， 在3.0版本正式推出， 有效地解 

決了Redis分布式方面的需求。 當遇到單機記憶體、 并發、 流量等瓶頸時， 可 

以采用Cluster架構方案達到負載均衡的目的。 之前， Redis分布式方案一般 

有兩種： 

·用戶端分區方案， 優點是分區邏輯可控， 缺點是需要自己處理資料路 

由、 高可用、 故障轉移等問題。 

·代理方案， 優點是簡化用戶端分布式邏輯和更新維護便利， 缺點是加 

重架構部署複雜度和性能損耗。 

現在官方為我們提供了專有的叢集方案： Redis Cluster， 它非常優雅地 

解決了Redis叢集方面的問題， 是以了解應用好Redis Cluster将極大地解放我 

們使用分布式Redis的工作量， 同時它也是學習分布式存儲的絕佳案例。

LRU(近期最少使用算法)TTL（逾時算法） 去除ttl最大的鍵值 

http://wiki.jikexueyuan.com/project/redis/data-elimination-mechanism.html 

http://www.infoq.com/cn/articles/tq-redis-memory-usage-optimization-storage 

http://www.redis.cn/topics/cluster-tutorial.html

redis2 和 redis3 的差別，redis3 内部通訊機制。

叢集方式的差別，3采用Cluster，2采用用戶端分區方案和代理方案 

通信過程說明： 

1） 叢集中的每個節點都會單獨開辟一個TCP通道， 用于節點之間彼此 

通信， 通信端口号在基礎端口上加10000。 

2） 每個節點在固定周期内通過特定規則選擇幾個節點發送ping消息。 

3） 接收到ping消息的節點用pong消息作為響應。

目前 redis 叢集有哪些玩法，各自優缺點，場景。

當緩存使用 持久化使用

Memcache 的原理，哪些資料适合放在緩存中。

基于libevent的事件處理 

内置記憶體存儲方式SLab Allocation機制 

并不單一的資料删除機制 

基于用戶端的分布式系統

變化頻繁，具有不穩定性的資料,不需要實時入庫, (比如使用者線上 

狀态、線上人數..) 

門戶網站的新聞等，覺得頁面靜态化仍不能滿足要求，可以放入 

到memcache中.(配合jquey的ajax請求)

redis 和 memcached 的記憶體管理的差別。

Memcached預設使用Slab Allocation機制管理記憶體，其主要思想是按照預先規定的大小，将配置設定的記憶體分割成特定長度的塊以存儲相應長度的key-value資料記錄，以完全解決記憶體碎片問題。 

Redis的記憶體管理主要通過源碼中zmalloc.h和zmalloc.c兩個檔案來實作的。 

在Redis中，并不是所有的資料都一直存儲在記憶體中的。這是和Memcached相比一個最大的差別。 

http://lib.csdn.net/article/redis/55323

Redis 的并發競争問題如何解決，了解 Redis 事務的 CAS 操作嗎。

Redis為單程序單線程模式，采用隊列模式将并發通路變為串行通路。Redis本身沒有鎖的概念，Redis對于多個用戶端連接配接并不存在競争，但是在Jedis用戶端對Redis進行并發通路時會發生連接配接逾時、資料轉換錯誤、阻塞、用戶端關閉連接配接等問題，這些問題均是由于用戶端連接配接混亂造成。對此有2種解決方法：

1.用戶端角度，為保證每個用戶端間正常有序與Redis進行通信，對連接配接進行池化，同時對用戶端讀寫Redis操作采用内部鎖synchronized。

2.伺服器角度，利用setnx實作鎖。

MULTI，EXEC，DISCARD，WATCH 四個指令是 Redis 事務的四個基礎指令。其中：

MULTI，告訴 Redis 伺服器開啟一個事務。注意，隻是開啟，而不是執行 

EXEC，告訴 Redis 開始執行事務 

DISCARD，告訴 Redis 取消事務 

WATCH，監視某一個鍵值對，它的作用是在事務執行之前如果監視的鍵值被修改，事務會被取消。 

可以利用watch實作cas樂觀鎖 

http://wiki.jikexueyuan.com/project/redis/transaction-mechanism.html 

http://www.jianshu.com/p/d777eb9f27df

Redis 的選舉算法和流程是怎樣的

Raft采用心跳機制觸發Leader選舉。系統啟動後，全部節點初始化為Follower，term為0.節點如果收到了RequestVote或者AppendEntries，就會保持自己的Follower身份。如果一段時間内沒收到AppendEntries消息直到選舉逾時，說明在該節點的逾時時間内還沒發現Leader，Follower就會轉換成Candidate，自己開始競選Leader。一旦轉化為Candidate，該節點立即開始下面幾件事情：

1、增加自己的term。 

2、啟動一個新的定時器。 

3、給自己投一票。 

4、向所有其他節點發送RequestVote，并等待其他節點的回複。 

如果在這過程中收到了其他節點發送的AppendEntries，就說明已經有Leader産生，自己就轉換成Follower，選舉結束。

如果在計時器逾時前，節點收到多數節點的同意投票，就轉換成Leader。同時向所有其他節點發送AppendEntries，告知自己成為了Leader。

每個節點在一個term内隻能投一票，采取先到先得的政策，Candidate前面說到已經投給了自己，Follower會投給第一個收到RequestVote的節點。每個Follower有一個計時器，在計時器逾時時仍然沒有接受到來自Leader的心跳RPC, 則自己轉換為Candidate, 開始請求投票，就是上面的的競選Leader步驟。

如果多個Candidate發起投票，每個Candidate都沒拿到多數的投票（Split Vote），那麼就會等到計時器逾時後重新成為Candidate，重複前面競選Leader步驟。

Raft協定的定時器采取随機逾時時間，這是選舉Leader的關鍵。每個節點定時器的逾時時間随機設定，随機選取配置時間的1倍到2倍之間。由于随機配置，是以各個Follower同時轉成Candidate的時間一般不一樣，在同一個term内，先轉為Candidate的節點會先發起投票，進而獲得多數票。多個節點同時轉換為Candidate的可能性很小。即使幾個Candidate同時發起投票，在該term内有幾個節點獲得一樣高的票數，隻是這個term無法選出Leader。由于各個節點定時器的逾時時間随機生成，那麼最先進入下一個term的節點，将更有機會成為Leader。連續多次發生在一個term内節點獲得一樣高票數在理論上幾率很小，實際上可以認為完全不可能發生。一般1-2個term類，Leader就會被選出來。

Sentinel的選舉流程

Sentinel叢集正常運作的時候每個節點epoch相同，當需要故障轉移的時候會在叢集中選出Leader執行故障轉移操作。Sentinel采用了Raft協定實作了Sentinel間選舉Leader的算法，不過也不完全跟論文描述的步驟一緻。Sentinel叢集運作過程中故障轉移完成，所有Sentinel又會恢複平等。Leader僅僅是故障轉移操作出現的角色。

選舉流程

1、某個Sentinel認定master客觀下線的節點後，該Sentinel會先看看自己有沒有投過票，如果自己已經投過票給其他Sentinel了，在2倍故障轉移的逾時時間自己就不會成為Leader。相當于它是一個Follower。 

2、如果該Sentinel還沒投過票，那麼它就成為Candidate。 

3、和Raft協定描述的一樣，成為Candidate，Sentinel需要完成幾件事情 

1）更新故障轉移狀态為start 

2）目前epoch加1，相當于進入一個新term，在Sentinel中epoch就是Raft協定中的term。 

3）更新自己的逾時時間為目前時間随機加上一段時間，随機時間為1s内的随機毫秒數。 

4）向其他節點發送is-master-down-by-addr指令請求投票。指令會帶上自己的epoch。 

5）給自己投一票，在Sentinel中，投票的方式是把自己master結構體裡的leader和leader_epoch改成投給的Sentinel和它的epoch。 

4、其他Sentinel會收到Candidate的is-master-down-by-addr指令。如果Sentinel目前epoch和Candidate傳給他的epoch一樣，說明他已經把自己master結構體裡的leader和leader_epoch改成其他Candidate，相當于把票投給了其他Candidate。投過票給别的Sentinel後，在目前epoch内自己就隻能成為Follower。 

5、Candidate會不斷的統計自己的票數，直到他發現認同他成為Leader的票數超過一半而且超過它配置的quorum（quorum可以參考《redis sentinel設計與實作》）。Sentinel比Raft協定增加了quorum，這樣一個Sentinel能否當選Leader還取決于它配置的quorum。 

6、如果在一個選舉時間内，Candidate沒有獲得超過一半且超過它配置的quorum的票數，自己的這次選舉就失敗了。 

7、如果在一個epoch内，沒有一個Candidate獲得更多的票數。那麼等待超過2倍故障轉移的逾時時間後，Candidate增加epoch重新投票。 

8、如果某個Candidate獲得超過一半且超過它配置的quorum的票數，那麼它就成為了Leader。 

9、與Raft協定不同，Leader并不會把自己成為Leader的消息發給其他Sentinel。其他Sentinel等待Leader從slave選出master後，檢測到新的master正常工作後，就會去掉客觀下線的辨別，進而不需要進入故障轉移流程。 

http://weizijun.cn/2015/04/30/Raft%E5%8D%8F%E8%AE%AE%E5%AE%9E%E6%88%98%E4%B9%8BRedis%20Sentinel%E7%9A%84%E9%80%89%E4%B8%BELeader%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/

redis 的持久化的機制，aof 和 rdb 的差別。

RDB 定時快照方式(snapshot)： 定時備份，可能會丢失資料 

AOF 基于語句追加方式 隻追加寫操作 

AOF 持久化和 RDB 持久化的最主要差別在于，前者記錄了資料的變更，而後者是儲存了資料本身

redis 的叢集怎麼同步的資料的。

redis replication redis-migrate-tool等方式

搜尋

elasticsearch 了解多少，說說你們公司 es 的叢集架構，索引資料大小，分片有多少，以及一些調優手段。elasticsearch 的反向索引是什麼。

ElasticSearch（簡稱ES）是一個分布式、Restful的搜尋及分析伺服器，設計用于分布式計算；能夠達到實時搜尋，穩定，可靠，快速。和Apache Solr一樣，它也是基于Lucence的索引伺服器，而ElasticSearch對比Solr的優點在于：

輕量級：安裝啟動友善，下載下傳檔案之後一條指令就可以啟動。
Schema free：可以向伺服器送出任意結構的JSON對象，Solr中使用schema.xml指定了索引結構。
多索引檔案支援：使用不同的index參數就能建立另一個索引檔案，Solr中需要另行配置。
分布式：Solr Cloud的配置比較複雜。
           

• 1
• 2
• 3
• 4
• 5

反向索引是實作“單詞-文檔矩陣”的一種具體存儲形式，通過反向索引，可以根據單詞快速擷取包含這個單詞的文檔清單。反向索引主要由兩個部分組成：“單詞詞典”和“倒排檔案”。

elasticsearch 索引資料多了怎麼辦，如何調優，部署。

使用bulk API 

初次索引的時候，把 replica 設定為 0 

增大 threadpool.index.queue_size 

增大 indices.memory.index_buffer_size 

增大 index.translog.flush_threshold_ops 

增大 index.translog.sync_interval 

增大 index.engine.robin.refresh_interval 

http://www.jianshu.com/p/5eeeeb4375d4

lucence 内部結構是什麼

索引(Index)： 

在Lucene中一個索引是放在一個檔案夾中的。 

如上圖，同一檔案夾中的所有的檔案構成一個Lucene索引。 

段(Segment)： 

一個索引可以包含多個段，段與段之間是獨立的，添加新文檔可以生成新的段，不同的段可以合并。 

如上圖，具有相同字首檔案的屬同一個段，圖中共三個段 “_0” 和 “_1”和“_2”。 

segments.gen和segments_X是段的中繼資料檔案，也即它們儲存了段的屬性資訊。 

文檔(Document)： 

文檔是我們建索引的基本機關，不同的文檔是儲存在不同的段中的，一個段可以包含多篇文檔。 

新添加的文檔是單獨儲存在一個新生成的段中，随着段的合并，不同的文檔合并到同一個段中。 

域(Field)： 

一篇文檔包含不同類型的資訊，可以分開索引，比如标題，時間，正文，作者等，都可以儲存在不同的域裡。 

不同域的索引方式可以不同，在真正解析域的存儲的時候，我們會詳細解讀。 

詞(Term)： 

詞是索引的最小機關，是經過詞法分析和語言處理後的字元串。