ZooKeeper

最近项目中新上线了抢优惠券功能，虽然用户不多但是，如何防止超发呢？单体应用情况下只需要在抢券方法前用synchronized修饰即可，但是目前大部分项目都是分布式微服务架构，所以就需要加分布式锁。项目用的SpringMVC+dubbo，注册中心使用的zookeeper，所以就选用的基于zookeeper的分布式锁。 原生的zookeeper分布式锁写起来比较复杂，使用zookeeper的Curator框架轻松实现，代码实现： pom文件 <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.4.6</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>4.0.1</version> </dependency> Spring集成 <!-- 重连策略 --> <bean id="retryPolicy" class="org.apache.curator.retry.ExponentialBackoffRetry"> <!-- 间隔时间基数 -->

前言 前段时间，蚂蚁金服的热度可不小，互联网圈人人都在讨论它上市的事情，实际上蚂蚁金服上市是迟早的事情。这一下，蚂蚁的员工含金量上升了不少，那我之前蚂蚁提前批这波面经，也是时候分享了。 这次面试，可以说是一波三折，波涛汹涌了，原本我是一个挺自信的人的，所以在面试前我算是处于一个斗志昂扬的状态，奈何在经历一面二面意志力被消磨了不少，虽然三面准备充足，但整体下来对自己表现不满意，所以以为是没戏了，没想到意外接来了HR面的通知，于是就这么意外的拿到了offer。 下面就对这次蚂蚁金服的面试体验进行一个分享，由于面试题比较多，所以只挑选了一些有针对性的核心题放在这里解析，如果你需要完整pdf版，只需要添加小助理vx：mxzFAFAFA即可！！ 蚂蚁金服意外的第一面 1、讲一讲ArrayList和LinkedList区别？ ArrayList 是一个可改变大小的数组。当更多的元素加入到ArrayList中时，其大小将会动态地增长。内部的元素可以直接通过get与set方法进行访问，因为ArrayList本质上就是一个数组， LinkedList 是一个双链表，在添加和删除元素时具有比ArrayList更好的性能.但在get与set方面弱于ArrayList。 当然，这些对比都是指数据量很大或者操作很频繁的情况下的对比,如果数据和运算量很小，那么对比将失去意义。 2、什么情况会造成内存泄漏？

1、环境 centos7 zookeeper-3.5.2 三台虚拟机：master、slaves1、slaves2 2、将zookeeper安装包先上传到master的/opt/softWare/zookeeper目录下并解压和重命名 3、进入conf目录将zoo_sample.cfg文件重命名为zoo.cfg并添加如下配置: #数据目录. 可以是任意目录,其中的dataDir目录和dataLogDir需要提前建立好 #注意 应该谨慎地选择日志存放的位置，使用专用的日志存储设备能够大大地提高系统的性能，如果将日志存储在比较繁忙的存储设备上，那么将会在很大程度上影响系统的性能。 dataDir=/opt/softWare/zookeeper/data/zookeeper #log目录, 同样可以是任意目录. 如果没有设置该参数, 将使用和dataDir相同的设置，其中的dataDir目录和dataLogDir需要提前建立好 #注意 应该谨慎地选择日志存放的位置，使用专用的日志存储设备能够大大地提高系统的性能，如果将日志存储在比较繁忙的存储设备上，那么将会在很大程度上影响系统的性能。 dataLogDir=/opt/softWare/zookeeper/logs/zookeeper #在之前设置的dataDir中新建myid文件, 写入一个数字, 该数字表示这是第几号server.

Zookeeper是一个开源的高效分布式协调服务，可以用来协调其他分布式集群实例间的执行调度，比如Kafka的集群就使用Zookeeper来管理，在Zookeeper的文件树结构中，存放着Kafka的一些节点元数据信息，比如broker信息，消费者信息，topic信息等。Kafka可以从Zookeeper上获取相关信息，保证各个实例间的元数据是一致的。 另外，Zookeeper也可以作为一个服务注册和发布服务，比如作为Dubbo的服务注册中心，用来管理各个服务实例发布的接口信息。 Zookeeper的定位是一个分布式的协调服务，所以它并不能像Kafka或者Redis一样存储大量的数据，它的树状的结构上的节点中只能存储少量的信息，不过能存储的数据量以及完全满足它的分布式协调和服务注册和发现中心的要求了。 下面搭建一个Zookeeper的集群，便于后续的学习使用。 在VM中创建了三台linux虚拟机，IP地址分别是: 192.168.200.128 192.168.200.129 192.168.200.130 首先去官网下载zookeeper的软件包： http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.5.5/ 下载之后上传到三台服务器上： 把压缩包解压到opt目录下，使用 sudo tar -zxvf apache

