• <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>

            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 閱讀(18506) | 評論 (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 閱讀(3073) | 評論 (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 閱讀(18506) | 評論 (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 閱讀(2296) | 評論 (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 閱讀(2183) | 評論 (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 閱讀(3073) | 評論 (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 閱讀(952) | 評論 (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 閱讀(653) | 評論 (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 閱讀(480) | 評論 (0)編輯 收藏

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

            僅列出標題  下一頁
            久久超碰97人人做人人爱| 97香蕉久久夜色精品国产 | 亚洲va久久久久| 国产精品成人99久久久久91gav| 蜜臀久久99精品久久久久久小说 | 久久这里的只有是精品23| 久久精品视屏| 久久久久国产精品嫩草影院| 91精品免费久久久久久久久| 久久这里有精品视频| 亚洲愉拍99热成人精品热久久 | 精品国产一区二区三区久久| 蜜桃麻豆www久久| 久久综合鬼色88久久精品综合自在自线噜噜 | 久久免费看黄a级毛片| 久久99精品国产麻豆宅宅| 久久久精品人妻一区二区三区四 | 嫩草影院久久99| 国产精品无码久久四虎| 久久精品免费网站网| 久久青青色综合| 国产美女久久久| 国产精品亚洲美女久久久| 久久久久国产| 亚洲αv久久久噜噜噜噜噜| 国内精品伊人久久久久网站| 日韩精品久久无码人妻中文字幕| 99久久99这里只有免费费精品| 99久久综合狠狠综合久久止| 国产成人精品久久亚洲| 中文成人无码精品久久久不卡| 久久精品国产亚洲网站| 久久青青草原精品国产不卡| 久久国产劲爆AV内射—百度| 国产精品99久久精品| 久久影院亚洲一区| 九九久久自然熟的香蕉图片| 国产成人精品久久亚洲高清不卡| 亚洲国产成人久久一区WWW| 久久久久亚洲AV无码麻豆| 久久精品不卡|