Manual:Maxlag parameter/zh

如果您的MediaWiki是部署在並行式數據庫叢集中（如维基媒体所用），高频次的编辑可能使副本伺服器滞后. 其中一種解決辦法是，每當副本延誤超過某一臨界值时，自动停止所有機器人和維護工作. MediaWiki 1.10中引進了maxlag參數，讓客戶端的程式可以處理這種情況. 自1.27版，maxlag參數的機制更新为仅限于 的請求.

使用 時，可以透過URL查詢字串或POST数据指明以秒為單位的整數作為maxlag參數. 例如，[/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=1 此链接]显示"MediaWiki"页面的元数据，除非延时大于1秒，而[/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 此链接](在结尾加-1)显示了实际延迟而没有元数据.

如果已超过请求中指定的延迟，则将返回503状态码（或在API请求期间是200状态，另见），响应正文格式如下：

下列HTTP标头被设置：


 * Retry-After: 建议客户端在重试前最少等待多少秒
 * X-Database-Lag: 最延后的从数据库延时的秒数

在维基媒体项目的建议用法如下：

如果你收到一个延迟错误提示，将你的脚本暂停至少5秒再进行尝试. 当心不要进入负载循环.
 * 使用 maxlag=5 (5秒). 这是个合适的不过分的值，已设为Pywikibot的默认值. 使用更高的值会带来更激进的行为，而更低的值更好.
 * It's possible that with this value, you may get a low duty cycle at times of high database load. That's OK, just let it wait for off-peak. We give humans priority at times of high load because we don't want to waste their time by rejecting their edits.
 * 异常高或持久的延时应当反馈至irc.freenode.net上的.
 * Interactive tasks (where a user is waiting for the result) may omit the maxlag parameter. Noninteractive tasks should always use it. See also API:Etiquette.

Note that the caching layer (Varnish or squid) may also generate error messages with a 503 status code, due to timeout of an upstream server. 客户端应当区别对待这些错误，因为它们可能在你尝试运行一个长时间的费时操作时总是发生. 在超时后不断重复操作会占用过多服务器资源并使你的客户端陷入无限循环. You can distinguish between cache-layer errors and MediaWiki lag conditions using any of the following:


 * X-Database-Lag header is distinctive to replication lag errors in MediaWiki
 * No Retry-After in Varnish errors
 * X-Squid-Error 标头会在squid错误中出现
 * The response body in replication lag errors will match the regex

为了测试目的，你可以设置一个负值故意让软件拒绝一个请求，例如下列URL：[/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 /w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1].

会检查maxlag参数，action API也会.