青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

lxyfirst

C++博客 首頁 新隨筆 聯系 聚合 管理
  33 Posts :: 3 Stories :: 27 Comments :: 0 Trackbacks

置頂隨筆 #

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

我們的應用場景類似電商,在一個訂單的生命周期內,有多個邏輯需要生成各自的id,還要考慮到可讀性和靈活性,我們決定實現一個獨立的id服務。
首先,id服務必須具有高可用性,業務邏輯處理中創建id失敗是不可接受的,所以id服務必須分布式部署,有多個節點同時對外服務,一個節點失敗則重試其他節點,保證成功創建id。
在分布式系統中保證數據的一致性成本是很高的,為了簡化設計和實現,每個節點都設計成對等的、獨立的,不需要保持數據同步。
其次,id服務必須可靠,數據不能丟失,因此數據的存儲放在獨立的mysql數據庫中,使用replace方式更新數據,id服務本身記錄更新日志。
最后,id服務必須靈活,可以自定義id格式,可以高效靈活的實現客戶端,因此通訊協議使用json over udp方式,在id服務端使用lua實現id格式的靈活定義。
ID規則
    具體規則有lua腳本定義,修改腳本后需要reload生效,需要實現4個函數
    min_counter :   計數器最小值
    max_counter :   計數器最大值
    reset_seconds : 計數器重置周期
    create_id : 根據計數器、自定義參數和時間參數創建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協議,數據格式為json ,字段定義:
    action: 請求類型 get: 創建ID ,  monitor:監控
    rule_name: 規則名字, 由服務端定義
    app_name : 應用名或命名空間 , 客戶端自定義,rule_name和app_name一起決定生成ID的唯一性
    salt :  自定義參數 ,可選項 ,
    seq : 自定義參數,可選項,原樣返回
    例如:
    創建ID請求:  {"action":"get","rule_name":"o2o","app_name":"test"}
    響應:{"code":0,"message":"success","data":"505140001"}
    監控請求:{"action":"monitor","rule_name":"o2o","app_name":"test"}
    響應:{"code":0,"message":"ok","data":{"counter":3,"node_offset":1}}
性能
    id服務器使用c++實現,性能測試做的比較簡單,因為性能不是id服務的主要關注點, 簡單以php為客戶端進行測試。
    4個php并發進程,每個進程不停發送20萬個請求,測試結果:
    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 : 平均耗時(秒)
    服務器TPS達到近1萬/秒時,平均延遲在0.3毫秒。

經過在生產環境使用,運行穩定,現在將整個系統開源出來,歡迎試用,有任何意見和建議歡迎反饋到lxyfirst@163.com 。
項目源代碼位置 : https://github.com/lxyfirst/id_server

版本更新9.19
1.增加數據落地的預保存和批量保存機制,一方面減少數據庫壓力,一方面增加異步保存的可靠性。
2.由于主線程和數據庫線程只需要傳遞sql語句,將線程間通信由pipe方式改為eventfd + lockfree queue方式。
posted @ 2015-09-17 14:09 star 閱讀(18541) | 評論 (4)編輯 收藏

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

2. drizzle_result_st對象初始時一些內部數據沒有初始化,容易造成程序崩潰,因此需要修改構造函數,初始化所有內部數據。涉及文件libdrizzle-2.0/structs.h 
相應字段為field, field_buffer,row 。

3. libdrizzle中運行時產生的內部對象都以雙鏈表形式掛接在其上級對象中,例如drizzle_st對象中有個雙鏈表維護其創建的drizzle_con_st對象,類似地,drizzle_con_st對象中有個雙鏈表維護其創建的drizzle_result_st對象,所有的對象通過這種形式級聯管理,并且這些對象中保存著上下文相關的狀態,這樣的實現方便資源管理,防止資源泄露,但在代理服務器中,請求和結果在不斷轉發過程中會形成大量的內存拷貝,為了減少轉發過程中的內存拷貝,需要把drizzle_result_st顯式的從drizzle_con_st中移除,當數據發往客戶端完成后再刪除,因此增加了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 閱讀(3102) | 評論 (0)編輯 收藏

2015年9月17日 #

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

