溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“2021最新版的memcache面試題有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“2021最新版的memcache面試題有哪些”吧！
（1）根據業務增量需求，采取基于日期模板創建索引，通過 roll over API 滾動索引；
（2）使用別名進行索引管理；
（3）每天凌晨定時對索引做 force_merge 操作，以釋放空間；
（4）采取冷熱分離機制，熱數據存儲到 SSD，提高檢索效率；冷數據定期進行 shrink操作，以縮減存儲；
（5）采取 curator 進行索引的生命周期管理；
（6）僅針對需要分詞的字段，合理的設置分詞器；
（7）Mapping 階段充分結合各個字段的屬性，是否需要檢索、是否需要存儲等。
（1）寫入前副本數設置為 0；
（2）寫入前關閉 refresh_interval 設置為-1，禁用刷新機制；
（3）寫入過程中：采取 bulk 批量寫入；
（4）寫入后恢復副本數和刷新間隔；
（5）盡量使用自動生成的 id。
（1）禁用 wildcard；
（2）禁用批量 terms（成百上千的場景）；
（3）充分利用倒排索引機制，能 keyword 類型盡量 keyword；
（4）數據量大時候，可以先基于時間敲定索引再檢索；
（5）設置合理的路由機制。
部署調優，業務調優等。上面的提及一部分，面試者就基本對你之前的實踐或者運維經驗有所評估了。
lucene 從 4+版本后開始大量使用的數據結構是 FST。FST 有兩個優點：
（1）空間占用小。通過對詞典中單詞前綴和后綴的重復利用，壓縮了存儲空間；
（2）查詢速度快。O(len(str))的查詢時間復雜度。
面試官：想了解大數據量的運維能力。
解答：索引數據的規劃，應在前期做好規劃，正所謂“設計先行，編碼在后”，這樣才能有效的避免突如其來的數據激增導致集群處理能力不足引發的線上客戶檢索或者其他業務受到影響。
如何調優，正如問題 1 所說，這里細化一下：
冷熱數據分離存儲，熱數據（比如最近 3 天或者一周的數據），其余為冷數據。
對于冷數據不會再寫入新數據，可以考慮定期 force_merge 加 shrink 壓縮操作，節省存儲空間和檢索效率。
一旦之前沒有規劃，這里就屬于應急策略。
結合 ES 自身的支持動態擴展的特點，動態新增機器的方式可以緩解集群壓力，注意：如果之前主節點等規劃合理，不需要重啟集群也能完成動態新增的。
1GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name 2ip port heapPercent heapMax id name
面試官：想了解 ES 搜索的底層原理，不再只關注業務層面了。
解答：
搜索拆解為“query then fetch” 兩個階段。
query 階段的目的：定位到位置，但不取。
面試官：想了解你的知識面的廣度和深度。
解答：
Lucene 是有索引和搜索的兩個過程，包含索引創建，索引，搜索三個要點。可以基于這個脈絡展開一些。
TransportClient 利用 transport 模塊遠程連接一個 elasticsearch 集群。它并不加入到集群中，只是簡單的獲得一個或者多個初始化的 transport 地址，并以 輪詢 的方式與這些地址進行通信。
（1）查詢 ： Elasticsearch 允許執行和合并多種類型的搜索 — 結構化、非結構化、地理位置、度量指標 — 搜索方式隨心而變。
（2）分析 ： 找到與查詢最匹配的十個文檔是一回事。但是如果面對的是十億行日志，又該如何解讀呢？Elasticsearch 聚合讓您能夠從大處著眼，探索數據的趨勢和模式。
（3）速度 ： Elasticsearch 很快。真的，真的很快。
（4）可擴展性 ： 可以在筆記本電腦上運行。 也可以在承載了 PB 級數據的成百上千臺服務器上運行。
（5）彈性 ： Elasticsearch 運行在一個分布式的環境中，從設計之初就考慮到了這一點。
（6）靈活性 ： 具備多個案例場景。數字、文本、地理位置、結構化、非結構化。所有的數據類型都歡迎。
（7）HADOOP & SPARK ： Elasticsearch + Hadoop
這里有一些使用Elasticsearch的用例：
（1）你經營一個網上商店，你允許你的顧客搜索你賣的產品。在這種情況下，您可以使用Elasticsearch來存儲整個產品目錄和庫存，并為它們提供搜索和自動完成建議。
（2）你希望收集日志或事務數據，并希望分析和挖掘這些數據，以查找趨勢、統計、匯總或異常。在這種情況下，你可以使用loghide (Elasticsearch/ loghide /Kibana堆棧的一部分)來收集、聚合和解析數據，然后讓loghide將這些數據輸入到Elasticsearch中。一旦數據在Elasticsearch中，你就可以運行搜 索和聚合來挖掘你感興趣的任何信息。
（3）你運行一個價格警報平臺，允許精通價格的客戶指定如下規則:“我有興趣購買特定的電子設備，如 果下個月任何供應商的產品價格低于X美元，我希望得到通知”。在這種情況下，你可以抓取供應商的價 格，將它們推入到Elasticsearch中，并使用其反向搜索(Percolator)功能來匹配價格走勢與客戶查詢， 并最終在找到匹配后將警報推送給客戶。
（4）你有分析/業務智能需求，并希望快速調查、分析、可視化，并對大量數據提出特別問題(想想數百 萬或數十億的記錄)。在這種情況下，你可以使用Elasticsearch來存儲數據，然后使用Kibana(Elasticsearch/ loghide /Kibana堆棧的一部分)來構建自定義儀表板，以可視化對您來說很重要的數據 的各個方面。此外，還可以使用Elasticsearch聚合功能對數據執行復雜的業務智能查詢。
（1）刪除和更新也都是寫操作，但是 Elasticsearch 中的文檔是不可變的，因此不能被刪除或者改動以展示其變更；
（2）磁盤上的每個段都有一個相應的.del 文件。當刪除請求發送后，文檔并沒有真的被刪除，而是在.del 文件中被標記為刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合并時，在.del文件中被標記為刪除的文檔將不會被寫入新段。
（3）在新的文檔被創建時，Elasticsearch 會為該文檔指定一個版本號，當執行更新時，舊版本的文檔在.del 文件中被標記為刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉。
（1）Lucene的索引過程，就是按照全文檢索的基本過程，將倒排表寫成此文件格式的過程。
（2）Lucene的搜索過程，就是按照此文件格式將索引進去的信息讀出來，然后計算每篇文檔打分(score)的過程。
（1）64 GB 內存的機器是非常理想的， 但是 32 GB 和 16 GB 機器也是很常見的。少于 8 GB 會適得其反。
（2）如果你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個內核提供的額外并發遠勝過稍微快一點點的時鐘頻率。
（3）如果你負擔得起 SSD，它將遠遠超出任何旋轉介質。 基于 SSD 的節點，查詢和索引性能都有提升。如果你負擔得起，SSD 是一個好的選擇。
（4）即使數據中心們近在咫尺，也要避免集群跨越多個數據中心。絕對要避免集群跨越大的地理距離。
（5）請確保運行你應用程序的 JVM 和服務器的 JVM 是完全一樣的。 在Elasticsearch 的幾個地方，使用 Java 的本地序列化。
（6）通過設置 gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time 可以在集群重啟的時候避免過多的分片交換，這可能會讓數據恢復從數個小時縮短為幾秒鐘。
（7）Elasticsearch 默認被配置為使用單播發現，以防止節點無意中加入集群。只有在同一臺機器上運行的節點才會自動組成集群。最好使用單播代替組播。
（8）不要隨意修改垃圾回收器（CMS）和各個線程池的大小。
（9）把你的內存的（少于）一半給 Lucene（但不要超過 32 GB！），通過ES_HEAP_SIZE 環境變量設置。
（10）內存交換到磁盤對服務器性能來說是致命的。如果內存交換到磁盤上，一個100 微秒的操作可能變成 10 毫秒。 再想想那么多 10 微秒的操作時延累加起來。 不難看出 swapping 對于性能是多么可怕。
（11）Lucene 使用了大 量 的文件。同時，Elasticsearch 在節點和 HTTP 客戶端之間進行通信也使用了大量的套接字。 所有這一切都需要足夠的文件描述符。你應該增加你的文件描述符，設置一個很大的值，如 64,000。
（1）使用批量請求并調整其大小：每次批量數據 5–15 MB 大是個不錯的起始點。
（2）存儲：使用 SSD
（3）段和合并：Elasticsearch 默認值是 20 MB/s，對機械磁盤應該是個不錯的設置。如果你用的是SSD，可以考慮提高到 100–200 MB/s。如果你在做批量導入，完全不在意搜索，你可以徹底關掉合并限流。另外還可以增加index.translog.flflush_threshold_size 設置，從默認的 512 MB 到更大一些的值，比如 1 GB，這可以在一次清空觸發的時候在事務日志里積累出更大的段。
（4）如果你的搜索結果不需要近實時的準確度，考慮把每個索引的index.refresh_interval 改到 30s。
（5）如果你在做大批量導入，考慮通過設置 index.number_of_replicas: 0 關閉副本。
（1）倒排詞典的索引需要常駐內存，無法 GC，需要監控 data node 上 segmentmemory 增長趨勢。
（2）各類緩存，fifield cache, fifilter cache, indexing cache, bulk queue 等等，要設置合理的大小，并且要應該根據最壞的情況來看 heap 是否夠用，也就是各類緩存全部占滿的時候，還有 heap 空間可以分配給其他任務嗎？避免采用 clear cache等“自欺欺人”的方式來釋放內存。
（3）避免返回大量結果集的搜索與聚合。確實需要大量拉取數據的場景，可以采用scan & scroll api來實現。
（4）cluster stats 駐留內存并無法水平擴展，超大規模集群可以考慮分拆成多個集群通過 tribe node連接。
（5）想知道 heap 夠不夠，必須結合實際應用場景，并對集群的 heap 使用情況做持續的監控。
（6）根據監控數據理解內存需求，合理配置各類circuit breaker，將內存溢出風險降低到最低
（1）可以通過版本號使用樂觀并發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的沖突；
（2）另外對于寫操作，一致性級別支持 quorum/one/all，默認為 quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因為網絡等原因導致寫入副本失敗，這樣該副本被認為故障，分片將會在一個不同的節點上重建。
（3）對于讀操作，可以設置 replication 為 sync(默認)，這使得操作在主分片和副本分片都完成后才會返回；如果設置 replication 為 async 時，也可以通過設置搜索請求參數_preference 為 primary 來查詢主分片，確保文檔是最新版本。
Marvel 讓你可以很簡單的通過 Kibana 監控 Elasticsearch。你可以實時查看你的集群健康狀態和性能，也可以分析過去的集群、索引和節點指標。
常用字典數據結構如下所示：
Trie 的核心思想是空間換時間，利用字符串的公共前綴來降低查詢時間的開銷以達到提高效率的目的。 它有 3 個基本性質：
1）根節點不包含字符，除根節點外每一個節點都只包含一個字符。
2）從根節點到某一節點，路徑上經過的字符連接起來，為該節點對應的字符串。
3）每個節點的所有子節點包含的字符都不相同。
感謝各位的閱讀，以上就是“2021最新版的memcache面試題有哪些”的內容了，經過本文的學習后，相信大家對2021最新版的memcache面試題有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
