[3]elasticsearch源码深入分析——Setting和Environment

本篇为ElasticSearch源码分析系列文章的第三篇,上文解释了ElasticSearch的启动过程,其中多处涉及到了Setting,Settings和Environment类,所以本篇就以这几个类为出发点,详细研究ElasticSearch的源码架构。

Setting

Setting<T>类位于common/settings包下,封装了典型的环境设定,比如:value,parsing,scope。在ElasticSearch或者任何ElasticSearch插件中使用到的设定,都是用这个类型安全(通过提供Property的枚举类)且通用的设定类搭配AbstractScopedSettings类来设定工程参数的。一般封装完善的基础设施类工程都会提供类似于ElasticSearch中的Setting这种环境设定类型的完善封装类。

Setting继承于ToXContentToBytes,由于ToXContentToBytes是ToXContent的继承类,该实现支持将对象序列化为BytesReference,所以该类是支持序列化的。该类的继承关系如图所示:

Setting的继承关系

Setting在ElasticSearch中是如何使用的呢?由于该类提供了简单直接的参数设定,先如下图这样定义一个类型为Boolean的Setting实例,类似于:

    public static final Setting<Boolean>;
    MY_BOOLEAN = Setting.boolSetting("my.bool.setting", true, SettingsProperty.NodeScope);

然后通过SECURITY_FILTER_BAD_DEFAULTS_SETTING.get(settings)得到给定参数settings中的my.bool.setting值。当然setting里面提供的逻辑也是很复杂。

Setting中的方法如下所示:

Setting中的参数设定

Setting中最关键的构造方法是:

private Setting(Key key, @Nullable Setting<T> fallbackSetting, Function<Settings, String> defaultValue, Function<String, T> parser, Validator<T> validator, Property... properties)

分别在Setting的实例中注入了以下变量:

  • Key:setting的key,如果是GroupSetting则代表group的前缀
  • EnumSet<Property>:包含的Property有
    • Dynamic:该setting是否是动态可更新
    • Final:该setting是否是最终地,如果是最终的,那么该setting将不可更新。在index已经关闭的情况下,在index范围内设置该属性(Final)将会失败
    • Filtered:该setting是否配置了过滤属性
    • NodeScope:该setting的节点范围
    • IndexScope:该setting的索引范围
    • Deprecated:该setting是否是被声明遗弃
    • isGroupSetting:该setting是否是一个setting集合
  • Function<Settings, String> defaultValue:在使用get()方法获取setting的原始默认字符串时用到,一般会传入泛型T的一个默认值((s)->value)
  • Setting<T> fallbackSetting:如果还没有定义变量setting,就用设置回退的setting。在调用Setting的get(Settings primary, Settings secondary) 方法时,如果primary不存在的话就会调用fallbackSetting的get方法
  • Function<String, T> parser:与validator函数接口联合使用通过get()获取setting的值
  • Validator<T> validator

Key是Setting中定义的接口,只有一个match方法。分别有以下四个实现类:

  • SimpleKey
    • GroupKey:match方法检查key必须以'.'结尾
    • ListKey:match方法检查key必须以'.'结尾
  • AffixKey:允许静态前缀和后缀。这是用于为不同账户设置动态名称空间。

Setting中定了一个函数接口Validator<T>,主要事来验证setting的,定义的validate方法被Setting实例的值和Map(Setting)实例所调用。如下图:

Setting的Validator接口

Settings

通过一个简单的构造方法或Settigns的内部静态类Builder的builder方法来产生Settings实例。

通过Settings.Builder来得到Builder的实例,通过Builder 的put和set方法来装配Builder,最后只要调用Builder 的builder()方法就能得到Settings的实例。如下图:

构造Settings实例

Settings中的FilteredMap做了函数接口封装设计,在继承AbstractMap的基础上,定义了函数借口Predicate<String> filter,如此的话形参filter传入参数 "(k) -> k.startsWith(prefix)",那么在调用settings的get方法时就会先调用filter.test(key)来判断key是不是符合startWith(prefix),从而达到了过滤的效果。

申明:private static final class FilteredMap extends AbstractMap<String, String>

构造方法:FilteredMap(Map<String, String> delegate, Predicate<String> filter, String prefix)

下图是Setting和Settings的继承关系图,可见Setting和Setting之间并无直接关系:

setting,和settings的继承关系

ToXContent

一个允许使用XContentBuilderObject转换为XContent的接口。输出可能是也可能不是一个值对象。实现了ToXContentObject的对象输出有效值,不过值得一提的是,实现输出不可能或可能不需要startObject和endObject原型。

ToXContent接口中定义了空类型参数,Map类型参数,委托类型参数,在ElasticSearch输出各种内容的时候用到。

Environment

在上一篇中提到了在启动过程中作为重要参数传递的Environment实例,包含了很多类似于path.homepath.datapath.logspath.repopath.shared_datapidfile的参数设定,如下所示:

Environment中的参数

在Environment的构造参数Environment(final Settings settings, final Path configPath)中,依次检查构造了上述提到的参数。

Environment的源码比较简单,简单就是一些参数的封装,提供了若干参数获得的方法,如下图:

Environment 中的环境参数获取方法
另外关于XContent相关类

在common下的xcontent模块(Xcontent接口,CborXContent类,JsonXContent类,SmileXContent类,YamlXContent类),是ElasticSearch响应cat API请求时,指定响应返回数据格式(cbor,json,smile,yaml)用到的模块,在设置http请求的x-content内容时使用到。

在代码中也可以看到,在rest包的AbstractRestChannel有调用到XContentBuilder(XContent xContent, OutputStream os, Set<String> includes, Set<String> excludes)方法。

推荐阅读更多精彩内容