qileilove

CentOS7網(wǎng)絡(luò)配置和服務(wù)管理

posted @ 2014-09-09 10:19 順其自然EVO 閱讀(13480) | 評論 (1) | 編輯 收藏

成立第三方軟件測試公司的時候尚未成熟

posted @ 2014-09-09 10:18 順其自然EVO 閱讀(169) | 評論 (0) | 編輯 收藏

現(xiàn)有項目風(fēng)險管理的缺陷分析

posted @ 2014-09-09 10:15 順其自然EVO 閱讀(203) | 評論 (0) | 編輯 收藏

滲透測試之我見

posted @ 2014-09-09 10:11 順其自然EVO 閱讀(238) | 評論 (1) | 編輯 收藏

談?wù)劸W(wǎng)站測試中的AB測試方法

posted @ 2014-09-09 10:05 順其自然EVO 閱讀(171) | 評論 (0) | 編輯 收藏

高性能Web服務(wù)器Nginx的配置與部署研究（15）Upstream負(fù)載均衡模塊

轉(zhuǎn)載請注明來自“柳大的CSDN博客”：http://blog.csdn.net/poechant

更多文章請瀏覽CSDN專欄《Nginx高性能Web服務(wù)器》或服務(wù)器后端開發(fā)系列——《實戰(zhàn)Nginx高性能Web服務(wù)器》

Nginx 的 HttpUpstreamModule 提供對后端（backend）服務(wù)器的簡單負(fù)載均衡。一個最簡單的 upstream 寫法如下：

upstream backend {

server backend1.example.com;

server backend2.example.com;

server.backend3.example.com;

}

server {

location / {

proxy_pass http://backend;

}

}

1、后端服務(wù)器

通過 upstream 可以設(shè)定后端服務(wù)器，指定的方式可以是IP 地址與端口、域名、UNIX 套接字（socket）。其中如果域名可以被解析為多個地址，則這些地址都作為 backend。下面舉例說明：

upstream backend {

server blog.csdn.net/poechant;

server 145.223.156.89:8090;

server unix:/tmp/backend3;

}

第一個 backend 是用域名指定的。第二個 backend 是用 IP 和端口號指定的。第三個 backend 是用 UNIX 套接字指定的。

2、負(fù)載均衡策略

Nginx 提供輪詢（round robin）、用戶 IP 哈希（client IP）和指定權(quán)重 3 種方式。

默認(rèn)情況下，Nginx 會為你提供輪詢作為負(fù)載均衡策略。但是這并不一定能夠讓你滿意。比如，某一時段內(nèi)的一連串訪問都是由同一個用戶 Michael 發(fā)起的，那么第一次 Michael 的請求可能是 backend2，而下一次是 backend3，然后是 backend1、backend2、backend3……在大多數(shù)應(yīng)用場景中，這樣并不高效。當(dāng)然，也正因如此，Nginx 為你提供了一個按照 Michael、Jason、David 等等這些亂七八糟的用戶的 IP 來 hash 的方式，這樣每個 client 的訪問請求都會被甩給同一個后端服務(wù)器。（另外，由于最近發(fā)現(xiàn)很多網(wǎng)站以不留原文鏈接的方式盜取本博博文，所以我就在這插一下本博的地址“http://blog.csdn.net/poechant”）具體的使用方式如下：

upstream backend {

ip_hash;

server backend1.example.com;

server backend2.example.com;

server.backend3.example.com;

}

這種策略中，用于進(jìn)行hash 運算的 key，是 client 的 C 類 IP 地址（C 類 IP 地址就是范圍在 192.0.0.0 到 223.255.255.255 之間，前三段號碼表示子網(wǎng)，第四段號碼為本地主機(jī)的 IP 地址類別）。這樣的方式保證一個 client 每次請求都將到達(dá)同一個 backend。當(dāng)然，如果所 hash 到的 backend 當(dāng)前不可用，則請求會被轉(zhuǎn)移到其他 backend。

再介紹一個和 ip_hash 配合使用的關(guān)鍵字：down。當(dāng)某個一個 server 暫時性的宕機(jī)（down）時，你可以使用“down”來標(biāo)示出來，并且這樣被標(biāo)示的 server 就不會接受請求去處理。具體如下：

upstream backend {

server blog.csdn.net/poechant down;

server 145.223.156.89:8090;

server unix:/tmp/backend3;

}

還可以使用指定權(quán)重（weight）的方式，如下：

upstream backend {

server backend1.example.com;

server 123.321.123.321:456 weight=4;

}

