golanggzip的簡單介紹

本文目錄一覽：

• 1、zstd，未來可期的數據壓縮算法
• 2、golang中compress/gzip
• 3、集中式日誌分析平台 – ELK Stack – Filebeat 壓測
• 4、如何部署Golang應用
• 5、網絡：什麼是 MIME TYPE?

zstd，未來可期的數據壓縮算法

最近了解到了 zstd 這種新的壓縮算法。不像lz4，lzo，snappy等近幾年流行的壓縮算法專註於壓縮和解壓縮性能，zstd在性能不錯的同時號稱壓縮率跟Deflate（zip/gzip的算法）相當。下面是 官網 列出的數據：

我們知道，壓縮算法的效果和性能跟被壓縮的數據類型和模式有很大的關係，光看別人的測試數據、benchmark是不夠的。正好有功能開發需要，於是結合我們的使用場景真實測試的一下。

驚喜的是，實測的結果比官方提供的還好，終於找到了我們的cup of tea。

Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 8G內存

CentOS 7.0

對幾種支持流式寫入的壓縮算法，使用對應的命令行工具進行壓縮測試。

除了snappy，各種壓縮算法/工具都支持設置壓縮級別，高級別意味着以更長的壓縮時間換取更高的壓縮率。

100萬行不重複的某個應用的日誌文件，大小為977MB。

從上面可以看出：

zstd無論從處理時間還是壓縮率來看都佔優。snappy, lz4, lzo的壓縮率較低，但壓縮速度都很快，而zstd甚至比這些算法更快。Gzip的壓縮率比lz4等高不少，而zstd的壓縮率比gzip還提升一倍。

如果從上面的比較還不是特別直觀的話，我們再引入一個創造性的指標（從網上其他壓縮算法對比沒有見過使用這項指標）：

代表單位處理時間可以壓縮去掉多少冗餘數據。其中 權重係數 用來指定壓縮率和壓縮速度哪個更重要，這裡我們認為在我們的使用場景里兩者同樣重要，取係數為1。

從這裡我們可以明顯看出， zstd lz4 lzo snappy 其他 。

對1000行、大小約為1MB的文件進行壓縮測試，各種算法的壓縮率跟1GB大文件的壓縮率幾乎一樣。

下面再對更小的數據量——10行日誌數據的壓縮率進行對比。雖然我們的使用場景里沒有對小數據量的壓縮處理，但還是比較好奇zstd字典模式的效果。

其中最後一組數據為zstd使用10000行日誌進行訓練生成字典文件，並利用字典文件輔助壓縮測試數據。

可以看出來，除了zstd字典模式外，各種壓縮算法在處理更小的數據量時壓縮率都下降很多。而zstd字典模式對壓縮率帶來幫助非常明顯，與gzip對比，壓縮率從1000行時相差1倍，到10行時變為了相差接近3倍。

下一篇文章將給大家對比這幾種算法的golang開源庫的性能和壓縮率。敬請期待。

golang中compress/gzip

go標準庫的gzip包中提供了兩個操作，分別是壓縮和解壓

常量和變量

（1）壓縮

demo

(2)解壓

demo

集中式日誌分析平台 – ELK Stack – Filebeat 壓測

任何一款採集 agent 進行公司內全面推廣前都需要進行性能測試以及資源限制功能測試，以保證：

對於 Filebeat 這款號稱 golang 編寫，性能強於 logstahs-forwarder 的採集 agent，我們也需要這樣進行嚴謹對待。

硬件選擇虛擬機，6cores + 16GB Mem + 175GB SSD + 1000Mbps 帶寬；

Filebeat 配置，輸出到 console：

Filebeat 配置，輸出到 Kafka：

我們開啟 Filebeat 的 6060 端口，並使用 python 腳本進行指標採集。

expvar_rates.py ，每秒統計出 Filebeat 指標，主要看：

Step1. 啟動 Filebeat (172.16.134.8)

Step2. 啟動統計腳本

Step3. 啟動 tsar

Step4. 寫入壓測數據(6個進程寫入，6千萬條日誌)

在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 0.8 cores。

在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 1.6 cores。

