[百分點大數據技術團隊]大規模文件存儲OSS技術與實踐

編者按
在數字政府領域，許多項目中都有各類類型的文件，它們有不一樣的大小、不一樣的用途，甚至編碼方式都會千差萬別。咱們但願經過OSS來將這些文件按照必定的規則存儲起來，在咱們須要的時候，能很快的取出來，而且應用到當前的項目中，甚至能和其餘的應用系統集成起來，造成一整套的基於OSS存儲的生態系統。百分點基於實踐探索自主研發出了OSS，能夠將海量的網頁內容、圖片、音視頻等非結構化數據，在高併發的場景下被快速、準確的存儲及方便的下載。

對象存儲服務（Object Storage Service，簡稱OSS），是百分點對外提供的海量、安全、低成本、高可靠的對象存儲服務。用戶能夠經過簡單的REST接口，進行數據的上傳和下載。同時，OSS提供Java語言的SDK，簡化用戶的編程。基於OSS，用戶能夠搭建出各類我的和企業數據備份、業務數據應用等基於大規模數據存儲的服務。同時OSS還能夠與其餘組件搭配使用，普遍應用於海量數據存儲與備份，數據加工與處理，內容加速分發，業務數據挖掘等多種業務場景。

1.架構設計

基於對OSS的要求，咱們設計的架構以下圖所示：

咱們採用了HBase+Ceph來進行底層存儲，對於小於1MB的數據進入HBase，對於大於1MB的數據進入Ceph，同時數據經過Tomcat提供對外服務。基於上面的架構，咱們的OSS能夠實現如下的性能目標。

1.1 高吞吐性

OSS的底層存儲充分利用各組件的性能優點，來使整個集羣能夠達到較高的吞吐量。

HBase（Hadoop Database），是一個高可靠性、高性能、面向列、可伸縮的分佈式存儲系統，利用HBase技術可在廉價PCServer上搭建起大規模結構化存儲集羣。對於小於1MB的文件寫入HBase是一個很棒的設計。

那麼大於1MB的文件，咱們存入哪裏呢？有這麼幾種方案可供咱們選擇，好比Hadoop，FastDFS，Ceph等組件。咱們最終選擇了Ceph作大文件存儲。

Ceph是一種爲優秀的性能、可靠性和可擴展性而設計的統一的、分佈式文件系統。Ceph的開發目標能夠簡單定義爲如下三項：

可輕鬆擴展到數PB容量

支持多種工做負載的高性能

高可靠性

1.2 高可用性

高可用性對文件存儲系統是極爲重要的，由於數據是極爲寶貴的，若是數據在OSS中很容易丟失或者不可靠，那麼它的存在乎義就不大了。

對於OSS的高可用，咱們早就作了深思熟慮的思考。HBase的數據最終存儲HDFS中，而HDFS是指被設計成適合運行在通用硬件(commodity hardware)上的分佈式文件系統（DistributedFile System）。咱們能夠經過定義它的多副本機制來達到它的高可用性。

和HBase相似，Ceph也能夠經過多副本機制來實現它的高可用性。

同時，咱們能夠定義存儲的文件的過時時間來避免存儲的文件無限增加，在咱們的應用中，默認設置爲90天。

1.3 可擴展性

當系統的吞吐量愈來愈大，或者存儲容量以及快達到OSS所能承受的流量瓶頸時，咱們能夠經過橫向擴展相關組件來應對流量的變化。

對於直接對外提供Rest接口的Tomcat服務，若是單Tomcat服務器達到性能瓶頸時，咱們能夠增長Tomcat服務器來進行橫向擴展，同時爲了對外提供統一的網關，咱們增長了LVS+Keepalived這一層來實現，以下圖所示：

正常狀況下，LVS使用DR模式代理若干臺Tomcat服務器，keepalived是實現LVS的高可用的。當其中一臺LVS出現故障下線後，keepalived經過虛擬IP技術快速切換到另一臺可用的LVS上。

另外對於HBase和Ceph的擴展性是簡單易於實現的，只須要增長待擴展的機器，進行相關配置，便可快速加入集羣，相應的數據也會進行rebalance。

1.4 限流算法

在上面的功能概覽中簡單的說明了在某些場景中咱們須要進行流量限制，那麼這裏將詳細介紹限流的原理。

在OSS中，咱們使用Guava的RateLimiter做爲限流的組件。Guava的RateLimiter的限流方式有兩種：漏桶算法和令牌桶算法。咱們採用的是令牌桶算法。

