亚洲综合激情,中文一区二区,亚洲在线视频免费观看

[置頂]分布式高可用id服務(wù)器設(shè)計實現(xiàn)

服務(wù)端/后臺開發(fā)中如何生成id是每個開發(fā)者都會遇到的問題，在電商、游戲領(lǐng)域尤其突出。
如何保證生成id的唯一性、可靠性、高可用性，如何組織id的格式，在不同的應(yīng)用場景和限制下實現(xiàn)方式也不盡相同。

我們的應(yīng)用場景類似電商，在一個訂單的生命周期內(nèi)，有多個邏輯需要生成各自的id，還要考慮到可讀性和靈活性，我們決定實現(xiàn)一個獨立的id服務(wù)。
首先，id服務(wù)必須具有高可用性，業(yè)務(wù)邏輯處理中創(chuàng)建id失敗是不可接受的，所以id服務(wù)必須分布式部署，有多個節(jié)點同時對外服務(wù)，一個節(jié)點失敗則重試其他節(jié)點，保證成功創(chuàng)建id。
在分布式系統(tǒng)中保證數(shù)據(jù)的一致性成本是很高的，為了簡化設(shè)計和實現(xiàn)，每個節(jié)點都設(shè)計成對等的、獨立的，不需要保持數(shù)據(jù)同步。
其次，id服務(wù)必須可靠，數(shù)據(jù)不能丟失，因此數(shù)據(jù)的存儲放在獨立的mysql數(shù)據(jù)庫中，使用replace方式更新數(shù)據(jù)，id服務(wù)本身記錄更新日志。
最后，id服務(wù)必須靈活，可以自定義id格式，可以高效靈活的實現(xiàn)客戶端，因此通訊協(xié)議使用json over udp方式，在id服務(wù)端使用lua實現(xiàn)id格式的靈活定義。

ID規(guī)則

具體規(guī)則有l(wèi)ua腳本定義，修改腳本后需要reload生效，需要實現(xiàn)4個函數(shù)

min_counter : 計數(shù)器最小值

max_counter : 計數(shù)器最大值

reset_seconds : 計數(shù)器重置周期

create_id : 根據(jù)計數(shù)器、自定義參數(shù)和時間參數(shù)創(chuàng)建ID。
例如：

function min_counter()

return 0

end

function max_counter()

return 9999

end

function reset_seconds()

return 86400

end

function create_id(counter,now,salt)

local seq = counter:generate_counter()

local new_id = string.format("%01d%02d%02d%04d",now:year()%10 ,now:month(),now:day(),seq)

return new_id

end

接口

采用udp協(xié)議，數(shù)據(jù)格式為json ，字段定義：

action: 請求類型 get：創(chuàng)建ID ， monitor：監(jiān)控

rule_name: 規(guī)則名字，由服務(wù)端定義

app_name : 應(yīng)用名或命名空間，客戶端自定義，rule_name和app_name一起決定生成ID的唯一性

salt : 自定義參數(shù) ，可選項，

seq : 自定義參數(shù)，可選項，原樣返回
例如:
創(chuàng)建ID請求: {"action":"get","rule_name":"o2o","app_name":"test"}

響應(yīng)：{"code":0,"message":"success","data":"505140001"}

監(jiān)控請求：{"action":"monitor","rule_name":"o2o","app_name":"test"}

響應(yīng)：{"code":0,"message":"ok","data":{"counter":3,"node_offset":1}}

性能

id服務(wù)器使用c++實現(xiàn)，性能測試做的比較簡單，因為性能不是id服務(wù)的主要關(guān)注點，簡單以php為客戶端進行測試。
4個php并發(fā)進程，每個進程不停發(fā)送20萬個請求，測試結(jié)果：

total:200000 fail:0 min:0.000214 max:0.087330 avg:0.000393

total:200000 fail:0 min:0.000215 max:0.087129 avg:0.000391

total:200000 fail:0 min:0.000221 max:0.087252 avg:0.000391

