最近在开发时偶尔会观测到zk报出BadVersionException，后在搜索引起上得知了是乐观锁相关的问题，很快就解决了问题。不过学而不思则罔：无论是单体应用还是分布式系统，在运行过程中总要有一种机制来保证数据排他性。接下来，我们就来看看zk是如何实现这种机制的。

本文首发于泊浮目的简书:[链接]版本日期备注1.02020.4.8文章首发1.12020.4.18优化小结部分描述，使其更加详细易懂1.22020.8.10删除部分不重要的代码，减少篇幅，优化描述方式1. 前言本文面向读者：有java基础并对zk源码实现感兴趣的同学。用过zookeeper的同学都知道watch是一个非常好用的机制，今天我们就来看看它的实现...

我们知道zookeeper是一个分布式协同系统。在一个大型的分布式系统中，必然会有大量的client来连接zookeeper。那么zookeeper是如何管理这些session的生命周期呢？带着这个问题，我们进入今天的正文。

本文首发于泊浮目的简书:[链接] 版本 日期 备注 1.0 2020.3.12 文章首发 1.0.1 2020.3.16 改进部分大小写问题及形容方式 1.0.2 2020.3.21 改进可能会引起错误理解的部分 1.0.3 2020.3.29 修改标题 1.0.4 2020.4.18 改进小结部分 1.0.5 2020.6.26 更新部分部分解释，改进注释风格 1.0.6 2020.7.6 增加部分详细解释 前言 ...

这个可以通过官网来看[链接]。第一眼看过去，我们就知道它是一个分布式协同系统。并且提供了一些分布式系统中较常用的功能：如配置管理、DNS服务、分布式协同和组成员管理。

如果按照以往的惯例，我会在标题前面加个词简单描述一下。但在写这篇文章时，我想了很久，都没想出什么词可以满足“简单的描述一下”。所以就不写了。

本文首发于泊浮目的简书:[链接]版本日期备注1.02019.8.11文章首发1.12021.5.21修改标题：浅谈函数式编程-> 谈谈代码：函数式编程1. 前言一个风和日丽的下午,我看着日常看代码做重构迁移,突然看到这么段代码: {代码...} 看了这段代码我整个人都不好了!首先是那火箭式的三个嵌套for循环,再者就是那些变量声明语句.为了...

简单解释一下这段代码——即通过ssh到一台机器上,然后执行一些命令.对命令输出的东西,开了一个循环,每一次读一定的位置,然后以字节流的形式读回来.

代理模式是在编程中非常常见的设计模式.笔者在面试的过程中也经常会问到相关的问题,但是很多同学答的并不尽人意.在这篇文章中,笔者想和大家聊聊代理模式的应用及一些实践.

最近项目在测试阶段陆陆续续的测出了一些bug.这个情况刚出现的时候,让笔者很困惑——平时我们的每个feature代码都是跟随着大量看起来考虑很周全的case进入代码仓库的,然而事实还是打了我们的脸.故在本文,笔者将会从最近的所学所想来谈谈编写测试的时候我们应该注意什么.

在写代码的日常中,if...else语句是极为常见的.正因其常见性,很多同学在写代码的时候并不会去思考其在目前代码中的用法是否妥当.而随着项目的日渐发展,糟糕的if...else语句将会充斥在各处,让项目的可维护性急剧下降.故在这篇文章中,笔者想和大家谈谈如何避免写出糟糕if...else语句.

18年还是让我觉得过得很快,我想去年的我也是这么想的.不同的是,我觉得我今年经历了许多事,这让我变得...或者说,在那么几个瞬间,我又老了一点.

众所周知，ZStack管理节点部分有一套较为完善的自动化测试框架，可以满足大多数场景。而Utility并非如此，只能通过黑盒测试来保证其质量，且许多测试场景需要start up一个真实的ZStack的环境，测试成本较高。

在前文 ZStack源码剖析之二次开发——可扩展框架中，我们大概的了解了如何在ZStack中进行二次开发。在本文，笔者将和大家一起了解一下常用debug管理节点的方法，用于更好的了解运行时的情况。

我经常写测试——这算是我对软件工程的一点执念。前阵子折腾了基于ZStack的二次开发，每次提交代码前都要自己跑一趟测试，着实有点慢。自己撸一套系统成本又太高，正发愁时发现GitLab自带了CI系统，便开始了折腾之旅。

在上篇文章中（ZStack源码剖析之二次开发——可扩展框架），我们简单的了解了一下ZStack核心引擎的二次开发技巧。在这篇文章中，我们将一起来了解ZStack-Utility（即ZStack的Agent端）的二开姿势。

在ZStack博文-5.通用插件系统中，官方提出了几个较为经典的扩展方式。但在实际的二次开发中，这些做法未必能够完全满足需求。今天笔者就和大家一起来看一看一些常见的扩展方法。

在ZStack中，当用户在UI上发起操作时，前端会调用后端的API对实际的资源发起操作请求。但在一个分布式系统中，我们不能假设网络是可靠的（同样要面对的还有单点故障等）——这往往导致API会超时。ZStack有默认的API超时机制，为30mins。但从UI上看来，用户的体验不是很好，如下：

