騰訊微博廣告平臺--監控系統的開發與總結

    從13年7月份開始，就一直呆在微博部門進行效果廣告的後臺配套系統的開發，很榮幸，做爲一位實習生，能真正的參與到項目中去，仍是頗有收穫的，有必要把這幾個月本身所作的事稍微總結一下，理清一下思路。

可能有些東西涉及到公司隱私，因此我不會詳細的去描述。此隨筆僅供各位看官學習交流之用，請勿轉載，請勿用於其它目的，如引發糾紛，請本身負責。

    言歸正傳，我剛到部門的時候，微博正在進行商業化，剛經歷了幾個月的封閉開發，廣告平臺已經大致成型，可是缺乏一些對廣告效果的監控。個人工做主要是負責這個。  

    技術上，其實說白了，就是對數據庫的增刪改查（並且通常只涉及到查）。那這麼說，就更加簡單了，查數據庫——整理數據——前臺顯示。是的主體就是這麼三步。其實就是通俗意義上的信息系統。

   接下來，說說咱們剛開始碰到的問題，隨着系統的開發，查詢條件愈來愈複雜，須要顯示的數據也愈來愈多，產品和運維的人但願全面詳細的瞭解整個平臺每小時，天天，每月的各個終端等等詳細狀況，還須要瞭解某些個訂單，廣告主的實時廣告消耗狀況等等。伴隨着系統功能的不斷增長，某些查詢也愈來愈耗時了，並且當你有不少的查詢語句，並且查詢時間愈來愈長，會對線上的系統的穩定性產生影響，固然能夠有從庫，加索引等等優化查詢語句的辦法，在必定程度上能夠提升數據庫響應時間，可是終究不是一個長久之計。

  另外一方面，剛開始設計數據庫的時候，咱們儘可能知足第三範式，考慮節約內存，節約數據傳輸大小，實時響應等等各方面，可是碰到查詢的時候，就會帶來一些問題，有時候爲了查詢一個廣告主的全部訂單，你可能要經過先查詢廣告主的全部計劃，而後從計劃表中獲取全部的訂單，而後再去訂單表中查詢具體的訂單信息，這種查詢語句，想必你們看起來都會嫌惡心的，固然能夠用join，可是合適麼，我是不太看好這種方式的，尤爲是還涉及到數據庫的量，速度，各類事務等等。固然是我的習慣問題，我比較喜歡乾乾淨淨的sql語句，不崇尚特別複雜的SQL語句，也不崇尚特別複雜的代碼，好的代碼必然是很是清晰的，僅僅是我的理解。

   從上面兩方面，本來是一個爲了查詢的「附贈」系統，卻要開始改變整個廣告系統主體了，固然這也是很是有必要的，起碼組長也是很是認同的，那說說咱們具體是怎麼改變上面這些矛盾的，上面的那些個矛盾可能也不全。

    1. 修改部分原有的數據庫表，多增長一些冗餘字段，我只是查的功能，那這就須要增「刪」修這三方面都作一些改變。並且從這個項目中也能夠體會到，數據庫表的設計，第三範式不必定是最好的，有時候作一些冗餘，會帶來不少的方便。

    2. 針對產品，運維等相關人員提出的各類數據要求，新增一個數據庫，專門作統計需求，將計費，廣告等信息經過php腳本，同步到新的統計庫中，並在統計庫原始表的基礎上，增長各類腳本，作統計，造成各個統計表。凡是作過數據統計的人應該都知道，開發人員最討厭的就是統計數據，由於這個數據的東西，它是不容許有錯誤的，數據哪怕有一點不對，就得查問題。

    3 在新建了統計庫的基礎上，咱們有不少的腳本在週期性的作着統計工做，這裏得保證各個腳本正常的運行，數據的正確，當前系統定時運行的腳本可能已經有20多個了。能夠理解爲從兩個源頭流出的數據通過一個個管道到達了一個個表，並且從某一方面來講，監控系統，也必須帶有一些監測的功能，而最好的反應系統運行狀況，就是各類數據，一旦數據出了什麼問題，咱們可否立刻查到問題的所在。這裏引出了，咱們是如何解決這些的。首先，說一些常識性的東西，隨着腳本的增多，腳本的命名，各個腳本的分類，放在各自的文件夾當中，各個腳本運行都須要在一些關鍵的點上打日誌，腳本運行其實涉及到兩種，正常運行和數據恢復，每一個系統或多或少會有一些bug，我這邊的數據算是最底層的數據了，一旦個人前面有一些異常，就直接影響到了我這邊的數據，因此有些時候，就會涉及到數據恢復，那伴隨着腳本的增多，像這種從源頭數據就已經有問題，我就須要運行N個腳本，並且是有必定的順序，來恢復數據，這裏就須要在編寫每一個腳本的時候，考慮是否是還須要再編寫一個錯誤數據恢復的腳本，這樣腳本的量一會兒有翻倍了，固然有些腳本，沒辦法，就得用兩個腳本，可是有的腳本，實際上是能夠用一個腳原本實現的，只須要輸入一些參數控制好了。另外，又新增了一個腳本控制中心，這個root型的腳本就是用來控制和運行全部的腳本的，若是咱們要數據恢復，只須要運行這個腳本，輸入相應的控制參數，好了，它會本身去恢復的，而後咱們再校對一下數據就ok了。

    4 腳本的監控，數據的監控是不可避免的，這裏實際上是兩個需求，一個是腳本是不是正常運行了，另外一個方面是數據是否符合預期。腳本的是否正常運行，只須要讀取待同步的表和同步的表，看看數據是否一致就能夠了。可是若是要對每一個表都作這樣的操做，就顯得有點多餘了，並且在能省查詢語句就省的原則上，我是採用了從原始表，到末端表數據進行一致性判斷，若是一致，那就代表這一條數據流上，腳本運行正確，數據沒有問題，如若否則，它會告警，而後我就會去查各個腳本運行的log，固然新部署一個腳本，確定會多作一些一致性判斷，到後來基本穩定以後，就不必了。經過這種方面，能最少的查詢，判斷數據是否有問題。另外，咱們採用了兩個數據來源，兩個數據來源數據通常狀況下不會出現太大的偏差，其實一個數據來源是計費數據，另外一個是日誌數據，計費數據只須要關注扣的錢（固然確定不只僅只有這個）就好了，日誌數據就會含有一些其餘的詳細信息，那咱們就會將這兩個數據來源的數據進行比較（至關於對原始數據的比較），偏差過大就開始告警，告警這一模塊，就利用一些微信，郵箱接口等等。

    5. 經過以上的幾部，如今基本上造成了一個閉環，重新業務上線，產生數據，數據分析，數據監控等等。並且對於咱們查找問題也給出了很大的參考性，舉個例子，若是發現數據異常了，而我這邊沒有收到腳本同步之間的告警，那麼能夠直接跳過我這邊的檢查，在根據兩個數據來源的比較，和往期數據的比較，發現日誌上數據不對，查找是誰新上了東西麼？作了哪些修改，哪些數據不正常，而不是像無頭蒼蠅同樣從頭開始查問題，能夠很快發現問題，很快定位問題。經過上面的腳本跑統計數據，也知足了產品各項查詢數據要求，擴展性還能夠，固然確定還會有更好的作法，可是目前這是個不錯的設計。

      差很少從宏觀角度來說的就這些了，若是涉及到技術，倒反沒有什麼了，都是mysql+php+js+html,也沒有涉及到很複雜的算法，很高深的技術，能解決問題的不必定是高深的技術，並且針對不一樣問題的不一樣思路。