ZK

一，规划三台zk服务器构成集群 ip:172.18.1.1 机器名：zk1 对应myid: 1 ip:172.18.1.2 机器名：zk2 对应myid: 2 ip:172.18.1.3 机器名：zk3 对应myid: 3 说明：为什么zookeeper集群的数量需要是单数？ 1，为了容错，增删改操作中需要半数以上服务器通过才算成功， 2，防脑裂，一个zookeeper集群中,必需有且只能有一台leader服务器 当leader服务器宕机时,剩下的服务器会通过半数以上投票选出一个新的leader服务器 集群总数共2台时，半数是1，半数以上最少是2，也就是一台也不能宕机 集群总数共3台时，半数是1.5，半数以上最少是2，也就是允许一台能宕机 集群总数共4台时，半数是2，半数以上最少是3，也就是允许一台能宕机 集群总数共5台时，半数是2.5，半数以上最少是3，也就是允许两台能宕机, 集群总数共6台时，半数是3，半数以上最少是4，也就是允许两台能宕机, 可见 允许两台能宕机:5台比6台成本更低 允许一台能宕机:3台比4台成本更低 说明：刘宏缔的架构森林是一个专注架构的博客，地址： https://www.cnblogs.com/architectforest 对应的源码可以访问这里获取： https://github.com/liuhongdi/ 说明：作者:刘宏缔 邮箱:

3 月，跳不动了？>>> 背景 公司选用elasticjob作为分布式任务调度工具，版本2.1.5，其中有一个任务对应机器两台，A和B，任务总分片数是4，A对应分片0、1，B对应分片2、3。任务每晚23:30:00执行，T日计算数据记录日期T+1，供T+1日使用。 突然有一天，A机器在22:24运行执行起分片2任务，执行完分片2之后又执行了分片3， 注意分片2、3本该是机器B所用的分片 ，这两点就很奇怪了，异常的时间执行了不属于自己的分片，而且是一个一个执行。下方是日志中记录的task id // 异常的task id，很清楚的看到分片是@2@，机器A在执行 "taskId":"jobname@-@2@-@READY@-@A机器ip@-@4927" // 正常的task id，分片号@2,3@，ip对应的是机器B "taskId":"jobname@-@2,3@-@READY@-@B机器ip@-@12384" 经过分析，基本断定是进任务失效转移逻辑了。但是，为什么任务失效转移呢？任务不在执行的时间点，而且也没有执行中，不可能出现这个情况。 经过回忆，22:23的时候，开发对机器B做了一次内存dump，与A机器启动相差一分钟，可能问题出在这里了。难道对B机器做dump操作导致B短暂与ZK注册中心断开了吗，导致误以为服务器宕机？带着问题，我们又对B做了一次dump，很快

3 月，跳不动了？>>> 概述 Apache Kafka 是一个快速、可扩展的、高吞吐的、可容错的分布式“发布-订阅”消息系统， 使用 Scala 与 Java 语言编写，能够将消息从一个端点传递到另一个端点。 较之传统的消息中间件（例如 ActiveMQ、RabbitMQ），Kafka 具有高吞吐量、内置分区、支持消息副本和高容错的特性，非常适合大规模消息处理应用程序。 kafka官网 Kafka 通常用于两大类应用程序： 建立实时流数据管道，以可靠地在系统或应用程序之间获取数据。 构建实时流应用程序，以转换或响应数据流。 kafka监控 kafka搭建好投入使用后，为了运维更便捷，借助一些管理工具很有必要。目前Kafka监控方案看似很多，然而并没有一个“大而全”的通用解决方案，各家框架也是各有千秋。 常见监控工具 Kafka Manager Kafka Offset Monitor Kafka Eagle JmxTool ... ... 工具比较 安装环境：Centos 7.6 工具名称 特点 备注 Kafka Manager 实现broker级常见的JMX监控； 能对consumer消费进度进行监控； 还能在页面上直接对多个集群进行管理。 编译安装，比较耗时； 不能进行访问控制； 不能配置告警； 耗费内存。 Kafka Eagle 能够实现broker级常见的JMX监控；

