我认为，增加延迟并不是真正解决问题，而是将其隐藏起来，直到您增长并添加更多的媒体和服务器，因此lsyncd将花费更长的时间，您每次都必须增加延迟。
还有，更新现有帖子怎么样？人们可能会添加媒体项目和更新，或者向库中添加更多项目，您将不得不在每次保存操作上添加延迟，听起来非常粗糙、脆弱和糟糕的用户体验。
我可以想出三种方法来解决这个问题。首先，如果在目标服务器上找不到请求的文件，您可以将请求代理到wp内容/上载到“主”服务器。我想你可以用try_files 在nginx中：
try_files $uri @proxy;
location @proxy {
proxy_pass http://master:80;
}
这应该可以很好地与当前设置配合使用，并且
@proxy 将在使用lsyncd的复制尚未完成时启动。
第二种方法是使用分布式文件系统，如GlusterFS或Ceph。您可以以类似NFS的方式使用它们，即一次在多个节点上挂载、可读写，这样您就不必再拥有“主”web服务器——它们中的每一个都可以写入文件系统。
然而，请注意，在装载的远程文件系统上执行大量文件IO很容易成为性能瓶颈(#31066 因此，请确保在web服务器和文件系统集群之间有某种磁盘io缓存和非常低的延迟（至少是相同的机架或相同的数据中心）。
第三种选择是对象存储，最好使用HTTP访问，如Amazon S3。这将需要更繁重的工作，因为现在您必须将所有上载的文件移动到远程目标（不要被s3fs愚弄，它是一个蠕虫罐头），并且您将无法轻松地在本地执行操作，例如重新生成缩略图、从本地文件读取EXIF数据等。
现在，回答你原来的问题。与其增加延迟，我建议您考虑一下发布帖子的时间安排，比如用户点击发布按钮后的5分钟。为此，我会调查transition_post_status 行动，注意draft => publish 转换并将其更改为future 具有wp_insert_post().
希望有帮助！
