最近公司要求對公共平臺的接口，進行監控。對於用戶敏感信息、用戶登錄信息，以及用戶其他的附屬信息的訪問，做實時統計，例如敏感信息，按每小時統計訪問了多少用戶的敏感信息；ip訪問敏感信息量TopN排行等。
數據來源於項目打印的debug日誌，這些日誌是由核心框架打印的標準日誌，其中大概包含了原始ip，當前用戶id與類型，訪問接口的客戶端，訪問時間，接口入參等信息。
日誌採用flume收集，並放入kafka中。
我們的系統接入kafka，消息日誌數據。
剛開始定方案時，是將kafka中的數據直接放入MySQL數據庫中，由於日誌量大，對不同業務日誌，做不同的分表處理，有的按天分表，有的按小時分表。
當系統上線時，數據庫的寫瓶頸就表現出來了。由於數據庫是單點的，因此所有的寫壓力都集中在一個點上。首先暴露的問題是表鎖。即日誌消費線程在寫數據的同時，統計線程還做了一些校正數據的事情，這導致在相同表上的競爭。我們的解決方案是，把需要校正的這些數據，單拎出來放到另一個表中，這樣，就只有日誌消費線程在插入數據庫。
之後又遇到問題，有個業務日誌量特別大（正常非高峯期，每小時數據量在1.4G/18,000,000），由於數據量特別大，導致寫線程相對於日誌有較大的延遲，而且越拉越大。通過檢查發現，寫入數據庫速度跟不上，我們首先嚐試，先停止統計線程去查數據，只寫，但速度還是不行。接着，我們把該表的唯一一個索引去掉，結果速度馬上就上來了，由於沒有了索引，就得全表查，因此分表不能再是一天一張表，改爲一小時一張表。
數據庫寫性能上來以後，有一個更大的問題出現了，數據庫所在的服務器，硬件能支持的IOPS大概爲500ps左右，而我們大概的峯值竟然達到15k，大大超出了硬盤的吞吐，直接導致MySQL卡死宕機（具體是硬件的限制還是MySQL自身原因導致服務宕機未知）。MySQL卡死不僅僅因爲寫的量太大，還在於對這麼大的表進行復雜的sum、count、group查詢導致的鎖表和內存開銷。我們的數據庫是主從複製的，那爲什麼統計是在主庫而沒有去從庫呢？因爲這樣大批量數據的寫入，從庫的同步延時將變得非常大，我們當時看的延時是一天，這主要是因爲主庫的插入是多線程並行的，而從庫是根據主庫的日誌，串行進行的。
總之，由於MySQL在分佈式方面的弱點，導致它不合適於做大批量數據插入的場景。