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

            我們的應用場景類似電商,在一個訂單的生命周期內(nèi),有多個邏輯需要生成各自的id,還要考慮到可讀性和靈活性,我們決定實現(xiàn)一個獨立的id服務。
            首先,id服務必須具有高可用性,業(yè)務邏輯處理中創(chuàng)建id失敗是不可接受的,所以id服務必須分布式部署,有多個節(jié)點同時對外服務,一個節(jié)點失敗則重試其他節(jié)點,保證成功創(chuàng)建id。
            在分布式系統(tǒng)中保證數(shù)據(jù)的一致性成本是很高的,為了簡化設計和實現(xiàn),每個節(jié)點都設計成對等的、獨立的,不需要保持數(shù)據(jù)同步。
            其次,id服務必須可靠,數(shù)據(jù)不能丟失,因此數(shù)據(jù)的存儲放在獨立的mysql數(shù)據(jù)庫中,使用replace方式更新數(shù)據(jù),id服務本身記錄更新日志。
            最后,id服務必須靈活,可以自定義id格式,可以高效靈活的實現(xiàn)客戶端,因此通訊協(xié)議使用json over udp方式,在id服務端使用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ī)則名字, 由服務端定義
                app_name : 應用名或命名空間 , 客戶端自定義,rule_name和app_name一起決定生成ID的唯一性
                salt :  自定義參數(shù) ,可選項 ,
                seq : 自定義參數(shù),可選項,原樣返回
                例如:
                創(chuàng)建ID請求:  {"action":"get","rule_name":"o2o","app_name":"test"}
                響應:{"code":0,"message":"success","data":"505140001"}
                監(jiān)控請求:{"action":"monitor","rule_name":"o2o","app_name":"test"}
                響應:{"code":0,"message":"ok","data":{"counter":3,"node_offset":1}}
            性能
                id服務器使用c++實現(xiàn),性能測試做的比較簡單,因為性能不是id服務的主要關注點, 簡單以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 : 平均耗時(秒)
                服務器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ù)落地的預保存和批量保存機制,一方面減少數(shù)據(jù)庫壓力,一方面增加異步保存的可靠性。
            2.由于主線程和數(shù)據(jù)庫線程只需要傳遞sql語句,將線程間通信由pipe方式改為eventfd + lockfree queue方式。
            posted on 2015-09-17 14:09 star 閱讀(18506) 評論(4)  編輯 收藏 引用

            Feedback

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

            # re: 分布式高可用id服務器設計實現(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也提供這種通訊機制 。

              回復  更多評論
              

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

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

            久久精品国产精品国产精品污| 久久99这里只有精品国产| 国产精品美女久久久久久2018| 国产成人无码久久久精品一| 久久午夜电影网| 亚洲精品午夜国产va久久| 久久WWW免费人成一看片| 四虎国产精品免费久久久| 久久一区二区三区免费| 久久久久久亚洲Av无码精品专口| 久久青草国产手机看片福利盒子| 久久亚洲天堂| 久久精品无码一区二区三区| 污污内射久久一区二区欧美日韩 | 亚洲中文字幕无码久久精品1| 97精品国产91久久久久久| 亚洲国产成人久久一区久久 | 久久91亚洲人成电影网站| 久久人人爽人人爽AV片| 狠狠色丁香久久综合五月| 久久成人国产精品免费软件| 久久久久亚洲精品中文字幕| 久久99国产精品99久久| 性色欲网站人妻丰满中文久久不卡| 久久99国产一区二区三区| 91精品国产高清久久久久久io | 国产香蕉久久精品综合网| 91秦先生久久久久久久| 久久久久亚洲av无码专区喷水| 四虎影视久久久免费| 久久综合久久伊人| 久久精品国产一区二区三区| 伊人丁香狠狠色综合久久| 久久九九亚洲精品| 久久精品国产69国产精品亚洲| 7777久久亚洲中文字幕| 国产综合久久久久| 色成年激情久久综合| 久久久九九有精品国产| 国产999精品久久久久久| 精品无码久久久久久久动漫|