total:200000 fail:0 min:0.000218 max:0.087484 avg:0.000391
說明 min : 最小耗時(秒) max : 最大耗時(秒) avg : 平均耗時(秒)
服務(wù)器TPS達到近1萬/秒時，平均延遲在0.3毫秒。

經(jīng)過在生產(chǎn)環(huán)境使用，運行穩(wěn)定，現(xiàn)在將整個系統(tǒng)開源出來，歡迎試用，有任何意見和建議歡迎反饋到lxyfirst＠163.com 。

項目源代碼位置 : https://github.com/lxyfirst/id_server

版本更新9.19
1.增加數(shù)據(jù)落地的預(yù)保存和批量保存機制，一方面減少數(shù)據(jù)庫壓力，一方面增加異步保存的可靠性。
2.由于主線程和數(shù)據(jù)庫線程只需要傳遞sql語句，將線程間通信由pipe方式改為eventfd + lockfree queue方式。

posted @ 2015-09-17 14:09 star 閱讀(18537) | 評論 (4) | 編輯收藏

[置頂]使用libdrizzle實現(xiàn)mysql代理服務(wù)器的問題及優(yōu)化

近期項目需要一個mysql代理服務(wù)器，實現(xiàn)mysql協(xié)議代理和路由功能，形成簡單的mysql集群服務(wù)。現(xiàn)成的開源方案是mysql-proxy ，分析功能和源代碼后發(fā)現(xiàn)跟我們的應(yīng)用場景不太匹配，于是決定重新實現(xiàn)一個符合需求的mysql代理服務(wù)器，考慮到需要完美支持mysql協(xié)議，優(yōu)先選擇了libdrizzle庫， libdrizzle是開源項目drizzle中的協(xié)議庫，而drizzle可以看作mysql的分支版本，目前穩(wěn)定版本是7.1.36 ，下面主要是記錄使用libdrizzle中遇到的一些問題。
1. 關(guān)于nonblock模式的問題，現(xiàn)代應(yīng)用服務(wù)器典型架構(gòu)一般是使用reactor/proactor模式的事件驅(qū)動模型，如何把libdrizzle和應(yīng)用服務(wù)器的驅(qū)動模型很好的結(jié)合起來尤其重要， libdrizzle支持nonblock模式，獨立實現(xiàn)了事件驅(qū)動機制，使用poll監(jiān)控網(wǎng)絡(luò)事件，具體在drizzle_con_wait()中實現(xiàn)，然后通過drizzle_con_ready()遍歷產(chǎn)生事件的網(wǎng)絡(luò)連接，即drizzle_con_st對象，該接口難以與通常的網(wǎng)絡(luò)事件驅(qū)動機制配合使用，性能也不太理想，具體用法可參見其自帶的樣例程序examples/client.cc , 也就是說libdrizzle的驅(qū)動模型需要重新封裝成跟應(yīng)用服務(wù)器相匹配，才能真正發(fā)揮nonblock模式的性能。

2. drizzle_result_st對象初始時一些內(nèi)部數(shù)據(jù)沒有初始化，容易造成程序崩潰，因此需要修改構(gòu)造函數(shù)，初始化所有內(nèi)部數(shù)據(jù)。涉及文件libdrizzle-2.0/structs.h 。相應(yīng)字段為field, field_buffer,row 。

3. libdrizzle中運行時產(chǎn)生的內(nèi)部對象都以雙鏈表形式掛接在其上級對象中，例如drizzle_st對象中有個雙鏈表維護其創(chuàng)建的drizzle_con_st對象，類似地，drizzle_con_st對象中有個雙鏈表維護其創(chuàng)建的drizzle_result_st對象，所有的對象通過這種形式級聯(lián)管理，并且這些對象中保存著上下文相關(guān)的狀態(tài)，這樣的實現(xiàn)方便資源管理，防止資源泄露，但在代理服務(wù)器中，請求和結(jié)果在不斷轉(zhuǎn)發(fā)過程中會形成大量的內(nèi)存拷貝，為了減少轉(zhuǎn)發(fā)過程中的內(nèi)存拷貝，需要把drizzle_result_st顯式的從drizzle_con_st中移除，當數(shù)據(jù)發(fā)往客戶端完成后再刪除，因此增加了drizzle_result_detach()接口，用于從drizzle_con_st對象中移除drizzle_result_st對象，涉及文件libdrizzle-2.0/result.h , libdrizzle-2.0/result.cc 。

