Apache Curator

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文源码： GitHub·点这里 || GitEE·点这里 一、Zookeeper基础简介 1、概念简介 Zookeeper是一个Apache开源的分布式的应用，为系统架构提供协调服务。从设计模式角度来审视：该组件是一个基于观察者模式设计的框架，负责存储和管理数据，接受观察者的注册，一旦数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 2、基本理论 数据结构 ZooKeeper记录数据的结构与Linux文件系统相似，整体可以看作一棵树，每个节点称ZNode。每个Znode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。 节点类型 短暂（ephemeral）：客户端和服务器端断开连接后，创建的节点自动删除。 持久（persistent）：客户端和服务器端断开连接后，创建的节点持久化保存。 集群服务 在Zookeeper集群服务是由一个领导者（leader），多个跟随者（follower）组成的集群。领导者负责进行投票的发起和决议，更新集群服务状态

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言   随着瓜子业务的不断发展，系统规模在逐渐扩大，目前在瓜子的私有云上已经运行着数百个 Dubbo 应用，上千个 Dubbo 实例。瓜子各部门业务迅速发展，版本没有来得及统一，各个部门都有自己的用法。随着第二机房的建设，Dubbo 版本统一的需求变得越发迫切。几个月前，公司发生了一次与 Dubbo 相关的生产事故，成为了公司 基于社区 Dubbo 2.7.3 版本升级的诱因。   接下来，我会从这次线上事故开始，讲讲我们这段时间所做的 Dubbo 版本升级的历程以及我们规划的 Dubbo 后续多机房的方案。 一、Ephermal节点未及时删除导致provider不能恢复注册的问题修复 事故背景   在生产环境，瓜子内部各业务线共用一套zookeeper集群作为dubbo的注册中心。2019年9月份，机房的一台交换机发生故障，导致zookeeper集群出现了几分钟的网络波动。在zookeeper集群恢复后，正常情况下dubbo的provider应该会很快重新注册到zookeeper上，但有一小部分的provider很长一段时间没有重新注册到zookeeper上，直到手动重启应用后才恢复注册。 排查过程   首先，我们统计了出现这种现象的dubbo服务的版本分布情况，发现在大多数的dubbo版本中都存在这种问题

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言   随着瓜子业务的不断发展，系统规模在逐渐扩大，目前在瓜子的私有云上已经运行着数百个 Dubbo 应用，上千个 Dubbo 实例。瓜子各部门业务迅速发展，版本没有来得及统一，各个部门都有自己的用法。随着第二机房的建设，Dubbo 版本统一的需求变得越发迫切。几个月前，公司发生了一次与 Dubbo 相关的生产事故，成为了公司 基于社区 Dubbo 2.7.3 版本升级的诱因。   接下来，我会从这次线上事故开始，讲讲我们这段时间所做的 Dubbo 版本升级的历程以及我们规划的 Dubbo 后续多机房的方案。 一、Ephermal节点未及时删除导致provider不能恢复注册的问题修复 事故背景   在生产环境，瓜子内部各业务线共用一套zookeeper集群作为dubbo的注册中心。2019年9月份，机房的一台交换机发生故障，导致zookeeper集群出现了几分钟的网络波动。在zookeeper集群恢复后，正常情况下dubbo的provider应该会很快重新注册到zookeeper上，但有一小部分的provider很长一段时间没有重新注册到zookeeper上，直到手动重启应用后才恢复注册。 排查过程   首先，我们统计了出现这种现象的dubbo服务的版本分布情况，发现在大多数的dubbo版本中都存在这种问题

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 配置Zookeeper安装目录 在宿主机配置zookeeper安装目录：/docker/develop/zookeeper 并且在文件夹创建 data 和logs 目录： mkdir -p /docker/develop/zookeeper/data mkdir -p /docker/develop/zookeeper/logs [root@centos-knight ~]# cd /docker/develop/zookeeper [root@centos-knight zookeeper]# mkdir -p /docker/develop/zookeeper/data [root@centos-knight zookeeper]# mkdir -p /docker/develop/zookeeper/logs 授权文件目录：chmod -R 777 /docker/develop/zookeeper/ [root@centos-knight zookeeper]# chmod -R 777 /docker/develop/zookeeper/ [root@centos-knight zookeeper]# 安装和部署Zookeeper 拉取zookeeper镜像：docker pull zookeeper

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 为什么需要分布式锁 直接作用是保证同一时刻同一代码不被重复执行, 更深一层目的其实是为了保证“功效性”和“正确性”. 功效性(Efficiency) 即节省计算机资源, 减少不必要的重复执行. 如果只是单纯地保证功效性, 一般可以容忍锁出现失误, 因为不会对执行结果造成影响. 准确性(Correctness) 即程序执行结果不会出现错误, 数据不会出现不一致. 这种场景下, 一般不可容忍锁出现失误. 如何实现分布式锁 可以看到网上有很多民众给出了自己的demo, 但仔细研究发现demo离“工业级”还是有一定差距. 如果要使用分布式锁, 我们最好去参考或直接使用一些比较成熟的框架. 分布式环境下, 实现锁机制, 需要基于一个集中式存储, 比如: mysql(或其他数据库)、redis、zookeeper, 简单对比如下: 中间件 原理 特点 参考框架 mysql InnoDB事务引擎的行级锁 性能差 Quartz redis 原子命令setNX 性能高 单点实现简单 集群实现稍复杂 Redisson zookeeper 临时顺序节点 实现复杂 Curator 来源： oschina 链接： https://my.oschina.net/wangxu3655/blog/3143778

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 为什么需要日志备份 KubeSphere 日志系统使用 Fluent Bit + ElasticSearch 的日志采集存储方案，并通过 Curator 实现对 Index 的生命周期管理，定期清理久远日志。对于有日志审计和灾备需求的场景来说，KubeSphere 默认的 7 天日志保留策略远远不够， 仅备份 ElasticSearch 数据盘并不能保证数据可恢复性和完整性 。 ElasticSearch 开源社区提供了 SnapShot API 帮助我们实现长期的存储快照和恢复。本文介绍如何针对 KubeSphere（版本 2.1.0）内置 ElasticSearch （版本 6.7.0）组件进行改造，实践日志备份，以满足审计和灾备的需求。 注：如果是数据量较小、带查询条件的日志导出场景，可以使用 KubeSphere 一键导出功能，或尝试使用 elasticsearch-dump 工具。外接商业版 ElasticSearch 的 KubeSphere 用户也可以直接开启 ElasticSearch X-Pack 中提供的 SnapShot Lifecycle Management 功能。 前提条件 执行存储快照前，我们需要在 ElasticSearch 集群中注册存放快照文件的仓库

