原文鏈接: https://trainyao.github.io/post/mosn/source_shm/
本文記錄了對 MOSN 的源碼研究 - MOSN 的共享內(nèi)存模型蛾方。
本文的內(nèi)容基于 MOSN v0.9.0单默，commit id b2a239f5温峭。
機(jī)制
MOSN 用共享內(nèi)存來存儲 metrics 信息锰霜。MOSN 用 mmap 將文件映射到內(nèi)存，在內(nèi)存數(shù)組之上封裝了一層關(guān)于 metrics 的存取邏輯区岗，實現(xiàn)了 go-metrics
包的關(guān)于 metrics 的接口矛洞，通過這種方式組裝出了一種基于共享內(nèi)存的 metrics 實現(xiàn)供 MOSN 使用。
創(chuàng)建共享內(nèi)存：Mmap
操作共享內(nèi)存的方法主要在 pkg/shm/shm.go 文件下：
func Alloc(name string, size int) (*ShmSpan, error) {
...
return NewShmSpan(name, data), nil
}
func Free(span *ShmSpan) error {
Clear(span.name)
return syscall.Munmap(span.origin)
}
func Clear(name string) error {
return os.Remove(path(name))
}
都是圍繞著 ShmSpan 結(jié)構(gòu)體的幾個操作方法呕屎。再來看 ShmSpan 結(jié)構(gòu)體：
type ShmSpan struct {
origin []byte // mmap 返回的數(shù)組
name string // span 名, 創(chuàng)建時指定
data uintptr // 保存 mmap 內(nèi)存段的首指針
offset int // span 已經(jīng)使用的字節(jié)長度
size int // span 大小
}
Alloc 方法按照給定的 name 參數(shù)，在配置文件的目錄下創(chuàng)建文件敬察，并執(zhí)行 sync.Mmap秀睛，其文件尺寸即 size 參數(shù)大小。Mmap 過后莲祸，將信息保存在 ShmSpan結(jié)構(gòu)內(nèi)返回蹂安。
代碼邏輯比較簡單椭迎，大家可以自行閱讀：https://github.com/mosn/mosn/blob/b2a239f5/pkg/shm/shm.go#L28
由此看出，一個 ShmSpan 可以看做是一個共享內(nèi)存塊田盈。
下面我們將會分析共享內(nèi)存塊在 MOSN 里的使用場景：metrics侠碧。
操作共享內(nèi)存：配置
在分析如何通過共享內(nèi)存存取 metrics 之前，首先看這相關(guān)的功能是如何配置的缠黍。
https://github.com/mosn/mosn/blob/b2a239f5/pkg/mosn/starter.go#L318
func initializeMetrics(config v2.MetricsConfig) {
// init shm zone
if config.ShmZone != "" && config.ShmSize > 0 {
shm.InitDefaultMetricsZone(config.ShmZone, int(config.ShmSize), store.GetMosnState() != store.Active_Reconfiguring)
...
從這里看出，通過讀取配置文件的 ShmZone 和 ShmSize 來初始化共享內(nèi)存药蜻，即配置文件的以下兩個字段是控制著共享內(nèi)存的文件名和大小的：
{
...
"metrics": {
...
"shm_zone": "文件名",
"shm_size": "共享內(nèi)存文件大小"
},
...
}
操作共享內(nèi)存：metrics
metrics 相關(guān)的邏輯在 pkg/metrics 包下瓷式。
上文說的 ShmSpan 是保存共享內(nèi)存信息的結(jié)構(gòu)體，而要理解 MOSN metrics 對共享內(nèi)存的使用语泽，還要先理解 MOSN 封裝的幾個結(jié)構(gòu)體：zone贸典、hashSet 和 hashEntry。
這幾個結(jié)構(gòu)體與 ShmSpan 的關(guān)系大致是這樣的：
ShmSpan 是共享內(nèi)存塊踱卵，而 zone廊驼、hashSet 和 hashEntry 對 ShmSpan 進(jìn)行了劃分：
-
hashSet封裝出了 metrics name 映射到 metrics value 的哈希表 -
hashEntry是哈希表的值，也是 metrics 值的保存的共享內(nèi)存空間 -
zone對ShmSpan進(jìn)行了劃分惋砂，劃分出了一個int32值作為互斥鎖妒挎；一個int32值作為zone的引用計數(shù)；也劃分出了一片空間保存hashSet
以上步驟做好后西饵，創(chuàng)建一個 metrics 就可以通過創(chuàng)建對應(yīng)的哈希 key value酝掩，拿到對應(yīng)的共享內(nèi)存地址，存取 metrics 信息眷柔。
下面是源碼步驟期虾，大家可以自行跟蹤調(diào)試：
1) 創(chuàng)建 zone：
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L81
func newSharedMetrics(name string, size int) (*zone, error) {
alignedSize := align(size, pageSize)
// 申請 ShmSpan
span, err := shm.Alloc(name, alignedSize)
if err != nil {
return nil, err
}
// 1. mutex and ref
// 從 span 里取 4 個字節(jié)做互斥鎖
mutex, err := span.Alloc(4)
if err != nil {
return nil, err
}
// 從 span 里取 4 個字節(jié)做引用計數(shù)
ref, err := span.Alloc(4)
if err != nil {
return nil, err
}
zone := &zone{
span: span,
mutex: (*uint32)(unsafe.Pointer(mutex)),
ref: (*uint32)(unsafe.Pointer(ref)),
}
// 2. hashSet
// 劃分哈希表過程
// assuming that 100 entries with 50 slots, so the ratio of occupied memory is
// entries:slots = 100 x 128 : 50 x 4 = 64 : 1
// so assuming slots memory size is N, total allocated memory size is M, then we have:
// M - 1024 < 65N + 28 <= M
// 計算 slot 的數(shù)量和內(nèi)存占用大小
slotsNum := (alignedSize - 28) / (65 * 4)
slotsSize := slotsNum * 4
// 計算 entry 數(shù)量和內(nèi)存占用大小
entryNum := slotsNum * 2
entrySize := slotsSize * 64
// 哈希表內(nèi)存大小 = entry 內(nèi)存占用 + 20 字節(jié) + slot 內(nèi)存占用大小
hashSegSize := entrySize + 20 + slotsSize
hashSegment, err := span.Alloc(hashSegSize)
if err != nil {
return nil, err
}
// if zones's ref > 0, no need to initialize hashset's value
// 初始化哈希表結(jié)構(gòu)
set, err := newHashSet(hashSegment, hashSegSize, entryNum, slotsNum, atomic.LoadUint32(zone.ref) == 0)
if err != nil {
return nil, err
}
zone.set = set
// add ref
atomic.AddUint32(zone.ref, 1)
return zone, nil
}
這里可以大致說一下哈希表初始化的算法：首先 alignedSize 表示 4k 對齊后的 ShmSpan 大小，前 8 個字節(jié)被分配為互斥鎖和引用計數(shù)驯嘱，
另外 20 個字節(jié)被分配為哈希表的 meta 結(jié)構(gòu)體镶苞，
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/hashset.go#L54
type hashSet struct {
entry []hashEntry
meta *meta
slots []uint32
}
...
type meta struct {
cap uint32
size uint32
freeIndex uint32
slotsNum uint32
bytesNum uint32
}
所以真正能被分配為哈希表信息儲存的空間 = 總空間 - 8 字節(jié) - 20 字節(jié)。那能分配多少個哈希表信息呢鞠评？要看看 MOSN 的哈希表組織形式：entry 最開始首尾相連茂蚓，后面會被組織成一個一個的 slot 鏈表供哈希碰撞時遍歷查詢。
所以 slot 和 entry 的比例控制著哈希表查找的性能：entry 比 slot 作為比例的話谢澈，比例越高意味著更容易碰撞煌贴，鏈表越長，查找性能下降锥忿；相反比例越低鏈表越短牛郑，查找性能越高，但是有越多 slot 閑置敬鬓，空間會浪費淹朋。
從注釋看笙各，MOSN 將比例寫死為 2：1。假設(shè) 100 個 entry + 50 個 slot础芍，其內(nèi)存比等于 100 * 128（entry 內(nèi)存占用）：50 * 4 = 64：1杈抢，即一份 2：1 的 entry+slot 需要用到（64 + 1）* 4 個字節(jié)。
所以仑性，如果按照 2：1 來分配的話惶楼，一共可以分配的份數(shù) = 哈希表信息儲存空間 / 每一份空間占用 = (總空間 - 8 - 20) / (64 + 1) * 4 份。由此就可以算出 entry 和 slot 可以分配多少份了诊杆。
2) 創(chuàng)建指標(biāo)：
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/counter.go#L56
func NewShmCounterFunc(name string) func() gometrics.Counter {
return func() gometrics.Counter {
if defaultZone != nil {
if entry, err := defaultZone.alloc(name); err == nil {
...
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L166
func (z *zone) alloc(name string) (*hashEntry, error) {
z.lock()
defer z.unlock()
entry, create := z.set.Alloc(name)
...
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/hashset.go#L135
func (s *hashSet) Alloc(name string) (*hashEntry, bool) {
// 1. search existed slots and entries
// 計算 hash 值作為 slot index
h := hash(name)
slot := h % s.meta.slotsNum
// name convert if length exceeded
if len(name) > maxNameLength {
// if name is longer than max length, use hash_string as leading character
// and the remaining maxNameLength - len(hash_string) bytes follows
hStr := strconv.Itoa(int(h))
name = hStr + name[len(hStr)+len(name)-maxNameLength:]
}
nameBytes := []byte(name)
// 查找鏈表找到對應(yīng)的 entry
var entry *hashEntry
for index := s.slots[slot]; index != sentinel; {
entry = &s.entry[index]
if entry.equalName(nameBytes) {
return entry, false
}
index = entry.next
}
// 2. create new entry
// 如果找不到, 創(chuàng)建新的 entry
if s.meta.size >= s.meta.cap {
return nil, false
}
// 創(chuàng)建新的 entry 從 hashset 的 meta 信息里拿 next free index
newIndex := s.meta.freeIndex
newEntry := &s.entry[newIndex]
newEntry.assignName(nameBytes)
newEntry.ref = 1
if entry == nil {
// 所以是鏈表頭,保存 index 到 slot
s.slots[slot] = newIndex
} else {
// 否則保存在上一個 entry 的 next 字段內(nèi)
entry.next = newIndex
}
s.meta.size++
// 設(shè)置 next free index
s.meta.freeIndex = newEntry.next
// 設(shè)置隊尾
newEntry.next = sentinel
return newEntry, true
}
3) 用 Entry 保存 metrics 值
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/counter.go#L56
func NewShmCounterFunc(name string) func() gometrics.Counter {
return func() gometrics.Counter {
if defaultZone != nil {
if entry, err := defaultZone.alloc(name); err == nil {
return ShmCounter(unsafe.Pointer(&entry.value))
}
...
可以看出歼捐，entry 的 value 是真正被用作記錄 metrics 值的地方，它是一個 64 位的空間晨汹。
為什么使用共享內(nèi)存保存 metrics
看到這里你可能會問豹储，為什么要這么辛苦封裝共享內(nèi)存來保存 metrics 值？為什么不直接使用堆空間來做呢淘这？
其實在源碼里也有答案：
https://github.com/mosn/mosn/blob/b2a239f5/pkg/mosn/starter.go#L318
func initializeMetrics(config v2.MetricsConfig) {
// init shm zone
if config.ShmZone != "" && config.ShmSize > 0 {
shm.InitDefaultMetricsZone(config.ShmZone, int(config.ShmSize), store.GetMosnState() != store.Active_Reconfiguring)
...
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L58
func createMetricsZone(name string, size int, clear bool) *zone {
if clear {
shm.Clear(name)
}
...
如果 clear 為真剥扣，共享內(nèi)存就會被清除，那么什么時候為假呢铝穷？當(dāng) store.GetMosnState() 方法返回 store.Active_Reconfigureing 的時候钠怯。即，當(dāng) MOSN reconfig 重啟的時候氧骤，
已經(jīng)保存的 metrics 是會被保留的呻疹。
而且從這里可以看出：
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L124
func newSharedMetrics(name string, size int) (*zone, error) {
...
set, err := newHashSet(hashSegment, hashSegSize, entryNum, slotsNum, atomic.LoadUint32(zone.ref) == 0)
...
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/hashset.go#L78
func newHashSet(segment uintptr, bytesNum, cap, slotsNum int, init bool) (*hashSet, error) {
set := &hashSet{}
...
當(dāng) zone.ref 引用計數(shù)不為 0 的時候，哈希表里面的信息也是會被保留的筹陵。
再來看 zone.mutex 互斥鎖的使用：
https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L136
func (z *zone) lock() {
times := 0
// 5ms spin interval, 5 times burst
for {
if atomic.CompareAndSwapUint32(z.mutex, 0, pid) {
return
}
...
是通過設(shè)置進(jìn)程 ID 來獲取鎖的刽锤，由此能看出 MOSN 的用意：這個以文件作為 mmap 的共享內(nèi)存是可以被多個 MOSN 進(jìn)程共用的。
例如像同一臺機(jī)器多個 MOSN 作為 sidecar 的場景朦佩，我們完全可以掛載宿主機(jī)同一個文件作為不同 sidecar 的共享內(nèi)存文件映射并思，
除了能達(dá)到 metrics 信息共享的效果外，也避免了 metrics 重復(fù)的內(nèi)存占用语稠，這里應(yīng)該是有優(yōu)化考慮在的宋彼。而且這個文件可以看作是一種文件格式，
在任何時候都可以被持久化保存和提取分析使用的仙畦。
總結(jié)
本文通過分析 MOSN 源碼输涕，簡述了 MOSN 的共享內(nèi)存模型，分析了 MOSN 創(chuàng)建共享內(nèi)存慨畸、配置 metrics 和 metrics 對共享內(nèi)存塊的使用莱坎。
參考資料:
