源码中对节点的如下称呼应该是等价的: 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