最近在看Cassandra，但自打配起一个集群后，负载就不均衡了。
Address Status State Load Owns Token
134154547520101788379756316570162344774
10.20.223.115 Up Normal 138.43 KB 32.81% 19836060994110698319501384270720800576
10.20.223.116 Up Normal 143.39 KB 7.93% 33327637713098975372896733928855304024
10.20.223.113 Up Normal 143.46 KB 28.38% 81617185997645741434910225007556485361
10.20.223.114 Up Normal 133.3 KB 3.01% 86736862331839877952832406350985306765
10.20.223.117 Up Normal 138.43 KB 5.90% 96770512718388865179675126530244922092
10.20.223.112 Up Normal 138.52 KB 21.97% 134154547520101788379756316570162344774
将 auto_bootstrap 设为 true后，只有一个节点的Token发生了变化。整体均衡度没有明显变化。
由于是初次接触Cassandra，怀疑是否有做过错误的
配置
而未被发现。
于是尝试重新搭建环境、增、删节点，均以失败告终。
也有
朋友
怀疑是数据量少或运行时间少导致的。但我看官方的数据，仅1G数据3个节点都是均衡的，我认为还是配置问题，而且官方介绍负载均衡的算法与Token有关。于是按官方说明手动计算Token：
def tokens(nodes):
for
x in xrange(nodes):
print 2 ** 127 / nodes * x
然后手动指定(conf/cassandra.yaml) initial_token值，启动后发现Token值并非读取这个配置。应该是头一次启动计算后写入到了
system
空间
里了(system空间中peers表中）。
然后手动更新所有节点的Token值：
bin
/nodetool -host 10.20.10.31 -port 8080 move 88888888888888888888888888888888888888
注意：Move过程会按新环移动现有数据，完成之后再查看节点信息。神了！虽然当前没有数据，但我已经感觉到问题被解决了：
Address Status State Load Owns Token
170141183460469231731687303715884105726
10.20.223.111 Up Normal 169.96 KB 14.29% 24305883351495604533098186245126300818
10.20.223.112 Up Normal 175.13 KB 14.29% 48611766702991209066196372490252601636
10.20.223.113 Up Normal 175.13 KB 14.29% 72917650054486813599294558735378902454
10.20.223.114 Up Normal 180.48 KB 14.29% 97223533405982418132392744980505203272
10.20.223.115 Up Normal 169.93 KB 14.29% 121529416757478022665490931225631504090
10.20.223.116 Up Normal 175.07 KB 14.29% 145835300108973627198589117470757804908
10.20.223.117 Up Normal 169.96 KB 14.29% 170141183460469231731687303715884105726
OK，加些数据看看是否均衡吧：
Address Status State Load Owns Token
170141183460469231731687303715884105726
10.20.223.111 Up Normal 1.26 GB 14.29% 24305883351495604533098186245126300818
10.20.223.112 Up Normal 1.26 GB 14.29% 48611766702991209066196372490252601636
10.20.223.113 Up Normal 1.26 GB 14.29% 72917650054486813599294558735378902454
10.20.223.114 Up Normal 1.26 GB 14.29% 97223533405982418132392744980505203272
10.20.223.115 Up Normal 1.26 GB 14.29% 121529416757478022665490931225631504090
10.20.223.116 Up Normal 1.26 GB 14.29% 145835300108973627198589117470757804908
10.20.223.117 Up Normal 1.26 GB 14.29% 170141183460469231731687303715884105726
实在是太均衡了，原来就是Token惹的祸！
另外的一篇
文章
：
Cassandra之Token
http://www.ningoo.net/html/2010/cassandra_token.html
有一个多月没有更新过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对应的数据归属于哪个节点：
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 ringAddress Status Load Range Ring 85070591730234600000000000000000000000192.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。
原文链接：
http://ju.outofmemory.cn/entry/245780
处理关系数据库集群（例如 Pgpool II 和 Postgres-XC）
处理存储集群（例如 GlusterFS）或 Amazon S3
处理多个反向代理、SSL 终结器、静态缓存、
负载
平衡器
处理专用应用程序主机以运行自动化作业
多层次安全加固
用于处理日常任务和维护的剧本（例如复制 SSH 密钥、执行 LMS 升级、执行主机升级、切换维护
一个现代、功能丰富且高度可调的 C/C++ 客户端库，适用于 Apache
Cassandra
2.1+，仅使用
Cassandra
的二进制协议和
Cassandra
查询语言 v3。此驱动程序也可以与其他 DataStax 产品一起使用：
异步 API
简单、准备和批处理语句
异步 I/O、并行执行和请求流水线
自动节点发现
自动重新连接
可配置的
负载均衡
适用于任何集群大小
延迟感知路由
元组和UDT
客户端时间戳
空闲连接心跳
支持物化视图和二级索引元数据
支持集群键顺序frozen<>和
Cassandra
版本元数据
黑名单、白名单DC和黑名单DC
负载均衡
策略
自定义身份验证器
具有 SSL 对等身份验证支持的反向 DNS
随机接触点
DSE 功能
DSE 认证
明文/DSE
GSSAPI (Kerberos)
DSE 地理空间类型
DSE代理认证和代理执行
DSE 日期范围
支持DataStax Astra云数据平台
更多详情、使用方法，请下载后细读README.md文件
创建
Cassandra
客户端
每个集群应该有一个
Cassandra
Client。 每个
Cassandra
Client 都有一个 ActorSystem。
val client = new
Cassandra
Client ( Seq ( " localhost " ))
Eureka是一项基于REST（代表性状态转移）的服务，主要在AWS云中用于查找服务，以实现
负载均衡
和中间层服务器的故障转移。
在Netflix，Eureka除了在中间层
负载
平衡中发挥关键作用外，还用于以下目的。
为了帮助Netflix Asgard，这是一种开源服务，可简化云部署，
在出现问题的情况下快速回滚版本，避免重新启动100个实例，这可能会花费很长时间。
在滚动推送中，以避免出现问题时将新版本传播到所有实例。
对于我们的
cassandra
部署，可以使实例流量减少以进行维护。
为我们的memcached缓存服务标识环中的节点列表。
用于出于各种其他原因承载有关服务的其他其他特定于应用程序的元数据。
由于某些必需的库是java8 （ servo ），因此构建需要java8 ，但是源和目标兼容性仍设置为1.7 。 请注意，应该签出标签以执行构建。
http://www.datastax.com/docs/1.2/initialize/token_generation#calculating-tokens-for-the-murmur3partitioner
一、环境 1、hadoop 0.20.2 2、操作系统 Linux 二、关于
负载均衡
1、一般情况下，数据在录入集群的时候就进行
负载均衡
，根据各个节点的情况来做数据平衡分发存放。 2、但是如果在新增节点之后，如果想做到
负载均衡
则需要使用balancer的命令。对于这个命令，一般是有一个阀值，默认是10% 也就是说，节点之间差额不过10%，集群认为就是
均衡
的。 3、当然，
负载
的越平均，查询相对也较快，但是
均衡
的过程会耗时不少。 三、操作 1、新添加节点到
1.1 CAP定理
CAP定理由加州大学伯克利分校Eric Brewer教授提出，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）三者不可兼得。并且由于分布式系统必须进行网络分区，将系统部署在不同的数据中心、节点上，故而分区容错性也就是CAP定义中的P必须实现。
所以，当前的分布式系统只能在C和A，也就是一致性和可用性
cassandra
集群要求严格的时间同步，有一点同步就会发生这样那样的问题，这个事情我已经在
cassandra
集群要求严格的时间同步里说明了，所以时间同步是
cassandra
集群的前提。
cassandra
使用的是最后一致性模型，也就是说一开始的并发更新的数据可能是不一致的，但是经过这段不一致的时间之后，系统会达到最终的一致性。让每个客户端看到的结果是一样的。
这个最终一致性的强度，在cas...
在第一部分中，我们介绍了一些基本实践，然后通过一个具体的例子帮助大家开启
Cassandra
数据模型设计之旅。你可以跳过第一部分直接阅读本篇文章，但是我推荐你看看第一篇文章中“术语和约定”部分。如果你是一个
Cassandra
新手，我还是建议你先阅读第一部分。
以下列出的实践有些可能会发生变化，我将提供相关JIRA地址给大家，以方便跟踪最新进展。下面让我们先从几个基本实践开始吧！
通过column
对线上nginx日志监控，采用的Elasticsearch+Logstash+Grafand架构的模式，本来运行的很正常的，今天上去看的时候，监控图标出现了以下报错:
后查阅相关资料，启动es的时候忘记设置堆内存（ES_HEAP_SIZE）导致这种情况。es默认启动是指定堆内存为1G，在生产环境肯定是不能满足的。于是，对ES的堆内存进行重新指定，修改方式如下：
打开ES的配置文件目录，找到ES的内存配置文件，文件名如下：
打开jvm.optinons将原本默认的 -Xms1g 、-Xms1g两个参数的值进
编写的Java文件编译成class文件，class文件放入JVM中转义机器码，让机器执行
Java跨平台：一次编译到处运行原理，是因为安装了不同文件操作系统的JDK（JVM）， 字节码（class）文件适配不同底层的操作系统（不同操作系统的文件操作/描述符不同，不同操作系统的句柄也不同），所以通过字节码...
源：http://hi.baidu.com/higkoo/blog/item/070ce226b751f0048b82a103.html
最近在看
Cassandra
，但自打配起一个集群后，
负载
就不
均衡
了。
Address Status State Load Owns Token ...