void drizzle_result_detach(drizzle_result_st *result)
{

  if (result->con)
  {
    result->con->result_count--;
    if (result->con->result_list == result)
      result->con->result_list= result->next;
  }

  if (result->prev)
    result->prev->next= result->next;

  if (result->next)
    result->next->prev= result->prev;

  result->con = NULL ;
  result->prev = NULL ;
  result->next = NULL ;
}

posted @ 2014-01-07 10:07 star 閱讀(3100) | 評論 (0) | 編輯收藏

分布式高可用id服務(wù)器設(shè)計實現(xiàn)

服務(wù)端/后臺開發(fā)中如何生成id是每個開發(fā)者都會遇到的問題，在電商、游戲領(lǐng)域尤其突出。
如何保證生成id的唯一性、可靠性、高可用性，如何組織id的格式，在不同的應(yīng)用場景和限制下實現(xiàn)方式也不盡相同。

我們的應(yīng)用場景類似電商，在一個訂單的生命周期內(nèi)，有多個邏輯需要生成各自的id，還要考慮到可讀性和靈活性，我們決定實現(xiàn)一個獨立的id服務(wù)。
首先，id服務(wù)必須具有高可用性，業(yè)務(wù)邏輯處理中創(chuàng)建id失敗是不可接受的，所以id服務(wù)必須分布式部署，有多個節(jié)點同時對外服務(wù)，一個節(jié)點失敗則重試其他節(jié)點，保證成功創(chuàng)建id。
在分布式系統(tǒng)中保證數(shù)據(jù)的一致性成本是很高的，為了簡化設(shè)計和實現(xiàn)，每個節(jié)點都設(shè)計成對等的、獨立的，不需要保持數(shù)據(jù)同步。
其次，id服務(wù)必須可靠，數(shù)據(jù)不能丟失，因此數(shù)據(jù)的存儲放在獨立的mysql數(shù)據(jù)庫中，使用replace方式更新數(shù)據(jù)，id服務(wù)本身記錄更新日志。
最后，id服務(wù)必須靈活，可以自定義id格式，可以高效靈活的實現(xiàn)客戶端，因此通訊協(xié)議使用json over udp方式，在id服務(wù)端使用lua實現(xiàn)id格式的靈活定義。

ID規(guī)則

具體規(guī)則有l(wèi)ua腳本定義，修改腳本后需要reload生效，需要實現(xiàn)4個函數(shù)

min_counter : 計數(shù)器最小值

max_counter : 計數(shù)器最大值

reset_seconds : 計數(shù)器重置周期

create_id : 根據(jù)計數(shù)器、自定義參數(shù)和時間參數(shù)創(chuàng)建ID。
例如：

function min_counter()

return 0

end

function max_counter()

return 9999

end

function reset_seconds()

return 86400

end

function create_id(counter,now,salt)

local seq = counter:generate_counter()

local new_id = string.format("%01d%02d%02d%04d",now:year()%10 ,now:month(),now:day(),seq)

return new_id

end

接口

采用udp協(xié)議，數(shù)據(jù)格式為json ，字段定義：

action: 請求類型 get：創(chuàng)建ID ， monitor：監(jiān)控

rule_name: 規(guī)則名字，由服務(wù)端定義

app_name : 應(yīng)用名或命名空間，客戶端自定義，rule_name和app_name一起決定生成ID的唯一性

salt : 自定義參數(shù) ，可選項，

seq : 自定義參數(shù)，可選項，原樣返回
例如:
創(chuàng)建ID請求: {"action":"get","rule_name":"o2o","app_name":"test"}

響應(yīng)：{"code":0,"message":"success","data":"505140001"}

監(jiān)控請求：{"action":"monitor","rule_name":"o2o","app_name":"test"}

