<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    敏捷、分布式、ALM過程自動化、企業(yè)應用架構
    posts - 14, comments - 0, trackbacks - 0, articles - 1
      BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

    2012年5月15日

    Hadoop實施已經有快一個月了,對Hadoop的概念理解、使用,Linux與shell腳本,甚至mysql都有了更多的理解。


    項目背景:用于互聯網信息收集后的關鍵詞匹配與內容提取。

    主要系統(tǒng)架構分為互聯網爬蟲、分析、業(yè)務應用三塊:

    簡單架構描述

    由于我在當中的角色主要負責分析架構的搭建,所以其他兩塊都畫得簡單,下面也不會過多的描述。


    Hadoop理解:提到Hadoop都想到的是云、分布式計算,在一段時間的實施之后有了一些具體的理解。

    Hadoop的優(yōu)勢:

    針對性能指標,當業(yè)務數據量總量或增速上升到一定級別,依靠關系型數據庫一定無法支持。對于非關系型數據庫,包括Nosql和Solr一類存儲方式,稍顯復雜,對于機器集群性能要求偏高(相對于文件系統(tǒng))。從數據使用模式上來講,目前海量數據的常常是不包含復雜邏輯的簡單統(tǒng)計整理(比如上述系統(tǒng)中的關鍵詞匹配)。這時候文件系統(tǒng)的優(yōu)勢反而比較明顯(結構簡單,邏輯簡單)。

    如上述系統(tǒng)的應用場景是怎么樣的呢,在一個強大的爬蟲系統(tǒng)之下,每個小時的數據增量在G到10G的級別,需要搜索所有的文件,獲取關鍵字的匹配,并且對匹配內容進行摘要。很類似我們windows里面的搜索功能,需要解決的就是如何在這樣增幅的文件系統(tǒng)之下,如何滿足業(yè)務系統(tǒng)的需求。

    分析系統(tǒng)有什么要求呢?

    能夠建立集群,分布式的保存數據文件內容(統(tǒng)一控制,可配置)。

    有一定的保護機制,保證數據或節(jié)點丟失不會影響系統(tǒng)使用。

    如果有一個任務腳本執(zhí)行框架機制就好了(用于并行計算)。

    能夠進行節(jié)點間的數據均衡。

    能夠簡單的查看所有的狀態(tài)與日志(web客戶端)

    可能主要是這些了。若自己實現,確實是個復雜而龐大的工程,現在我們有了Hadoop。


    系統(tǒng)物理架構:

    我們使用了一臺服務器,利用虛擬化,安裝了7套64x位的CentOS。一個Namenode,6個Datanode,復制數設置為3。每個系統(tǒng)分配到一個cpu,2G內存,Datanode掛載了500G的存儲空間。

    理想的Hadoop的搭建環(huán)境,參照《Best Practices for Selecting Apache Hadoop Hardware》(http://hortonworks.com/blog/best-practices-for-selecting-apache-hadoop-hardware/)一文,以及一些其他的文章。

    CPU:最好是雙CPU,8核左右。不用太高了。

    內存:推薦48G,但是4G應該就可以運行Hadoop了。

    硬盤:7200轉的SATA硬盤即可,Hadoop很占空間,所以盡量加。

    網絡:內部的數據交換要求非常高,內網最好是千兆網卡,帶寬為1GB。

    理想與現實,有錢與沒錢,呵呵。


    系統(tǒng)軟件架構:

    Hadoop:版本使用的是1.0.3,再下來就是2了,為了盡量簡化應用,所以不考慮2的新特性。對Hadoop沒有做太多的設置,基本基于默認。70為Namenode,71-76為Datanode。

    JDK:1.6.0_33 (64x)


    系統(tǒng)實施過程:

    HDFS部分:

    爬蟲抓取數據,整理后存放在50文件服務器,70以外部掛載的形式讀取。網頁文件比較小,假如直接寫入Hadoop對Namenode負載過大,所以入庫前合并,將每小時網頁整合成為一個文件寫入HDFS,由于區(qū)分類別,所以每小時基本寫入10個文件左右,總量在5-8G,耗時在40-50分鐘。(這個過程中,由于爬蟲的IO過于頻繁,導致文件讀取困難,所以做了定時任務,每小時啟動一次,將需要處理的文件先拷貝到臨時區(qū)域,合并入庫之后再刪除。此處應該是受到單核cpu的限制,所有操作均是串行,包括拷貝(cp)和合并入庫(java),所以Namenode嚴重建議配置稍高。)

    此處沒有太多問題。

    MapReduce部分:

    寫入完成后,進行分析工作,MapReduce。此處的工作過程為:數據庫定時生成關鍵詞列表文件。Job執(zhí)行時會讀取列表文件,匹配指定范圍內的HDFS文件(過去一小時),匹配出對應的表達式與HTML,Map過程結束。在Reduce階段,會將Map的所有數據入數據庫(Mysql)。

    此處出現過一些問題,記錄下來。

    1. Reduce階段需要加載Mysql的第三方驅動包。我在三個環(huán)境測試過(公司、家里、發(fā)布環(huán)境),使用 -libjars 一定可以,有的地方不需要也可以。不明確,懷疑與HADOOP_HOME環(huán)境變量有關。

    2. MR過程中使用log4j打印日志,在Hadoop臨時目錄(如果你沒有配置dfs.name.dir,dfs.data.dir,mapred.local.dir.mapred.system.dir等目錄,這些都會在hadoop.tmp.dir當中,我就偷懶都沒配置)mapred文件夾中查看一下。

    整個過程實際上還是比較簡單的,基本編碼量就在Job的部分,但是一個Java文件就夠了。在目前初級階段應該還是比較好用的?,F在還沒有測試Job的執(zhí)行效率。完成后會繼續(xù)記錄下來。有什么問題可以提出。我想到什么也會在本文繼續(xù)更新。

    posted @ 2012-08-08 20:21 一酌散千憂 閱讀(585) | 評論 (0)編輯 收藏

    硬件資源:

    三臺CentOS5.6虛擬機(Vmware

    本機 windows7 64x

     

    基本資源配置:

    三臺虛擬機均是克隆自同一個鏡像

    已經安裝了Java環(huán)境(jdk1.6.0_25

    Hadoop路徑在/usr/hadoop/hadoop-0.20.205.0

     

    操作步驟:

    1、機器名稱規(guī)范

    ip分別為128、129、130,將128設置為master,其他設置為slave

    修改

    /etc/sysconfig/network

    /etc/hosts

    兩處配置,名稱分別為hadoop-master\hadoop-slave01\hadoop-slave02

    注意:此處名稱最好不用使用下劃線,有可能引發(fā)namenode的啟動異常。

     

    2、修改Hadoop配置 

    master節(jié)點的conf中修改masterslave文件,分別為機器的ip地址

     

    修改master節(jié)點的conf中:

    core-site.xml

    <property>

    <name>fs.default.name</name>

    <value>hdfs://ip-master:9000</value>

    </property>

     

    mapred-site.xml

    <property>

    <name>mapred.job.tracker</name>                                   

    <value>master:9001</value>                                

    </property>

     

    hdfs-site.xm

    <property>

    <name>dfs.replication</name>

    <value>2</value>

    </property>

    注意此處的端口號均為默認。

     

     

    3、建立m-s之間的ssh連接

    首先masterslave機器都需要進行ssh信任文件生成,執(zhí)行如下命令:

    $ ssh-keygen -t rsa

    中間需要輸入的地方直接回車,接受缺省值即可

     

    由于使用root用戶登錄,所以密鑰文件生成在 /root/.ssh/文件夾下,存有一對密鑰id_dsaid_dsa.pub。

    此處id_dsa(私鑰)必須為其他用戶不可讀,所以文件屬性應當是600

     

    master機器執(zhí)行:

    id_dsa.pub(公鑰)復制為 authorized_keys

    $ cp id_dsa.pub authorized_keys

    如果是多臺機器需要,無密碼登陸,則各自機器產生公鑰追加到authorized_keys即可.

     

    使用scp協(xié)議覆蓋slave端的密鑰文件夾,使得slave機器信任來自master的連接:

    $ scp /root/.ssh/* ip-slave:/root/.ssh

     

     

    4、啟動服務 

    建議將$HADOOP_HOME/bin下的所有文件給與執(zhí)行權限:

    $ chmod 777 bin

     

    master作為namenod需要執(zhí)行如下腳本:

    $HADOOP_HOME/bin/hadoop namenode –format

     

    完成后執(zhí)行 $HADOOP_HOME/bin/start-all.sh

     

    5、問題檢查

    Hadoop根目錄下的logs文件中,檢查各個服務日志的啟動情況

     

     

    6、其他情況說明:

    Q: $HADOOP_HOME is deprecated

    A: 基本不會產生任何影響。由于腳本啟動時設置了該環(huán)境變量,就會提示用戶原有環(huán)境變量失效??梢匀∠h(huán)境變量設置,或者直接去bin/hadoop中找到這句話,去掉即可

     

    Q: 無效的選項 -jvm / Unrecognized option: -jvm

    A: 在使用root用戶登錄時 bin/hadoop 腳本就會進行判斷,加上-jvm參數。此處是為了進入jsvchttp://commons.apache.org/daemon/jsvc.html),此處并不確定是否bug,也不再進行詳細的追溯,解決方法就是進入 bin/hadoop 腳本中 找到 jvm 參數并去掉。

     

     

     

     

     

     

     

    posted @ 2012-07-04 07:38 一酌散千憂 閱讀(588) | 評論 (0)編輯 收藏

    公司里有同事時常抱怨,項目的用戶體驗太差,常常挨領導的罵。大家都認為是在用戶體驗的設計方面,公司人員的能力和經驗都不足引起的。發(fā)牢騷的時候也會說,如果公司能夠請得起“淘寶”的UI設計師,咱們的系統(tǒng)肯定會更上一層樓。我之前也一直認為如此,即我們的設計是影響項目體驗的重要原因。最近被領導調動去協(xié)助一個項目,產生了一些不一樣的體會。

    項目背景,一個新的產品,小型項目,純開發(fā)人員3-4人,2名熟練開發(fā)人員,1名新手,偶爾會有協(xié)助人員。沒有技術經理,項目經理身負多個項目,對項目進度關心不足,部門經理會協(xié)助進行工作和進度管理??梢钥吹焦芾磉€是比較混亂。

    由于項目進度太慢,領導要求從我這邊調一個熟練人員協(xié)助開發(fā)。我也基本了解他們的項目狀況,為了不讓我的人進去抓瞎,我就和他一起去了解項目情況。

    項目狀況比較糟糕,介入項目時已經開發(fā)了一段時間,保留的文檔只有兩份,一副數據庫說明,一份非常粗略的需求說明,而且還與開發(fā)進度不同步,就是沒有維護。

    我了解了一下項目目前的難度,開發(fā)人員和我反映一個是人員熟練程度的問題,二是需求變更的問題。我整體了解了一下項目目前的需求和設計,以及進度。就挑了一個模塊詢問他們的變更情況,這個模塊是一個關鍵詞匹配功能。結果是領導看了他們的頁面之后,嫌信息量太少,就要求提供一些更細化的數據展示。開發(fā)人員問我有什么意見,我就簡單講了一下頁面大概怎么構建。其中有一個點,是用于變更數據范圍,即查詢的表變更,我一開始覺得使用下拉框就可以,產生了一些意見。有人建議分為不同子模塊,或者tab頁,或者分為多塊并列展示。我想了想,就給他們講了我認為幾種方案的優(yōu)點缺點及適用范圍。

     

    1.       多塊并行展示:

    多個不同范圍的數據在同一頁面中分為不同區(qū)域以相同形式展示。原因是由于多塊數據之間有一定的關聯因果關系,或值得對比。適用范圍:如購物網站中的多個物品比較。

    2.       Tab頁:

    同一個頁面的多個tab頁,表示多個tab頁中的數據可能在一定的領域概念之下有一定的關聯,但關聯度不強。因為tab頁更重要的是強調一個同步工作的狀態(tài),即A tab頁查看一定信息,會打開B tab頁查看其他信息,中途還會切回A tab頁。適用范圍:如郵箱中,收件箱和草稿箱。

    3.       下拉框

    下拉框作為查詢條件的一部分,常用于有著常規(guī)或固定的可選擇內容中(如性別,月份),更多是以過濾的形態(tài)出現,即下拉框更適合針對某表的某個字段過濾,如果針對的是數據范圍或是對用戶需要直觀了解的重要業(yè)務條件則不太合適。適用范圍:如在考試成績中使用下拉框過濾“男女”或“及格不及格”。

    4.       單選框

    單選框與下拉框的作用范圍相似,但是不同之處在于將被選項全部展示,目的在于能夠讓用戶清楚的了解當前數據顯示的實際范圍或條件,以及備選的其他范圍或條件。更適用于選項與實際業(yè)務及當前展示數據關系重要,不同選項可能會引發(fā)用戶的不同行為。適用范圍:如銀行系統(tǒng)顯示了當前用戶下綁定多個帳號時,使用單選框。

     

    經過上述討論,我們仔細分析了這個模塊中用戶的實際需求,以及可能后續(xù)操作,最終選擇的單選框的方案。

    目前還沒有后續(xù),但是我想我們基于用戶真是需求的挖掘和后續(xù)操作的認真分析,會讓我們在與領導進行需求討論的時候有更加充分合理的依據。

    回來之后我又看了看淘寶的搜索頁面,比如就搜索“鞋子”來講,將品牌這欄設置為單選和下拉將是完全不同的效果,而確定方案的理由則是對于用戶的需求和實際行為的深入研究。這個應該是需求分析和調研的結果。將搜索條件以tag的形式標注于頁面上,并且可以直接點擊X按鈕進行刪除,我覺得更加可以傾向為用戶體驗。滿足并充分考慮了用戶實際需求的是好的需求分析,能夠簡化并引導用戶行為的是好的用戶體驗。

    當我們面臨的系統(tǒng)感覺非常難用的時候,往往這時候并非是用戶體驗差,我們應該檢討的是我們對用戶需求有沒有好好挖掘,做出來的是不是用戶想要、用戶能用的系統(tǒng)。

    posted @ 2012-05-22 05:02 一酌散千憂 閱讀(265) | 評論 (0)編輯 收藏

    Zookeeper的核心概念:

    ZNode

    Znode就是核心結構,Zookeeper服務中是由大量的Znode構成。Znode一般是由客戶端建立和修改,作為信息或標志的載體,甚至本身就是標志。

    Znode可以設置為持久(PERSISTENT)或臨時(EPHEMERAL),區(qū)別在于臨時的節(jié)點若斷開連接后就自動刪除。建立節(jié)點時可選擇是否使用序列號命名(SEQUENTIAL),若啟用則會自動在節(jié)點名后加入唯一序列編號。

    Session

    作為客戶端和Zookeeper服務之間交互的憑證。

    Watch

    當客戶端對節(jié)點信息進行查詢操作之后,可以選擇是否設置一個Watch。其作用就是當本次查詢的數據在服務器端發(fā)生變化之后,會對設置Watch的客戶端發(fā)送通知。一次發(fā)送之后,就將刪除該Watch,以后的變更或不再設置Watch則不會通知。

    ACLs

    節(jié)點的權限限制使用ACL,如增刪改查操作。

    Zookeeper的服務器安裝:

    1、下載對應版本號的tar.gz文件

    2、使用 tar xzvf zookeeper-3.4.2.tar.gz -C ./ 解壓

    3、設置,將conf/zoo.example.cfg復制到conf/zoo.cfg或者手動建立一個新的。

    4、啟動Zookeeper服務:bin/zkServer.sh start

    5、啟動客戶端連接:bin/zkCli.sh -server 127.0.0.1:2181(此處在本機,且使用了默認端口,且在Java環(huán)境中)

    6、使用命令:ls、get、set等。

    7、關閉Zookeeper服務:bin/zkServer.sh stop

    Zookeeper代碼編寫:

    代碼編寫部分比較簡單,因為暴露的接口很少,主要復雜在于項目如何使用節(jié)點以及節(jié)點信息。

    啟動Zookeeper服務之后,客戶端代碼進行節(jié)點的增刪,Watch的設置,內容的改查等。

    此處建議查看官方的《Programming with ZooKeeper - A basic tutorial》部分,當中舉了兩個例子來模擬分布式系統(tǒng)的應用。

    代碼基本沒有問題,唯一需要注意的就是:若之間按照原版進行調試時,有可能在調用

     Stat s = zk.exists(root, false);

    這句代碼時會出現一個異常,當中包括“KeeperErrorCode = ConnectionLoss for”。

    這個問題引起的原因可以看一下代碼

                    System.out.println("Starting ZK:");
                    zk 
    = new ZooKeeper(address, 3000this);
                    mutex 
    = new Integer(-1);
                    System.out.println(
    "Finished starting ZK: " + zk);

    最后一行有打印出Zookeeper目前的信息,若未修改的原代碼,此處的State應當是CONECTING。連接中的時候去驗證是否存在節(jié)點會報錯。解決的方法也很簡單,就是等到Zookeeper客戶端以及完全連接上服務器,State為CONECTED之后再進行其他操作。給出代碼示例:

    // 使用了倒數計數,只需要計數一次
    private CountDownLatch connectedSignal = new CountDownLatch(1); 
    SyncPrimitive(String address) {
        
    if(zk == null){
            
    try {
                System.out.println(
    "Starting ZK:");
                zk 
    = new ZooKeeper(address, 3000this);
                mutex 
    = new Integer(-1);
                connectedSignal.await(); 
    // 等待連接完成
                System.out.println("Finished starting ZK: " + zk);
            } 
    catch (IOException e) {
                System.out.println(e.toString());
                zk 
    = null;
            } 
    catch (InterruptedException e) {
                
    // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }
        
    //else mutex = new Integer(-1);
    }
    synchronized public void process(WatchedEvent event) {
        
    // 此處設立在Watch中會在狀態(tài)變化后觸發(fā)事件
        if (event.getState() == KeeperState.SyncConnected) {
            connectedSignal.countDown();
    // 倒數-1
        }
        
            
    synchronized (mutex) {
                
    //System.out.println("Process: " + event.getType());
                mutex.notify();
            }
    }

    這樣就可以正確運行代碼了。

    Zookeeper的應用場景及方式:

    此處是為引用,原地址為(http://rdc.taobao.com/team/jm/archives/1232 

    ZooKeeper是一個高可用的分布式數據管理與系統(tǒng)協(xié)調框架。基于對Paxos算法的實現,使該框架保證了分布式環(huán)境中數據的強一致性,也正是基于這樣的特性,使得zookeeper能夠應用于很多場景。網上對zk的使用場景也有不少介紹,本文將結合作者身邊的項目例子,系統(tǒng)的對zk的使用場景進行歸類介紹。 值得注意的是,zk并不是生來就為這些場景設計,都是后來眾多開發(fā)者根據框架的特性,摸索出來的典型使用方法。因此,也非常歡迎你分享你在ZK使用上的奇技淫巧。

    場景類別

    典型場景描述(ZK特性,使用方法)

    應用中的具體使用

    數據發(fā)布與訂閱

    發(fā)布與訂閱即所謂的配置管理,顧名思義就是將數據發(fā)布到zk節(jié)點上,供訂閱者動態(tài)獲取數據,實現配置信息的集中式管理和動態(tài)更新。例如全局的配置信息,地址列表等就非常適合使用。

    1. 索引信息和集群中機器節(jié)點狀態(tài)存放在zk的一些指定節(jié)點,供各個客戶端訂閱使用。2. 系統(tǒng)日志(經過處理后的)存儲,這些日志通常2-3天后被清除。 

    3. 應用中用到的一些配置信息集中管理,在應用啟動的時候主動來獲取一次,并且在節(jié)點上注冊一個Watcher,以后每次配置有更新,實時通知到應用,獲取最新配置信息。

    4. 業(yè)務邏輯中需要用到的一些全局變量,比如一些消息中間件的消息隊列通常有個offset,這個offset存放在zk上,這樣集群中每個發(fā)送者都能知道當前的發(fā)送進度。

    5. 系統(tǒng)中有些信息需要動態(tài)獲取,并且還會存在人工手動去修改這個信息。以前通常是暴露出接口,例如JMX接口,有了zk后,只要將這些信息存放到zk節(jié)點上即可。

    Name Service

    這個主要是作為分布式命名服務,通過調用zk的create node api,能夠很容易創(chuàng)建一個全局唯一的path,這個path就可以作為一個名稱。

     

    分布通知/協(xié)調

    ZooKeeper中特有watcher注冊與異步通知機制,能夠很好的實現分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調,實現對數據變更的實時處理。使用方法通常是不同系統(tǒng)都對ZK上同一個znode進行注冊,監(jiān)聽znode的變化(包括znode本身內容及子節(jié)點的),其中一個系統(tǒng)update了znode,那么另一個系統(tǒng)能夠收到通知,并作出相應處理。

    1. 另一種心跳檢測機制:檢測系統(tǒng)和被檢測系統(tǒng)之間并不直接關聯起來,而是通過zk上某個節(jié)點關聯,大大減少系統(tǒng)耦合。2. 另一種系統(tǒng)調度模式:某系統(tǒng)有控制臺和推送系統(tǒng)兩部分組成,控制臺的職責是控制推送系統(tǒng)進行相應的推送工作。管理人員在控制臺作的一些操作,實際上是修改了ZK上某些節(jié)點的狀態(tài),而zk就把這些變化通知給他們注冊Watcher的客戶端,即推送系統(tǒng),于是,作出相應的推送任務。 

    3. 另一種工作匯報模式:一些類似于任務分發(fā)系統(tǒng),子任務啟動后,到zk來注冊一個臨時節(jié)點,并且定時將自己的進度進行匯報(將進度寫回這個臨時節(jié)點),這樣任務管理者就能夠實時知道任務進度。

    總之,使用zookeeper來進行分布式通知和協(xié)調能夠大大降低系統(tǒng)之間的耦合。

    分布式鎖

    分布式鎖,這個主要得益于ZooKeeper為我們保證了數據的強一致性,即用戶只要完全相信每時每刻,zk集群中任意節(jié)點(一個zk server)上的相同znode的數據是一定是相同的。鎖服務可以分為兩類,一個是保持獨占,另一個是控制時序。 

    所謂保持獨占,就是所有試圖來獲取這個鎖的客戶端,最終只有一個可以成功獲得這把鎖。通常的做法是把zk上的一個znode看作是一把鎖,通過create znode的方式來實現。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點,最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。

    控制時序,就是所有視圖來獲取這個鎖的客戶端,最終都是會被安排執(zhí)行,只是有個全局時序了。做法和上面基本類似,只是這里 /distribute_lock 已經預先存在,客戶端在它下面創(chuàng)建臨時有序節(jié)點(這個可以通過節(jié)點的屬性控制:CreateMode.EPHEMERAL_SEQUENTIAL來指定)。Zk的父節(jié)點(/distribute_lock)維持一份sequence,保證子節(jié)點創(chuàng)建的時序性,從而也形成了每個客戶端的全局時序。

     

    集群管理

    1. 集群機器監(jiān)控:這通常用于那種對集群中機器狀態(tài),機器在線率有較高要求的場景,能夠快速對集群中機器變化作出響應。這樣的場景中,往往有一個監(jiān)控系統(tǒng),實時檢測集群機器是否存活。過去的做法通常是:監(jiān)控系統(tǒng)通過某種手段(比如ping)定時檢測每個機器,或者每個機器自己定時向監(jiān)控系統(tǒng)匯報“我還活著”。 這種做法可行,但是存在兩個比較明顯的問題:1. 集群中機器有變動的時候,牽連修改的東西比較多。2. 有一定的延時。 

    利用ZooKeeper有兩個特性,就可以實時另一種集群機器存活性監(jiān)控系統(tǒng):a. 客戶端在節(jié)點 x 上注冊一個Watcher,那么如果 x 的子節(jié)點變化了,會通知該客戶端。b. 創(chuàng)建EPHEMERAL類型的節(jié)點,一旦客戶端和服務器的會話結束或過期,那么該節(jié)點就會消失。

    例如,監(jiān)控系統(tǒng)在 /clusterServers 節(jié)點上注冊一個Watcher,以后每動態(tài)加機器,那么就往 /clusterServers 下創(chuàng)建一個 EPHEMERAL類型的節(jié)點:/clusterServers/{hostname}. 這樣,監(jiān)控系統(tǒng)就能夠實時知道機器的增減情況,至于后續(xù)處理就是監(jiān)控系統(tǒng)的業(yè)務了。
    2. Master選舉則是zookeeper中最為經典的使用場景了。

    在分布式環(huán)境中,相同的業(yè)務應用分布在不同的機器上,有些業(yè)務邏輯(例如一些耗時的計算,網絡I/O處理),往往只需要讓整個集群中的某一臺機器進行執(zhí)行,其余機器可以共享這個結果,這樣可以大大減少重復勞動,提高性能,于是這個master選舉便是這種場景下的碰到的主要問題。

    利用ZooKeeper的強一致性,能夠保證在分布式高并發(fā)情況下節(jié)點創(chuàng)建的全局唯一性,即:同時有多個客戶端請求創(chuàng)建 /currentMaster 節(jié)點,最終一定只有一個客戶端請求能夠創(chuàng)建成功。

    利用這個特性,就能很輕易的在分布式環(huán)境中進行集群選取了。

    另外,這種場景演化一下,就是動態(tài)Master選舉。這就要用到 EPHEMERAL_SEQUENTIAL類型節(jié)點的特性了。

    上文中提到,所有客戶端創(chuàng)建請求,最終只有一個能夠創(chuàng)建成功。在這里稍微變化下,就是允許所有請求都能夠創(chuàng)建成功,但是得有個創(chuàng)建順序,于是所有的請求最終在ZK上創(chuàng)建結果的一種可能情況是這樣: /currentMaster/{sessionId}-1 , /currentMaster/{sessionId}-2 , /currentMaster/{sessionId}-3 ….. 每次選取序列號最小的那個機器作為Master,如果這個機器掛了,由于他創(chuàng)建的節(jié)點會馬上小時,那么之后最小的那個機器就是Master了。

    1. 在搜索系統(tǒng)中,如果集群中每個機器都生成一份全量索引,不僅耗時,而且不能保證彼此之間索引數據一致。因此讓集群中的Master來進行全量索引的生成,然后同步到集群中其它機器。2. 另外,Master選舉的容災措施是,可以隨時進行手動指定master,就是說應用在zk在無法獲取master信息時,可以通過比如http方式,向一個地方獲取master。

    分布式隊列

    隊列方面,我目前感覺有兩種,一種是常規(guī)的先進先出隊列,另一種是要等到隊列成員聚齊之后的才統(tǒng)一按序執(zhí)行。對于第二種先進先出隊列,和分布式鎖服務中的控制時序場景基本原理一致,這里不再贅述。 

    第二種隊列其實是在FIFO隊列的基礎上作了一個增強。通??梢栽?nbsp;/queue 這個znode下預先建立一個/queue/num 節(jié)點,并且賦值為n(或者直接給/queue賦值n),表示隊列大小,之后每次有隊列成員加入后,就判斷下是否已經到達隊列大小,決定是否可以開始執(zhí)行了。這種用法的典型場景是,分布式環(huán)境中,一個大任務Task A,需要在很多子任務完成(或條件就緒)情況下才能進行。這個時候,凡是其中一個子任務完成(就緒),那么就去 /taskList 下建立自己的臨時時序節(jié)點(CreateMode.EPHEMERAL_SEQUENTIAL),當 /taskList 發(fā)現自己下面的子節(jié)點滿足指定個數,就可以進行下一步按序進行處理了。

     

    posted @ 2012-05-15 11:02 一酌散千憂 閱讀(4835) | 評論 (0)編輯 收藏

    主站蜘蛛池模板: 大片免费观看92在线视频线视频 | 77777_亚洲午夜久久多人| 无码专区AAAAAA免费视频| 亚洲一级视频在线观看| 国产精品成人免费综合| 成人免费区一区二区三区| 日本亚洲免费无线码| 91麻豆国产自产在线观看亚洲| 18级成人毛片免费观看| 亚洲AV无码专区在线观看成人| 亚洲情综合五月天| a毛片基地免费全部视频| 一个人免费观看视频在线中文| 亚洲综合视频在线观看| 亚洲国产成人久久综合一区77| 亚洲美女免费视频| j8又粗又长又硬又爽免费视频 | 亚洲人成伊人成综合网久久久| 精品成在人线AV无码免费看 | 在线成人a毛片免费播放| 全免费a级毛片免费看| 国产精品无码亚洲精品2021| 色婷婷亚洲十月十月色天 | 国产亚洲国产bv网站在线| 亚洲日韩中文无码久久| 在线日韩av永久免费观看| 1000部啪啪毛片免费看| 好男人资源在线WWW免费 | 久草免费福利视频| 久久精品国产亚洲av瑜伽| 18亚洲男同志videos网站| 亚洲中文字幕日产乱码高清app| 永久久久免费浮力影院| AV无码免费永久在线观看| 99精品免费视品| 一本岛v免费不卡一二三区| 亚洲午夜福利在线视频| 亚洲伊人久久大香线蕉啊| 亚洲国产精品国自产电影| 亚洲最大激情中文字幕| 亚洲AV无码乱码在线观看牲色|