golang實現NFS,golang使用

本文目錄一覽：

• 1、golang如何實現urldecode
• 2、golang實現簡單的流式處理
• 3、golang sync.Pool的用法及實現
• 4、golang協程調度模式解密
• 5、組件分享之後端組件——基於Golang實現的高性能和彈性的流處理器benthos
• 6、（十一）golang 內存分析

golang如何實現urldecode

首先你的理解是錯的，不管用戶態的API(syscall)是否是同步還是非同步，在kernel層面都是非同步的。

其實實現原理很簡單，就是利用C(嵌入彙編)語言可以直接修改寄存器(setcontext/setjmp/longjmp均是類似原理，修改程序指針eip實現跳轉，棧指針實現上線文切換)來實現從func_a調進去，從func_b返回出來這種行為。對於golang來說，func_a/func_b屬於不同的goroutine，從而就實現了goroutine的調度切換。

另外對於所有可能阻塞的syscall，golang對其進行了封裝，底層實際是epoll方式做的，註冊回調後切換到另一個runnable的goroutine。

golang實現簡單的流式處理

實現一個最簡單的類似spark的流式處理流程

包含map和filter

數據

map函數

fliter函數

所有數據+1 過濾出偶數 過濾出大於5的數

golang sync.Pool的用法及實現

正如sycn.Pool的名字所示，這是go中實現的一個對象池，為什麼要有這個池呢？首先go是自帶垃圾回收機制（也就是通常所說的gc）。gc會帶來運行時的開銷，對於高頻的內存申請與釋放，如果將不用的對象存放在一個池子中，用的時候從池子中取出一個對象，用完了再還回去，這樣就能減輕gc的壓力。

對於池這個概念，之前可能聽說過連接池。能否用sync.Pool實現一個連接池呢？答案是不能的。因為對於sync.Pool而言，我們無法保證每次放回去再取出來的對象是與之前一致的，對象的內存存在著唄銷毀的可能。因此，這個sync.Pool的存在僅僅是為了減緩gc的壓力而生的。

定義sync.Pool的時候只需要設置一個New成員，它是一個函數，類型為func() interface{}，當池子中沒有空閑的對象時就會調用New函數生成一個。由於pool中對象的數量不可控，因此並沒有傳遞任何與對象數量有關的參數。

然後，調用調用Get函數就可以取出一個對象，調用Put函數就可以將對象歸還到池子中。

golang協程調度模式解密

golang學習筆記

頻繁創建線程會造成不必要的開銷，所以才有了線程池。在線程池中預先保存一定數量的線程，新任務發布到任務隊列，線程池中的線程不斷地從任務隊列中取出任務並執行，可以有效的減少創建和銷毀帶來的開銷。

過多的線程會導致爭搶cpu資源，且上下文的切換的開銷變大。而工作在用戶態的協程能大大減少上下文切換的開銷。協程調度器把可運行的協程逐個調度到線程中執行，同時即時把阻塞的協程調度出協程，從而有效地避免了線程的頻繁切換，達到了少量線程實現高並發的效果。

多個協程分享操作系統分給線程的時間片，從而達到充分利用CPU的目的，協程調度器決定了則決定了協程運行的順序。每個線程同一時刻只能運行一個協程。

go調度模型包含三個實體：

每個處理器維護者一個協程G的隊列，處理器依次將協程G調度到M中執行。

每個P會周期性地查看全局隊列中是否有G待運行並將其調度到M中執行，全局隊列中的G主要來自系統調用中恢復的G.

如果協程發起系統調用，則整個工作線程M被阻塞，協程隊列中的其他協程都會阻塞。

一般情況下M的個數會略大於P個數，多出來的M將會在G產生系統調用時發揮作用。與線程池類似，Go也提供M池子。當協程G1發起系統掉用時，M1會釋放P,由 M1-P-G1 G2 … 轉變成 M1-G1 , M2會接管P的其他協程 M2-P-G2 G3 G4… 。

冗餘的M可能來源於緩存池，也可能是新建的。

當G1結束系統調用後，根據M1是否獲取到P,進行不用的處理。

多個處理P維護隊列可能不均衡，導致部分處理器非常繁忙，而其餘相對空閑。產生原因是有些協程自身不斷地派生協程。

為此Go調度器提供了工作量竊取策略，當某個處理器P沒有需要調度的協程時，將從其他處理中偷取協程，每次偷取一半。