響應(yīng)：{"code":0,"message":"ok","data":{"counter":3,"node_offset":1}}

性能

id服務(wù)器使用c++實現(xiàn)，性能測試做的比較簡單，因為性能不是id服務(wù)的主要關(guān)注點，簡單以php為客戶端進行測試。
4個php并發(fā)進程，每個進程不停發(fā)送20萬個請求，測試結(jié)果：

total:200000 fail:0 min:0.000214 max:0.087330 avg:0.000393

total:200000 fail:0 min:0.000215 max:0.087129 avg:0.000391

total:200000 fail:0 min:0.000221 max:0.087252 avg:0.000391

total:200000 fail:0 min:0.000218 max:0.087484 avg:0.000391
說明 min : 最小耗時(秒) max : 最大耗時(秒) avg : 平均耗時(秒)
服務(wù)器TPS達到近1萬/秒時，平均延遲在0.3毫秒。

經(jīng)過在生產(chǎn)環(huán)境使用，運行穩(wěn)定，現(xiàn)在將整個系統(tǒng)開源出來，歡迎試用，有任何意見和建議歡迎反饋到lxyfirst＠163.com 。

項目源代碼位置 : https://github.com/lxyfirst/id_server

版本更新9.19
1.增加數(shù)據(jù)落地的預(yù)保存和批量保存機制，一方面減少數(shù)據(jù)庫壓力，一方面增加異步保存的可靠性。
2.由于主線程和數(shù)據(jù)庫線程只需要傳遞sql語句，將線程間通信由pipe方式改為eventfd + lockfree queue方式。

posted @ 2015-09-17 14:09 star 閱讀(18537) | 評論 (4) | 編輯收藏

用svn管理svn賬號和權(quán)限

svn的賬號和權(quán)限管理是基于文件的，修改時需要更新到服務(wù)器，多有不便，可利用svn管理賬號和權(quán)限，利用svn的pos-commit 鉤子監(jiān)測賬號和權(quán)限文件變化，多個庫可共享同一賬號和權(quán)限文件。

/home/svn/conf/目錄下存放了多個庫共用的passwd和authz文件，用來控制這些庫的賬號和訪問權(quán)限，獨立的svn_admin庫中存放對應(yīng)的passwd和authz文件，有更新時自動同步到/home/svn/conf/下。
svn_admin庫的post-commit 腳本如下:

REPOS="$1"
REV="$2"
FILE_DIR="/home/svn/conf"
UPDATE_FILE_LIST="passwd authz"

for FILENAME in $UPDATE_FILE_LIST ; do
    if svnlook changed $REPOS -r $REV |grep $FILENAME >/dev/null ; then
        DST_FILE=$FILE_DIR/$FILENAME
        mv $DST_FILE $DST_FILE.old
        svnlook cat $REPOS $FILENAME > $DST_FILE
    fi
done

posted @ 2014-05-23 11:03 star 閱讀(2314) | 評論 (0) | 編輯收藏

twemproxy(nutcracker)源代碼簡要分析

twemproxy(nutcracker)是twitter實現(xiàn)的開源memcached和redis代理，主要功能是根據(jù)key分發(fā)請求到后端的memcached和redis服務(wù)器，簡化memcached和redis集群服務(wù)的實現(xiàn)。
出于對twemproxy實現(xiàn)機制的好奇，簡要閱讀了代碼，特別是網(wǎng)絡(luò)處理部分，一般這部分是網(wǎng)絡(luò)服務(wù)器的核心，這里記錄下其代碼實現(xiàn)邏輯和發(fā)現(xiàn)的問題。

