背景
日志，角色不同，出發點和認識的角度也不同
RD使用日志，首先是為了調試程序，當程序上線后，日志是為了記錄err和trace。
PM可以通過日志分析，可以得出業務指標相關的統計情況。
日志的作用大致有三：異常、trace、統計。
日志使用的痛點
使用日志時大部分的場景或特點如下：
1.日志為純文本，即可讀。
2.日志分散在各個機器上，或者同步到某一台機器。
3.某某發現一個問題，讓某某去查log。
這里有幾個問題，或者說提高點
1.文本冗余度太大，浪費資源，如果轉換為二進制，預估有5倍的收益。
2.日志分散，查找效率低，即使集中，在沒有具體時間點情況下，掃描日志會很慢。
3.日志分析難度大，誰寫的日志誰來查，查到和肉眼找到還差一步...
目標
所以，我們可以設計這樣一個日志系統
1.支持海量數據的日志存儲（TB二進制）
2.日志二進制、結構化
3.查詢速度快，難度低
設計
讀寫日志
日志查詢過程經分解和總結共性后，幾乎是下邊三種情況
1.K-V查詢，比如基於某個消息ID，查詢一條記錄。
2.集合查詢，比如查詢某個用戶的消息記錄。
3.集合range查詢，比如查詢某個用戶0點到1點消息記錄。
那么，ssdb是非常適合這三個需求的。
日志系統具有寫多讀少的特定，再基於磁盤存儲的業界主流方案，LSM是適合的，
而SSDB的存儲依賴的leveldb正好屬於LSM系。
日志二進制
一個大的日志是沒辦法人用肉眼掃描的，所以不如使用二進制代替以節約空間，但是日志
會隨着需求的變化，格式也可能會變化，所以必須考慮二進制向文本反序列化時的
兼容性問題，那么protobuf是非常適合這個需求的。
海量日志
Sharding
業務的sharding，一個業務對應N個存儲服務，N個業務對應N*N個存儲服務，單一存儲服務內只
承載一個業務。
磁盤的sharding，一塊盤對應N個存儲服務，N塊磁盤對應N*N個存儲服務。
0 1 2 3 4
db |_____|_____|_____|_____|
0 1t 4t
disk |_______|_______________|
Resharding
擴容時增加存儲服務即可。
縮絨時刪除存儲服務即可。
Failover
存儲服務掛了后重啟就可以。
由於存儲的是日志，在機器發生故障后是允許丟的，所以數據不做遷移，只需將相應的服務等比例
遷走即可。