小結：

測試步驟和上述一致，區別在於配置文件需要輸出到 Kafka。

在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 0.7~0.8 cores。

在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 2.0 cores。

小結：

測試步驟和上述一致，區別在於配置文件需要輸出到 Kafka。

和上述步驟不同的是，啟動 Filebeat 時需要 systemd 限制 CPU、句柄數，根據之前的理論，句柄數限制在 100 已經非常夠用，CPU 限制在 1 core。

修改 /usr/lib/systemd/system/filebeat.service ：

執行 reload：

對 CPU 進行限制：

確認是否限制成功：

有如下輸出表示OK：

在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 0.7 ~ 0.8 cores。

在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 1.0 cores，限制生效。

小結：

在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 0.75 ~ 0.9 cores。

在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 1.0 cores，限制生效。

小結：

在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 0.7 ~ 0.75 cores。

在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致佔據了 0.9 cores，未達到限制。

小結：

A. FB 全力採集 247B 數據(真實環境類似日誌長度)，速率為 ~ 40K/s，CPU 開銷為 2 cores；

B. FB 在 CPU 限制 1 cores 情況下，採集 247B 數據速率為 ~ 20K/s，可以認為單核採集速率為 ~ 20K/s/core；

C. 日誌單行數據越大，吞吐越小，5KB 每行已經非常誇張，即使如此，沒有壓縮的情況下帶寬消耗 35MBps，gzip 壓縮率一般為 0.3~0.4，佔用帶寬為 10.5~14MBps，對於千兆網卡來說壓力較小；

如何部署Golang應用

安裝supervisord

# 通過引導程序 ez_setup.py 來安裝。這個引導程序會聯網下載最新版本setuptools來安裝，同時也可以更新本地的setuptools。

wget

sudo python ez_setup.py

# 更新setuptools：

sudo python ez_setup.py -U setuptools

# 安裝supervisor

easy_install supervisor

# 生成配置文件

echo_supervisord_conf /etc/supervisord.conf

# 編輯配置文件

vim /etc/supervisord.conf

# 進入vim後找到最後兩行，打開注釋（取消前面的分號），

# [include]

# files = supervisor.d/*.ini

# 將所有的supervisor配置都放到 /etc/supervisor.d目錄

mkdir /etc/supervisor.d

創建 supervisor 對應程序的配置文件

其中的一些路徑需要換成自己對應的，這裡將 zankbo 這個web 應用放在了對應的用戶目錄下

通過在生產服務器上設置environment可以在程序里判斷是線上還是開發模式，如 zankbo 的 debug判斷

當然也可已在啟動命令處加入參數，如 command = /home/zankbo/gopath/src/zankbo/zankbo -d 來關閉Debug模式。

if os.Getenv(“APP_NAME”) == “ZANKBO_PRODUCT” {

beego.RunMode = “prod”

}

vim /etc/supervisor.d/zankbo.ini

# 寫入

[program:zankbo]

directory = /home/zankbo/gopath/src/zankbo

environment=APP_NAME=”ZANKBO_PRODUCT”

command = /home/zankbo/gopath/src/zankbo/zankbo

autostart = true

startsecs = 5

user = zankbo

redirect_stderr = true

stdout_logfile = /home/zankbo/log/zankbo.log

建立對應的用戶

useradd zankbo

# 將www用戶加入到zankbo用戶組，Nginx以www用戶運行

usermod -a -G zankbo www

# 更改用戶家目錄用戶組的權限，使Nginx可以訪問

chmod g+rx /home/zankbo

部署Go環境

其中的目錄為，go：Go安裝目錄 gopath：Go工作目錄，下面有src、pkg、bin三個目錄 log：日誌文件夾

[zankbo@MyCloudServer ~]$ pwd

/home/zankbo

[zankbo@MyCloudServer ~]$ vim .bashrc

# 設置Go環境變量，在.bashrc文件末尾寫下如下內容

export GOROOT=$HOME/go

export GOPATH=$HOME/gopath

export PATH=$PATH:$GOROOT/bin:$GOPATH/bi

# 切換到用戶家目錄

[root@MyCloudServer ~]# su – zankbo

