memcache的分布式原理

　　memcached 雖然稱為 “ 分布式 ” 緩存服務器，但服務器端并沒有 “ 分布式 ” 功能。每個服務器都是完全獨立和隔離的服務。memcached 的分布式，則是完全由客戶端程序庫實現的。這種分布式是 memcached 的最大特點。

　　memcache的內存分配機制

　　如何存放數據到memcached緩存中?(memcache內存分配機制)

　　Slab Allocator內存分配機制：預先將內存分配成數個slab倉庫，每個倉庫再切出不同大小的chunk，去適配收到的數據。多余的只能造成浪費，不可避免。 增長因子(Grace factor)：一般而言觀察數據大小的變化規律設置合理的增長因子，默認1.25倍. 太大容易造成浪費。memcached.exe -m 64 -p 11211 -f 1.25

　　如果有100byte的內容要存儲，但122大小的倉庫的chunk用滿了怎么辦? 答:是并不會尋找更大倉庫的chunk來存儲，而是把122倉庫中的舊數據踢掉!

　　memcache的惰性失效機制

　　當某個值過期后并不會從內存刪除。(因此status統計時的curr_items有其信息) 2 如果之前沒有get過，將不會自動刪除。如果(過期失效，沒get過一次)又沒有一個新值去占用他的位置時，當做空的chunk占用。3 當取其值(get)時，判斷是否過期：如果過期返回空，且清空。(所以curr_items就減少了) 即這個過期只是讓用戶看不到這個數據而已，并沒有在過期的瞬間立即從內存刪除，這個過程 稱為lazy expirtion，屬性失效，好處是節約了cpu和檢測的成本，稱為“惰性失效機制”

　　memcache緩存的無底洞現象

　　緩存的無底洞現象：facebook的工作人員反應，他們在2010年左右，memcacahed節點就已經達到3000個，大約數千G的緩存，他們發現一個問題，memchache連接頻率太高導致效率下降，于是加memcache節點，添加后發現連接頻率導致的問題仍然沒有好轉，稱之為“無底洞現象”。

　　問題分析：以用戶為例：user-133-age，user-133_name，user-133-height.........N個key 當服務器增多，133號用戶的信息也被散落在更多的服務器， 所以同樣是訪問個人主頁，得到相同的個人信息，節點越多，要連接節點越多，對于memcache的連接數并沒有隨著節點的增多而降低，問題出現。

　　事實上：nosql和傳統的rdbms并不是水火不容，兩者在某些設計上是可以相互參考的。對于nosql的key-value這種存儲，key的設計可以參考mysql中表和列的設計。比如user表下有age、name、height列，對應的key可以用user：133：age=23，user：133：name=ls，user：133：height=168;

　　問題的解決方案：把某一組key按其共同前綴來分布，比如：user：133：age=23，user：133：name=ls，user：133：height=168;在用分布式算法求其節點時，應該以user：133來計算，而不是以user：133：age來計算，這樣這三個關于個人信息的key都落在同一個節點上。再次訪問只需要連接一個節點。問題解決。

　　hash算法平衡性

　　平衡性指的是hash的結果盡可能分布到所有的緩存中去，這樣可以使得所有的緩存空間都可以得到利用。但是hash算法不保證絕對的平衡性，為了解決這個問題一致性hash引入了“虛擬節點”的概念。虛擬節點”( virtual node )是實際節點在 hash 空間的復制品( replica )，一實際個節點對應了若干個“虛擬節點”，這個對應個數也成為“復制個數”，“虛擬節點”在 hash 空間中以 hash 值排列。“虛擬節點”的hash計算可以采用對應節點的IP地址加數字后綴的方式。??例如假設 cache A 的 IP 地址為202.168.14.241 。??引入“虛擬節點”前，計算 cache A 的 hash 值：Hash(“202.168.14.241”); ??引入“虛擬節點”后，計算“虛擬節”點 cache A1 和 cache A2 的 hash 值：????Hash(“202.168.14.241#1”); // cache A1 ????Hash(“202.168.14.241#2”); // cache A2 ??這樣只要是命中cacheA1和cacheA2節點，就相當于命中了cacheA的緩存。這樣平衡性就得到了提高。?

　　memcached與redis的區別

　　 redis做存儲，可以持久化，memcache做緩存，數據易丟失。2 redis支持多數據類型，memcache存放字符串。3 redis服務端僅支持單進程、單線程訪問，也就是先來后到的串行模式，避免線程上下文切換，自然也就保證數據操作的原子性。Memcache服務端是支持多線程訪問的。4 redis雖然是單進程單線程模式，但是redis使用了IO多路復用技術做到一個線程可以處理很多個請求來保證高性能。

　　Redis的主從復制

　　1在Slave啟動并連接到Master之后，它將主動發送一個SYNC命令給Master。2 Master在收到SYNC命令之后，將執行BGSAVE命令執行后臺存盤進程(rdb快照), 同時收集所有接收到的修改數據集的命令即寫命令到緩沖區，在后臺存盤進程執行完畢后，Master將傳送整個數據庫文件到Slave。3 Slave在接收到數據庫文件數據之后，將自身內存清空，加載rdb文件到內存中完成一次完全同步。4 接著，Master繼續將所有已經收集到緩沖區的修改命令，和新的修改命令依次傳送給Slaves 5 Slave將在本地執行這些數據修改命令，從而達到最終的數據同步 6 之后Master和Slave之間會不斷通過異步方式進行命令的同步，從而保證數據的實時同步 7 如果Master和Slave之間的鏈接出現斷連現象，Slave可以自動重連Master，但是在 重新連接成功之后：2.8之前的redis將進行一次完全同步 

　　Redis的部分復制過程

　　部分同步工作原理如下：1)：Master為被發送的復制流創建一個內存緩沖區(in-memory backlog)，記錄最近發送的復制流命令 2)：Master和Slave之間都記錄一個復制偏移量(replication offset)和當前Master ID(Master run id) 3)：當出現網絡斷開，Slave會重新連接，并且向Master請求繼續執行原來的復制進程 4)：如果Slave中斷網前的MasterID和當前要連的MasterID相同，并且從斷開時到當前時刻Slave記錄的偏移量所指定的數據仍然保存在Master的復制流緩沖區里面，則Master會向Slave發送缺失的那部分數據，Slave執行后復制工作可以繼續執行。5)：否則Slave就執行完整重同步操作

      以上就是動力節點Java培訓機構小編介紹的“2020年Java中級工程師面試題”的內容，希望對大家有幫助，如有疑問，請在線咨詢，有專業老師隨時為你服務。

相關推薦

最新最全java面試題及答案（初級到高級）

史上最全的中高級JAVA工程師面試題及答案匯總

Java高級開發工程師面試題

2019史上最全java面試題題庫大全800題

哪有資深java工程師面試題