201.刪除_你們怎麼處理redis緩存的數據，怎麼刪除的
redis緩存的數據有一些是常駐緩存的，當數據庫中數據有變化時做數據同步。
有一些緩存是設置有效期的，當緩存到期後會自動刪除。刪除redis緩存使用del或者hdel命令。[備註:hdel,hashKey delete]
202.redis的事務
- redis事務：可以一次執行多個命令，本質是一組命令的集合。一個事務中的所有命令都會序列化，按順序地串行化執行而不會被其它命令插入，不許加塞.
- redis事務能幹嘛：一個隊列中，一次性、順序性、排他性的執行一系列命令.
[備註: ACID,原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）] - redis監控：鎖的介紹
在MySQL中我們都知道有行鎖和表鎖的概念，所謂的行鎖也就是把我需要改的那一行給鎖住，不讓其他的事務去修改；而表鎖就是在修改一張表的時候把整張表都鎖住，不讓其他的事務修改，所以行鎖的效率比表鎖的概念更高，那麼在redis也存在鎖的概念- 樂觀鎖（Optimistic Lock）： 顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，樂觀鎖策略:提交版本必須大於記錄當前版本才能執行更新
- 悲觀鎖（Pessimistic Lock）： 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型數據庫裏邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖.[備註: 在Java中，synchronized的思想也是悲觀鎖]
- CAS（Check And Set）：
- redis事務三階段：
- 開啓：以MULTI開始一個事務
- 入隊：將多個命令入隊到事務中，接到這些命令並不會立即執行，而是放到等待執行的事務隊列裏面
- 執行：由EXEC命令觸發事務(execute,執行)
- redis事務三大特性：
- 單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷。
- 沒有隔離級別的概念：隊列中的命令沒有提交之前都不會實際的被執行，因爲事務提交前任何指令都不會被實際執行，也就不存在”事務內的查詢要看到事務裏的更新，在事務外查詢不能看到”這個讓人萬分頭痛的問題
- 不保證原子性：redis同一個事務中如果有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾
203.什麼是ES？
es是一個高擴展、開源的全文檢索和分析引擎，它可以準實時地快速存儲、搜索、分析海量的數據。
204.爲什麼要使用到ES？
因爲在我們商城中的數據，將來會非常多，所以採用以往的模糊查詢，模糊查詢前置配置，會放棄索引，導致商品查詢是全表掃面，在百萬級別的數據庫中，效率非常低下，而我們使用ES做一個全文索引，我們將經常查詢的商品的某些字段，比如說商品名，描述、價格還有id這些字段我們放入我們索引庫裏，可以提高查詢速度。
205.Elasticsearch是如何實現Master選舉的？
- Elasticsearch的選主是ZenDiscovery模塊負責的，主要包含Ping（節點之間通過這個RPC來發現彼此）和Unicast（單播模塊包含一個主機列表以控制哪些節點需要ping通）這兩部分；
- 對所有可以成爲master的節點（node.master: true）根據nodeId字典排序，每次選舉每個節點都把自己所知道節點排一次序，然後選出第一個（第0位）節點，暫且認爲它是master節點。
- 如果對某個節點的投票數達到一定的值（可以成爲master節點數n/2+1）並且該節點自己也選舉自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。
補充：master節點的職責主要包括集羣、節點和索引的管理，不負責文檔級別的管理；data節點可以關閉http功能。
206.Elasticsearch中的節點（比如共20個），其中的10個選了一個master，另外10個選了另一個master，怎麼辦？
- 當集羣master候選數量不小於3個時，可以通過設置最少投票通過數量（discovery.zen.minimum_master_nodes）超過所有候選節點一半以上來解決腦裂問題；
- 當候選數量爲兩個時，只能修改爲唯一的一個master候選，其他作爲data節點，避免腦裂問題。
207.客戶端在和集羣連接時，如何選擇特定的節點執行請求的？
TransportClient利用transport模塊遠程連接一個elasticsearch集羣。它並不加入到集羣中，只是簡單的獲得一個或者多個初始化的transport地址，並以 輪詢 的方式與這些地址進行通信。
208.詳細描述一下Elasticsearch索引文檔的過程。
協調節點默認使用文檔ID參與計算（也支持通過routing），以便爲路由提供合適的分片。
shard = hash(document_id) % (num_of_primary_shards)
- 當分片所在的節點接收到來自協調節點的請求後，會將請求寫入到Memory Buffer，然後定時（默認是每隔1秒）寫入到Filesystem Cache，這個從Momery Buffer到Filesystem Cache的過程就叫做refresh；
- 當然在某些情況下，存在Momery Buffer和Filesystem Cache的數據可能會丟失，ES是通過translog的機制來保證數據的可靠性的。其實現機制是接收到請求後，同時也會寫入到translog中，當Filesystem cache中的數據寫入到磁盤中時，纔會清除掉，這個過程叫做flush；
- 在flush過程中，內存中的緩衝將被清除，內容被寫入一個新段，段的fsync將創建一個新的提交點，並將內容刷新到磁盤，舊的translog將被刪除並開始一個新的translog。
- flush觸發的時機是定時觸發（默認30分鐘）或者translog變得太大（默認爲512M）時；
補充：關於Lucene的Segement：- Lucene索引是由多個段組成，段本身是一個功能齊全的倒排索引。
- 段是不可變的，允許Lucene將新的文檔增量地添加到索引中，而不用從頭重建索引。
- 對於每一個搜索請求而言，索引中的所有段都會被搜索，並且每個段會消耗CPU的時鐘周、文件句柄和內存。這意味着段的數量越多，搜索性能會越低。
- 爲了解決這個問題，Elasticsearch會合並小段到一個較大的段，提交新的合併段到磁盤，並刪除那些舊的小段。
209.詳細描述一下Elasticsearch更新和刪除文檔的過程。
- 刪除和更新也都是寫操作，但是Elasticsearch中的文檔是不可變的，因此不能被刪除或者改動以展示其變更；
- 磁盤上的每個段都有一個相應的.del文件。當刪除請求發送後，文檔並沒有真的被刪除，而是在.del文件中被標記爲刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合併時，在.del文件中被標記爲刪除的文檔將不會被寫入新段。
- 在新的文檔被創建時，Elasticsearch會爲該文檔指定一個版本號，當執行更新時，舊版本的文檔在.del文件中被標記爲刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉。
210.詳細描述一下Elasticsearch搜索的過程。
- 搜索被執行成一個兩階段過程，我們稱之爲 Query Then Fetch；
- 在初始查詢階段時，查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。 每個分片在本地執行搜索並構建一個匹配文檔的大小爲 from + size 的優先隊列。PS：在搜索的時候是會查詢Filesystem Cache的，但是有部分數據還在Memory Buffer，所以搜索是近實時的。
- 每個分片返回各自優先隊列中 所有文檔的 ID 和排序值 給協調節點，它合併這些值到自己的優先隊列中來產生一個全局排序後的結果列表。
- 接下來就是 取回階段，協調節點辨別出哪些文檔需要被取回並向相關的分片提交多個 GET 請求。每個分片加載並 豐富 文檔，如果有需要的話，接着返回文檔給協調節點。一旦所有的文檔都被取回了，協調節點返回結果給客戶端。
補充：
Query Then Fetch的搜索類型在文檔相關性打分的時候參考的是本分片的數據，這樣在文檔數量較少的時候可能不夠準確，DFS Query Then Fetch增加了一個預查詢的處理，詢問Term和Document frequency，這個評分更準確，但是性能會變差。