[zankbo@MyCloudServer ~]$ ls

go gopath log

將項目代碼放到gopath/src下面，如我的播客項目:

[zankbo@MyCloudServer ~]$ tree -L 2 gopath/src/

gopath/src/

├── github.com

│ ├── astaxie

│ ├── beego

│ ├── go-sql-driver

│ ├── howeyc

│ ├── jacobsa

│ ├── smartystreets

│ └── wendal

└── zankbo

├── admin

├── blog

├── build_pkg.sh

├── common

├── conf

├── controllers

├── dbstruct.mwb

├── main.go

├── models

├── static

├── views

└── zankbo

導入項目sql文件到數據庫

在項目文件夾執行build

[zankbo@MyCloudServer zankbo]$ pwd

/home/zankbo/gopath/src/zankbo

[zankbo@MyCloudServer zankbo]$ go build

會在項目下生成與包名對應的可執行文件，這裡為:zankbo，build的時候可能會遇到錯誤，比如mysql的密碼之類的，可根據提示排錯。

通過supervisor 來啟動服務

# supervisorctl start zankbo

配置Nginx

server {

listen 80;

server_name zankbo.com ;

root /home/zankbo/gopath/src/zankbo;

error_log logs/zankbo.com.error.log warn ;

location /static/ {

root /home/zankbo/gopath/src/zankbo;

location ~ .*\.(js|css)$ {

access_log off;

expires 1d;

}

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {

gzip off;

access_log off;

expires 3d;

}

}

location / {

proxy_pass ;

}

}

網絡：什麼是 MIME TYPE?

最近在讀 Golang 的源碼，看到 mime.go 這個文件時，有點看不懂了。

MIME, Mutipurpose Internet Mail Extensions,多用途 Internet 郵箱擴展。MIME 是描述消息內容類型的 internet 標準。在創建之初，是為了在發送電子郵件時附加多媒體數據，讓郵件客戶程序根據其類型進行處理。現在 MIME TYPE 被 HTTP 協議支持後，使得HTTP能夠傳輸各種各樣的文件。

瀏覽器通過 MIME TYE,也就是該資源的媒體類型，來決定以什麼形式顯示數據。

媒體類型通常是通過 HTTP 協議，由 Web 服務器請求頭中的 Content-Type 來告知瀏覽器數據類型的，比如：

表示內容是 text/HTML 類型，也就是超文本文件。注意，必須是 “text/HTML” 而不是 “HTML/text”.因為 MIME 是經過 ietf 組織協商，以 RFC 的形式發佈在網上的。

需要注意的是： 只有一些在互聯網上獲得廣泛應用的格式才會獲得一個 MIME Type ，如果是某個客戶端自己定義的格式，一般只能以 application/x- 開頭。

Internet 中有一個專門組織來對 MIME 標準進行修訂，但是由於 Internet 發展過快，很多應用程序便使用在類別中以 x- 開頭的方法標識這個類別還沒有成為標準，例如 x-gzip,x-tar等。

其實是不是標準無關緊要，只要客戶端和服務器都能識別這個格式就可以了。在 app 端會使用自定義標準來保證數據安全。

MIME類型與文檔的後綴相關，因此服務器使用文檔的後綴來區分不同文件的 MIME 類型，服務器中必須規定文件後綴和MIME類型之間的對應關係。而客戶端從服務器上接收數據的時候，它只是從服務器接收數據流，並不了解文檔的名字，因此服務器需要使用附加信息來告訴客戶程序數據的 MIME 類型。服務器將首先發送以下兩行 MIME 標識信息，這個信息並不是真正的數據文件的一部分。

注意，第二行為一個空格，這是必須的，使用這個空行的目的是將 MIME 信息與真正的數據內容分離開。

通用結構： type/subtype

MIME 類型對大小寫不敏感，但是通常傳統寫法是小寫。

分類

對於 text 文件類型若是沒有特定的 subtype，就使用 text/plain, 類似的二進制文件如果沒有特定或已知的 subtype，就使用 application/octet-stream.

還有非MIME 類型，但是比較通用的 icon 類型，image/x-icon