• <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++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              33 Posts :: 3 Stories :: 27 Comments :: 0 Trackbacks
            服務(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 on 2015-09-17 14:09 star 閱讀(18506) 評論(4)  編輯 收藏 引用

            Feedback

            # re: 分布式高可用id服務(wù)器設(shè)計實現(xiàn) 2015-09-18 08:51 single
            博主能再說明一下多節(jié)點之間是如何保證id的唯一性,如何保證id_server的id存盤性能  回復(fù)  更多評論
              

            # re: 分布式高可用id服務(wù)器設(shè)計實現(xiàn) 2015-09-18 10:22 star
            @single
            多節(jié)點沒有直接通信,所以id的唯一性是通過配置步長和偏移保證的,比如說整個集群部署兩個節(jié)點,那么一個節(jié)點產(chǎn)生的id都是奇數(shù),另一個節(jié)點產(chǎn)生的id都是偶數(shù),從而互相獨立且唯一。
            id的存盤是異步多線程實現(xiàn),類似于生產(chǎn)者消費者模式,實現(xiàn)方面目前主線程和數(shù)據(jù)庫線程之間通過管道傳遞數(shù)據(jù), 當然用eventfd + lockfree queue 會更好些,framework也提供這種通訊機制 。

              回復(fù)  更多評論
              

            # re: 分布式高可用id服務(wù)器設(shè)計實現(xiàn) 2015-09-18 11:41 single
            @star
            那保存這一塊可以考慮將產(chǎn)生的id推到消息隊列。  回復(fù)  更多評論
              

            # re: 分布式高可用id服務(wù)器設(shè)計實現(xiàn) 2015-10-30 10:48 路人
            id用一個進程分配既費勁又浪費還可能出現(xiàn)單點問題,用uuid就行了,mongodb的id隨便在哪生成都不重復(fù)  回復(fù)  更多評論
              

            狠狠色婷婷综合天天久久丁香| 72种姿势欧美久久久久大黄蕉| 99久久精品国产一区二区蜜芽| 青青青国产精品国产精品久久久久| 久久国产免费直播| 国产亚洲精久久久久久无码77777| 久久久久免费看成人影片| 久久久久久久综合综合狠狠| 亚洲欧洲中文日韩久久AV乱码| 久久狠狠色狠狠色综合| 久久青青草原精品国产不卡| 国产午夜久久影院| 中文成人无码精品久久久不卡| 久久婷婷国产综合精品| 国产亚洲精品久久久久秋霞| 粉嫩小泬无遮挡久久久久久| 久久人人爽人人爽人人片AV不| 色综合久久综精品| 久久99精品久久只有精品| 久久久久久噜噜精品免费直播| AV无码久久久久不卡蜜桃| 一本大道久久香蕉成人网| 国产高清美女一级a毛片久久w| 久久亚洲国产欧洲精品一| 99久久精品免费看国产一区二区三区 | 久久国产精品成人影院| 性做久久久久久久久老女人 | 久久99精品久久久久久9蜜桃| 99999久久久久久亚洲| 久久婷婷人人澡人人爽人人爱| 欧美色综合久久久久久| 99久久精品国产综合一区| 狠狠狠色丁香婷婷综合久久五月| 亚洲AV无码久久| 国产三级久久久精品麻豆三级| 成人久久免费网站| 久久人妻无码中文字幕| 久久SE精品一区二区| 亚洲一区精品伊人久久伊人| 欧洲性大片xxxxx久久久| 麻豆久久|