一.简介
拼写检查是个不错的功能，不过还可以根据用户的输入给出建议查询词，从最开始就避免拼写错误。在移动端中“胖手指失误”是很常见的。自动建议就能发挥很大的作用。
效果如下：
一般情况下，自动建议功能需要满足两个要求：
1.速度快。一个笨重的输入方案不能跟上用户的输入节奏，没有比这更让人恼火的了。建议组件必须保证随着用户输入的每个字符更新建议，这种响应达到毫秒级。
2.根据词频顺序返回排名建议。如果建议的是索引中只有少数文档出现的罕见词，特别是当用户只输入少量字符时，这种建议是没有意义的。
二.自动建议请求处理器
Solr专门设计了自定义的请求处理器，用来封装简单界面背后的复杂行为。代码如下：
该代码的定义修改了原来的搜索组件定义，仅包含建议搜索组件。它用一个名为suggest的搜索组件取代了默认组件栈【query、facet、debug等】。请记住，自动建议的关键要求是执行速度快，因此不希望/suggest处理器在执行其他搜索组件上消耗太多资源。
为了收到查询建议，搜索应用必须发送请求给/suggest处理器。代码如下：
三.自动建议搜索组件
当/suggest处理器收到一个请求时，它会调用建议搜索组件来生成建议。代码如下：
拼写检查和自动建议之间存在一个关键性的区别。拼写检查从一个完整的查询词中生成建议，而自动建议只具有预修正功能。拼写检查使用字符串距离算法来寻找词项与查询词之间的相似性。自动建议并没有一个完整的词来生成建议，因此字符串距离并没有太大的意义。
实现自动建议的一个原始方法是，当用户输入时使用通配符搜索。然而，对于自动建议而言，通配符搜索速度太慢，需要另寻其它方法。Solr内置的建议组件使用前缀树的数据结构，它支持使用前缀进行快速查找，这正是预输入建议所需要的。
Solr的查找结构对通过前缀查找词项是有效的，当用户输入at时，Solr能快速找到以at开头的很多词。在大型搜索中，一个前缀能匹配出很多词项，这时我们不希望低频率词好罕见词对建议列表造成干扰，因此需要一种方法，按照热门程度对查询建议词进行排序。从大多数用户角度考虑，如果一个词项仅在数百万个文档中的几个文档中出现过，那么它可能不是一个很好的查询建议。
上面的自动建议使用org.apache.solr.spelling.suggest.fst.FSTLookup类，它的数据结构基于有限状态自动机，无论前缀长短，都能够进行快速、即时的查找。FSTLookupFactory方法构建速度相对较慢，但它的内存占用量很小，对于大型字典而言是一个不错的选择。
当索引新的文档时，建议词典必须重新构建，从而添加新词。