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

踩