3、Delete API
delete API 可以让你删除一个特定id的文档，下面例子删除twitter索引中_doc类型、id为1的文档：
DELETE /twitter/_doc/1返回结果：
{
"_shards" : {
"total" : 2,
"failed" : 0,
"successful" : 2
},
"_index" : "twitter",
"_type" : "_doc",
"_id" : "1",
"_version" : 2,
"_primary_term": 1,
"_seq_no": 5,
"result": "deleted"
}3.1 乐观锁（ Optimistic Concurrency Control）
删除操作可以是有条件的，只有在为文档的最后一次修改分配了if_seq_no和if_primary_term才能执行索引操作。如果检测到不匹配，则操作将导致VersionConflictException和状态代码409.有关详细信息，请参阅乐观并发控制。
3.2 版本（Versioning）
index文档后都有一个版本号，删除文档时，可以指定version参数确保相关的文档(版本号一致)被正确删除，并且文档的版本号在删除操作执行期间不能被更改。任何一个写操作（包括删除操作）都会导致版本号递增。
被删除文档的版本号在短时间内仍可使用，以便控制并发操作。已删除文档的版本号保持的可用的时间由index.gc_deletes索引设置确定，默认为60秒。
3.3 路由（Routing）
如果索引的时候指定了routing参数，那么删除的时候也要指定对应的routing参数，否则删除不了相应的文档。
DELETE /twitter/_doc/1?routing=kimchy上例将根据kimchy进行路由删除id为1的文档。请注意，在没有正确路由的情况下将导致文档无法正确删除。
当在映射中设置_routing但没有指定routing参数时，delete api会抛RoutingMissingException异常并且拒绝本次请求。
3.4 自动创建索引（Automatic index creation）
如果使用了外部版本控制，则删除操作会自动创建一个之前尚未创建过的索引（请参阅创建索引API以手动创建索引）
如果以前未创建过特定类型，还会自动为特定类型创建动态类型映射（请查看put mapping API以手动创建类型映射）。
3.5 分布式（Distributed）
delete请求会通过hash路由到某个分片上，然后被重定向到该id组中的主分片上，并复制（如果需要）到该id组中的副本分片上。之后在所有相关分片上执行删除操作。
3.6 等待活跃分片（Wait For Active Shards）
当执行删除操作是，可以设置 wait_for_active_shards参数要求活跃分片数达到某个值的时候才能执行删除操作。查阅这里了解使用例子。
3.7 刷新（Refresh）
设置此请求所做的更改到搜索可见的时间。查阅refresh
3.8 超时（Timeout）
执行删除操作时，执行删除操作的主分片可能不可用。这可能是因为主分片正在恢复中或者主分片正在进行迁移。默认情况下，删除操作会等待一分钟，如果主分片还是不可用就会报错。你可以在delete API 中通过timeout参数显式指定超时时间。下面例子把timeout设置为5分钟：
DELETE /twitter/_doc/1?timeout=5m