twemproxy作為代理服務(wù)器，主體邏輯都圍繞著數(shù)據(jù)流轉(zhuǎn)，采用了單線程非阻塞模型，在linux下由epoll驅(qū)動整個程序的運行，對于事件驅(qū)動模塊的封裝在event目錄下，event_base對象是引擎，conn對象是具體的連接，conn對象中定義一系列事件處理的回調(diào)函數(shù)，典型的reactor機制，linux下的實現(xiàn)文件是nc_epoll.c 。
事件引擎模塊使用了兩層回調(diào)機制， event_base上有個基本的回調(diào)函數(shù)，這個回調(diào)函數(shù)進一步調(diào)用conn對象的相應(yīng)回調(diào)函數(shù) （注：一般直接使用conn的回調(diào)也就夠了）。
面向客戶端的conn回調(diào)：

conn->recv = msg_recv;

conn->recv_next = req_recv_next;

conn->recv_done = req_recv_done;

conn->send = msg_send;

conn->send_next = rsp_send_next;

conn->send_done = rsp_send_done;

conn->close = client_close;

conn->active = client_active;

conn->enqueue_outq = req_client_enqueue_omsgq;

conn->dequeue_outq = req_client_dequeue_omsgq;

面向后端memcached和redis的conn回調(diào)：

conn->recv = msg_recv;

conn->recv_next = rsp_recv_next;

conn->recv_done = rsp_recv_done;

conn->send = msg_send;

conn->send_next = req_send_next;

conn->send_done = req_send_done;

conn->close = server_close;

conn->active = server_active;

conn->enqueue_inq = req_server_enqueue_imsgq;

conn->dequeue_inq = req_server_dequeue_imsgq;

conn->enqueue_outq = req_server_enqueue_omsgq;

conn->dequeue_outq = req_server_dequeue_omsgq;

twemproxy面向客戶端時，由proxy_accept接收連接，創(chuàng)建客戶端conn對象，并將其加入到事件引擎中。
twemproxy面向后端時，由server_pool管理各個到后端的conn對象，同樣會加入到事件引擎中。

在請求處理模塊有2個主要的概念是 mbuf對象和msg對象，mbuf對象是數(shù)據(jù)緩沖區(qū)，發(fā)送和接收的數(shù)據(jù)都存放在mbuf中，采用鏈式管理。msg對象是具體的邏輯請求，采用鏈式管理，形成請求/響應(yīng)隊列。請求和響應(yīng)的處理模塊分別在nc_request.c和nc_response.c中實現(xiàn)。

客戶端連接的處理邏輯：

core_recv

conn->recv 即msg_recv ，read事件處理

conn->recv_next 即req_recv_next ，獲得msg對象，沒有則創(chuàng)建

msg_recv_chain 創(chuàng)建mbuf對象，接收并處理數(shù)據(jù)

[create mbuf]

conn_recv 真正的read數(shù)據(jù)

msg_parse 解析， mbuf->msg

msg_parsed 解析完成

conn->recv_done 即req_recv_done

req_filter 過濾器，暫無操作

req_forward 分發(fā)請求

server_pool_conn 根據(jù)key獲得后端conn對象

將s_conn加入寫事件監(jiān)控，將msg加入轉(zhuǎn)發(fā)隊列，可寫事件被觸發(fā)后轉(zhuǎn)發(fā)隊列內(nèi)請求

s_conn->enqueue_inq req_server_enqueue_imsgq

conn->recv_next 即req_recv_next，繼續(xù)下一個

注：從代碼實現(xiàn)看回調(diào)邏輯的層次性不強，收發(fā)數(shù)據(jù)放入mbuf列表，然后用writev處理，在遇到發(fā)送不完時還要拆分mbuf，重新組織iovec，實現(xiàn)上有些復(fù)雜。
另外conn對象的數(shù)據(jù)采用一次讀/寫完的方式處理，在高壓力下可能會產(chǎn)生大量的mbuf對象。

未完待續(xù)。

posted @ 2014-03-09 13:42 star 閱讀(2198) | 評論 (0) | 編輯收藏

使用libdrizzle實現(xiàn)mysql代理服務(wù)器的問題及優(yōu)化