對於不少應用場景來講，除了要求可以限制數據的平均傳輸速率外，還要求容許某種程度的突發傳輸。這時候漏桶算法可能就不合適了，令牌桶算法更爲適合。如圖所示，令牌桶算法的原理是系統會以一個恆定的速度往桶裏放入令牌，而若是請求須要被處理，則須要先從桶裏獲取一個令牌，當桶裏沒有令牌可取時，則拒絕服務。

咱們的OSS就是採用令牌桶的方式來對流量進行限制的，當客戶端以某一穩定的速率來向OSS寫入的時候，系統是穩定的而且大多數的時候是這樣的。可是咱們有時須要應對流量峯值，這個時候超過咱們規定的流量就會被限制。如今問題來了，被限制的流量若是直接丟棄，那麼可能重要的文件被丟棄，這樣顯然不符合咱們對OSS定位爲高可用存儲系統的要求。因而在限流的邏輯中咱們加入瞭如下處理流程：當流量達到系統的瓶頸時，咱們將被限流的流量寫入kafka，等到系統負載下降的時候，再從kafka中讀取這部分流量重放至OSS,這樣既保證了OSS的穩定性，又解決因限流帶來的數據丟失問題。

2.功能概覽

2.1 文件上傳

客戶端以RESTFul接口方式向OSS服務器發送上傳文件的請求，OSS將文件存儲到HBase或Ceph中，而後向客戶端返回存儲的狀態。

咱們將文件名做爲存儲的惟一標識，這樣設計的好處有兩點，第一，咱們不須要返回用戶文件在OSS服務器的存儲路徑；第二，也能夠避免同名文件反覆上傳。

2.2 文件下載

客戶端以RESTFul接口方式帶上須要查詢的文件名請求OSS服務器，OSS根據文件名查詢對應的文件，返回請求客戶端。

2.3 流量限制

流量限制是以一種被動的方式來對流量進行控制的方式。咱們能夠經過壓力測試來粗略估計OSS所能承受的最大壓力，而後在配置文件中配置限流的數值。這裏要注意的是，須要根據業務的特色對限制的流量進行處理，其一，能夠徹底丟棄掉被限制的流量；其二，也能夠對限制的流量進行相應的處理。

3.場景分析

現以公司某項目作講解來進一步說明OSS在項目中的實際應用以及最佳實踐。

3.1 項目的現狀

3.1.1 流量狀況

以中期某城市交付爲基準：每秒約120Gb流量，天天1.5億個文件，每秒大概1800個文件。

其它各分中心的數據均爲上述城市的倍數，好比A中心的比例係數爲33.33，那麼它每秒的流量約4000Gb，天天約34億個文件，每秒大概6萬個文件，以此類推。

3.1.2 單機性能

目前單機Tomcat能支撐最大12000TPS，對於各中心每秒的數據量，單機顯然不能支撐這麼大的數據量，咱們須要採用Tomcat集羣來支撐這麼大的數據流量。

3.1.3 流量峯值

在進行機器數以及相關硬件進行評估時，須要考慮流量峯值的狀況，咱們通常以正常流量的2到3倍來進行規劃，好比，某個分中心的流量爲每秒1300Gb，那麼咱們設計時就須要考慮峯值的狀況，也就是最大能支撐每秒3900的流量。

3.2 集羣的設計目標

基於上面描述的項目現狀，通過分析，咱們的整個OSS集羣須要實現如下設計目標：

各中心採用Tomcat集羣來支撐數據流量

各中心的流量均衡打到每臺Tomcat服務器

負載均衡設備的高可用

存儲服務的穩定性

3.3 最佳實踐

3.3.1 如何保證Tomcat單機的性能最優

咱們主要從如下幾個方面來優化Tomcat的性能：

1）JVM內存大小

2）最大線程數（maxThreads）

3）最大鏈接數（maxConnections）

4）全鏈接隊列長度（acceptCount）

咱們選用單臺機器來測試Tomcat的性能，硬件配置以下：

Tomcat的版本選用8.5.43。

測試的目標：

單臺Tomcat支持的最大併發數

單臺Tomcat支持的最大TPS

NIO模型和APR模型的性能對比

測試工具使用：ApacheBench。

咱們使用對比測試的方法，分別測試在上傳1KB，10KB，100KB，1M，10M，100M的時候，Tomcat各項指標的數值。

Tomcat配置：maxThreads=100，minSpareThreads=10，acceptCount=102400，maxConnections=1000000，acceptorThreadCount=2
JVM配置：-Xmx16384m -Xms16384m
-Xmn1024m -XX:+UseConcMarkSweepGC
-XX:MaxPermSize=256m
一、使用NIO模型的測試結果以下：

根據以上測試結果可得出如下結論：

