elasticsearch的rack_id和zone的使用来实现es的定向请求和有意识的分区备份

在使用es时，我们有时候希望分片分布在特地的机器上，或者希望请求在某些机器上执行，es为我们提供了Shard Allocation Awareness的概念，即通过用户对集群节点的标识，es集群会自动的去为节点划分区间，然后根据节点所处区间，为节点分配primary shard和replica。
其主要通过rack_id和zone来实现。

官方文档实例有两个标记选项：rack_id和zone，两者都可以为节点划分区间。假设有五个分片一个副本，此时只有一个区间A的话，使用rack_id属性，区间A会同时存在主分配和其副本，当增加区间B时，集群会把备份备份或者主分片转移到区间B中，保证两个区间都有完整数据；而使用zone属性的话，当只存在区间A时，区间A只会存在主分片，只有当存在区间A和B时，集群才会创建分片，并保证两个区间都有完整数据。

PS：zone还可以作用在索引上，指定某个请求在哪个区间执行。

通过测试，发现确实符合官网文档的描述。
- 1、primary和replication混合散落在两个分区上，最终结果满足每个分区都有完整的数据备份（包括某个分区内有节点挂掉后，重新分配的结果），不过primary和replication是混合分布的，而不是相互分离。
- 2、在执行操作时，默认在同区间去执行请求，包括请求client，client会把请求转发到本区间的master上，而本区间的master在调用dataNode时，也是调用的本区间的节点。

第一点是很好测试的，搭建集群，创建索引，观察，然后down调节点，观察即可。

关于第二点的测试方式如下：
es中有慢日志记录功能，我们可以把慢日志的阈值给设置的很小，然后进行查询，再观察每个节点的日子记录（es的日志是分节点记录的，所以我们可以根据节点下有没有慢日志记录来判断节点有没有参与请求）

PUT http://192.168.1.112:9101/index_name/_settings
{
    "index.search.slowlog.threshold.fetch.debug": "1ms" 
}
PUT http://192.168.1.112:9101/_cluster/settings
{
    "transient" : {
        "logger.index.search.slowlog" : "DEBUG"
    }
}

测试完记得把配置改回去。

有问题欢迎交流。