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