我們的應用場景類似電商,在一個訂單的生命周期內,有多個邏輯需要生成各自的id,還要考慮到可讀性和靈活性,我們決定實現一個獨立的id服務。
首先,id服務必須具有高可用性,業務邏輯處理中創建id失敗是不可接受的,所以id服務必須分布式部署,有多個節點同時對外服務,一個節點失敗則重試其他節點,保證成功創建id。
在分布式系統中保證數據的一致性成本是很高的,為了簡化設計和實現,每個節點都設計成對等的、獨立的,不需要保持數據同步。
其次,id服務必須可靠,數據不能丟失,因此數據的存儲放在獨立的mysql數據庫中,使用replace方式更新數據,id服務本身記錄更新日志。
最后,id服務必須靈活,可以自定義id格式,可以高效靈活的實現客戶端,因此通訊協議使用json over udp方式,在id服務端使用lua實現id格式的靈活定義。
ID規則
    具體規則有lua腳本定義,修改腳本后需要reload生效,需要實現4個函數
    min_counter :   計數器最小值
    max_counter :   計數器最大值
    reset_seconds : 計數器重置周期
    create_id : 根據計數器、自定義參數和時間參數創建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協議,數據格式為json ,字段定義:
    action: 請求類型 get: 創建ID ,  monitor:監控
    rule_name: 規則名字, 由服務端定義
    app_name : 應用名或命名空間 , 客戶端自定義,rule_name和app_name一起決定生成ID的唯一性
    salt :  自定義參數 ,可選項 ,
    seq : 自定義參數,可選項,原樣返回
    例如:
    創建ID請求:  {"action":"get","rule_name":"o2o","app_name":"test"}
    響應:{"code":0,"message":"success","data":"505140001"}
    監控請求:{"action":"monitor","rule_name":"o2o","app_name":"test"}
    響應:{"code":0,"message":"ok","data":{"counter":3,"node_offset":1}}
性能
    id服務器使用c++實現,性能測試做的比較簡單,因為性能不是id服務的主要關注點, 簡單以php為客戶端進行測試。
    4個php并發進程,每個進程不停發送20萬個請求,測試結果:
    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 : 平均耗時(秒)
    服務器TPS達到近1萬/秒時,平均延遲在0.3毫秒。

經過在生產環境使用,運行穩定,現在將整個系統開源出來,歡迎試用,有任何意見和建議歡迎反饋到lxyfirst@163.com 。
項目源代碼位置 : https://github.com/lxyfirst/id_server

版本更新9.19
1.增加數據落地的預保存和批量保存機制,一方面減少數據庫壓力,一方面增加異步保存的可靠性。
2.由于主線程和數據庫線程只需要傳遞sql語句,將線程間通信由pipe方式改為eventfd + lockfree queue方式。
posted @ 2015-09-17 14:09 star 閱讀(18541) | 評論 (4)編輯 收藏

2014年5月23日 #

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

/home/svn/conf/目錄下存放了多個庫共用的passwd和authz文件,用來控制這些庫的賬號和訪問權限,獨立的svn_admin庫中存放對應的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 閱讀(2315) | 評論 (0)編輯 收藏

2014年3月9日 #

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

twemproxy作為代理服務器,主體邏輯都圍繞著數據流轉,采用了單線程非阻塞模型,在linux下由epoll驅動整個程序的運行,對于事件驅動模塊的封裝在event目錄下,event_base對象是引擎,conn對象是具體的連接,conn對象中定義一系列事件處理的回調函數,典型的reactor機制,linux下的實現文件是nc_epoll.c 。 
事件引擎模塊使用了兩層回調機制, event_base上有個基本的回調函數,這個回調函數進一步調用conn對象的相應回調函數  (注:一般直接使用conn的回調也就夠了)。
面向客戶端的conn回調:
        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回調:
        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接收連接,創建客戶端conn對象,并將其加入到事件引擎中。
twemproxy面向后端時,由server_pool管理各個到后端的conn對象,同樣會加入到事件引擎中。

在請求處理模塊有2個主要的概念是 mbuf對象和msg對象,mbuf對象是數據緩沖區,發送和接收的數據都存放在mbuf中, 采用鏈式管理。msg對象是具體的邏輯請求,采用鏈式管理,形成請求/響應隊列。請求和響應的處理模塊分別在nc_request.c和nc_response.c中實現。