近期項目需要一個mysql代理服務(wù)器，實現(xiàn)mysql協(xié)議代理和路由功能，形成簡單的mysql集群服務(wù)。現(xiàn)成的開源方案是mysql-proxy ，分析功能和源代碼后發(fā)現(xiàn)跟我們的應(yīng)用場景不太匹配，于是決定重新實現(xiàn)一個符合需求的mysql代理服務(wù)器，考慮到需要完美支持mysql協(xié)議，優(yōu)先選擇了libdrizzle庫， libdrizzle是開源項目drizzle中的協(xié)議庫，而drizzle可以看作mysql的分支版本，目前穩(wěn)定版本是7.1.36 ，下面主要是記錄使用libdrizzle中遇到的一些問題。
1. 關(guān)于nonblock模式的問題，現(xiàn)代應(yīng)用服務(wù)器典型架構(gòu)一般是使用reactor/proactor模式的事件驅(qū)動模型，如何把libdrizzle和應(yīng)用服務(wù)器的驅(qū)動模型很好的結(jié)合起來尤其重要， libdrizzle支持nonblock模式，獨立實現(xiàn)了事件驅(qū)動機制，使用poll監(jiān)控網(wǎng)絡(luò)事件，具體在drizzle_con_wait()中實現(xiàn)，然后通過drizzle_con_ready()遍歷產(chǎn)生事件的網(wǎng)絡(luò)連接，即drizzle_con_st對象，該接口難以與通常的網(wǎng)絡(luò)事件驅(qū)動機制配合使用，性能也不太理想，具體用法可參見其自帶的樣例程序examples/client.cc , 也就是說libdrizzle的驅(qū)動模型需要重新封裝成跟應(yīng)用服務(wù)器相匹配，才能真正發(fā)揮nonblock模式的性能。

2. drizzle_result_st對象初始時一些內(nèi)部數(shù)據(jù)沒有初始化，容易造成程序崩潰，因此需要修改構(gòu)造函數(shù)，初始化所有內(nèi)部數(shù)據(jù)。涉及文件libdrizzle-2.0/structs.h 。相應(yīng)字段為field, field_buffer,row 。

3. libdrizzle中運行時產(chǎn)生的內(nèi)部對象都以雙鏈表形式掛接在其上級對象中，例如drizzle_st對象中有個雙鏈表維護其創(chuàng)建的drizzle_con_st對象，類似地，drizzle_con_st對象中有個雙鏈表維護其創(chuàng)建的drizzle_result_st對象，所有的對象通過這種形式級聯(lián)管理，并且這些對象中保存著上下文相關(guān)的狀態(tài)，這樣的實現(xiàn)方便資源管理，防止資源泄露，但在代理服務(wù)器中，請求和結(jié)果在不斷轉(zhuǎn)發(fā)過程中會形成大量的內(nèi)存拷貝，為了減少轉(zhuǎn)發(fā)過程中的內(nèi)存拷貝，需要把drizzle_result_st顯式的從drizzle_con_st中移除，當數(shù)據(jù)發(fā)往客戶端完成后再刪除，因此增加了drizzle_result_detach()接口，用于從drizzle_con_st對象中移除drizzle_result_st對象，涉及文件libdrizzle-2.0/result.h , libdrizzle-2.0/result.cc 。

void drizzle_result_detach(drizzle_result_st *result)
{

  if (result->con)
  {
    result->con->result_count--;
    if (result->con->result_list == result)
      result->con->result_list= result->next;
  }

  if (result->prev)
    result->prev->next= result->next;

  if (result->next)
    result->next->prev= result->prev;

  result->con = NULL ;
  result->prev = NULL ;
  result->next = NULL ;
}

posted @ 2014-01-07 10:07 star 閱讀(3100) | 評論 (0) | 編輯收藏

keepalived配置注意事項

