zc.resumelb 1.0.2

基本部署

基本部署是最容易快速启动的。

[app:main]
use = egg:bobo
bobo_resources = zc.resumelb.tests

[server:main]
use = egg:zc.resumelb
address = 127.0.0.1:8000

resumelb -LINFO -a :8080 127.0.0.1:8000

基于ZooKeeper的部署

在基于ZooKeeper的部署中，工作进程注册到ZooKeeper，负载均衡器从ZooKeeper获取工作进程地址。随着工作进程的启动和停止，它们将自动添加到和从负载均衡器池中删除。此外，大多数配置参数都是从ZooKeeper中读取的，并且在ZooKeeper中更改时在运行时更新。有关ZooKeeper的更多信息以及如何构建和维护ZooKeeper树，请参阅http://pypi.python.org/pypi/zc.zk。

基于ZooKeeper的工人部署

与基本部署一样，您将基于ZooKeeper的工作进程作为WSGI堆栈中的服务器进行部署。由paste.server_runner zk 入口点提供Paste部署服务器运行器。运行器接受参数：

use egg:zc.resumelb#zk

这会选择基于ZooKeeper的工作进程运行器。

zookeeper CONNECTION

一个ZooKeeper连接字符串。

path PATH

工人在此获取配置并注册其地址的ZooKeeper节点路径。该节点应具有一个名为 providers 的子节点，其中发布地址。

address HOST:PORT

要监听的地址，形式为HOST:PORT

threads NTHREADS

如果指定了一个大于零的数字，则使用给定大小的线程池调用底层WSGI堆栈。

resume_file PATH

简历文件的路径。定期，工作进程的简历会保存到此文件，并在启动时读取该文件以初始化工作进程的简历。

tracelog LOGGER

请求跟踪日志并指定要使用的Python记录器名称。

[app:main]
use = egg:bobo
bobo_resources = zc.resumelb.tests

[server:main]
use = egg:zc.resumelb#zk
zookeeper = 127.0.0.1:2181
path = /lb/workers

zkresumelb -LINFO 127.0.0.1:2181 /lb

/lb
  /providers
  /workers
    /providers

1.0.2 (2015-03-11)

• 修复：当没有未决请求时，nagios监视器指标显示max request age为-1。这是愚蠢的。

• 修复了一个包装错误。

1.0.1 (2015-03-03)

• 修复：未捕获的应用程序异常在HEAD请求中被错误处理。

• 修复：在单版本模式下或使用替代池实现时，LB工人路径无法链接。

1.0.0 (2015-02-19)

• Nagios监控插件。请参阅src/zc/resumelb/nagios.rst。

• 现在您可以提供替代池实现。

  感谢： https://github.com/zopefoundation/zc.resumelb/pull/3

• 有一个新的池实现 zc.resumelb.classlesspool.ClasslessPool，它仅根据后备任务分配工作，忽略恢复。这对于没有大量驻留集或没有很好的请求隔离方式的小型应用程序很有用，但可以从ZooKeeper感知负载均衡中受益。

0.7.5 (2014-11-18)

• 修复：Tracelogs未包括启动和停止记录。

0.7.4 (2014-10-29)

• 修复：在返回迭代器之前未调用WSGI start_response函数的应用程序或中间件没有被适当处理。

• 修复：当负载均衡器从工人断开连接时，文件描述符泄漏。

0.7.3 (2014-06-04)

• 添加了一些优化以减少负载均衡器和工人之间的延迟。

0.7.2 (2014-06-02)

• 从负载均衡器到工人的keep-alive消息，以检测不干净地离去的工人。

  （请注意，工人不需要更新。）

0.7.1 (2012-10-17)

• 修复：当与ZooKeeper一起使用时，由于ZooKeeper“跳动”，负载均衡器可能最终与同一工人有多个连接。（ZooKeeper可能会报告工人已离开并返回，而实际上工人并未离开。）

• 修复：在单版本模式下，版本之间的跳动可能导致工人和书后备任务计算不正确，从而导致断言错误。

• 在单版本模式下，记录版本更改。

0.7.0 (2012-07-05)