默認(rèn)情況下 weight 為 1，對于上面的例子，第一個 server 的權(quán)重取默認(rèn)值 1，第二個是 4，所以相當(dāng)于第一個 server 接收 20% 的請求，第二接收 80% 的。要注意的是weight 與 ip_hash 是不能同時使用的，原因很簡單，他們是不同且彼此沖突的策略。

3、重試策略

可以為每個 backend 指定最大的重試次數(shù)，和重試時間間隔。所使用的關(guān)鍵字是 max_fails 和 fail_timeout。如下所示：

upstream backend {

server backend1.example.com weight=5;

server 54.244.56.3:8081 max_fails=3fail_timeout=30s;

}

在上例中，最大失敗次數(shù)為 3，也就是最多進(jìn)行 3 次嘗試，且超時時間為 30秒。max_fails 的默認(rèn)值為 1，fail_timeout 的默認(rèn)值是 10s。傳輸失敗的情形，由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 響應(yīng)時間。

有一種情況需要注意，就是 upstream 中只有一個 server 時，max_fails 和 fail_timeout 參數(shù)可能不會起作用。導(dǎo)致的問題就是 nginx 只會嘗試一次 upstream 請求，如果失敗這個請求就被拋棄了 : (……解決的方法，比較取巧，就是在 upstream 中將你這個可憐的唯一 server 多寫幾次，如下：

upstream backend {

server backend.example.com max_fails fail_timeout=30s;

server backend.example.com max_fails fail_timeout=30s;

server backend.example.com max_fails fail_timeout=30s;

}

4、備機(jī)策略

從 Nginx 的 0.6.7 版本開始，可以使用“backup”關(guān)鍵字。當(dāng)所有的非備機(jī)（non-backup）都宕機(jī)（down）或者繁忙（busy）的時候，就只使用由 backup 標(biāo)注的備機(jī)。必須要注意的是，backup 不能和 ip_hash 關(guān)鍵字一起使用。舉例如下：

upstream backend {

server backend1.example.com;

server backend2.example.com backup;

server backend3.example.com;

}

轉(zhuǎn)載請注明來自“柳大的CSDN博客”：http://blog.csdn.net/poechant

更多文章請瀏覽CSDN專欄《Nginx高性能Web服務(wù)器》或服務(wù)器后端開發(fā)系列——《實戰(zhàn)Nginx高性能Web服務(wù)器》

posted @ 2014-09-09 09:31 順其自然EVO 閱讀(170) | 評論 (0) | 編輯 收藏

Cacti監(jiān)控Redis實現(xiàn)過程

　　>>>

　3，然后下載redis的模板

　　wget http://mysql-cacti-templates.googlecode.com/files/better-cacti-templates-1.1.8.tar.gz

　　配置監(jiān)控腳本

　　mongodb或redis的監(jiān)控所需到的是你下載目錄中的better-cacti-templates-1.1.8\scripts下的

　　ss_get_by_ssh.php 這個腳本 這個腳本需要放在cacti的服務(wù)端。

　　如果你cacti是裝到/var/www/html/cacti/目錄下。

　　把該文件放在其下面的scripts目錄下。別忘了看下權(quán)限。要有執(zhí)行權(quán)限。

　　然后修改該文件。主要修改一下選項，大概在40行。

　　# ============================================================================

　　$ssh_user   = 'root';                          # SSH username

　　$ssh_port   = 22;                               # SSH port

　　$ssh_iden   = '-i /root/.ssh/id_rsa';   # SSH identity

　　##修改根據(jù)你的配置，你的ssh連接用戶，還有認(rèn)證私鑰的位置。

　　大該在50行，還可以修改其默認(rèn)的去探測的端口（如果redis不是正常默認(rèn)端口啟動需要修改這些）。

　　$redis_port    = 6379;                    # Which port redis listens on

　　4，導(dǎo)入模板，模板目錄為better-cacti-templates-1.1.8\templates

　　在cacti界面導(dǎo)入界面，創(chuàng)建redis服務(wù)器的Graph，如下所示：

　　5，去查看Graph效果圖，如下所示：

posted @ 2014-09-05 11:00 順其自然EVO 閱讀(861) | 評論 (0) | 編輯 收藏

數(shù)據(jù)庫系統(tǒng)load飆高問題解決思路

posted @ 2014-09-05 10:59 順其自然EVO 閱讀(1818) | 評論 (0) | 編輯 收藏

BigInteger在Java8中的改進(jìn)

posted @ 2014-09-05 10:53 順其自然EVO 閱讀(176) | 評論 (0) | 編輯 收藏

分享一種需求評審的方案

posted @ 2014-09-05 10:50 順其自然EVO 閱讀(226) | 評論 (0) | 編輯 收藏