前阵子在生产上碰到了一个诡异现象：全量作业无法正常进行，日志中充斥着java.util.concurrent.TimeoutException: Heartbeat of TaskManager with id container xxxx(HOSTNAME:PORT) timed out的报错。

将Flink应用至生产已有一段时间，刚上生产的时候有幸排查过因数据倾斜引起的Checkpoint超时问题——当时简单的了解了相关机制，最近正好在读Flink源码，不如趁这个机会搞清楚。

前阵子组里的小伙伴问我“为什么Flink从我们的代码到真正可执行的状态，要经过这么多个graph转换？这样做有什么好处嘛？”我早期看到这里的设计时的确有过相同的疑惑，当时由于手里还在看别的东西，查阅过一些资料后就翻页了。如今又碰到了这样的问题，不妨就在这篇文章中好好搞清楚。

写这篇文章前，我翻看了一下去年的总结。发现“人终将一死”这个想法在那时便植入我的脑海里。每当早上醒来，睁眼看到太阳升起，我便会想到这个事——这倒不会让我产生负能量，我只是会想这辈子能做些什么，变成什么样的人。这意味着我很难在一些简单的事中获得满足或沉溺于一些唾手可得的欲望之中。

在最初接触到Flink时，是来自于业界里一些头部玩家的分享——大家会用其来处理海量数据。在这种场景下，如何避免JVM GC带来StopTheWorld带来的副作用这样的问题一直盘绕在我心头。直到用了Flink以后，阅读了相关的源码（以1.14.0为基准），终于有了一些答案。在这篇文章里也是会分享给大家。

最近负责了产品中一部分的监控事宜。我想到时序数据库的对于RT和IOPS的要求应该很高，因此想看看它内部是怎么实现的——会不会和我认识的Kafka、HBase很像。

前阵子笔者涉及了些许监控相关的开发工作，在开发过程中也碰到过些许问题，便翻读了Flink相关部分的代码，在读代码的过程中发现了一些好的设计，因此也是写成文章整理上来。

之前的DDD文章——谈谈代码：降低复杂度，从放弃三层架构到DDD入门，通篇下来像 是简单的讲了一些概念，然后快速的实战一下——很多同学反馈感觉就是入门了，但没有完全入门，因此我们再加一篇。

但这有一个问题，需要分配端口。之前我们团队用了很多麻烦的实现：分布式锁、多份状态存储等...但仍然避免不了端口泄漏、浪费的问题（拓扑高可用机制会导致它在不同的机器间偏移，那么之前分配的某机器端口就无用了）。尽管我们也可以去监控拓扑的生命周期，但这绝非易事——在较大的场景中，k级的拓扑是很正常的，然而要...

本文首发于泊浮目的简书:[链接]版本日期备注1.02021.8.1文章首发1.12021.8.3改进部分描述1.前言最近我发现团队某项目的复杂度越来越高（典型的三层架构），具体表现为：代码可读性较差：各个服务之间调用复杂，流程不清晰修改某服务业务代码导致大量无关服务的测试用例失败，单个功能开发者很难迅速定位相关问题测试用例...

本文首发于泊浮目的简书：[链接]版本日期备注1.02021.6.20文章首发最近Iceberg有点小火，在这里也是根据自己看到的资料做个笔记输出一下。数据湖的定义就不说了，不了解的小伙伴可以看我之前做的笔记大数据学习笔记1：数仓、数据湖、数据中台。1. 数据湖发展现状从广义上来说数据湖系统主要包括数据湖村处和数据湖分析现...

商业智能（Business Intelligence）诞生在上个世纪 90 年代，它是将企业已有的数据转化为知识，帮助企业做出经营分析决策。

大数据从数据源开始，经过分析、挖掘到最终获得价值一般需要经过6个主要环节，包括数据收集、数据存储、资源管理与服务协调、计算引擎、数据分析和数据可视化，技术体系如图所示。每个环节都面临不同程度的技术挑战。

本文首发于泊浮目的简书:[链接]版本日期备注1.02020.9.13文章首发1.12020.11.8优化对于第一个方案的措辞1.22021.1.17优化小结部分1.32021.2.3修改标题从利用Clean Architecture写好白盒测试 -> 遵循Clean Architecture写好白盒测试1.42021.5.21修改标题从遵循Clean Architecture写好白盒测试 -> 技巧：遵循Clean A...

为什么是最简单的方式呢？我们想象一下，当我们写数据到Leader时，Leader写入自己的一份数据后，可能会做副本到Follower，那么拷贝的数量、及所在的位置都由该Leader来控制。但如果是多Leader调度，就要涉及到数据分区，请求负载均衡等问题了。

当我们向zk发出一个数据更新请求时，这个请求的处理流程是什么样的？zk又是使用了什么共识算法来保证一致性呢？带着这些问题，我们进入今天的正文。

最近在开发时偶尔会观测到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模式。