• <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++博客 首頁(yè) 新隨筆 聯(lián)系 聚合 管理
              33 Posts :: 3 Stories :: 27 Comments :: 0 Trackbacks

            置頂隨筆 #

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

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

            經(jīng)過(guò)在生產(chǎn)環(huán)境使用,運(yùn)行穩(wěn)定,現(xiàn)在將整個(gè)系統(tǒng)開(kāi)源出來(lái),歡迎試用,有任何意見(jiàn)和建議歡迎反饋到lxyfirst@163.com 。
            項(xiàng)目源代碼位置 : https://github.com/lxyfirst/id_server

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

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

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

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

            僅列出標(biāo)題  下一頁(yè)
            久久久久综合中文字幕| 国产精品成人精品久久久| 思思久久99热免费精品6| 久久综合亚洲色一区二区三区| 伊人情人综合成人久久网小说| 无码人妻久久一区二区三区免费 | 久久国产精品无| 色婷婷综合久久久中文字幕 | 国产精品美女久久久久AV福利| 久久久久无码国产精品不卡| 蜜臀av性久久久久蜜臀aⅴ麻豆 | 国产亚洲精品自在久久| 四虎久久影院| 久久综合九色综合精品| 一本色道久久HEZYO无码| 免费一级欧美大片久久网| 久久久久亚洲AV成人片| 欧美成人免费观看久久| 麻豆精品久久久一区二区| 久久精品一区二区三区AV| 亚洲婷婷国产精品电影人久久 | 99久久人妻无码精品系列蜜桃| 一本一道久久精品综合| 久久精品国产亚洲沈樵| av色综合久久天堂av色综合在 | 青青青国产精品国产精品久久久久| 久久婷婷午色综合夜啪| 精品99久久aaa一级毛片| 人妻无码精品久久亚瑟影视| 久久精品国产99国产精品澳门| 99久久无色码中文字幕人妻| 亚洲AV伊人久久青青草原| 久久www免费人成精品香蕉| 国产精品99久久不卡| 久久精品国产福利国产秒| 精品久久久久久无码专区| 久久久久久无码Av成人影院| 精品久久久久久亚洲精品| 99久久精品毛片免费播放| 久久精品国产欧美日韩| 久久91这里精品国产2020|