keepalived是用來進行網(wǎng)絡(luò)fail-over的強大工具，配置簡單靈活，功能強大，實現(xiàn)了vrrp協(xié)議和健康檢查，配合lvs使用可實現(xiàn)高可用性。
典型雙機熱備配置方案：
兩臺機器的keepalived實例都配置成BACKUP狀態(tài)，priority高的自動作為master , priority低的自動作為slave ，也可以將priority設(shè)置為相同，先啟動的作為master 。兩邊都設(shè)置nopreempt，防止出現(xiàn)故障->恢復(fù)過程中的再切換。
1.在master發(fā)生故障->恢復(fù)過程中，原backup會替換為master對外服務(wù)，當原master恢復(fù)后，一般希望原master作為新backup，以避免master的再次切換，可以使用nopreempt參數(shù)，防止priority高的發(fā)起切換。
2. 當keepalived設(shè)置為隨系統(tǒng)啟動自動啟動時，應(yīng)加上一定的延遲，防止網(wǎng)絡(luò)或系統(tǒng)未準備好影響keepalived的狀態(tài)。
3. 當后端的RS有狀態(tài)(https)時，lvs一般需要使用sh負載算法或使用持久性連接，以便同一來源的請求分發(fā)到同一RS，當http和https的請求分發(fā)需要一致時，可以使用iptable對報文做fmark，使用fmark配置lvs 。

posted @ 2011-11-16 11:11 star 閱讀(970) | 評論 (0) | 編輯收藏

LVS配置注意事項

1. arp問題
在DR或者tunnel模式下，RS需要綁定VIP以便直接將報文發(fā)回客戶端。因此需要在RS上屏蔽網(wǎng)絡(luò)內(nèi)對VIP進行arp查詢的響應(yīng) 。

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

2. mtu問題
在tunnel模式下，LD將客戶端報文進行封裝（加IPIP頭）后發(fā)送給RS ，因此RS需要調(diào)整MTU大小，預(yù)留IPIP頭空間，以便客戶端正確分包。

ifconfig "$OUT_DEV" mtu 1480

3.報文轉(zhuǎn)發(fā)問題
在DR或者tunnel模式下，報文直接轉(zhuǎn)發(fā)到RS。

echo 1 > /proc/sys/net/ipv4/ip_forward

4.LD支持連接數(shù)問題
   內(nèi)核ip_vs模塊的參數(shù)conn_tab_bits指定了conn表的大小，最大為20 ，支持1M個連接。

5.LD做HA時VIP接管問題
   新LD接管故障LD的VIP時，需要及時做arp廣播，keepalived會自動完成，也通過arping命令查看。

6.LD的cpu負載問題
   LD的網(wǎng)卡軟中斷(ksoftirqd)由一個cpu處理，無法利用多核，調(diào)整軟中斷的smp_affinity可以改變綁定的cpu，但無法做多核負載均衡。
內(nèi)核2.6.32之后已經(jīng)支持軟中斷的負載均衡。
   使用支持RSS的網(wǎng)卡，有多個隊列，或者使用多個網(wǎng)卡做bonding 。

echo "alias bond0 bonding" >> /etc/modprobe.conf

修改ifcfg-bond0 , ifcfg-ethX配置文件。

7. 系統(tǒng)內(nèi)核參數(shù)調(diào)整參考

net.ipv4.tcp_tw_recyle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 40960
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_max_tw_buckets = 8192
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 40960
#net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_rmem = 4194304 8388608 16777216
net.ipv4.tcp_wmem = 4194304 8388608 16777216
net.ipv4.udp_mem = 4194304 8388608 16777216
net.ipv4.udp_rmem_min = 1048576
net.ipv4.udp_wmem_min = 1048576

net.core.somaxconn = 40960
net.core.netdev_max_backlog = 40960
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

參考:http://www.austintek.com/LVS/

posted @ 2011-10-10 15:55 star 閱讀(668) | 評論 (0) | 編輯收藏

網(wǎng)卡負載均衡

1.服務(wù)器網(wǎng)卡軟中斷的cpu負載均衡。 1.網(wǎng)卡支持RSS（Receive Side Scaling，接收方擴展）。 2.內(nèi)核支持RSS。
2.網(wǎng)卡bonding 。多塊網(wǎng)卡綁定同一IP地址對外提供服務(wù)，通過bonding，虛擬一塊網(wǎng)卡對外提供服務(wù)。

http://t.chinaunix.net/archiver/tid-1927269.html

