監控系統之資料儲存
關於監控資料的儲存問題，是乙個典型的大資料儲存的例子，
系統設計的時候的乙個很重要的的工作的就是容量規劃
至少有如下幾點需要嚴謹的測算
1 整個系統需要面臨的流量壓力： qps ，網路流量等
2 需要儲存的資料量：每天新增的資料量，穩定的總資料量
3 最常用的查詢方式
進而需要根據測算的結果決定：
1 需要的伺服器數量，系統的資料流向
2 需要多少的儲存空間，用什麼來儲存資料
3 是否需要關係型資料庫
監控系統 流量估算：
--qps （query per second）
監控系統中主要的qps壓力來自部署在每個機器上的監控agent，假設為了保證監控報警的及時性。
我們每台機器5s向上游傳輸一次監控資料，假設公司虛擬機器1000臺那麼產生的qps大約是：
1000/5 = 200（qps）
這樣的壓力還是可以用單台伺服器承載的
--網路流量
我們假設：每個監控項占用16個bytes，一共50個監控項，我們都儲存在一行，那麼網路流量大約是
16*50*200 = 16000（bps） 約等於160（kbps） = 1.28 (mbps)
依舊是單台伺服器能夠承載的
監控系統的資料量估算
每天新增的資料量：
根據上次估算，一天下產生的資料行數為：
200*（24*3600） = 17280000 約等於 1700萬行
產生的資料量大約是：
16 * 50*17280000 = 13824000000 約等於 13gb
穩定的資料量
一般的情況下：我們比價關注的是7天之內的監控資料，更久遠的資料為們可以另外歸檔到乙個冷資料庫，而7天的資料量為
17280000 * 7 = 120 960 000 約等於1.2億行
資料量：
13 824000000 * 7 = 96768 000 000 約等於96.8g
最常用查詢方式：
監控的資料直接沒有什麼直接的關聯關係，查詢的場景往往是限定機器，監控項，時間段
一次查詢放回的資料量可能會比較大
綜合上面的估算和分析，監控資料儲存即可以使用傳統性的關係型資料庫，也可以使用key-value資料庫
key-value 資料庫能做，mysql也能做，大多數效能更好，可靠性更高。
這裡我們必須要明白，mysql的純qps效能不如redis不是由於mysql的實現或者演算法有問題。而是mysql定位是資料庫
redis定位是快取，所以mysql需要保證每條資料的更改盡可能的進行持久化，而redis沒***這一點，持久化就意味著
資料需要落在硬碟上才能給使用者返回成功。保證這一點就會造成很多損失，對於乙個資料庫來說，這些損失也是必要的
mysql通過拆庫，拆表是可以應對任意多的資料量的，但是有乙個前提就是需要提前規劃，而且很難做到客戶端透明，
但是對於我們監控資料的儲存，這完全是可以消化的。
關於網路的幾個問題
q1 請你分別划划osi的七層網路結構圖，和tcp ip的五層結構圖？1 osi每層功能及特點 a 物理層 為資料鏈路層提供物理連線，在其上序列傳送位元流，即所傳送資料的單位是位元。此外，該層中還具有確定連線裝置的電氣特性和物理特性等功能。b 資料鏈路層 負責在網路節點間的線路上通過檢測 流量控制和...
關於Time Wait的幾個問題
time wait是個常問的問題，tcp網路程式設計中最不容易理解的也是它的time wait狀態，這也說明了tcp ip四次揮手中time wait狀態的重要性。下面通過4個問題來描述它 1.time wait狀態是什麼 2.為什麼會有time wait狀態 3.哪一方會有time wait狀態 ...
關於EOF的幾個問題
1 如何輸入eof ctrl z in win or ctrl d in linux 2 阻塞式以及非阻塞式 輸入緩衝是行緩衝。當從鍵盤上輸入一串字元並按回車後，這些字元會首先被送到輸入緩衝區中儲存。每當按下回車鍵後，cin.get 就會檢測輸入緩衝區中是否有了可讀的資料。cin.get 還會對鍵盤...