搶佔式調度，是指避免某個協程長時間執行，而阻礙其他協程被調度的機制。

調度器監控每個協程執行時間，一旦執行時間過長且有其他協程等待，會把協程暫停，轉而調度等待的協程，以達到類似時間片輪轉的效果。比如for循環會一直佔用執行權。

在IO密集型應用，GOMAXPROCS大小設置大一些，獲取性能會更好。

IO密集型會經常發生系統調用，會有一個新的M啟用或創建，但由於Go調度器檢測M到被阻塞有一定延遲。如果P數量多，則P管理協程隊列會變小。

組件分享之後端組件——基於Golang實現的高性能和彈性的流處理器benthos

近期正在探索前端、後端、系統端各類常用組件與工具，對其一些常見的組件進行再次整理一下，形成標準化組件專題，後續該專題將包含各類語言中的一些常用組件。歡迎大家進行持續關注。

本節我們分享的是基於Golang實現的高性能和彈性的流處理器 benthos ，它能夠以各種代理模式連接各種 源 和 接收器，並對有效負載執行 水合、濃縮、轉換和過濾 。

它帶有 強大的映射語言 ，易於部署和監控，並且可以作為靜態二進位文件、docker 映像或 無伺服器函數 放入您的管道，使其成為雲原生。

Benthos 是完全聲明性的，流管道在單個配置文件中定義，允許您指定連接器和處理階段列表：

Apache Pulsar, AWS (DynamoDB, Kinesis, S3, SQS, SNS), Azure (Blob storage, Queue storage, Table storage), Cassandra, Elasticsearch, File, GCP (Pub/Sub, Cloud storage), HDFS, HTTP (server and client, including websockets), Kafka, Memcached, MQTT, Nanomsg, NATS, NATS JetStream, NATS Streaming, NSQ, AMQP 0.91 (RabbitMQ), AMQP 1, Redis (streams, list, pubsub, hashes), MongoDB, SQL (MySQL, PostgreSQL, Clickhouse, MSSQL), Stdin/Stdout, TCP UDP, sockets and ZMQ4.

1、docker安裝

具體使用方式可以參見該 文檔

有關如何配置更高級的流處理概念（例如流連接、擴充工作流等）的指導，請查看 說明書部分。

有關在 Go 中構建您自己的自定義插件的指導，請查看 公共 API。

（十一）golang 內存分析

編寫過C語言程序的肯定知道通過malloc()方法動態申請內存，其中內存分配器使用的是glibc提供的ptmalloc2。 除了glibc，業界比較出名的內存分配器有Google的tcmalloc和Facebook的jemalloc。二者在避免內存碎片和性能上均比glic有比較大的優勢，在多線程環境中效果更明顯。

Golang中也實現了內存分配器，原理與tcmalloc類似，簡單的說就是維護一塊大的全局內存，每個線程(Golang中為P)維護一塊小的私有內存，私有內存不足再從全局申請。另外，內存分配與GC（垃圾回收）關係密切，所以了解GC前有必要了解內存分配的原理。

為了方便自主管理內存，做法便是先向系統申請一塊內存，然後將內存切割成小塊，通過一定的內存分配演算法管理內存。 以64位系統為例，Golang程序啟動時會向系統申請的內存如下圖所示：

預申請的內存劃分為spans、bitmap、arena三部分。其中arena即為所謂的堆區，應用中需要的內存從這裡分配。其中spans和bitmap是為了管理arena區而存在的。

arena的大小為512G，為了方便管理把arena區域劃分成一個個的page，每個page為8KB,一共有512GB/8KB個頁；

spans區域存放span的指針，每個指針對應一個page，所以span區域的大小為(512GB/8KB)乘以指針大小8byte = 512M

bitmap區域大小也是通過arena計算出來，不過主要用於GC。

span是用於管理arena頁的關鍵數據結構，每個span中包含1個或多個連續頁，為了滿足小對象分配，span中的一頁會劃分更小的粒度，而對於大對象比如超過頁大小，則通過多頁實現。

根據對象大小，劃分了一系列class，每個class都代表一個固定大小的對象，以及每個span的大小。如下表所示：

上表中每列含義如下：

class： class ID，每個span結構中都有一個class ID, 表示該span可處理的對象類型

bytes/obj：該class代表對象的位元組數

