memcached企業面試題

時間 2019-12-17

原文原文鏈接

面試題以下：html

一、Memcached是什麼，有什麼做用？
Memcached是一個開源的，高性能的內存綬存軟件，從名稱上看Mem就是內存的意思，而Cache就是緩存的意思。前端

Memcached的做用：經過在事先規劃好的內存空間中臨時綬存數據庫中的各種數據，以達到減小業務對數據庫的直接高併發訪問，從而達到提高數據庫的訪問性能，加速網站集羣動態應用服務的能力。mysql

二、Memcached服務在企業集羣架構中應用場景ios

1、做爲數據庫的前端緩存應用
a、完整緩存（易），靜態緩存
例如：商品分類（京東），以及商品信息，可事先放在內存裏，而後再對外提供數據訪問，這種先放到內存，咱們稱之爲預熱，（先把數據存緩存中），用戶訪問時能夠只讀取memcached緩存，不讀取數據庫了。
b、執點緩存（難）
須要前端web程序配合，只緩存熱點的數據，即緩存常常被訪問的數據。
先預熱數據庫裏的基礎數據，而後在動態更新，選讀取緩存，若是緩存裏沒有對應的數據，程序再去讀取數據庫，而後程序把讀取的新數據放入緩存存儲。web

特殊說明：面試

一、若是碰到電商秒殺等高併發的業務，必定要事先預熱，或者其它思想實現，例如：稱殺只是獲取資格，而不是瞬間秒殺到手商品。
那麼什麼是獲取資格？redis

就是在數據庫中，把0標成1.就有資格啦。再慢慢的去領取商品訂單。由於秒殺過程太長會佔用服務器資源。算法

二、若是數據更新，同時觸發緩存更新，防止給用戶過時數據。sql

c、對於持久化緩存存儲系統，例如：redis，能夠替代一部分數據庫的存儲，一些簡單的數據業務，投票，統計，好友關注，商品分類等。nosql= not only sql數據庫

2、做業集羣的session會話共享存儲。
http://oldboy.blog.51cto.com/2561410/1331316
http://oldboy.blog.51cto.com/2561410/1323468

三、Memcached服務在不一樣企業業務應用場景中的工做流程
a、當web程序須要訪問後端數據庫獲取數據時會優先訪問Memcached內存緩存，若是緩存中有數據就直接獲取返回前端服務及用戶，若是沒有數據（沒有命中），在由程序請求後端的數據庫服務器，獲取到對應的數據後，除了返回給前端服務及用戶數據外，還會把數據放到Memcached內存中進行緩存，等待下次請求被訪問，Memcache內存始終是數據庫的擋箭牌，從而大大的減輕數據庫的訪問壓力，提升整個網站架構的響應速度，提高了用戶體驗。

b、當程序更新，修改或刪除數據庫中已有的數據時，會同時發送請求通知Memcached已經緩存的同一個ID內容的舊數據失效，從而保證Memcache中數據和數據庫中的數據一致。

若是在高併發場合，除了通知Memcached過程的緩存失效外，還會經過相關機制，使得在用戶訪問新數據前，經過程序預先把更新過的數據推送到memcache中緩存起來，這樣能夠減小數據庫的訪問壓力，提高Memcached中緩存命中率。

c、數據庫插件能夠再寫入更新數據庫後，自動拋給MC緩存起來，自身不Cache.

四、Memcached服務分佈式集羣如何實現？

特殊說明：Memcached集羣和web服務集羣是不同的，全部Memcached的數據總和纔是數據庫的數據。每臺Memcached都是部分數據。
（一臺memcached的數據，就是一部分mysql數據庫的數據）

a、程序端實現
程序加載全部mc的ip列表，經過對key作hash (一致性哈希算法)
例如：web1 (key)===>對應A,B,C,D,E,F,G.....若干臺服務器。（經過哈希算法實現）

b、負載均衡器
經過對key作hash (一致性哈希算法)

一致哈希算法的目的是不但保證每一個對象只請求一個對應的服務器，並且當節點宕機，緩存服務器的更新從新分配比例降到最低。

Memcached資料：
http://blog.csdn.net/cutesource/article/details/5848253

五、Memcached服務特色及工做原理是什麼？
a、徹底基於內存緩存的
b、節點之間相互獨立
c、C/S模式架構，C語言編寫，總共2000行代碼。
d、異步Ｉ/O 模型，使用libevent做爲事件通知機制。
e、被緩存的數據以key/value鍵值對形式存在的。
f、所有數據存放於內存中，無持久性存儲的設計，重啓服務器，內存裏的數據會丟失。
g、當內存中緩存的數據容量達到啓動時設定的內存值時，就自動使用LRU算法刪除過時的緩存數據。
h、能夠對存儲的數據設置過時時間，這樣過時後的數據自動被清除，服務自己不會監控過時，而是在訪問的時候查看key的時間戳,判斷是否過時。
j、memcache會對設定的內存進行分塊，再把塊分組，而後再提供服務。

