MySQL百萬級高并發網站實戰攻略_MySQL

　　就在前幾天公司旗下一網站(由于這是公司的商業內容我就不說是那個網站了)以下簡稱A站，這A站在年后流量猛增從一天的七八十萬猛跑到了好幾百萬的IP，一天下來接近一千萬的PV讓整個服務器在高壓下超負荷的工作著，時不時的服務就出現宕機。

　　最首先反映出情況的是數據統計，一天下來一個數據也沒有統計上，原來是MySQL停止工作了。

　　本文就圍繞這個問題來講講我們公司幾個技術人員的解決方案。

　　1. MySQL服務器集群

　　由于是小公司在資金和成本上都有所限制，而且在技術上也沒有幾個技術員接觸過，所以這個方法自然就讓大伙否決了。

　　這里說說我個人的理解!做集群不但添加資費的開銷，而且在技術上也有很大的挑戰，對于我們公司目前的情況是不大現實的。集群無非就是把一臺服務器的壓力轉接到兩臺或是多臺服務器上，我是這么理解的，也許我理解有誤，還請大家指教。

　　2. 分而治之

　　這個方法和集群差不多，不過是把統計的代碼放在不同的服務器上跑，由于公司有不少配置低的服務器跑幾萬到幾十萬IP還是沒有問題的，我們可以把幾百萬流量分成十來個幾十萬的量分而統計。

　　優點：充分的利用了現在的資源，解決了目前的問題。

　　缺點：這樣的方法不是長久之計，遲早還是會出問題的。而且在統計數據的時候比較麻煩。

　　3. 統計代碼的修改

　　由于之前采用的是在插入數據之前加以判斷，這個IP是否存在，來路等的處理，無形中增加了服務器的壓力，所以大伙把統計代碼改成來一個就插入數據庫，不管三七二十一等以后在處理。

　　這個方法基本上把當天的數據保留下來了，可是在處理的時候由于數據量的龐大，來來回回還是把服務器跑死了，而且在插入的時候由于當時設計數據結構的時候留有的索引，也大大的消耗了不少的服務器資源。

　　那么把索引去掉到最后處理的時候又是老慢的，得不償失。

　　4. 統計方式的修改

　　最后這一個方法，效果非常的明顯。那是什么方法呢!

　　這里就主要介紹這個方法：

　　A、 保留原用的數據結構不變，并把所有的數據按一定的結構存入文件

　　結構：可以是xml,json，也可以是你自己想的任何有規律的數據排放。

　　例如：

　　1 221.2.70.52,http://www.baidu.com,windowxprn

　　2 221.2.70.52,http://www.baidu.com,windowxprn

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com