cassandra 學習筆記(2)

源碼中對節點的以下稱呼應該是等價的: end point , node ,  machine , datacenter , host。

    cassandra節點的啓動main()在類org.apache.cassandra.service.CassandraDaemon中，細節在 setup()中。過程當中會start一個CassandraServer的實例peerStorageServer。 peerStorageServer在創建的時候，內部會實例化一個 StorageService實例，在該StorageService實例初始化的過程當中，該節點的全部功能服務會被配置激活，這些操做是在 StorageService的默認構造器中完成的。

    StorageService的構造器中大體作了以下幾件事情：

    1)生成一個storageLoadBalancer_s實例負責負載均衡，如今尚未明白原理。

    2)生成一個endPointSnitch_實例，這個提供了對兩個end_point進行比較的一個途徑，基本上是判斷兩個end_point是否是同一個ip等

    3)啓動了MessagingService，而且註冊了一些handler實例。MessagingService是負責該end_point與其餘end_point進行通訊的。兩個節點間通訊的內容被封裝在一個Message的實例裏面。

       好比，若是節點A想向節點B得到必定的數據，那麼A須要經過本身的MessageService向節點B發送一個Message實例，這個實例裏面包含了以下信息：這個請求的類型（屬於什麼stage） ，這個請求要調用的B的哪一個handler來處理，以及這個請求的其餘具體內容。當節點B接收到節點A發送過來的Message實例後，會將根據這個 Message實例內部指定的handler信息,將該實例轉發相應的handler去處理。固然這樣作的前提是這個指定的handler已經在B節點註冊了，而這個註冊過程就是在StorageService啓動的時候完成的。

    4)consistencyManager_：還沒明白什麼意思。

    5)StageManager的配置：

       這個stage的概念來自於「SEDA「( staged event driven architecture)中的」S」,參考http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf。

       大體意思好像是能夠將一個工做流程分爲若干個階段(stage)，而後給各個stage動態的分配線程資源來處理stage內定義的邏輯。stage和 stage之間的通訊是經過任務隊列完成的，當一個stage的邏輯執行完後，若是須要調用下一個stage來繼續執行，那麼就往下一個stage保有的任務隊列中寫入必要的任務信息。

       這樣的SEDA結構的好處是：在實際的運行當中各個stage的忙閒程度是不同的，能夠經過將比較閒的stage上的線程資源分配給同期比較忙的stage來實現效率上的提升。

       在cassandra中，仍是以3)中例子說明，在A節點發往B節點的Message實例中有一個「這個請求的類型」的信息，這個信息保存在 Message實例內header實例的type_上，是一個字符串。這個字符串標明瞭當MessageService獲取了Message實例後究竟由那個 stage來負責執行指定的handler對象。由於handler對象只是定義了對Message的處理邏輯，因此須要stage裏面的線程來對其進行執行。

       當前的stage只有4種，依次在StroageService的 /* All stage identifiers */標註下被定義，分別負責不一樣的任務，「ROW-READ-STAGE」是負責讀取的，其餘的含義尚未徹底搞清楚，大概是負責修改，數據壓縮和 http後臺頁面信息接收的。

       StageManager部分的源碼還沒喲看到，多是負責各個stage間線程調度的吧。

    6)設置nodepicker_定義了當前節點對周圍節點的查詢策略，具體的還不清楚

轉：http://blog.csdn.net/pakly_9527/archive/2009/08/13/4441540.aspx