说明
扩展分为
纵向扩展:购买更好的服务器
横向扩展:增加服务器（elasticsearch更适合横向扩展)
elasticsearch可以用于构建高可用和可扩展的系统,elasticsearch天生就是分布式的 它知道如何管理各个节点 我们程序并不需要关心
elasticsearch默认就是一个集群，比如前面的例子的集群看起来如下图
主节点只用于临时的管理节点的 删除索引 移除或新增节点 主节点不参与文档的变更和搜索，那么表示主节点并不会出现性能瓶颈， 请求都平均分配给了其他节点,各个子节点都知道数据保存在哪个节点上。子节点负责将我们的请求转发到相应数据的节点 获得数据 并返回给客户端
集群健康
get请求:http://127.0.0.1:9200/_cluster/health
结果
{ "cluster_name": "elasticsearch",//集群名称 "status": "yellow",//集群状态(yellow,grren,red) "timed_out": false,//是否超时 "number_of_nodes": 1,//总节点数 "number_of_data_nodes": 1,//总节点数 "active_primary_shards": 15,//可用的主分片数量 "active_shards": 15,//可用的总分片数量 "relocating_shards": 0,//正在迁移的分片数量 "initializing_shards": 0,//正在初始化的分片数量 "unassigned_shards": 15,//未分配的分片数量 "delayed_unassigned_shards": 0,//延迟未分配的分片数量 "number_of_pending_tasks": 0,//等待执行任务数量0 "number_of_in_flight_fetch": 0, "task_max_waiting_in_queue_millis": 0,//任务在队列中等待的较大时间(毫秒) "active_shards_percent_as_number": 50//可用的总分片数量所占百分比 }
status 的值为:yellow,grren,red
yellow:所有主要分片可用，但是不是所有复制分片可以使用
red:不是所有主要分片都可用
grren:所有主要分片和复制分片都可用
添加索引
索引里面存在一个或者多个shard(分片),分片保存了 索引中数据的一部分。我们检索数据都是在分片上,分片又存在集群中的各个节点上,当集群节点扩展或缩小会自动迁移分片
分片可以是主分片和复制分片:
主分片可以理解为索引中的一个文档，主分片的数量决定了索引最多能存储多少条数据,
复制分片可以理解为主分片的数据备份，防止硬件故障导致的数据丢失,同时可以提供请求
当索引建立后 主分片的数量就固定了 但是可以调整复制分片数量
例子
添加一个3个主分片一个复制分片的的blogs索引
先把我们之前存在的索引清空
查询存在的所有索引
get 请求：http://127.0.0.1:9200/_cat/indices?v
结果
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size yellow open opcmdevpretty BuAOTDdqSIOGsemOQD9TuQ 5 1 0 0 1.2kb 1.2kb yellow open blogs2 1k8UpYTPTk2JnTrclogVUA 3 1 0 0 783b 783b yellow open opcmdev FrXbou2aR061erz6913_BQ 5 1 3 0 18.7kb 18.7kb yellow open blogs4 BWHZTGSSQbWPpUGqPVdA1w 3 1 0 0 783b 783b yellow open opcm 1dqGOUuPSIeuyGMEyL0Y-w 5 1 11 0 45.4kb 45.4kb yellow open blogs 7GTeHqQrTjWJAyiBKy-2DA 3 1 0 0 783b 783b
删除所有 delete请求：http://127.0.0.1:9200/_all
我们再查看集群健康
可以看到我们的分片数量都是0
现在我们为blogs索引添加一个 3个主分片1个复制分片
put请求：http://127.0.0.1:9200/blogs
参数
{ "settings":{ "number_of_shards":3, "number_of_replicas":1 } }
再查看集群健康
{ "cluster_name": "elasticsearch", "status": "yellow", "timed_out": false, "number_of_nodes": 1, "number_of_data_nodes": 1, "active_primary_shards": 3, "active_shards": 3, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 3, "delayed_unassigned_shards": 0, "number_of_pending_tasks": 0, "number_of_in_flight_fetch": 0, "task_max_waiting_in_queue_millis": 0, "active_shards_percent_as_number": 50 }
上面我们提到yellow是表示所有主分片都可用 但是并不是所有复制分片都可用 unassigned_shards其实就是主分片对应的几个复制分片。因为我们单节点为主分片备份数据是没有必要的，这个节点异常 备份数据也会丢失。所以是3个复制分片是unassined
先不研究了 环境部署有其他人弄。先学习各种特性
分片原理
当索引一条shard=hash(routing)%number_of_parimary_shard 会通过_Id（默认） 的hash%主分片的数量 得出的余数 得出的数一定在0~主分片数量-1之间 所以有分片的索引就能路由到对应的分片
主分片和复制分片怎么交互的
上图3个集群节点有2个主分片p*他们各有2个复制分片R*
上图任意一个节点都能接收请求，都知道文档的位置。如果文档不在当前节点当转发到文档存在节点。
所以集群情况下 我们最好根据算法负载均衡发送请求到节点