2020年Java中級(jí)工程師面試題

更新時(shí)間：2020-01-03 15:04:14 來源：動(dòng)力節(jié)點(diǎn) 瀏覽3935次

　　memcache的分布式原理

　　memcached 雖然稱為 “ 分布式 ” 緩存服務(wù)器，但服務(wù)器端并沒有 “ 分布式 ” 功能。每個(gè)服務(wù)器都是完全獨(dú)立和隔離的服務(wù)。memcached 的分布式，則是完全由客戶端程序庫(kù)實(shí)現(xiàn)的。這種分布式是 memcached 的最大特點(diǎn)。

　　memcache的內(nèi)存分配機(jī)制

　　如何存放數(shù)據(jù)到memcached緩存中?(memcache內(nèi)存分配機(jī)制)

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

　　如果有100byte的內(nèi)容要存儲(chǔ)，但122大小的倉(cāng)庫(kù)的chunk用滿了怎么辦? 答:是并不會(huì)尋找更大倉(cāng)庫(kù)的chunk來存儲(chǔ)，而是把122倉(cāng)庫(kù)中的舊數(shù)據(jù)踢掉!

　　memcache的惰性失效機(jī)制

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

　　memcache緩存的無底洞現(xiàn)象

　　緩存的無底洞現(xiàn)象：facebook的工作人員反應(yīng)，他們?cè)?010年左右，memcacahed節(jié)點(diǎn)就已經(jīng)達(dá)到3000個(gè)，大約數(shù)千G的緩存，他們發(fā)現(xiàn)一個(gè)問題，memchache連接頻率太高導(dǎo)致效率下降，于是加memcache節(jié)點(diǎn)，添加后發(fā)現(xiàn)連接頻率導(dǎo)致的問題仍然沒有好轉(zhuǎn)，稱之為“無底洞現(xiàn)象”。

　　問題分析：以用戶為例：user-133-age，user-133_name，user-133-height.........N個(gè)key 當(dāng)服務(wù)器增多，133號(hào)用戶的信息也被散落在更多的服務(wù)器，所以同樣是訪問個(gè)人主頁，得到相同的個(gè)人信息，節(jié)點(diǎn)越多，要連接節(jié)點(diǎn)越多，對(duì)于memcache的連接數(shù)并沒有隨著節(jié)點(diǎn)的增多而降低，問題出現(xiàn)。

　　事實(shí)上：nosql和傳統(tǒng)的rdbms并不是水火不容，兩者在某些設(shè)計(jì)上是可以相互參考的。對(duì)于nosql的key-value這種存儲(chǔ)，key的設(shè)計(jì)可以參考mysql中表和列的設(shè)計(jì)。比如user表下有age、name、height列，對(duì)應(yīng)的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;在用分布式算法求其節(jié)點(diǎn)時(shí)，應(yīng)該以u(píng)ser：133來計(jì)算，而不是以u(píng)ser：133：age來計(jì)算，這樣這三個(gè)關(guān)于個(gè)人信息的key都落在同一個(gè)節(jié)點(diǎn)上。再次訪問只需要連接一個(gè)節(jié)點(diǎn)。問題解決。

　　hash算法平衡性

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

　　memcached與redis的區(qū)別

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

　　Redis的主從復(fù)制

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

　　Redis的部分復(fù)制過程

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

2020年Java中級(jí)工程師面試題