客戶端連接的處理邏輯:

    core_recv 
        conn->recv        即msg_recv ,read事件處理
            conn->recv_next           即req_recv_next ,獲得msg對象,沒有則創建
            msg_recv_chain             創建mbuf對象,接收并處理數據
                  [create mbuf]
                  conn_recv       真正的read數據
                  msg_parse      解析 , mbuf->msg
                       msg_parsed   解析完成
                           conn->recv_done   即req_recv_done    
                               req_filter        過濾器,暫無操作
                               req_forward    分發請求
                                   server_pool_conn 根據key獲得后端conn對象
                                   將s_conn加入寫事件監控,將msg加入轉發隊列,可寫事件被觸發后轉發隊列內請求
                                   s_conn->enqueue_inq req_server_enqueue_imsgq
 
                  conn->recv_next      即req_recv_next,繼續下一個

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

未完待續。
posted @ 2014-03-09 13:42 star 閱讀(2201) | 評論 (0)編輯 收藏

2014年1月7日 #

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

2. drizzle_result_st對象初始時一些內部數據沒有初始化,容易造成程序崩潰,因此需要修改構造函數,初始化所有內部數據。涉及文件libdrizzle-2.0/structs.h 
相應字段為field, field_buffer,row 。

3. libdrizzle中運行時產生的內部對象都以雙鏈表形式掛接在其上級對象中,例如drizzle_st對象中有個雙鏈表維護其創建的drizzle_con_st對象,類似地,drizzle_con_st對象中有個雙鏈表維護其創建的drizzle_result_st對象,所有的對象通過這種形式級聯管理,并且這些對象中保存著上下文相關的狀態,這樣的實現方便資源管理,防止資源泄露,但在代理服務器中,請求和結果在不斷轉發過程中會形成大量的內存拷貝,為了減少轉發過程中的內存拷貝,需要把drizzle_result_st顯式的從drizzle_con_st中移除,當數據發往客戶端完成后再刪除,因此增加了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 閱讀(3102) | 評論 (0)編輯 收藏

2011年11月16日 #

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

2011年10月10日 #

1. arp問題
   在DR或者tunnel模式下,RS需要綁定VIP以便直接將報文發回客戶端。因此需要在RS上屏蔽網絡內對VIP進行arp查詢的響應 。
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頭)后發送給RS , 因此RS需要調整MTU大小,預留IPIP頭空間,以便客戶端正確分包。
ifconfig "$OUT_DEV" mtu 1480

3.報文轉發問題
    在DR或者tunnel模式下,報文直接轉發到RS。
echo 1 > /proc/sys/net/ipv4/ip_forward

4.LD支持連接數問題
   內核ip_vs模塊的參數conn_tab_bits指定了conn表的大小,最大為20 ,支持1M個連接。

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

6.LD的cpu負載問題
   LD的網卡軟中斷(ksoftirqd)由一個cpu處理,無法利用多核,調整軟中斷的smp_affinity可以改變綁定的cpu,但無法做多核負載均衡。
   內核2.6.32之后已經支持軟中斷的負載均衡。
   使用支持RSS的網卡,有多個隊列,或者使用多個網卡做bonding 。
  echo "alias bond0 bonding" >> /etc/modprobe.conf
  修改ifcfg-bond0 , ifcfg-ethX配置文件。

7. 系統內核參數調整參考
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 閱讀(669) | 評論 (0)編輯 收藏

2011年8月4日 #

1.服務器網卡軟中斷的cpu負載均衡。 1.網卡支持RSS(Receive Side Scaling,接收方擴展)。 2.內核支持RSS。
2.網卡bonding 。多塊網卡綁定同一IP地址對外提供服務,通過bonding,虛擬一塊網卡對外提供服務。
http://t.chinaunix.net/archiver/tid-1927269.html
posted @ 2011-08-04 10:44 star 閱讀(499) | 評論 (0)編輯 收藏

多線程系統中通知用哪種方式效率更好,在一臺4核Xeon 3.00GHZ的機器上對比了linux下mq和socketpair通信性能,一寫線程,一讀線程,初步結論是mq勝出,mq 46w/s ,socketpair 40w/s 。
posted @ 2011-08-04 10:36 star 閱讀(1561) | 評論 (2)編輯 收藏

2011年7月7日 #