bytes/span：每個span佔用堆的位元組數，也即頁數乘以頁大小

objects: 每個span可分配的對象個數，也即（bytes/spans）/（bytes/obj）waste

bytes: 每個span產生的內存碎片，也即（bytes/spans）%（bytes/obj）上表可見最大的對象是32K大小，超過32K大小的由特殊的class表示，該class ID為0，每個class只包含一個對象。

span是內存管理的基本單位,每個span用於管理特定的class對象, 跟據對象大小，span將一個或多個頁拆分成多個塊進行管理。src/runtime/mheap.go:mspan定義了其數據結構：

以class 10為例，span和管理的內存如下圖所示：

spanclass為10，參照class表可得出npages=1,nelems=56,elemsize為144。其中startAddr是在span初始化時就指定了某個頁的地址。allocBits指向一個點陣圖，每位代表一個塊是否被分配，本例中有兩個塊已經被分配，其allocCount也為2。next和prev用於將多個span鏈接起來，這有利於管理多個span，接下來會進行說明。

有了管理內存的基本單位span，還要有個數據結構來管理span，這個數據結構叫mcentral，各線程需要內存時從mcentral管理的span中申請內存，為了避免多線程申請內存時不斷的加鎖，Golang為每個線程分配了span的緩存，這個緩存即是cache。src/runtime/mcache.go:mcache定義了cache的數據結構

alloc為mspan的指針數組，數組大小為class總數的2倍。數組中每個元素代表了一種class類型的span列表，每種class類型都有兩組span列表，第一組列表中所表示的對象中包含了指針，第二組列表中所表示的對象不含有指針，這麼做是為了提高GC掃描性能，對於不包含指針的span列表，沒必要去掃描。根據對象是否包含指針，將對象分為noscan和scan兩類，其中noscan代表沒有指針，而scan則代表有指針，需要GC進行掃描。mcache和span的對應關係如下圖所示：

mchache在初始化時是沒有任何span的，在使用過程中會動態的從central中獲取並緩存下來，跟據使用情況，每種class的span個數也不相同。上圖所示，class 0的span數比class1的要多，說明本線程中分配的小對象要多一些。

cache作為線程的私有資源為單個線程服務，而central則是全局資源，為多個線程服務，當某個線程內存不足時會向central申請，當某個線程釋放內存時又會回收進central。src/runtime/mcentral.go:mcentral定義了central數據結構：

lock: 線程間互斥鎖，防止多線程讀寫衝突

spanclass : 每個mcentral管理著一組有相同class的span列表

nonempty: 指還有內存可用的span列表

empty: 指沒有內存可用的span列表

nmalloc: 指累計分配的對象個數線程從central獲取span步驟如下：

將span歸還步驟如下：

從mcentral數據結構可見，每個mcentral對象只管理特定的class規格的span。事實上每種class都會對應一個mcentral,這個mcentral的集合存放於mheap數據結構中。src/runtime/mheap.go:mheap定義了heap的數據結構：

lock： 互斥鎖

spans: 指向spans區域，用於映射span和page的關係

bitmap：bitmap的起始地址

arena_start: arena區域首地址

arena_used: 當前arena已使用區域的最大地址

central: 每種class對應的兩個mcentral

從數據結構可見，mheap管理著全部的內存，事實上Golang就是通過一個mheap類型的全局變數進行內存管理的。mheap內存管理示意圖如下：

系統預分配的內存分為spans、bitmap、arean三個區域，通過mheap管理起來。接下來看內存分配過程。

針對待分配對象的大小不同有不同的分配邏輯：

(0, 16B) 且不包含指針的對象： Tiny分配

(0, 16B) 包含指針的對象：正常分配

[16B, 32KB] : 正常分配

(32KB, -) : 大對象分配其中Tiny分配和大對象分配都屬於內存管理的優化範疇，這裡暫時僅關注一般的分配方法。

以申請size為n的內存為例，分配步驟如下：

Golang內存分配是個相當複雜的過程，其中還摻雜了GC的處理，這裡僅僅對其關鍵數據結構進行了說明，了解其原理而又不至於深陷實現細節。1、Golang程序啟動時申請一大塊內存並劃分成spans、bitmap、arena區域

2、arena區域按頁劃分成一個個小塊。

3、span管理一個或多個頁。

4、mcentral管理多個span供線程申請使用

5、mcache作為線程私有資源，資源來源於mcentral。