背景 上篇文章我简单的介绍了自己打造的通俗简版RPC通信框架，这篇是对简版的增强~ 如果大家对此项目还感兴趣的话，可到码云上瞄瞄： Netty-RPC 上篇文章链接： 《SpringBoot2+Netty打造通俗简版RPC通信框架》 在介绍后续新增功能前，我们先回顾一下最简单的RPC通信的流程，流程图如下： 我们可以看到其实整个流程其实是非常的简单的：客户端接收前端发送的请求，封装好请求Packet根据配置打开Netty通道进行通信，服务端接收请求Packet，解析并且根据请求信息，反射获取实现类调用方法，得到结果并封装好响应Packet然后返回结果给客户端，客户端获取结果响应给前端。 新增功能 因为是模仿Dubbo造RPC通信框架，那么Dubbo基本的功能我们当然也必须得有啦，下面列出的是我后续新增的优化： 单一长连接 服务注解，并且带版本号 增加注册中心 处理Netty客户端或服务端主动断开异常 业务处理使用自定义业务线程池 详细的代码大家可到我的码云上阅读。 详细介绍 首先，我们先看一下带注册中心后的流程图： 我们可以看到多了个Zookeeper作为注册中心，然后就到了监听缓存列表，和服务缓存列表。大家不理解这两个列表不重要，下面我将继续详细的介绍一下我做这些功能的思路。 1、单一长连接： 首先上一下简单的流程图： 思路非常的简单：就是使用内存缓存缓存起来，结构就是Map

点击上方 蓝字 关注我们 文末有惊喜 kafka架构图 在这里插入图片描述 kafka核心控制器 定义 在kafka集群中，会选举出一个broker作为控制器(controller)，负责管理集群中所有的分区和副本的状态； 职责 监听broker变化，通过监听Zookeeper中的/brokers/ids/ 节点方式来实现 监听topic变化，通过监听Zookeeper中的/brokers/topics节点方式来实现，实时监听topic变化 管理topic、partition、broker相关的信息 更新数据的元数据信息，同步到其他的broker节点 选举过程 broker控制器选举的原理是借助于zookeeper的临时节点实现：kafka集群启动时，每个broker都会尝试争当控制器，都会往zookeeper的controller节点注册自己，但是由于zookeerper的特性，如果节点已经创建过，再创建就会失败，所以只会有一个broker创建成功，那么创建成功的broker就会成为控制器;此外其他broker都会监听这个controller节点 在这里插入图片描述 由于controller是临时节点，当控制器broker挂机之后，就会断开与zookeeper的会话连接，临时节点也会消失，其它节点监听到controller节点消失后，就会重新争取controller节点。

SpringBoot整合Dubbo+Zookeaper 1.安装运行zookeeper （1）下载zookeeper 官网： http://zookeeper.apache.org/ （2）解压缩 （3）修改配置文件 拷贝zoo_sample.cfg重命名为zoo.cfg 修改配置文档 # The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial # synchronization phase can take initLimit=10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. # do not use /tmp for storage, /tmp here is just # example sakes. dataDir=../data # the port at which the clients will connect clientPort=2181 # the maximum

序言 dubbo就是个rpc框架，之前都是一直在用，现在稍微总结下以备以后使用。 我就直接贴代码了，代码肯定能运行，如果运行不了那么看我之前的zookeeper配置，或者把我贴的代码重新复制下，实在不行请留言，我看到会回复的。 整体项目结构 项目是父子maven结构，父maven中基础jar包都依赖好了，子maven只需继承父maven，额外依赖自己的jar包就可以，其中 domain 是放实体类的， interfaceapi 是放提供者提供给消费者的接口的。 provider 是提供者 consumer 是消费者，不过真实项目中可能一个模块即是消费者又是提供者。所以自己需要的话直接写就行，用法都一样的。 2.主pom文件 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion>

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/bV8AhqAjQp4a_iXRfobkCQ 作者简介：郑志彬，毕业于华南理工大学计算机科学与技术（双语班）。先后从事过电子商务、开放平台、移动浏览器、推荐广告和大数据、人工智能等相关开发和架构。目前在vivo智能平台中心从事 AI中台建设以及广告推荐业务。擅长各种业务形态的业务架构、平台化以及各种业务解决方案。 博客地址： http://arganzheng.life 。 背景 最近要把原来做的那套集中式日志监控系统进行迁移，原来的实现方案是: Log Agent => Log Server => ElasticSearch => Kibana，其中Log Agent和Log Server之间走的是Thrift RPC，自己实现了一个简单的负载均衡(WRB)。 原来的方案其实运行的挺好的，异步化Agent对应用性能基本没有影响。支持我们这个每天几千万PV的应用一点压力都没有。不过有个缺点就是如果错误日志暴增，Log Server这块处理不过来，会导致消息丢失。当然我们量级没有达到这个程度，而且也是可以通过引入队列缓冲一下处理。不过现在综合考虑，其实直接使用消息队列会更简单。PRC，负载均衡，负载缓冲都内建实现了。另一种方式是直接读取日志，类似于logstash或者flume的方式

---------------------------------------------------------------------------------------------------- applicationContext - resources.xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation ="http://www.springframework.org/schema/beans http: // www.springframework.org/schema/beans/spring-beans-3.0.xsd"> <!-- load properties --> <bean id="propertyConfigurer" class ="com.agu3.kafka.base.PropertyConfigurer"> <property name="locations"> <list> <value>classpath:/common-kafka