posted @ 2011-08-04 10:44 star 閱讀(496) | 評論 (0) | 編輯收藏

linux上mq和socketpair的通信性能比較

多線程系統(tǒng)中通知用哪種方式效率更好，在一臺4核Xeon 3.00GHZ的機器上對比了linux下mq和socketpair通信性能，一寫線程，一讀線程，初步結(jié)論是mq勝出，mq 46w/s ，socketpair 40w/s 。

posted @ 2011-08-04 10:36 star 閱讀(1560) | 評論 (2) | 編輯收藏

典型網(wǎng)絡(luò)模型性能比較

使用幾個經(jīng)典網(wǎng)絡(luò)模型實現(xiàn)非阻塞簡單http服務(wù)，部署在一臺4核Xeon 3.00GHZ的機器上進行壓力測試。

短連接

長連接

客戶端

1個線程

97%cpu，多核分擔(dān)

60%cpu網(wǎng)卡中斷

1.6w/s

平均響應(yīng)時間10ms

100%cpu

15%cpu網(wǎng)卡軟中斷

2.8w/s

平均響應(yīng)時間7ms

100并發(fā)/客戶端

100w請求/客戶端

2個客戶端

4個線程

每個線程70%cpu

99%cpu網(wǎng)卡中斷

2.1w/s

平均響應(yīng)時間9ms

每個線程100%cpu

40%cpu網(wǎng)卡軟中斷

6.5w/s

平均響應(yīng)時間3ms

100并發(fā)/客戶端

100w請求/客戶端

2個客戶端

1個leader線程，接受連接

4個worker線程，處理請求

leader線程90%cpu

worker線程40%cpu

75%網(wǎng)卡中斷

1.8w/s

平均響應(yīng)時間10ms

leader線程1%cpu

worker線程100%cpu

40%網(wǎng)卡中斷

6.0w/s

平均響應(yīng)時間3ms

100并發(fā)/客戶端

100w請求/客戶端

2個客戶端

結(jié)論：

1. 短連接中，建立連接是很耗費資源的。

2. 長連接中，多線程在提高處理能力方面是很有價值的，尤其是運算量多的請求。

3. 多個線程同時接受連接會造成cpu軟中斷的overhead。

posted @ 2011-07-07 13:24 star 閱讀(382) | 評論 (0) | 編輯收藏

消息隊列beanstalkd簡介

beanstalkd源于fackbook，是一個快速、簡單的內(nèi)存消息隊列，也可以開啟binlog，消息將被寫入日志文件，用于重啟時恢復(fù)數(shù)據(jù)。
1.消息被稱作job，在服務(wù)器端儲存在內(nèi)存隊列中，具有DELAYED,READY,RESERVED,BURIED狀態(tài)，狀態(tài)轉(zhuǎn)換圖如下

Here is a picture of the typical job lifecycle:

   put            reserve               delete
  -----> [READY] ---------> [RESERVED] --------> *poof*

Here is a picture with more possibilities:

   put with delay               release with delay
  ----------------> [DELAYED] <------------.
                        |                   |
                        | (time passes)     |
                        |                   |
   put                  v     reserve       |       delete
  -----------------> [READY] ---------> [RESERVED] --------> *poof*
                       ^  ^                |  |
                       |   \  release      |  |
                       |    `-------------'   |
                       |                      |
                       | kick                 |
                       |                      |
                       |       bury           |
                    [BURIED] <---------------'
                       |
                       |  delete
                        `--------> *poof*

消息支持優(yōu)先級，生存時間的設(shè)置。不同狀態(tài)的消息分別處于相應(yīng)狀態(tài)的隊列中。
2. 消息屬于某個tube，tube類似于namespace或者消息主題的概念，消費者可以訂閱一個或多個tube ，從而接收這些tube的消息。
3. beanstalkd的代碼實現(xiàn)和協(xié)議定義很類似memcached的風(fēng)格。

posted @ 2011-06-29 14:43 star 閱讀(1715) | 評論 (0) | 編輯收藏

lxyfirst

常用鏈接

留言簿(2)

隨筆檔案

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