六、簡述Memcached內存管理機制原理？
　　malloc的全稱是memory allocation ,中文叫運態內存分配，當沒法知道內存具體位置的時候，想要綁定真正的內存空間，就須要用到動態的分配內存。

　　早期的Memcached內存管理方式是經過malloc的分配的內存，使用完後經過free來回收內存，這種方式容易產生內存碎片，並下降操做系統對內存的管理效率。加劇操做系統內存管理器的負擔，最壞的狀況下，會致使操做系統比memcached進程自己還慢，爲了解決這個問題，Slab Allocation內存分配機制就延生了。
　　如今Memcached利用Slab Allocation機制來分配和管理內存。
　　Slab Allocation機制原理是按照預先規定的大小，將分配給memcached的內存分割成特定長度的內存塊（chunk)，再把尺寸相同的內存塊，分紅組
（chunks slab class),這些內存塊不會釋放，能夠重複利用。

圖1 Slab Allocation的構造圖

並且，slab allocator還有重複使用已分配的內存的目的。也就是說，分配到的內存不會釋放，而是重複利用。

Slab Allocation的主要術語

Page

分配給Slab的內存空間，默認是1MB。分配給Slab以後根據slab的大小切分紅chunk。

Chunk

用於緩存記錄的內存空間。

Slab Class

特定大小的chunk的組。

在Slab中緩存記錄的原理

下面說明memcached如何針對客戶端發送的數據選擇slab並緩存到chunk中。

memcached根據收到的數據的大小，選擇最適合數據大小的slab（圖2）。 memcached中保存着slab內空閒chunk的列表，根據該列表選擇chunk，而後將數據緩存於其中。

圖2 選擇存儲記錄的組的方法

實際上，Slab Allocator也是有利也有弊。下面介紹一下它的缺點。

Slab Allocator的缺點

Slab Allocator解決了當初的內存碎片問題，但新的機制也給memcached帶來了新的問題。

這個問題就是，因爲分配的是特定長度的內存，所以沒法有效利用分配的內存。例如，將100字節的數據緩存到128字節的chunk中，剩餘的28字節就浪費了（圖3）。

圖3 chunk空間的使用

對於該問題目前尚未完美的解決方案，但在文檔中記載了比較有效的解決方案。

The most efficient way to reduce the waste is to use a list of size classes that closely matches (if that’s at all possible) common sizes of objects that the clients of this particular installation of memcached are likely to store.

就是說，若是預先知道客戶端發送的數據的公用大小，或者僅緩存大小相同的數據的狀況下，只要使用適合數據大小的組的列表，就能夠減小浪費。

可是很遺憾，如今還不能進行任何調優，只能期待之後的版本了。可是，咱們能夠調節slab class的大小的差異。

　　Memcached服務器端保存着一個空閒的內存塊列表，當有數據存入時根據接收到的數據大小，分配一個能存下這個數據的最小內存塊。這種方式有時會形成內存浪費。

　　例如：將一個200字節的數據存入一個300字節的內存塊中，會有100字節內存被浪費掉，不能使用。避免浪費內存的辦法是，預先計算出應用存入的數據大小，或把同一業務類型的數據存入一個Memcached服務器中，確保存入的數據大小相對均勻，這樣就能夠減小對內存的浪費。還有一種辦法是，在啓動時指定「-f」參數，能在某種程度上控制內存組之間的大小差別。在應用中使用Memcached時，一般能夠不從新設置這個參數，使用默認值1.25進行部署。若是想優化Memcached對內存的使用，能夠考慮從新計算數據的預期平均長度，調整這個參數來得到合適的設置值。

使用Growth Factor對Slab Allocator內存管理機制進行調優

　　memcached在啓動時指定 Growth Factor因子（經過-f選項），就能夠在某種程度上控制slab之間的差別。默認值爲1.25。可是，在該選項出現以前，這個因子曾經固定爲2，稱爲「powers of 2」策略。

讓咱們用之前的設置，以verbose模式啓動memcached試試看：

$ memcached -f 2 -vv

下面是啓動後的verbose輸出：

slab class   1: chunk size    128 perslab  8192
slab class   2: chunk size    256 perslab  4096
slab class   3: chunk size    512 perslab  2048
slab class   4: chunk size   1024 perslab  1024
slab class   5: chunk size   2048 perslab   512
slab class   6: chunk size   4096 perslab   256
slab class   7: chunk size   8192 perslab   128
slab class   8: chunk size  16384 perslab    64
slab class   9: chunk size  32768 perslab    32
slab class  10: chunk size  65536 perslab    16
slab class  11: chunk size 131072 perslab     8
slab class  12: chunk size 262144 perslab     4
slab class  13: chunk size 524288 perslab     2