无论什么程序，其目的都是解决问题。而为了解决问题，我们又需要编写特定的算法。使用Strategy模式可以整体地替换算法的实现部分。能够整体地替换算法，能让我们轻松地以不同的算法去解决一个问题，这种模式就是Strategy模式。

EventFacade是一个很有意思的组件，因为它几乎是自举的。这就意味着有兴趣的朋友可以copy and paste，然后稍作修改就可以在自己的项目里工作起来了。

笔者工作2年有余，刚开始实习的时候是不知道自动化测试这种神器的，在刚开始工作的时候往往苦于救火灭火再救火，搞的心力憔悴，一度怀疑猿生。实践自动化测试后感觉生产力慢慢的解放了，那个时候搞的还是偏单机应用，测试的Cover也是止步在单机应用上。在接触到了ZStack以后，由于其产品化的特性，对软件质量要求偏高，...

随着ZStack的版本迭代，其可以掌管的资源也越来越多。但新增模块的结构却还是大致相同，此即是ZStack的经典设计模式——这套模式也被开发者称为ZStack三驾马车。

前阵子出去玩了一趟，回来思衬着年度总结还没写，就过来补了。 回看，在ZStack待了1年多，从30多人到团队到近百人团队，从A轮前到B轮展望——有好有坏，尽收眼里。一句话概括：我肥了，也变强了。 今年在内部GitLab的Activity记录（六月的时候我们从GitHub上切到了GitLab）： 接下来说说今年我在工作中意识到的一些事情吧—...

在ZStack（或者说产品化的IaaS软件）中的任务通常有很长的执行路径，错误可能发生在路径的任意一处。为了保证系统的正确性，需提供一种较为完善的回滚机制——在ZStack中，通过一个工作流引擎，ZStack的每一个步骤都被包裹在独立的工作流中，可以在出错的时候回滚。此外，通过在配置文件中组装工作流的方式，关键的执行路...

在ZStack中，最基本的执行单位不仅仅是一个函数，也可以是一个任务（Task。其本质实现了Java的Callable接口）。通过大小合理的线程池调度来并行的消费这些任务，使ZStack这个Iaas软件有条不紊运行在大型的数据中心里。

前言 前阵子和同事在吃饭时聊起Java的String，觉得自己之前的笔记写的略显零散。故此又重新整理了一下。 String在Java中算是一个有意思的类型，是final类型，因此不可以继承这个类、不能修改这个类。 两个小问题 我们先来看一段代码： {代码...} 试问：这两行代码执行后，原始的 String 对象中的内容到底变了没有？ 答案...

本文首发于泊浮目的专栏：[链接] 在Go语言中，有一个关键字叫做defer——其作用是在函数return前执行。在ZStack中也有类似的工具类，让我们来看看吧。 演示代码 {代码...} 这段代码是ZStack ManageNode(简称MN)在接收到创建计算规格的请求后的处理逻辑，大致的逻辑即： 在DB中创建一条记录 添加当前账户与该计算规格的关联...

ZStack是下一代开源的云计算IaaS（基础架构即服务）软件。它主要面向的是未来的智能数据中心，通过提供的API来管理包括计算、存储和网络在内的数据中心的各种资源。跟OpenStack相比，ZStack具有易用、稳定、灵活、超高性能等特点。其单管理节点可以管理1万台物理机规模集群，多个管理节点构建的集群可以做到使用一个数据...

看了该问题，笔者真是有所感慨：从实习到现在，从接的外包小项目到企业级应用，从觉得日志没什么软用到在客户的环境中排bug在日志中看到蛛丝马迹。不得不说，日志真是太重要了。

消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

Spring致力于提供一种方法管理你的业务对象。在大量Java EE的应用中，随处可见Spring。今天我将简单的介绍一下Spring这个框架。

Java反射机制主要提供了以下功能： 在运行时判断任意一个对象所属的类 在运行时构造任意一个类的对象 在运行时判断任意一个类所具有的成员变量和方法 在运行时调用任意一个对象的方法 生成动态代理 很多框架都用到了反射机制，包括大名鼎鼎的Spring。因此，了解反射也可以说是为之后学习框架源码而打下坚实的基础。 即便...

多线程的软件设计方案确实可以最大限度地发挥现代多核处理器的计算能力，提高生产系列的吞吐量和性能。但是，若不加控制和管理的随意使用线程，对系统的性能反而会产生不利的影响。最容易想到的后果就是线程过多导致CPU忙于切换而无力执行其中的工作。

int枚举是编译时常量，被编译到客户端中，如果枚举常量关联的int发生变化，客户端必须重新编译，如果没有重新编译，程序仍可以运行，但行为就不确定了。

目前我就职于一家做云计算的公司，属于研发岗。这儿人才云集，我觉得我可能是其中最菜的一个。所以还是要感谢创始人的知遇之恩。虽然有点忙，但是我过得很快乐，我可以学到很多东西。