使用幾個經典網絡模型實現非阻塞簡單http服務,部署在一臺4Xeon 3.00GHZ的機器上進行壓力測試。

 

短連接

長連接

客戶端

1個線程

97%cpu,多核分擔

60%cpu網卡中斷

1.6w/s

平均響應時間10ms

100%cpu

15%cpu網卡軟中斷

2.8w/s

平均響應時間7ms

100并發/客戶端

100w請求/客戶端

2個客戶端

 

4個線程

每個線程70%cpu

99%cpu網卡中斷

2.1w/s

平均響應時間9ms

每個線程100%cpu

40%cpu網卡軟中斷

6.5w/s

平均響應時間3ms

100并發/客戶端

100w請求/客戶端

2個客戶端

 

1leader線程,接受連接

4worker線程,處理請求

leader線程90%cpu

worker線程40%cpu

75%網卡中斷

1.8w/s

平均響應時間10ms

leader線程1%cpu

worker線程100%cpu

40%網卡中斷

6.0w/s

平均響應時間3ms

100并發/客戶端

100w請求/客戶端

2個客戶端

 

 

結論:

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

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

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

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

2011年6月29日 #

beanstalkd源于fackbook,是一個快速、簡單的內存消息隊列,也可以開啟binlog,消息將被寫入日志文件,用于重啟時恢復數據。
1.消息被稱作job,在服務器端儲存在內存隊列中,具有DELAYED,READY,RESERVED,BURIED狀態,狀態轉換圖如下
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*

消息支持優先級,生存時間的設置。不同狀態的消息分別處于相應狀態的隊列中。
2. 消息屬于某個tube,tube類似于namespace或者消息主題的概念,消費者可以訂閱一個或多個tube ,從而接收這些tube的消息 。
3. beanstalkd的代碼實現和協議定義很類似memcached的風格。
posted @ 2011-06-29 14:43 star 閱讀(1715) | 評論 (0)編輯 收藏