假如现在有一个表，表里记录的是一些延迟消息，也就是在未来某时刻需要发送出去的消息，表的记录数不定，如果很多，那么需要多台机器来执行，如果很少，那么一两台就够了，这时候需要一个领导选举/任务分片的工作，下面是一个方案，使用curator来实现。 上代码： import com.google.common.collect.Lists; import org.apache.commons.lang3.StringUtils; import org.apache.curator.framework.CuratorFramework; import org.apache.curator.framework.CuratorFrameworkFactory; import org.apache.curator.framework.recipes.cache.NodeCache; import org.apache.curator.framework.recipes.cache.NodeCacheListener; import org.apache.curator.framework.recipes.cache.PathChildrenCache; import org.apache.curator.framework.recipes.cache.PathChildrenCacheEvent;

博物馆学研究的目的 （荷）彼得·冯·门施 尽管诸多关于博物馆学认知目的的不同看法可以被归纳为数个主要群体，但没有一个群体可以被称为“学派”。一般来说，学派是由于博物馆学研究目的的不同而产生的，而非研究对象的差异。因博物馆学研究目标和目的的不同，甚至导致了博物馆学界的分裂。1985年，国际博物馆学专业委员会的一些成员成立了“国际新博物馆学运动”。 三种倾向 决定博物馆学是否纯学术学科的基本标准之一是博物馆学能否满足社会需要。据此标准，博物馆学研究可区分为与博物馆学领域中的博物馆实践活动有关的研究，以及对作为博物馆领域理论框架的博物馆学的研究。如果博物馆学被承认为学术学科，就必须证明博物馆学对普遍知识的贡献；如果博物馆学被认为是博物馆实践活动的理论框架，就必须清楚表明博物馆工作者能够从博物馆学中获益。针对这后一个条件，研究者表述了不同的观点，在对这些观点分析后，可发现存在下述基本倾向：经验-理论倾向，行为倾向，哲学-批判倾向。这些倾向并不相互排斥。经验-理论倾向主要是启发性的，人类行为学倾向制定行为的战略，哲学-批判倾向要形成明确的认识，并据以制定实践规范。博物馆学领域的哲学-批判倾向与经验-理论倾向及行为倾向有密切联系。 合理性 经验-理论倾向的研究目的是真实的合理性，即现实中各种现象间的重要联系，其结果基本上是描述性的，力图在历史及社会-文化背景中理解博物馆现象

curator zookeeper的高级封装库 是为了将zookeeper中的复杂操作隐藏起来，使得操作简单化，提供了操作的菜谱，并且结合了开发过程的最佳实践和常见的边际情况的处理； curator实现了锁，屏障，缓存这些原语的菜谱，相关网址 http://curator.apache.org/ curator中暴露和zookeeper不同的一组状态，如下为cutator中连接状态机模型 两种边界情况 1 在有序节点创建的过程中发生的错误情况的处理 2 删除一个节点时的错误处理 关于1的解释： 没有收到返回信息，在这种场景下，创建的时候会先添加一个唯一标示符，如果失败客户端就会重试，通过对比这个标示符，看节点是否创建成功 关于2的解释 如何对删除操作提供保障呢，会重试直到成功 三个菜谱 Leaderlatch LeaderSelector PathChildrenCache 1 节点选举 2群首选举 和leaderlatch之间的区别在于监听接口不同 3子节点缓存器，保存节点的列表和任务列表 还有很多菜谱提供开发者使用 来源： oschina 链接： https://my.oschina.net/u/1866807/blog/3014547

前言 最近在用Apache的Zookeeper客户端库Curator，Curator实现了一套的分布式锁，有可重入和不可重入，想起其实在单机环境下，Java提供的synchronized 和 ReentrantLock的锁工具，这两个都是可重入锁，所以可重入锁和不可重入锁有什么区别呢，带着这个问题，去网上找答案。 主题 很多的博客上都是列了怎么实现这两种锁，例如像下面的两段代码： public class Lock{ private boolean isLocked = false; public synchronized void lock() throws InterruptedException{ while(isLocked){ wait(); } isLocked = true; } public synchronized void unlock(){ isLocked = false; notify(); } } 上面实现的是一个不可重入锁，下面这段实现的是一个可重入锁： public class Lock{ boolean isLocked = false; Thread lockedBy = null; int lockedCount = 0; public synchronized void lock() throws InterruptedException{