可見，從128字節的組開始，組的大小依次增大爲原來的2倍。這樣設置的問題是，slab之間的差異比較大，有些狀況下就至關浪費內存。所以，爲儘可能減小內存浪費，兩年前追加了growth factor這個選項。

來看看如今的默認設置（f=1.25）時的輸出（篇幅所限，這裏只寫到第10組）：

slab class   1: chunk size     88 perslab 11915
slab class   2: chunk size    112 perslab  9362
slab class   3: chunk size    144 perslab  7281
slab class   4: chunk size    184 perslab  5698
slab class   5: chunk size    232 perslab  4519
slab class   6: chunk size    296 perslab  3542
slab class   7: chunk size    376 perslab  2788
slab class   8: chunk size    472 perslab  2221
slab class   9: chunk size    592 perslab  1771
slab class  10: chunk size    744 perslab  1409

可見，組間差距比因子爲2時小得多，更適合緩存幾百字節的記錄。從上面的輸出結果來看，可能會以爲有些計算偏差，這些偏差是爲了保持字節數的對齊而故意設置的。

將memcached引入產品，或是直接使用默認值進行部署時，最好是從新計算一下數據的預期平均長度，調整growth factor，以得到最恰當的設置。內存是珍貴的資源，浪費就太惋惜了。

接下來介紹一下如何使用memcached的stats命令查看slabs的利用率等各類各樣的信息。

查看memcached的內部狀態

memcached有個名爲stats的命令，使用它能夠得到各類各樣的信息。執行命令的方法不少，用telnet最爲簡單：

$ telnet 主機名 端口號

鏈接到memcached以後，輸入stats再按回車，便可得到包括資源利用率在內的各類信息。此外，輸入」stats slabs」或」stats items」還能夠得到關於緩存記錄的信息。結束程序請輸入quit。

這些命令的詳細信息能夠參考memcached軟件包內的protocol.txt文檔。

$ telnet localhost 11211
Trying ::1...
Connected to localhost.
Escape character is '^]'.
stats
STAT pid 481
STAT uptime 16574
STAT time 1213687612
STAT version 1.2.5
STAT pointer_size 32
STAT rusage_user 0.102297
STAT rusage_system 0.214317
STAT curr_items 0
STAT total_items 0
STAT bytes 0
STAT curr_connections 6
STAT total_connections 8
STAT connection_structures 7
STAT cmd_get 0
STAT cmd_set 0
STAT get_hits 0
STAT get_misses 0
STAT evictions 0
STAT bytes_read 20
STAT bytes_written 465
STAT limit_maxbytes 67108864
STAT threads 4
END
quit

另外，若是安裝了libmemcached這個面向C/C++語言的客戶端庫，就會安裝 memstat 這個命令。使用方法很簡單，能夠用更少的步驟得到與telnet相同的信息，還能一次性從多臺服務器得到信息。

$ memstat --servers=server1,server2,server3,...

libmemcached能夠從下面的地址得到：

http://tangent.org/552/libmemcached.html

查看slabs的使用情況

使用memcached的創造者Brad寫的名爲memcached-tool的Perl腳本，能夠方便地得到slab的使用狀況（它將memcached的返回值整理成容易閱讀的格式）。能夠從下面的地址得到腳本：

http://code.sixapart.com/svn/memcached/trunk/server/scripts/memcached-tool

使用方法也極其簡單：

$ memcached-tool 主機名:端口 選項

查看slabs使用情況時無需指定選項，所以用下面的命令便可：

$ memcached-tool 主機名:端口

得到的信息以下所示：

#  Item_Size   Max_age  1MB_pages Count   Full?
 1     104 B  1394292 s    1215 12249628    yes
 2     136 B  1456795 s      52  400919     yes
 3     176 B  1339587 s      33  196567     yes
 4     224 B  1360926 s     109  510221     yes
 5     280 B  1570071 s      49  183452     yes
 6     352 B  1592051 s      77  229197     yes
 7     440 B  1517732 s      66  157183     yes
 8     552 B  1460821 s      62  117697     yes
 9     696 B  1521917 s     143  215308     yes
10     872 B  1695035 s     205  246162     yes
11     1.1 kB 1681650 s     233  221968     yes
12     1.3 kB 1603363 s     241  183621     yes
13     1.7 kB 1634218 s      94   57197     yes
14     2.1 kB 1695038 s      75   36488     yes
15     2.6 kB 1747075 s      65   25203     yes
16     3.3 kB 1760661 s      78   24167     yes

各列的含義爲：

列	含義
#	slab class編號
Item_Size	Chunk大小
Max_age	LRU內最舊的記錄的生存時間
1MB_pages	分配給Slab的頁數
Count	Slab內的記錄數
Full?	Slab內是否含有空閒chunk