• 在负载均衡器中添加了对不能有多个工人版本的应用程序的支持。您可以逐步升级工人。具有新版本的工人将被忽略，直到它们成为多数，此时lb将停止使用旧版本的工人。

0.6.2 (2012-06-15)

• 修复：缺少套接字超时可能导致请求泄漏。

0.6.0 (2012-05-11)

• 添加了一个命令行脚本来检索lb状态数据，假设您正在使用ZooKeeper感知的负载均衡器脚本并已请求状态服务器。（还更新了状态输出，以显示请求开始时间作为整数秒。）

0.5.2 (2012-05-09)

• 修复：在负载均衡器中缓冲数据时创建的临时文件未明确关闭。通常，它们通过垃圾回收关闭，但在某些情况下，它们的数量可能会迅速增加，导致文件描述符耗尽。

• 修复：Tracelog的‘I’记录不总是包含输入长度信息。

• 修复：仅在使用线程池时包含Tracelog的‘I’记录。

0.5.1 (2012-05-07)

• 修复：当构造函数未传递参数或读取恢复文件时，工人恢复数据未正确初始化，导致恢复不更新。

• 修复：将工人错误写入标准输出而不是记录。

• 修复：表现不佳的WSGI应用程序未能捕获错误，导致请求挂起而不是返回500响应。

0.5.0 (2012-05-03)

• 更改了tracelog记录的标识方式，以反映lb请求编号。记录通过包含lb标识符作为前缀来消除歧义。例如，“1.22”表示来自lb 1的请求编号22。

• 在定义与ZooKeeper注册的工作者时，您现在可以在paste.ini文件中提供描述，该描述将在ZooKeeper中显示。虽然pid本身提供了足够的信息来找到工作者，但通常描述（例如实例名称或路径）可以使它更容易。

0.4.0 (2012-04-27)

• 将负载均衡算法更改为考虑未充分利用的工作者的队列，以便使用更低的方差参数，从而使新工作者得到更好的利用。

• 将负载均衡算法修改为在处理第一个未完成请求时不惩罚工作者，从而稍微增加难度以保持与有技能的工作者的工作。（换句话说，当调整工作者评分并检查最大队列长度时，如果工作者的队列不为零，则从工作者的队列中减去1。

• 使用ZooKeeper时提供的状态服务器现在监听Unix域套接字。

• 使用ZooKeeper时提供的状态服务器现在包括每个工作者的最老请求的开始时间，用于监控。

• 修复：工作者在内存中缓冲了大的请求体。现在大请求体被缓冲到磁盘。

• 内部优化，特别是处理大请求和响应体的方面。

0.3.0 (2012-03-28)

修改了zkresumelb（与ZooKeeper一起工作的负载均衡程序）处理访问日志的方式。现在，您传递一个Python日志记录器名称。如果不传递任何内容，则不会记录任何内容。

0.2.0 (2012-03-27)

• 有一个新的API用于获取工作者简历，通常用于监控代码

  >>> import zc.resume.worker
  >>> print zc.resume.worker.get_resume(addr)

  这对于获取工作者的简历以及确保工作者正在接受负载均衡连接都很有用。

  还有这个脚本的版本

  bin/get-worker-resume 192.168.24.60:33161

• 当使用ZooKeeper时，您可以请求lb状态服务器。地址被注册到ZooKeeper。当您连接到它时，您将获得一个包含整体lb队列长度以及每个工作者的地址和队列长度的JSON字符串。

• 将更新设置方法修改为在不提供时将设置还原为默认值。这对于与ZooKeeper一起使用尤为重要，这样您就可以查看树并知道设置而无需了解更改历史。

• 在SIGTERM上添加了优雅的负载均衡器和工作者关闭。

• 修复：在使用多个负载均衡器时，跟踪日志请求ID分配不正确。

• 添加了打包元数据，以帮助找到gevent 1.0b1（位于http://code.google.com/p/gevent/downloads/list）

• 更新了应用程序跟踪日志的API，以匹配zc.zservertracelog，主要是为了为ZTK应用程序获取数据库日志。

0.1.0 (2012-03-09)

初始发布。