3 月，跳不动了？>>> 一、前言 这期我想写很久了，但是因为时间的原因一直拖到了现在，我以为一两天就写完了，结果从构思到整理资料，再到写出来用了差不多一周的时间吧。 你们也知道丙丙一直都是创作鬼才来的，所以我肯定不会一本正经的写，我想了好几个切入点，最后决定用一个完整的电商系统作为切入点，带着大家看看，我们需要学些啥，我甚至还收集配套视频和资料，暖男石锤啊，这期是呕心沥血之作，不要白嫖了。 二、正文 在写这个文章之前，我花了点时间，自己臆想了一个电商系统，基本上算是麻雀虽小五脏俱全，我今天就用它开刀，一步步剖析，我会讲一下我们可能会接触的技术栈可能不全，但是够用，最后给个学习路线。 Tip：请多欣赏一会，每个点看一下，看看什么地方是你接触过的，什么技术栈是你不太熟悉的，我觉得还算是比较全的，有什么建议也可以留言给我。 不知道大家都看了一下没，现在我们就要庖丁解牛了，我从上到下依次分析。 三、前端 你可能会会好奇，你不是讲后端学习路线嘛，为啥还有前端的部分，我只能告诉你，傻瓜，肤浅。 我们可不能闭门造车，谁告诉你后端就不学点前端了？ 前端现在很多也了解后端的技术栈的，你想我们去一个网站，最先接触的，最先看到的是啥？ 没错就是前端，在大学你要是找不到专门的前端同学，去做系统肯定也要自己顶一下前端的，那我觉得最基本的技术栈得熟悉和了解吧

zookeeper 分布式锁 分布式锁的概念，大家应该都已经理解，在此不会细讲。 分布式锁简单来说就是服务器集群环境下出现用户高并发访问同一个资源时，对该资源访问进行加锁等待，以保证资源的准确性。 zookeeper的分布式锁是并发的多线程通过循环的请求创建zk节点来竞争锁的占有权，待取得占有权后，其他线程进入等待。待释放占有权后，其他线程再进行循环竞争。 本编文章，主要讲解zk分布式锁，如何使用，具体逻辑还需根据实际场景进行调整。 代码是在本地建设，为了方便测试，所以里面都是静态方法。真正的开发环境都是基于webservlet或微服务工程，使用bean的方式进行类对象或者方法的调用。大家可以根据自己的工程业务做zk分布式锁的封装。 重点提醒下： 如果使用zk的watcher监听通知，节点创建后并瞬间删除，zkServer将会监听失败。因为zkServer的监听有延迟，当执行监听的时候，他发现并无该节点的stat信息，故不执行监听。 1.客户端创建 　 　zk是支持集群的，所以这里两种客户端形式，代码操作是一样的，唯有连接地址略有差异。 package com.qy.zk.lock; import org.apache.curator.RetryPolicy; import org.apache.curator.framework.CuratorFramework; import

1、zk基础： 1.1、ZAB 协议 唯一leder保证了所有事务全局有序，follower 收到事务请求需要转发给leader ZAB 协议定义的两种模式：崩溃恢复和消息传播。 恢复模式 ：集群启动、leader 崩溃（leader 与 follower 网络中断等）时 集群处于恢复模式，对外不可用； 消息广播 ：过半的follower 同步了leader的状态后，集群进入广播模式，此时新加入的节点自动进入广播模式， 1.2、协议详解： 消息广播 采用的原子广播协议，类似二阶段提交。 leader 收到事务请求后为该事务生成全局唯一事务ID(WZID) 产生事务 proposal， 并发送给 follower， follower 收到后恢复确认（即选票），leader 收到过半选票就向客户端 commit 事务成功；消息广播协议采用 TCP 通信； 如何保证消息的全局有序处理? 1、leader 为 每个 follower 分配一个 FIFO 队列， 每个事务proposal 都会放进队列，再发送给 follower 。 2、follower 收到事务后先将proposal 落盘到事务日志，然后返回leader ACK。 3、leader 收到过半数的 ACK 就发送commit 消息给follower 通知其进行事务提交，同时自己也提交事务。 ZAB 协议保证在leader

