技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统架构 --> Cassandra之Token

Cassandra之Token

浏览:2964次  出处信息

    有一个多月没有更新过blog了,有点惭愧。不管何种理由,不管工作生活有何种变动,有一些我们内心真正追求的东西,不能放弃。昨天晚上,世界杯大幕拉开,在等待揭幕战的过程中,看了一段Cassandra关于dht部分的源代码。要在生产系统中运维,则数据如何分布不得不做周详细致的考虑。

    将Cassandra用于实际的生成环境,一个必须要考虑的关键问题是Token的选择。Token决定了每个节点存储的数据的分布范围,每个节点保存的数据的key在(前一个节点Token,本节点Token]的半开半闭区间内,所有的节点形成一个首尾相接的环,所以第一个节点保存的是大于最大Token小于等于最小Token之间的数据。

    根据采用的分区策略的不同,Token的类型和设置原则也有所不同。 Cassandra (0.6版本)本身支持三种分区策略:

    RandomPartitioner:随机分区是一种hash分区策略,使用的Token是大整数型(BigInteger),范围为0~2^127,因此极端情况下,一个采用随机分区策略的Cassandra集群的节点可以达到2^127+1个节点。嗯,为什么是2^127?因为Cassandra采用了MD5作为hash函数,其结果是128位的整数值(其中一位是符号位,Token取绝对值为结果)。采用随机分区策略的集群无法支持针对Key的范围查询。假如集群有N个节点,每个节点的hash空间采取平均分布的话,那么第i个节点的Token可以设置为:

 i * ( 2 ^ 127 / N )

    下面的测试程序是从org.apache.cassandra.utils.FBUtilities类抽取出来的计算MD5值的函数,输入任何字符都可以得到其对应的MD5的整数值,利用该值和节点的Token对比即可知道该Key对应的数据归属于哪个节点:

以下是代码片段:
import java.io.*;
import java.util.*;
import java.math.BigInteger;
import java.security.MessageDigest;

class get_md5{
  static final Scanner cin=new Scanner(System.in);

  public static byte[] hash(String type, byte[]... data){
    byte[] result = null;
    try{
      MessageDigest messageDigest = MessageDigest.getInstance(type);
      for(byte[] block : data)
        messageDigest.update(block);
      result = messageDigest.digest();
    }
    catch (Exception e){
      throw new RuntimeException(e);
    }
    return result;
  }

  public static BigInteger hash(String data){
    byte[] result = hash("MD5", data.getBytes());
    BigInteger hash = new BigInteger(result);
    return hash.abs();
  }

  public static void main(String[] args){
    while(cin.hasNext()){
      String str1=cin.next();
      BigInteger a= hash(str1);
      System.out.println(a);
    }
  }
}
以下是引用片段:
D:>java get_md5
ningoo
100335222541762605209205022078301814192
江枫
48295316926871024838894171432474082043

    OrderPreservingPartitioner:如果要支持针对Key的范围查询,那么可以选择这种有序分区策略。该策略采用的是字符串类型的Token。每个节点的具体选择需要根据Key的情况来确定。如果没有指定InitialToken,则系统会使用一个长度为16的随机字符串作为Token,字符串包含大小写字符和数字。

    CollatingOrderPreservingPartitioner:和OrderPreservingPartitioner一样是有序分区策略。只是排序的方式不一样,采用的是字节型Token,支持设置不同语言环境的排序方式,代码中默认是en_US。

    分区策略和每个节点的Token(Initial Token)都可以在storage-conf.xml配置文件中设置:

以下是引用片段:
<Partitioner>org.apache.cassandra.dht.RandomPartitioner</Partitioner>
<InitialToken>10633823966279300000000000000000000000</InitialToken>

    节点初始化完成以后,Token值做为元数据会保留在system keyspace中,每次启动会以该值为准,即使再改动配置文件中的InitialToken也不会产生任何影响。

以下是引用片段:
Saved Token found: 10633823966279300000000000000000000000

    通过nodetool的ring命令,可以查看集群各个节点的Token,这些Token值最好备份下来,当出现节点彻底顺坏时,可以重新设置同样的Token,确保数据分布可以不受节点损坏的影响。

以下是引用片段:
 nodetool -h test ring
Address       Status     Load          Range                                      Ring
                                       85070591730234600000000000000000000000
192.168.0.1 Up         0 bytes       10633823966279300000000000000000000000     |<--|
192.168.0.2 Up         0 bytes       85070591730234600000000000000000000000     |-->|

    PS: 在我的0.6.2的一个测试集群中,使用nodetool时不小心连到了9160端口,结果每次都会把节点搞挂,百试百灵。而且直接telnet到9160端口,随便发送个字符,也会把节点搞崩溃。不知道是我的测试环境的原因,还是Thrift有bug,这样节点的健壮性就有问题了,这个端口只能接受协议格式内的信息。对Java和Thrift都不太了解,把这个问题抛出来,希望有大牛能帮忙找到原因。

    Update:之前贴的nodetool错连9160端口的报错可能有点误导大家,因为jmx用的默认的8080端口,连9160端口jmx报错是正常的,问题是节点不应该崩溃的。看了/var/log/cassandra/system.log中记录的节点错误信息,报的是OOM,Cassandra的java进程都消失了。调整了一下jvm参数,将heap的最小内存从默认的256MB设置到1G(-Xms1G),还是有同样的问题。另外,我的java环境是jre1.6.0_18。

以下是引用片段:
ERROR [pool-1-thread-1] 2010-06-12 16:49:40,459 CassandraDaemon.java (line 78)
Fatal exception in thread Thread[pool-1-thread-1,5,main]
java.lang.OutOfMemoryError: Java heap space
        at org.apache.thrift.protocol.TBinaryProtocol.readStringBody(TBinaryProtocol.java:296)
        at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:203)
        at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:1113)
        at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:253)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

    Google了一把这个错误,也有人碰到过,并且发现Thrift确实有类似的bug:

    https://issues.apache.org/jira/browse/THRIFT-601

    参考文档:

    http://wiki.apache.org/cassandra/Operations

建议继续学习:

  1. hbase运维    (阅读:13678)
  2. 我对技术方向的一些反思    (阅读:9874)
  3. Key-Value小数据库tmdb发布:原理和实现    (阅读:7315)
  4. SQL vs NoSQL:数据库并发写入性能比拼    (阅读:6629)
  5. 让Redis使用TCMalloc,实现高性能NOSql服务器    (阅读:6100)
  6. Using MySQL as a NoSQL    (阅读:5668)
  7. SQL到NOSQL的思维转变    (阅读:5647)
  8. nosql数据库选型    (阅读:4816)
  9. 分享会-高性能nosql数据库redis    (阅读:4445)
  10. Cassandra和HBase主要设计思路对比    (阅读:4139)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1