1）在上傳相同文件大小的狀況下，隨着併發數的增大，會出現必定的丟包狀況；

2）在相同併發量的狀況下，隨着上傳文件大小增大，吞吐量會隨之降低。

二、使用APR模型的測試結果以下：

根據以上測試結果以及對比NIO模型的測試結果，咱們能夠得出如下結論：

1）小文件上傳APR模式不如NIO模式，大文件上傳APR模式要好於NIO模式；

2）隨着併發的增長，TPS先增長後減小，平均響應時間不斷增長；

3）小文件應該關注TPS，大文件應該關注平均響應時間；

4）小文件TPS大概在2萬到3萬之間，能接受的併發在300到500之間。

3.3.2 如何保證HBase存儲的穩定性

HBase以高吞吐著稱，那麼咱們應該如何在保證高吞吐的狀況下，能保證穩定的存儲。主要應該關注兩個點：

1）GC的次數以及停頓時間；

2）HBase的compaction機制。

3.3.2.1 GC調優

因爲HBase是使用Java編寫的，因此垃圾收集（GC）對HBase的影響也是很大的，咱們須要適當調整GC相關的參數，使得HBase能達到較好的性能和穩定的運行。在JVM中，有不少種垃圾收集器，咱們在項目中使用的是CMS GC，下面首先介紹CMS GC的工做原理，再詳細說明調優的相關細節。

3.3.2.2 GC調優目標

在介紹具體的調優技巧以前，有必要先來看看GC調優的最終目標和基本原則：

1）平均Minor GC時間儘量短；

2）CMS GC次數越少越好。

3.3.2.3 HBase 場景內存分析

通常來說，每種應用都會有本身的內存對象特性，分類來講無非就兩種：一種是對象的生存期較短的工程，好比大多數的HTTP請求處理工程，這類的對象可能佔到全部對象的70%左右；另外一種是對象生存期居多的工程，好比相似於HBase，Flink等這類大內存工程。這裏以HBase爲例，來看看具體的內存對象：

1）RPC請求對象

2）Memstore對象

3）BlockCache對象

所以能夠看到，HBase系統屬於對象生存期居多的工程，由於GC的時候只須要將RPC這類對象生存期較短的Young區淘汰掉就能夠達到最好的GC效果。

在HBase優化中比較關鍵的兩個GC的參數。

1）年輕代Young區的大小；

2）年輕代Young區中的Survivor區的大小以及進入老年代的閾值。

3.3.2.4 生產環境中的GC配置

假設咱們機器的物理內存是80G，因此根據上面的分析，咱們能夠對相關的參數作以下配置：

1）緩存模式採用BucketCache策略Offheap模式

2）內存咱們採用以下配置：

-Xmx64g -Xms64g -Xmn4g -Xss256k
-XX:MaxPermSize=512m
-XX:SurvivorRatio=2
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled
-XX:MaxTenuringThreshold=15
-XX:+UseCMSCompactAtFullCollection
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75
-XX:-DisableExplicitGC
3.3.3 如何保證大流量狀況下系統穩定運行

流量限制是以一種被動的方式來對流量進行控制的方式。咱們能夠經過壓力測試來粗略估計OSS所能承受的最大壓力，而後在配置文件中配置限流的數值。這裏要注意的是，須要根據業務的特色對限制的流量進行處理，其一，能夠徹底丟棄掉被限制的流量；其二，也能夠對限制的流量進行相應的處理。

4.OSS監控

OSS在運行過程當中，咱們須要瞭解相關的監控信息，好比每種文件類型在一段時間的佔比，或者在一段時間的網絡吞吐量等等，下面就來一一介紹咱們是如何來對OSS進行監控的吧。

4.1 以文件類型劃分的指定時間段內的總存儲佔比

該圖表用於統計當前OSS中各文件類型存儲的佔比。

4.2 以文件類型劃分的指定時間段內的文件數量佔比

該圖表用於統計當前OSS中各文件類型數量的佔比。

4.3 OSS服務指定時間段內的網絡吞吐量

該圖表用於統計OSS的吞吐量。

4.4 OSS服務指定時間段內的每秒併發處理數（TPS）

該圖表用於統計當前OSS的負載狀況。

5.結語與展望

咱們認爲，OSS必定會成爲一個集安全性、可靠性於一體的底層存儲服務。基於OSS，在公安領域能夠存儲天網中的卡口和視頻數據，並與公安內部的其餘應用造成一個基於高可用存儲、多方向應用的解決方案；在社會治理方面，能夠存儲網絡上的各類類型的數據，包括文字、音頻以及視頻，經過使用人工智能分析其中的關聯性，爲社會提供更安全的保證。