• 理解：把maxWarmingSearchers理解成一个提交队列，上一个提交没完成下一个提交就进入了，大概是下面这样的情况:

  1. 希望提交的数据马上可见，于是设置add之后马上提交

  2. 数据增量频率很高，每秒都有增量

  3. 服务器配置有限，每提交一次需要2秒;

  • 实验：那么问题来了，一分钟进行了60次提交，但是服务器需要120秒才能反应过来，接下来会发生这样的情况：

  1. 设置maxWarmingSearchers值为120：不会出现Error opening new searcher. exceeded limit of maxWarmingSearchers提示，但是120个提交积压在“提交队列”里面，数据依然不可见，因为下一分钟还有同样数据的增量和数据挤压，很快就会出现错误提示，如果将这个值无限放大，服务器会无法响应

  2. 设置maxWarmingSearchers值为119，出现Error opening new searcher. exceeded limit of maxWarmingSearchers提示，最后一个提交被拒绝

  • 思考:我们会发现,maxWarmingSearchers无论怎样设置都无法达到快速看到数据更新的初衷，那我们应该怎么做呢：

  1. 控制数据提交的频率

  2. 使用softcommit协调数据一致性延迟要求

  3. 从业务角度理解需求，不要单纯做技术实现

  • 进步：:那么maxWarmingSearchers参数和日志的意义在哪里呢：

  1. 控制服务器压力，避免提交过于频繁导致服务器无法正常提供检索服务

  2. 作为一个预警，知晓资源已经接近阈值