cassandra 学习笔记(3)

为什么80%的码农都做不了架构师？>>>   

当某个end point拿到一个key(比如”王老六”)并想取出他的相关信息的时候,这个节点是怎么知道这个key的相关信息是存放在哪些节点中的呢? 以下将用从客户端拿到的”get_clomun”请求为例，进行说明：

      “get_column”的相关信息会在CassandraServer的get_column(String tablename, String key, String columnPath)方法中被封装成一个readCommand实例，该对象简单包含了请求信息，另外也提供了一些别的方法。

      然后该command实例会最终被交给 StorageProxy.readProtocol(command,StorageService.ConsistencyLevel.WEAK)来处理，并期待这个方法能返回一个和key关联的columnFamily的数据，这些数据被装在一个row对象里返回的。

      在上述的StorageProxy.readProtocol(…)这个方法中，首先要做的事情就是根据提交的key(“王老六”)确定他的相关信息内容是存放在那些end point中的。而这个寻找end point的工作由StorageService.instance().getNStorageEndPoint(command.key)来完成。

      实际上，上述的StorageService的getNStorageEndPoint(String key)方法调用了他持有的实例”nodePicker_”的getStorageEndPoints(Token token) 来完成寻找end point这件事情。

      题外话：StorageService这个实例提供了本地节点数据存储和与其他节点交互的服务，这个实例是在节点启动之初被建立的，在建立的时候该实例会初始化一个nodePicker_放在其内部，这个nodePicker主要负责本地节点同其他节点的交互规则，也就是如何选择其他节点的策略。当前的策略有两种:RackAwareStrategy–机架敏感 和 RackUnawareStrategy–非机架敏感，默认策略是RackUnawareStrategy。

      所以默认情况下，nodePicker_就是一个RackUnawareStrategy实例，而他的 getStorageEndPoints(Token token)将被用来查找合适我们给出的key(“王老六”)的end point,这里合适的意思是“存有关于这个key的信息”。而这里提到的token是由key封装得来的，他对key进行了hash，并且继承了 Comparable接口。也就是说，这个token实例是可以和其他同类token比较大小的，而这样做的目的是为了“可以在Token组成的list 上进行二分查询Collection.binarySort，并定位查找目标的在list中的相对位置”–这种查找操作将被经常使用。默认情况下 token是一个BigIntegerToken的实例。

      nodePicker_最终会将查找的工作交给getStorageEndPoints(Token token, Map tokenToEndPointMap)来做，这个方法会返回一个查找到的end_point的数组。以下是对RackUnawareStrategy中的相应方法的说明（因为默认是使用这个方法）: //此处的tokenToEndPointMap保存了该节点知道的所有其他节点，并且可以根据他们的token查找到

//此处的token是我们要查找的key(“王老五”)生成的token,他跟上面end point的token生成的算法是相同的，也都是BigIntegerToken

  public EndPoint[] getStorageEndPoints(Token token, Map tokenToEndPointMap)     {         //根据key寻址的切入点         int startIndex;         List list = new ArrayList ();         int foundCount = 0;         //将key的set装入一个ArrayList中，并完成排序，（一位token是comparable的）         List [...]

转载于:https://my.oschina.net/javagg/blog/3233