curator

前言 前面已经讲解了Redis的客户端Redission是怎么实现分布式锁的，大多都深入到源码级别。 在分布式系统中，常见的分布式锁实现方案还有Zookeeper，接下来会深入研究Zookeeper是如何来实现分布式锁的。 Zookeeper初识 文件系统 Zookeeper维护一个类似文件系统的数据结构 image.png 每个子目录项如NameService都被称为znoed,和文件系统一样，我们能够自由的增加、删除znode,在znode下增加、删除子znode,唯一不同的在于znode是可以存储数据的。 有4种类型的znode PERSISTENT--持久化目录节点客户端与zookeeper断开连接后，该节点依旧存在 PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 EPHEMERAL-临时目录节点客户端与zookeeper断开连接后，该节点被删除 EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号 通知机制 客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）等，zookeeper会通知客户端。 分布式锁

zookeeper 注册中心 Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 [1]。 流程说明： 服务提供者启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址 服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址 监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。 支持以下功能： 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息 当注册中心重启时，能自动恢复注册数据，以及订阅请求 当会话过期时，能自动恢复注册数据，以及订阅请求 当设置 <dubbo:registry check="false" /> 时，记录失败注册和订阅请求，后台定时重试 可通过 <dubbo:registry username="admin" password="1234" /> 设置 zookeeper 登录信息 可通过 <dubbo:registry

转载来源 ： es索引管理工具-curator https://www.cnblogs.com/xiaobaozi-95/p/10450380.html 介绍 elasticsearch-curator 是官方收购的开源社区周边产品，用来管理es的索引和快照。 在6.6以后官方推出了ILM（索引生命周期管理策略），更加易于操作和方便使用，可以通过restful api，也可以在kibana界面直接操作。 官方文档： https://www.elastic.co/guide/en/elasticsearch/client/curator/current/index.html 功能包括：从别名添加、删除索引，更改分片路由分配，打开/关闭索引，创建/删除索引，快照管理、合并segment，更改索引分片副本数等。 目前使用的elasticsearch-curator版本是5.4, Python2.6安装会出现问题.建议在安装在python2.7+的环境中. 安装: # pip install elasticsearch-curator 使用: 命令语法: 命令行参数： curator [–config CONFIG.YML] [–dry-run] ACTION_FILE.YML $ curator -- help Usage : curator [ OPTIONS ] ACTION

场景分析 由于公司zabbix的历史数据存储在elasticsearch中，有个需求是尽可能地把监控的历史数据存储的长一点，最好是一年，目前的情况是三台ES节点，每天监控历史数据量有5G，目前最多可存储一个月的数据，超过30天的会被定时删除，每台内存分了8G，且全部使用机械硬盘，主分片为5，副本分片为1，查询需求一般只获取一周的历史数据，偶尔会有查一个月到两个月历史数据的需求。 节点规划 为了让ES能存储更长的历史数据，以及考虑到后续监控项添加导致数据的增长，我将节点数量增加至4节点，并将部分节点内存提高，部分节点采用SSD存储 192.168.179.133 200GSSD 4G内存 tag:hot node.name=es1 192.168.179.134 200GSSD 4G内存 tag:hot node.name=es2 192.168.179.135 1THDD 32G内存 tag:cold node.name=es3 node.master=false 192.168.179.136 1THDD 32G内存 tag:cold node.name=es4 node.master=false 优化思路 对数据mapping重新建模，对str类型的数据不进行分词，采用冷热节点对数据进行存储，前七天数据的索引分片设计为2主1副，索引存储在热节点上，超过七天的数据将被存储在冷节点

场景分析 由于公司zabbix的历史数据存储在elasticsearch中，有个需求是尽可能地把监控的历史数据存储的长一点，最好是一年，目前的情况是三台ES节点，每天监控历史数据量有5G，目前最多可存储一个月的数据，超过30天的会被定时删除，每台内存分了8G，且全部使用机械硬盘，主分片为5，副本分片为1，查询需求一般只获取一周的历史数据，偶尔会有查一个月到两个月历史数据的需求。 节点规划 为了让ES能存储更长的历史数据，我将节点数量增加至4节点，并将部分节点内存提高，部分节点采用SSD存储 192.168.179.133 200GSSD 4G内存 tag:hot node.name=es1 192.168.179.134 200GSSD 4G内存 tag:hot node.name=es2 192.168.179.135 500GHDD 64G内存 tag:cold node.name=es3 192.168.179.136 500GHDD 64G内存 tag:cold node.name=es4 优化思路 对数据mapping重新建模，对str类型的数据不进行分词，采用冷热节点对数据进行存储，前七天数据的索引分片设计为2主1副，索引存储在热节点上，超过七天的数据将被存储在冷节点，并修改冷节点上的副本分片数为0，ES提供了一个shrink的api来进行压缩

