專案成長記（四）—— 小型架構優化
自從上次搭建完小型架構以後，還是比較穩定的，但有一個讓人擔心的煩惱，那就是機器的負載都很高，基本上都是百分之七八十的佔用，不管是CPU還是記憶體，所以決定進行一次大規模的優化，決定優化完後在把成績告訴老大，眼瞅著過年了，到時候沒準多發點獎金啊，一想到獎金就來精神了，立馬行動。
重新設計架構圖如下：
主要的優化點：
1、在負載均衡伺服器上加上了web快取
2、在php伺服器上加上了zendopcache（這個在專案成長記（二）中已經講過了，這裡就省略了）
3、mysql配置優化（針對叢集）
4、利用現有的機器組成一個Memcached叢集（也就是說這個Memcached機器不是機器）
下面就具體說一下升級點：
一、web快取
#Nginx主要通過proxy_cache模組來實現快取
worker_processes 8; #CPU多少核就寫多少，利用cpu多核的優勢
error_log logs/error.log warn; #隨時記錄錯誤
pid logs/nginx.pid;
worker_rlimit_nofile 51200;
events {
use epoll;
worker_connections 51200; #允許更多的請求量
}
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local]'
' "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
sendfile on;
tcp_nopush on;
tcp_nodelay on;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
client_max_body_size 8m;
#關閉header頭顯示Nginx的版本號
server_tokens off;
keepalive_timeout 60;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 256k;
fastcgi_buffers 2 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml text/javascript;
gzip_vary on;
upstream p2pwd {
server 192.168.1.99 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.1.115 weight=1 max_fails=2 fail_timeout=30s;
}
#proxy_temp_path和proxy_cache_path必須是在一個分割槽,proxy_temp用於儲存臨時檔案
proxy_temp_path /data/soft/cache/proxy_temp_path;
#levels用於設定目錄結構（第一層是一個字元，第二層是2個字元，最多可以設定3層），
#keys_zone設定名稱和熱點內容存放的記憶體大小（Nginx會把熱點鍵和資料資訊放到記憶體中），
#inactive是多長時間沒有訪問就刪掉，max_size是硬碟快取的大小
proxy_cache_path /data/soft/cache/proxy_cache_path levels=1:2
keys_zone=p2pwd:200m inactive=1d max_size=30g;
server {
listen 80;
server_name a.bcd.com;
root /data/www/domain;
index index.html index.php;
access_log logs/a.access.log main;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
location ~ .*\.(gif|jpg|png|swf|bmp|jpeg|js|css)$ {
proxy_cache p2pwd;
#設定狀態碼對應的快取時間
proxy_cache_valid 200 304 12h;
proxy_cache_valid any 1m;
#設定快取鍵
proxy_cache_key $host$uri$is_args$args;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://p2pwd;
}
}
}當然這裡沒有刪除快取的功能，這個需要nginx編譯一個第三方模組叫ngx_cache_purge,可以參考修改，這裡還有一個快取方式fastcgi_cache模組，他和proxy_cache基本一樣，只是他負責快取動態的內容，比如php生成的內容。
二、opcache和Memcached在前面的章節已經說過，這裡不在贅述，但是需要說的一點是Memcached本身就支援分散式，可以通過程式語言實現分散式，比如php可以通過Memcached::addServers ( array$servers )新增多個伺服器，就算有一臺掛了也不怕。還有一個地方就是php.ini檔案裡，有一個expose_php On配置，為了安全把這個On改成Off可以隱藏header頭裡顯示PHP資訊。
三、MySQL優化
#mysql5.5以後innodb優化的已經很好了，完全可以代替MyISAM了，所以下面主要針對Innodb引擎 [mysqld] basedir = /data/soft/mysql datadir = /data/soft/mysql/data port = 3306 server_id = 1 socket = /tmp/mysqld.sock default_storage_engine = InnoDB log-bin = binlog expire_logs_days = 14 max_binlog_size = 5G binlog_cache_size = 10M max_binlog_cache_size = 20M slow_query_log long_query_time = 1 slow_query_log_file = /data/soft/mysql/data/slow.log open_files_limit = 65535 innodb = FORCE #innoDB控制日誌重新整理頻度，1是預設值，對於寫入頻率大並且對資料安全性沒有那麼苛刻，可以考慮設定成2，可以大幅度提高寫入效能 innodb_flush_log_at_trx_commit = 1 innodb_buffer_pool_size = 5G innodb_log_file_size = 1G innodb_file_per_table = 1 innodb_flush_method = 0_DIRECT #query_cache_size設定0的原因就是我這裡寫入的要求比較多，快取的話反而效能降低 query_cache_type = 0 query_cache_size = 0 thread_cache_size = 64 table_definition_cache = 512 table_open_cache = 512 #設定連線最大數，可以設定大一點，但是不宜太大，可以避免造成瓶頸 max_connections = 2000 sort_buffer_size = 10M #一次請求 max_allowed_packet = 6M #sql_mode設定用於設定很多安全方面的東西，具體可以百度一下 sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
上面只是覺得應該設定的地方，具體應該設定多少，還是應該根據實際環境，通過基準測試來確認。
好了，就優化這些吧，現在速度已經明顯上來了，這下老大應該滿意了，趕緊去跟老大彙報情況：“老大，咱們都系統已經很穩定了，不出意外應該沒問題”，老大立馬回了一句：“意外是什麼？”，“我靠，嘴賤”，心裡暗罵，“那就是機器掛了，機房完蛋了，地球毀滅了”，我半開玩笑的說，這個時候老闆來了，聽到我剛說的話，接著說：”那怎麼行，機器掛了，機房掛了就出問題，那我豈不是得天天燒香給機器還有機房，咱們做的可是跟錢打交道的，只要有人或者我就要服務一直在，我給你們提供足夠的資金，把服務給我搞的天衣無縫！！“，老闆說完，我不知道是該哭還是該笑，這時候說給錢了，早幹嘛去了，唉~~，看來要專案要真正的成長起來真不容易，看來我又要繼續”苦逼了“。
欲知後事如何，請聽下回分解……
轉載於:https://blog.51cto.com/weijingwu/1348760