某厂面试归来，发现自己落伍了！>>> 一、java源码相关 ArrayList创建和add等各种api使用原理 ArrayList 允许空值和重复元素，当往 ArrayList 中添加的元素数量大于其底层数组容量时，其会通过 扩容 机制重新生成一个更大的数组。 ArrayList 是非线程安全类，并发环境下，多个线程同时操作 ArrayList，会引发不可预知的异常或错误。 ArrayList创建源码 带有初始容量的构造方法 /** * Shared empty array instance used for empty instances. */ private static final Object[] EMPTY_ELEMENTDATA = {}; /** * Constructs an empty list with the specified initial capacity. * * @param initialCapacity the initial capacity of the list * @throws IllegalArgumentException if the specified initial capacity * is negative */ public ArrayList(int initialCapacity) { // 参数大于0

1.上传zookeeper压缩包到linux系统中 2.解压到/app目录 tar -zxvf zookeeper-3.4.5.tar.gz -C app 3.到conf目录下，修改zoo_sample.cfg为zoo.cfg 4.编辑zoo.cfg 4.1 修改本地存储路径 4.2 添加集群机器，端口 5.在新建的data目录中新建myid，内容为1，这个与刚才编辑的server.1向对应 6.把已经安装好的zookeeper复制到node002,node003中，注意修改data下的myid 7.在bin下启动zookeeper ./zkServer.sh start 为什么zkServer.sh start不可以？只能加上./ 8.查看zookeeper工作状态 ./zkServer.sh status 因为我们配置3台，只启动1台，少于集群配置的一半，zookeeper就不能工作 9.遇到此时遇到几个问题 1.在把zookeeper文件赋复制到另外两个服务器后，在启动./zkServer.sh start 后，jps查看进程，发现提示command not found 解决办法：从新安装jdk，并且重新配置环境变量 2.Zookeeper启动显示成功，zkServer.sh status报错 解决办法：网上查阅资料，有存在相同问题的朋友已解决，此处引入其解决办如下：

研读dubbo源码已经有一段时间了，dubbo中有非常多优秀的设计模式和示例代码值得学习，但是dubbo的调用层级和方法链都较为繁杂，如果不对源码思路进行梳理则很容易忘却，因此总结一篇研读心得，从 阅读源码的思路 、 应用调配的参数 以及 面试准备上 对此进行一个全面总结。 一、dubbo的架构思路 1.1 dubbo框架设计 dubbo官网的 架构设计 提供了一张整体的框架图，10个层级看起来挺吓人的。但是其核心总结起来就是： Microkernel + Plugin（微内核+插件） 。 官网介绍的架构设计思想是两点： 采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息； 采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。 对于第一点比较容易理解，因为是分布式环境，各系统之间的参数传递基于URL来携带配置信息，所有的参数都封装成 Dubbo 自定义的 URL 对象进行传递。URL 对象主要包括以下属性： String protocol String host int port String path Map < String , String > parameters 第二点

环境搭建 第一步：创建一个Maven工程，添加Maven依赖： < dependency > < groupId > junit </ groupId > < artifactId > junit </ artifactId > < version > 4.12 </ version > </ dependency > < dependency > < groupId > org.projectlombok </ groupId > < artifactId > lombok </ artifactId > < version > 1.18.4 </ version > </ dependency > < dependency > < groupId > org.apache.logging.log4j </ groupId > < artifactId > log4j-core </ artifactId > < version > 2.8.2 </ version > </ dependency > < dependency > < groupId > org.apache.zookeeper </ groupId > < artifactId > zookeeper </ artifactId > < version > 3.4.13 </ version > </