1，为什么要对elasticsearch进行生命周期管理？ ES索引存活数量过多，会给ES集群带来较大压力，不仅严重影响数据录入和数据查询效率，而且导致磁盘、CPU占用比过高，加大节点“驾崩”的风险。对ES进行索引生命周期管理意义重大，不仅能提高服务器性能，降低内存和磁盘使用率，而且能够优化数据结构，提升读写、查询效率，避免数据丢失情况出现。 2，如何对elasticsearch进行生命周期管理？ 针对索引，根据时间、空间、类型、优先级进行不同种类的管理策略。推荐以时间序列为导向对数据进行应用策略操作。 对于时间序列索引，索引生命周期中有五个阶段： 热数据–索引正在积极更新和查询。 暖数据–索引不再更新，但仍需要查询。 冷数据–索引不再被更新，且很少被查询。数据仍然需要搜索，但查询速度较慢也没关系。 数据归档–索引不在被更新和查询，但需要存储以作备份。 数据删除–不再需要索引，可以安全删除。 以时间序列为导向，控制索引的老化时间，将3天以内的数据定义为热数据，3天以上7天以内的数据定义为暖数据，7天以上30天以内的数据定义为冷数据，30天以上数据进行归档，无需归档的数据进行删除。经过优化处理，可极大提高ES的可用性，避免数据丢失。 3，用什么对elasticsearch进行生命周期管理？ 进行ES索引生命周期管理可借助工具。ES 7

消息订阅应用非常广泛，像spring config中，当配置发生改变时其他需要第一时间发现并且更新自己的配置信息；其实像之前说到的master选举也是一样，在我看来也是消息订阅的一种特例，当主节点宕机时，其他节点需要立即感应，并且同时立马进行主节点竞选 其实这一篇与master竞选原理一致，都是监听一个节点的状态，master节点选举主要监听的是主节点的移除事件，而消息订阅需要更具不同的场景进行不同的处理，就像配置文件一样，主要监听节点更新事件，下边看实现： 1.定义配置数据类，但是在这个例子中并没怎么用到，这里只是做一个封装，真是创建中肯定是需要的 public class ConfigData { private String cid ; private String nodeName ; public ConfigData ( ) { } public ConfigData ( String cid , String nodeName ) { this . cid = cid ; this . nodeName = nodeName ; } public String getCid ( ) { return cid ; } public void setCid ( String cid ) { this . cid = cid ; } public String

作者：焦振清 时间：2018-04-27 版本说明：5.6.4（要严格注意ES及其插件、第三方工具的版本匹配关系） 系统负载：（日志集群，日均写入10TB，保留7天） 1，出于高可用的考虑，同一个分区的多个副本不会被分配到同一台机器 如下截图所示，Index：queries，设置20副本，5分片。这个集群当前有14个可用数据节点，queries的0分区在这14个数据节点上均有且仅有一个副本，剩余​​的7个副本显示UNASSIGNED，并不会在当前14个节点上重复分配 2，Local Gateway参数生效顺序（仅在重启master时生效） gateway:expected_nodes，只要达到该值，立即可以进入恢复状态，假如有恢复必要的话 gateway:recover_after_time，如果未达到expected_nodes值，则需要等待recover_after_time时长，不管你当前有多少个nodes了 gateway:recover_after_nodes，在达到recover_after_time的时间后，还需要达到recover_after_nodes的设置值，才能进入恢复状态 3，避免所有索引被删除 action.destructive_requires_name:true，通过该参数禁止通过正则进行index的删除操作 curl -XDELETE http:/

1. Zookeeper的基本操作 　　zookeeper中的节点可以持久化/有序的两个维度分为四种类型： 　　PERSIST：持久化无序（保存在磁盘中） 　　PERSIST_SEQUENTIAL：持久化有序递增 　　EPHEMERAL：非持久化的无序的，保存在内存中，当客户端关闭后消失。 　　EPHEMERAL_SEQUENTIAL：非持久有序递增，保存在内存中，当客户端关闭后消失 　　每个节点都可以注册Watch操作，用于监听节点的变化，有四种事件类型如下： 　　Created event: Enabled with a call to exists 　　Deleted event: Enabled with a call to exists, getData, and getChildren 　　Changed event: Enabled with a call to exists and getData 　　Child event: Enabled with a call to getChildren 　　Watch的基本特征是客户端先得到通知，然后才能得到数据，Watch被fire之后就立即取消了，不会再有Watch后续变化，想要监听只能重新注册； 使用原生Zookeeper创建节点和监听节点变化代码如下： 　　1. 引入依赖，pom.xml <dependency>

一、写在前面 之前写过一篇文章（《 拜托，面试请不要再问我Redis分布式锁的实现原理 》），给大家说了一下Redisson这个开源框架是如何实现Redis分布式锁原理的，这篇文章再给大家聊一下ZooKeeper实现分布式锁的原理。 同理，我是直接基于比较常用的 Curator 这个开源框架，聊一下这个框架对ZooKeeper（以下简称zk）分布式锁的实现。 一般除了大公司是自行封装分布式锁框架之外，建议大家用这些开源框架封装好的分布式锁实现，这是一个比较快捷省事儿的方式。 二、ZooKeeper分布式锁机制 接下来我们一起来看看， 多客户端获取及释放zk分布式锁的整个流程及背后的原理。 首先大家看看下面的图，如果现在有两个客户端一起要争抢zk上的一把分布式锁，会是个什么场景？ 如果大家对zk还不太了解的话，建议先自行百度一下，简单了解点基本概念，比如zk有哪些节点类型等等。 参见上图。zk里有一把锁，这个锁就是zk上的一个节点。然后呢，两个客户端都要来获取这个锁，具体是怎么来获取呢？ 咱们就假设客户端A抢先一步，对zk发起了加分布式锁的请求，这个加锁请求是用到了zk中的一个特殊的概念，叫做 “临时顺序节点”。 简单来说，就是直接在"my_lock"这个锁节点下，创建一个顺序节点，这个顺序节点有zk内部自行维护的一个节点序号。 比如说，第一个客户端来搞一个顺序节点