zookeeper 配置

globalOutstandingLimit

这个配置指定了等待处理的最大请求数量的限制(zookeeper.globalOutstandingLimit)。

client发送请求的速度可能会比server端处理的速度快,会导致请求在server端排队,最终(在若干秒内)会使server的内存耗尽。为了避免这一点,如果等待的请求数量达到了globalOutstandingLimit,server端会拒绝client的请求。但是这个限制不是hard限制。每一个client至少能有一个outstanding请求,否则连接会开始出现超时。所以,当达到globalOutstandingLimit之后,只有在没有任何的pending请求时,server才会从client连接读取数据。

 

为了决定某一台确定的server的限制,可以简单的用这个配置项的值除以server的数量。现在没有一种聪明的方式来决定这个值来进行限制,总的说来,这个配置项的值就是outstanding请求的上限。实际上,负载无法在server间进行均衡,总有一些server的负载会高一些,即使没有达到上限。

默认的限制为1000个请求。通常不需要改变这个配置,如果有很多client会发送非常大的请求,你需要调低这个值,但是在实践中通常不需要改变这个值。

 

maxClientCnxns

决定了每个IP地址可以发起的socket连接个最大个数。

ZooKeeper使用了flow control和limit来避免连接过载。建立连接消耗的资源远远超过普通的操作消耗的资源。一瞬间过多的请求会造成拒绝服务的问题,所以加上了这个限制,当某个IP的连接超过了这个限制,server会拒绝连接。默认值为60。

 

clientPortAddress

默认server会监听所有的网络接口提供client来连接。有一些服务器会有多个网络接口,通常一些为内网接口一些为外网接口。如果不想开放外网接口,可以将此配置项设为内网接口。

 

minSessionTimeout

这是session过期的最小超时时间,单位为毫秒。当client发起连接时,它会请求一个特定的超时时间,但是实际的超时时间并能小于这个配置项。

 

开发者喜欢立即并准确的检测到client端的失败。但不幸的是,系统不能实时的检测到,实际上是使用心跳和超时来做的。超时的使用依赖于client端和server端的网络延迟和可靠性。超时时间必须至少等于网络的round trip time,但是偶尔会有丢包的情况,在这种情况下接收响应的时间会增加,因为会发送发送丢失的包。

 

默认minSessionTimeout是tickTime的2倍。把这个值设置得过低的话会导致错误的检测client的失败。设置得太高的话会导致检测client的失败的延迟。

 

maxSessionTimeout

这是最大的session超时时间,单位为毫秒。当client发起连接时,它会请求一个特定的超时时间,但是实际的超时时间并能大于这个配置项。

 

尽管这个配置不会影响系统性能,但会限制client消耗系统资源的时间。默认是tickTime的20倍。

 
0
posted @ 2016-04-08 13:47  zenghui940  阅读(1114)  评论(0编辑  收藏  举报