僅列出標題  下一頁
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            一区二区三区回区在观看免费视频| 欧美黄色一级视频| 国产主播一区二区| 国产欧美精品日韩区二区麻豆天美| 欧美精品福利在线| 欧美日韩精品一区二区| 欧美日韩国产精品| 国产精品成人久久久久| 国产精品久久久久高潮| 国产精品永久| 黑人一区二区三区四区五区| 精品不卡一区| 亚洲美女在线看| 亚洲免费视频中文字幕| 久久成人国产| 欧美福利在线观看| 亚洲精选成人| 欧美一二三区精品| 欧美不卡激情三级在线观看| 欧美日韩色一区| 国产亚洲人成a一在线v站| 精品不卡一区| 欧美91大片| 日韩亚洲欧美在线观看| 伊人春色精品| 亚洲黄色天堂| 欧美亚洲一区二区在线| 国产一区视频观看| 国内偷自视频区视频综合| 在线观看欧美黄色| 99精品欧美一区二区三区| 亚洲在线电影| 欧美国产日韩视频| 一区二区三区色| 久久手机精品视频| 欧美日韩国产综合视频在线观看| 欧美深夜福利| 在线观看视频免费一区二区三区| 一区二区三区欧美在线观看| 久久久www成人免费毛片麻豆| 最新中文字幕亚洲| 久久久噜噜噜久久久| 欧美视频在线一区二区三区| 在线精品国产欧美| 久久精品一区二区三区中文字幕| 9色porny自拍视频一区二区| 麻豆成人91精品二区三区| 国产午夜精品理论片a级探花| 一本色道久久99精品综合| 欧美成人伊人久久综合网| 亚洲一区二区三区免费观看| 欧美日本韩国| 日韩一区二区精品视频| 六月丁香综合| 久久精品日产第一区二区三区| 国产女人精品视频| 性欧美在线看片a免费观看| 日韩午夜免费视频| 欧美日本精品一区二区三区| 亚洲精品永久免费| 亚洲国产成人精品视频| 老司机一区二区三区| 狠狠色综合色区| 久久久久久999| 久久国产精品久久精品国产| 国产日韩欧美视频| 久久久久久亚洲精品中文字幕| 亚洲影院色无极综合| 国产精品久久午夜夜伦鲁鲁| 亚洲欧美日韩一区二区| 亚洲午夜一区二区三区| 欧美一区二区视频免费观看| 久久精品国产69国产精品亚洲| 日韩一级大片| 欧美日韩一区国产| 亚洲欧美国产毛片在线| 一区二区三区视频在线| 国产精品专区h在线观看| 久久成人免费视频| 久久久久久夜精品精品免费| 影音先锋成人资源站| 欧美激情一区二区| 欧美日韩国产丝袜另类| 午夜精品久久久久久久蜜桃app| 亚洲一二三区视频在线观看| 国产精品一区二区久久精品| 久久久久久有精品国产| 裸体一区二区三区| 9久re热视频在线精品| 亚洲天堂网在线观看| 狠狠做深爱婷婷久久综合一区 | 99精品久久免费看蜜臀剧情介绍| 亚洲精品日韩欧美| 国产精品视频男人的天堂| 久久婷婷综合激情| 欧美激情在线观看| 久久成年人视频| 六月天综合网| 亚洲女ⅴideoshd黑人| 久久精品视频一| 99国产精品久久久久老师| 篠田优中文在线播放第一区| 亚洲激情另类| 午夜精品av| 日韩视频免费在线观看| 校园激情久久| 一本色道久久| 久久久中精品2020中文| 亚洲一区在线观看视频| 久久夜色撩人精品| 亚洲欧美日韩成人| 欧美粗暴jizz性欧美20| 欧美在线综合| 欧美日在线观看| 欧美激情第3页| 国产日韩欧美高清| 一区二区欧美亚洲| 亚洲精品欧美日韩| 久久精品国内一区二区三区| 亚洲一区二区三区精品动漫| 米奇777在线欧美播放| 久久精品人人爽| 欧美午夜欧美| 亚洲精品日产精品乱码不卡| 1000部精品久久久久久久久| 性久久久久久久久| 性亚洲最疯狂xxxx高清| 欧美午夜不卡影院在线观看完整版免费| 久久一区二区三区av| 国产欧美日韩麻豆91| 亚洲视频在线看| 久久精品论坛| 99国产精品| 亚洲精品免费电影| 欧美在线|欧美| 久久久久综合网| 亚洲午夜羞羞片| 99亚洲一区二区| 新片速递亚洲合集欧美合集| 夜夜嗨av一区二区三区免费区| 国产亚洲激情视频在线| 国产精品草草| 国产综合激情| 亚洲国产欧美一区二区三区丁香婷| 一区一区视频| 久久aⅴ国产欧美74aaa| 国产欧美一二三区| 国产精品永久免费视频| 欧美性一区二区| 久久久久女教师免费一区| 欧美插天视频在线播放| 国产无遮挡一区二区三区毛片日本| 欧美成人国产| 欧美日韩国产在线| 亚洲少妇一区| 国产欧美精品| 欧美一激情一区二区三区| 欧美在线在线| 在线观看91精品国产入口| 久久久欧美精品sm网站| 欧美二区在线播放| 一区二区三区高清| 国产精品国产三级国产aⅴ无密码| 中文成人激情娱乐网| 欧美在线免费一级片| 一区二区三区在线观看欧美| 欧美69视频| 亚洲午夜久久久久久尤物| 久久国产精品久久久久久久久久| 精品69视频一区二区三区| 欧美成人69| 亚洲综合日韩| 欧美成人小视频| 亚洲一区免费在线观看| 国产综合网站| 欧美高清你懂得| 午夜性色一区二区三区免费视频 | 欧美日韩中文字幕在线视频| 亚洲国产精品小视频| 中文国产亚洲喷潮| 国产一区二区三区久久久久久久久| 蜜桃av一区| 亚洲综合另类| 亚洲精品久久久蜜桃| 久久精品一区二区国产| 99精品热视频| 亚洲欧美日韩国产精品| 欧美亚洲免费高清在线观看| 久久综合婷婷| 一区二区不卡在线视频 午夜欧美不卡'| 日韩一级黄色大片| 黄色一区二区三区四区| 欧美精品三级在线观看| 久久福利资源站| 一区二区三区欧美在线观看| 牛夜精品久久久久久久99黑人| 午夜精品久久久久久久99水蜜桃| 最新热久久免费视频| 狠狠久久婷婷| 国产精品久久久久久久浪潮网站|