Apache Curator

一、其他不多说 直接开始做吧 elasticsearch 安装配置 我这里测试用的2台机器安装ES6.8 rpm -ivh elasticsearch-6.8.10.rpm 集群配置 节点一 root@[ 8.1.10.146 @elastic1:/root ]# cat /etc/elasticsearch/elasticsearch.yml |grep -v "^#" cluster.name: Zabbix-history node.name: 8.1.10.146 path.data: /data/ESdata path.logs: /var/log/elasticsearch bootstrap.memory_lock: true network.host: 0.0.0.0 http.max_initial_line_length: 128k http.max_header_size: 64kb http.max_content_length: 500mb discovery.zen.ping.unicast.hosts: ["8.1.10.146", "8.1.10.147"] discovery.zen.minimum_master_nodes: 2 节点二 root@[ 8.1.10.147 @elastic2:/root ]# cat /etc

前言 涵盖各大公司会问到的面试点，同时随着版本的升级，可能也会有一些面试题更新，也会同步保持更新，因为篇幅原因（其实是我懒，哈哈）所以列了一部分答案，所有的答案见下文，总共485页合计20个技术点，文末自取pdf. 1、elasticsearch 了解多少，说说你们公司 es 的集群架构，索引数据大小，分片有多少，以及一些调优手段 。 面试官：想了解应聘者之前公司接触的 ES 使用场景、规模，有没有做过比较大规模的索引设计、规划、调优。 解答： 如实结合自己的实践场景回答即可。 比如：ES 集群架构 13 个节点，索引根据通道不同共 20+索引，根据日期，每日递增 20+，索引：10 分片，每日递增 1 亿+数据，每个通道每天索引大小控制：150GB 之内。 仅索引层面调优手段： 1.1、设计阶段调优 1、根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索 引； 2、使用别名进行索引管理； 3、每天凌晨定时对索引做 force_merge 操作，以释放空间； 4、采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink 操作，以缩减存储； 5、采取 curator 进行索引的生命周期管理； 6、仅针对需要分词的字段，合理的设置分词器； 7、Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。 1.2

1.我们要实现什么 ​ Provider: 暴露服务的服务提供方，我这里创建名为news-provider的Module来实现。 Consumer: 调用远程服务的服务消费方，我这里创建名为news-consumer的Module来实现。 Registry: 服务注册与发现的注册中心，使用Zookeeper来实现，具体实现可参考我之前文章。 Monitor: 统计服务的调用次调和调用时间的监控中心，Dubbo客户端，Dubbo客户端安装可参考我之前文章。 Container: 服务运行容器。 Provider提供服务，并上传到Register，Monitor可以对上传上来的服务进行管理，Consumer可以通过Register拿到Provider提供的服务的相关信息，进行消费 2.具体实现 1.创建一个普通Maven工程dubboservice，有3个子模块，服务接口模块news-ervice，定义了服务的规范；服务提供者模块news-provider，依赖服务接口模块，实现其规范，提供服务；服务消费者模块news-consumer，依赖服务接口模块，通过服务接口从注册中心拿到对应的服务。 工程pom.xml <dependencies> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo<

1.我们要实现什么 ​ Provider: 暴露服务的服务提供方，我这里创建名为news-provider的Module来实现。 Consumer: 调用远程服务的服务消费方，我这里创建名为news-consumer的Module来实现。 Registry: 服务注册与发现的注册中心，使用Zookeeper来实现，具体实现可参考我之前文章。 Monitor: 统计服务的调用次调和调用时间的监控中心，Dubbo客户端，Dubbo客户端安装可参考我之前文章。 Container: 服务运行容器。 Provider提供服务，并上传到Register，Monitor可以对上传上来的服务进行管理，Consumer可以通过Register拿到Provider提供的服务的相关信息，进行消费 2.具体实现 1.创建一个普通Maven工程dubboservice，有3个子模块，服务接口模块news-ervice，定义了服务的规范；服务提供者模块news-provider，依赖服务接口模块，实现其规范，提供服务；服务消费者模块news-consumer，依赖服务接口模块，通过服务接口从注册中心拿到对应的服务。 工程pom.xml <dependencies> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo<

目录 前言 项目版本 项目说明 集成Dubbo 2.6.x 新项目模块 老项目模块 集成Dubbo 2.7.x 新项目模块 老项目模块 参考资料 系列文章 前言 SpringCloud系列开篇文章就说到了，公司新项目将入坑SpringCloud全家桶，但原先线上老项目是采用Spring+Dubbo技术栈的，新项目中的部分业务还是和老项目有点关联的，重写这一部分业务逻辑也是需要点时间，本来想通过http请求进行业务交互的，总感觉不够优雅，原先也了解过SpringCloud Alibaba，趁着这个机会捣腾捣腾。 项目版本 spring-boot-version： 2.2.5.RELEASE spring-cloud.version： Hoxton.SR3 dubbo版本会分成2.6.x系列和2.7.x系列二个版本进行说明 dubbo2.6.x <dependency> <groupId>com.alibaba.boot</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>0.2.1.RELEASE</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId>

