在一開始接觸PHP接觸MYSQL的時候就聽不少人說:“Mysql就跑跑一天幾十萬IP的小站還可以,要是幾百萬IP就不行了”,原話不記得了,大體就是這個意思。一直也沒有好的機會去驗證這個說法,一是從沒有接手過這么大流量的網站,二是平時工作也比較忙,懶得去管這些,反正現在用不著,抱著這個想法把這個問題一直留到了最近,才把這個問題搞明白。
就在前幾天公司旗下一網站(由于這是公司的商業內容我就不說是那個網站了,免得有兄弟說是AD)以下簡稱A站,這A站在年后流量猛增從一天的七八十萬猛跑到了好幾百萬的IP,一天下來接近一千萬的Pv讓整個服務器在高壓下超負荷的工作著,時不時的服務就出現當機。
最首先反映出情況的是數據統計,一天下來一個數據也沒有統計上,原來是mysql掛了。
本文就圍繞這個問題來講講我們公司幾個技術人員的解決方案。
1. Mysql服務器集群
由于是小公司在資金和成本上都有所限制,而且在技術上也沒有幾個技術員接觸過,所以這個方法自然就讓大伙否決了。
這里說說我個人的理解!做集群不但添加資費的開銷,而且在技術上也有很大的挑戰,對于我們公司目前的情況是不大現實的。集群無非就是把一臺服務器的壓力轉接到兩臺或是多臺服務器上,我是這么理解的,也許我理解有誤,還請大家指教。
2. 分而治之
這個方法和集群差不多,不過是把統計的代碼放在不同的服務器上跑,由于公司有不少配置低的服務器跑幾萬到幾十萬IP還是沒有問題的,我們可以把幾百萬流量分成十來個幾十萬的量分而統計。
優點:充分的利用了現在的資源,解決了目前的問題。
缺點:這樣的方法不是長久之計,遲早還是會出問題的。而且在統計數據的時候比較麻煩。
3. 統計代碼的修改
由于之前采用的是在插入數據之前加以判斷,這個IP是否存在,來路等的處理,無形中增加了服務器的壓力,所以大伙把統計代碼改成來一個就插入數據庫,不管三七二十一等以后在處理。
這個方法基本上把當天的數據保留下來了,可是在處理的時候由于數據量的龐大,來來回回還是把服務器跑死了,而且在插入的時候由于當時設計數據結構的時候留有的索引,也大大的消耗了不少的服務器資源。
那么把索引去掉到最后處理的時候又是老慢的,得不償失。
4. 統計方式的修改
最后這一個方法,效果非常的明顯。那是什么方法呢!
這里就主要介紹這個方法:
A、 保留原用的數據結構不變,并把所有的數據按一定的結構存入文件。
結構:可以是xml,json,也可以是你自己想的任何有規律的數據排放。
例如:
1 221.2.70.52,http://www.baidu.com,windowxp\r\n 2 221.2.70.52,http://www.baidu.com,windowxp\r\n |
格式:
1 error_log("內容", 3, "/date.dat"); |
B、數據文件的命名
為什么這里要講文件的命名呢?如果就一味的把數據的寫入文件不作任何的處理那么他和直接插入數據庫有多大的區別呢?那么我們所作的一切都是無用功了。
首先是在時間的利用上:date(‘YmdH’)得到的值是如:2008121112這有什么好入,這樣一來這個數據就是一個小時一個文件必免了文件過大,而且不用去判斷自動生成。
IP的應用:由于在很多數據上都是一個IP操作的,所以把相同IP的數據放在一個文件里在后面的處理就非常方便處理。請看后面的介紹,這里我們取IP成三位為文件名字的一部分。
C、 數據的導入處理
通過以上兩位的操作當天的數據會一個不少的保留下來,接下來怎么處理其實并不是很重要了。但是這里還是講講我的想法。
入庫前處理:
前面講到把IP三位相同的放一個文件就是為了入庫前到它們進行處理,首先可以用最笨的方法把數據拆成N個數據。在進行重復數據的刪除。
如果一個IP瀏覽多頁那么PV在這里就可以得到統計,并把訪問的頁面進行處理,組成新的數據。
導入方法:
這里要介紹一下數據的導入方法
1 $sql="LOAD DATA INFILE '".$file."' INTO TABLE `test` FIELDS TERMINATED BY ',' LINES TERMINATED BY '\r\n'( 2 3 `time` , `md5` 4 5 )"; |
至此所以有數據也就講的差不多了。由于我肚子里的墨水太少,如有不得當之處還請大家見諒。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com