ElasticSearch 笔记

　　

ES集群脑裂出现的缘由:

 

1：网络缘由

　　内网通常不会出现此问题，能够监控内网流量状态。外网的网络出现问题的可能性大些。

2：节点负载

         主节点即负责管理集群又要存储数据，当访问量大时可能会致使es实例反应不过来而中止响应，此时其余节点在向主节点发送消息时得不到主节点的响应就会认为主节点挂了，从而从新选择主节点。

3：回收内存

         大规模回收内存时也会致使es集群失去响应。

 

两节点集群脑裂的预防:

在一个两节点集群，你能够添加一个新节点并把 node.data 参数设置为“false”。这样这个节点不会保存任何分片，但它仍然能够被选为主（默认行为）。由于这个节点是一个无数据节点，因此它能够放在一台便宜服务器上。如今你就有了一个三节点的集群，能够安全的把minimum_master_nodes设置为2，避免脑裂并且仍然能够丢失一个节点而且不会丢失数据。

结论

脑裂问题很难被完全解决。在elasticsearch的问题列表里仍然有关于这个的问题, 描述了在一个极端状况下正确设置了minimum_master_nodes的参数时仍然产生了脑裂问题。 elasticsearch项目组正在致力于开发一个选主算法的更好的实现，但若是你已经在运行elasticsearch集群了那么你须要知道这个潜在的问题。

 

对于大型的生产集群来讲，推荐使用一个专门的主节点来控制集群，该节点将不处理任何用户请求。

 

部落节点：部落节点能够跨越多个集群，它能够接收每一个集群的状态，而后合并成一个全局集群的状态，它能够读写全部节点上的数据。

 

Elasticseach查询分为两种，结构化查询和全文查询；

solr使用zk做为分布式管理器, elasticsearch本身维护分布式管理(脑裂问题)

 

Z 阶曲线经过交织点的坐标值的二进制表示来简单地计算多维度中的点的z值。一旦将数据被加到该排序中，任何一维数据结构，例如二叉搜索树，B树，跳跃表或（具备低有效位被截断）哈希表 均可以用来处理数据。经过 Z 阶曲线所获得的顺序能够等同地被描述为从四叉树的深度优先遍历获得的顺序。

这也是 Geohash 的另一个优势，搜索查找邻近点比较快。

 

kafka具备高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操做，具备O(1)的复杂度，消息处理的效率很高。

rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不同，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操做；基于存储的可靠性的要求存储能够采用内存或者硬盘。

Kafka是可靠的分布式日志存储服务。用简单的话来讲，你能够把Kafka看成可顺序写入的一大卷磁带， 能够随时倒带，快进到某个时间点重放

 

ELK通常部署:

 

ELK海量日志部署:

Filebeat支持异步话, 增长消息队列机制Kafka