最新的dubbo和zookeeper整合的问题 生活本不易，流人遂自安 博主最新在做小项目练手，在进行dubbo和zookeeper整合的时候遇到了一些问题，在这里这些问题做个小总结吧。 首先需要说明的是，这次使用的都是 最新的版本 。过一下我自己的配置，dubbo 2.6.6，zookeeper 3.4.13，Spring 5.1.5.RELEASE dubbo-admin的搭建 ​ 从dubbo2.6版本之后的dubbo-admin已经迁移到了另外一个分支，这是 dubbo-admin 新GitHub的地址。进去之后可以看到发布了两个release版本，下载 Dubbo OPS 0.1 的即可。 最新的Dubbo Admin 0.2.0是Pre release版本，刚发布不久QAQ 将其解压后，进入文件夹中，便可以 mvn install -Dmaven.test.skip=true 编译了。【当然你需要先按安装JDK和Maven】然后去编译输出的文件夹找到 dubbo-admin-0.1 jar ，注意不是dubbo-admin-distribution-0.1 jar。 dubbo-admin连接的zookeeper地址的修改可以到dubbo-admin-server\src\main\resources，修改application.properties文件中连接地址即可。

分布式锁三种实现方式： 1. 基于数据库实现分布式锁； 2. 基于缓存（Redis等）实现分布式锁； 3. 基于Zookeeper实现分布式锁； 一， 基于数据库实现分布式锁 1. 悲观锁 利用select … where … for update 排他锁 注意: 其他附加功能与实现一基本一致，这里需要注意的是“where name=lock ”，name字段必须要走索引，否则会锁表。有些情况下，比如表不大，mysql优化器会不走这个索引，导致锁表问题。 2. 乐观锁 所谓乐观锁与前边最大区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到。我们的抢购、秒杀就是用了这种实现以防止超卖。 通过增加递增的版本号字段实现乐观锁 二， 基于缓存（Redis等）实现分布式锁 1. 使用命令介绍： （1）SETNX SETNX key val：当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。 （2）expire expire key timeout：为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。 （3）delete delete key：删除key 在使用Redis实现分布式锁的时候，主要就会使用到这三个命令。 2

zk实现分布式锁的3种方式 第1种 创建一个znode，如果创建成功，则获取到锁，操作完成，删除znode即可释放锁； 如果创建失败（抛出异常），说明锁被其它服务的线程持有，当前线程休眠一小会儿，之后重试，设置一个计数器，如果重试指定次数后还没有获取到锁，就放弃。 缺点：未获取到锁时重试多次，浪费资源 第2种 在1的基础修改，如果创建失败，说明锁已被其它线程持有，给zndoe加一个watcher，监听节点删除事件（释放锁），当前线程休眠，节点删除事件发生时唤醒等待的线程。 缺点：会发生惊群现象，如果多个服务同时等待、监听此节点，释放锁后多个服务的线程都会被唤醒，但只有一个服务的线程可以获取到锁，其它服务的线程刚醒来又要沉睡。 第3种 在2的基础上进行修改，先创建有序的znode，假设都放在/lock下； 获取/lock的子节点列表，如果列表中只有一个元素，这个元素肯定是刚刚创建节点，认为当前线程已获取到锁；如果列表中的元素数量>1，获取倒数第二个元素，监听它的节点删除事件。 有序节点，获取子节点列表时，子节点是按照由小到大的顺序排列的，比如 [order0000000000, order0000000001, order0000000002,...] ，刚刚创建的节点是列表的最后一个元素，监听前一个节点即可。 用一个变量保存列表的最后一个元素（自己创建的有序节点）

Dubbo 通过注册中心在分布式环境中实现服务的注册与发现，而注册中心通常采用 ZooKeeper，研究注册中心相关源码绕不开 ZooKeeper，所以学习了 ZooKeeper 的基本概念以及相关 API 操作。 ZooKeeper 相关概念 session 客户端与服务端采用 TCP 长连接，服务端在为客户端创建 Session 会分配一个唯一 sessionId。在 Session timeout 时间内，客户端可以向服务端发送请求以及接受 watcher 事件通知。 数据结构 Zookeeper 将所有数据存储在内存中，数据模型是一棵树（Znode Tree)，由斜杠（/）的进行分割的路径，就是一个Znode，例如/foo/path1。 Znode Znode 将会保存数据内容以及相关属性信息。在 Znode 中使用 Stat 数据结保存相关属性信息。Stat 属性中有三种版本信息，分别为 version：当前节点版本信息，cversion:当前节点子节点版本，aversion 当前节点的 ACL 版本。每次发生改动，版本数值将会单调递增。 更新，删除 Znode 可以传入版本数值，如果版本数值不对，将会导致删除/更新失败，这个特性类似于 CAS 操作。 Znode 有以下几种类型： 永久节点 一旦创建，将会一直存在，除非手动删除。dubbo 目录节点为永久节点。 临时节点

这里不介绍关于curator的用法及优劣，旨在探究curator对于延迟队列的使用原理 怎么使用 <!--dependency--> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>4.0.1</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>4.0.1</version> </dependency> public class Processor { private final static CuratorFramework client; private final static DistributedDelayQueue<String> queue; static{ ZookeeperConfig config = ZookeeperConfig.getConfig(); // create client client = CuratorFrameworkFactory.newClient(config