穩定性三十六計-歷史記錄

引子

半夜三點，睡夢中被一陣沒人接聽誓不罷休的電話鈴吵醒。睡眼惺忪的接聽了電話，電話那頭傳來了不用聽清任何人類語言就能感覺的焦急。讓我趕快打開電腦，說服務整個不工做了！

打開監控看到線程池被打滿。本着「先恢復現場再排查緣由」的基本原則，重啓並擴容了一倍的服務器。服務又正常了。完美的作到了「三分鐘定位，十分鐘解決」。可是現場不在了，怎麼排查根因呢？答案是：歷史記錄。

 

爲何要作歷史記錄

歷史記錄是大數據的最重要數據源。經過歷史記錄能夠進行事件追溯、將來預判和推薦。舉個例子：

靜兒在網上搜索了「穩定性三十六計」這個詞，找到本身想要的內容了。而後去作別的事情，再打開瀏覽器的時候，發現旁邊的小彈出框裏推薦我《穩定性寶典》這本書。

這個推薦效果不少種算法都能實現，好比最近比較火的「協同過濾推薦算法(Collaborative Filtering Recommendation)」。啥是協同過濾推薦算法呢？協同過濾推薦算法簡而言之，就是找到相同興趣的羣體，將這個羣體中感興趣的其餘信息推薦給用戶。

實施的時候能夠先創建一個大表，X軸是全部的推薦內容，Y軸是全部的用戶。

而後咱們將每一個用戶感興趣的XY交叉點都標出來。如圖能夠看到對「穩定性三十六計」感興趣的對「穩定性寶典」感興趣的機率也很高。

歷史記錄對於穩定性，也能夠將其餘同類系統做爲用戶，將他們的問題做爲推薦項進行協同過濾分析，找到自身的可優化點。系統出了問題須要分析緣由時，事件追溯更是必不可少。

 

怎麼作歷史記錄

日誌

最經常使用的事件維度記錄是日誌。有存於本地磁盤和集中式日誌兩種。

本地磁盤日誌就是將日誌在程序中控制直接寫入本地磁盤。

集中式日誌的架構大同小異，基本結構以下：

• 採集器負責採集數據，併發送給收集器。
• 收集器負責收集採集器發送過來的數據，並定時寫入集羣。
• 存儲中心負責對數據分類、排序、去重，把同類型的數據合併。
• 分析和可視化平臺負責數據的展現。

如下是經常使用的數據收集系統的比較

 

產品	公司	優點	劣勢
Flume NG	Cloundera	1.支持故障轉移和負載均衡 2.容易水平擴展 3.社區活躍、文檔豐富 4.依賴第三方類庫少 5.經過事務保證數據一致性 6.支持多種存儲	1.須要本身實現客戶端代碼 2.對數據的過濾能力差
Scribe	Facebook	1.具備很高的容錯性 2.支持水平擴展	1.依賴zookeeper或Hash等工具 2.須要本身實現客戶端代碼 3.社區活躍度低、文檔少 3.依賴第三方庫多 4.部署複雜 5.存儲系統類型少 6.數據過濾解析能力差 7.官方已經中止更新和維護
Chukwa	Apache	1.高可靠 2.易擴展 3.社區活躍度較高 4.文檔資料豐富	1.依賴hadoop
ELK	Elasic.co	1.提供完整的解決方案 2.支持集羣部署和水平擴展 3.社區活躍度高、文檔豐富 4.部署簡單	1.佔用資源比較高

ELK不是一款軟件，而是Elasticsearch、Logstash和Kibana首字母的縮寫。這三者是開源軟件，一般配合一塊兒使用。並且前後歸於Elasic.co公司的名下，因此簡稱ELK Stack。根據Google Trend的信息顯示，ELK已經成爲目前最流行的集中式日誌解決方案。

 

Nosql

除了日誌，任何有價值的歷史信息都是應該存儲起來作分析的。這時候存儲就是關鍵。由於數據量大，對強一致性沒有苛刻的要求。因此從成本上傳統的關係型數據庫不是首選。通常選擇Nosql數據庫。Nosql數據庫主要有四類：

1.key-value數據庫

 

項目	說明
典型應用場景	內容緩存，主要用於處理大量數據的高訪問負載，也用於一些日誌系統
數據模型	Key指向Value的鍵值對，一般用hash table實現
強項	查找速度快
弱項	數據無結構，一般被當作字符串或者二進制數據
例子	Redis、Memcached

2.列式數據庫

項目	說明
典型應用場景	分佈式的文件系統
數據模型	以列簇式存儲，將統一列數據存在一塊兒
強項	查找速度快，可擴展性強，更容易進行分佈式擴展
弱項	功能相對侷限
例子	Cassandra、HBase

3.文檔型數據庫

項目	說明
典型應用場景	Web應用，Value是結構化的，容易被解析
數據模型	KeyValue的鍵值對，Value爲結構化數據
強項	數據結構要求不嚴格，表結構可變、不須要預先定義表結構
弱項	查詢性能不高，缺少統一的查詢語法
例子	CouchDB、MongoDB、Elasticsearch

4.圖結構數據庫

項目	說明
典型應用場景	社交網絡，推薦系統等。專一於構建關係圖譜
數據模型	圖結構
強項	利用圖結構相關算法，好比最短路徑尋址，N讀關係查找等
弱項	須要再次計算出所需信息，不容易作分佈式集羣方案
例子	Neo4j、InfoGrid、Infinite Graph

 

時序數據庫

時序數據庫全稱爲時間序列數據庫。時間序列數據庫主要用於指處理帶時間標籤的數據。帶時間標籤的數據也稱爲時間序列數據。

基於時間序列數據的特色，關係型數據庫沒法知足對時間序列數據的有效存儲與處理，所以迫切須要一種專門針對時間序列數據來作優化的數據庫系統，即時間序列數據庫。

目前行業內比較流行的開源時序數據庫產品對好比下：

 

	InfluxData	Prometheus	Graphite	OpenTSDB
數據模型	labels	labels	dot-separated	label
按時間分段管理數據	✔️	✔️	✔️	手動
分佈式	✔️商業版	單機	單機	✔️
聚合分析	弱	弱	弱	弱
權限管理	✔️商業版	×	×	×
接口	類SQL	REST	REST	REST
社區生態	+++	++	++	++
時間序列分析	無	無	無	無
抽取日誌指標	×	×	×	×
Rollup	✔️	×	✔️	×

 

總結

Talk is cheap, show me the data! 

 

推薦閱讀

• 蓋洛普Q12在團隊中的應用

• 演講稿：新人培養之道

• 自動化管理之新人培養

• 和真正的程序員在一塊兒是怎樣的體驗

• 從技術渣到被要求改行到硅谷程序媛

• 《程序員修煉之道》解讀1

• 到底多大才算高併發？

• 年紀大了，是否該往管理方向轉型？

• 《躍遷-成爲高手的技術》感悟

 

關於做者

一線開發十二年，有日本東京和美國硅谷研發經驗。有百餘項技術發明專利，目前任美團點評技術專家。有本身的技術公衆號「編程一輩子」。若是您在閱讀本書時有什麼疑問或者發現本書的錯誤，歡迎在公衆號裏給我留言。