九师兄

Flink 基于 Chandy-Lamport 分布式快照算法实现了 Checkpoint 机制，能够提供 Exactly Once 或者 At Least Once 语义。​Flink 通过在数据流中注入 barriers 将数据拆分为一段一段的数据，在不终止数据流处理的前提下，让每个节点可以独立创建 Checkpoint 保存自己的快照。每个 barrier 都有一个快照 ID ，在该快照 ID 之前的数据都会进入这个快照，而之后的数据会进入下一个快照。​。

k8s 是 G 家开源的神器，用于管理海量容器服务。k8s 集群内分为控制平面和 Node，控制平面是大脑，负责发指令，Node 是手脚，负责执行任务。控制平面内有 API Server，Scheduler，Controller Manager 以及 etcd 等组件。Node 中含有 Pod，Kubelet,Container runtime, Kube Proxy 等组件。控制平面和 Node 共同构成一个 Cluster。

执行一条 SQL 查询语句，期间发生了什么？连接器：建立连接，管理连接、校验用户身份；查询缓存：查询语句如果命中查询缓存则直接返回，否则继续往下执行。MySQL 8.0 已删除该模块；解析 SQL，通过解析器对 SQL 查询语句进行词法分析、语法分析，然后构建语法树，方便后续模块读取表名、字段、语句类型；执行 SQL：执行 SQL 共有三个阶段：预处理阶段：检查表或字段是否存在；将 select * 中的 * 符号扩展为表上的所有列。优化阶段：基于查询成本的考虑， 选择查询成本最小的执行计划；

本文概述了YARN（Yet Another Resource Negotiator）的任务提交与启动流程。首先介绍了YARN中的核心组件：ResourceManager（RM）负责全局资源调度，NodeManager（NM）管理单节点资源，ApplicationMaster（AM）协调具体应用运行，以及Container作为资源封装单位。然后详细描述了任务从客户端提交到最终运行的8个主要步骤：客户端请求启动AM→RM分配资源→NM启动AM→AM注册并申请任务资源→RM分配任务Container→AM请求NM

我们详细介绍了 MergeTree 系列中的 MergeTree、ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree 四种表引擎，还有 SummingMergeTree、AggregatingMergeTree 没有介绍，SummingMergeTree 是为不关心明细数据，只关心汇总数据设计的表引擎。

在 WatermarkStrategy 中，时间戳分配器都是大同小异的，指定字段提取时间戳就可以了；而不同策略的关键就在于 WatermarkGenerator 的实现。一种是周期性（ Periodic ），另一种是断点式（ PunctuatedonEvent() ：在每个事件到来时调用onPeriodicEmit() 由框架周期性调用。周期性调用的方法中发出水位线，自然就是周期性生成水位线；而在事件触发的方法中发出水位线，自然就是断点式生成了。

第一种方式定义的方式当然是通过直接继承ApplicationListener，同时不要忘记通过泛型指定事件类型，它可是将事件广播给监听器的核心匹配标志。@OverrideSystem.out.println(Thread.currentThread().getName() + "接受到事件:"+event.getSource());通过ApplicationListener定义的监听器，本质上是一个单事件监听器，也就是只能处理一种类型的事件。

Innodb 「支持事务，支持行级锁，更好的恢复性」 ，高并发下性能更好，所以呢，没有特殊要求（即Innodb无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用Innodb存储引擎。，delete执行时,如果age加了索引，MySQL会将所有相关的行加写锁和间隙锁，所有执行相关行会被锁住，如果删除数量大，会直接影响相关业务无法使用。这个点，是阿里开发手册中，Mysql的规约。你的字段，尤其是表示枚举状态时，如果含义被修改了，或者状态追加时，为了后面更好维护，需要即时更新字段的注释。

在工作当中执行数据库删除的时候一定要慎重再慎重，建议每次进行数据删除的使用最好数据表的备份工作，这样就会大大减少你删除跑路的几率。很多时候不要过于相信自己的动手能力，老虎还有打盹的时候，万一手滑了呢。尽可能养成好的数据库运维习惯，这样会让自己少跌跟头，你的事业才会更加顺利。

jar 包类似于 zip 压缩文件，只不过相比 zip 文件多了一个文件，该文件在构建 jar 包时自动创建想要制作可执行 JAR 包，在 MANIFEST.MF 中指定Main-Class是关键。使用 java 执行 jar 包的时候，实际上等同于使用 java 命令执行指定的Main-Class程序。Spring Boot 提供了一个插件 spring-boot-maven-plugin ，用于把程序打包成一个可执行的jar包。

此番修正主要是每个人对「扩容」定义存在了分歧，在JDK1.8中如果没有给HashMap设置初始容量，那么在第一次put()操作的时候会进行resize()。而有的人认为这算一次扩容，有的人认为这不是一次扩容，这只是HashMap容量的初始化。前者的人认为扩容次数为 8 次。后者的人认为扩容次数为 7 次。孤尽老师说对此分歧，希望用没有「二义性」的语言来表示，所以「扩容次数」修正为「resize次数」。

知识积累，建议大家去看原文。面试官问：Git 如何撤回已 Push 的代码？如果问你，你会吗？在日常的开发中，我们经常使用Git来进行版本控制。有时候，我们可能会不小心将错误的代码 Push 到远程仓库，或者想要在本地回退到之前的某个版本重新开发。或者像我一样，写了一些感觉以后很有用的优化方案push到线上，又接到了一个新的需求。但是呢，项目比较重要，没有经过测试的方案不能轻易上线，为了承接需求只能先把push上去的优化方案先下掉。

本章是对上一篇文章的补充。每个Spring Boot版本和内置容器不同，结果也不同，这里以Spring Boot 2.7.10版本 + 内置Tomcat容器举例。相关配置及默认值如下。

最近十年，Elasticsearch 已经成为了最受欢迎的开源检索引擎，并沉淀了大量的实践案例及优化总结。在本文中，我们尽可能全面地总结了 Elasticsearch 日常开发中的一些重要实践&避坑指南，希望能为大家提供 Elasticsearch 使用上的一些借鉴点，欢迎讨论！

当你在未指定 ID 的情况下对文档建立索引时，Elasticsearch 会自动为该文档生成唯一的 ID。该 ID 是 Base64 编码的 UUID，由多个部分组成，每个部分都有特定的用途。ID 生成过程针对索引速度和存储效率进行了优化。负责此过程的代码可以在 GitHub 上的 Elasticsearch 的 TimeBasedUUIDGenerator 类中找到。

转载：Elasticsearch集群健康与指标梳理对于运维管理员来讲集群平稳运行非常重要，Elasticsearch提供了health命令和stats统计指标来说明集群是否正常。一、集群健康状况说明通过「_cluster/health」命令能快速了解集群、索引、分片的健康状况，以及这些不健康大体是怎么引起的。复制参数说明level指定查询的层级，可选cluster, indices 和 shards ，默认clusterlocal是否从本地node查询，默认false从master节点查询。

注：这里的挂掉都是指网卡挂了，并不是被 kill 或者关机，这里两者有本质区别：网卡下线，需要探测时间。

在 YARN 中，不管是 ApplicationMaster（后面均简称 AM），还是一般的 container（例如 MR 中的 map 任务、reduce 任务；Spark 中的 executor 或者 Flink 中的 TaskManager），都有各自的启动上下文（ContainerLaunchContext）。上下文中包含了任务启动所依赖的资源（包括 jar，资源文件等）、环境变量、启动参数等。

OffsetIndex 继承 AbstractIndex，它使用了内存映射 MappedByteBuffer 读取索引文件。// 每条记录的大小@volatiletry {//如果文件是新建的，则分配空间。空间大小为，最接近maxIndexSize的entrySize的倍数// 获取file的大小。注意文件大小每次初始化为maxIndexSize，但是当文件关闭时，// 会截断掉多余的数据，所以文件的大小不是一样的// 实例MappedByteBufferelse。

那么问题来了，kafka到底会不会丢消息？答案是：会！（ 1 ）生产者发送数据；（ 2 ） Kafka Broker 存储数据；（ 3 ）消费者消费数据；在生产环境中严格做到exactly once其实是难的，同时也会牺牲效率和吞吐量，最佳实践是业务侧做好补偿机制，万一出现消息丢失可以兜底。

分布式事务了解吗？你们是如何解决分布式事务问题的？只要聊到你做了分布式系统，必问分布式事务，你对分布式事务一无所知的话，确实会很坑，你起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。现在面试，分布式系统成了标配，而分布式系统带来的分布式事务也成了标配了。因为你做系统肯定要用事务吧，如果是分布式系统，肯定要用分布式事务吧。先不说你搞过没有，起码你得明白有哪几种方案，每种方案可能有啥坑？比如 TCC 方案的网络问题、XA 方案的一致性问题。

代码编译的结果从本地机器码转变成字节码，是存储格式的一小步，却是编程语言发展的一大步。Java虚拟机把描述类的数据从Class文件加载进内存，并对数据进行校验，转换解析和初始化，最终形成可以呗虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这动作的代码模块成为“类加载器”。

register方法是将配置类注册到Spring的应用上下文中，它并不会立即创建配置类中声明的bean，这些bean的创建过程是在上下文的refresh阶段中进行的。在这个阶段，Spring容器会读取所有的配置类，并对配置类中使用了@Bean注解的方法进行解析，然后才会创建并初始化这些bean。@ConditionalOnProperty是Spring Boot中的一个注解，用于检查某个配置属性是否存在，或者是否有特定的值，只有满足条件的情况下，被该注解标记的类或方法才会被创建或执行。

一般来说，大企业或者架构师团队，都会为项目的业务系统定制一份较为通用的JVM参数模板，但是许多小企业和团队可能就疏于这一块的设计，如果老板某一天突然让你负责定制一个新系统的JVM参数，你上网去搜大量的JVM调优文章或博客，结果发现都是零零散散的、不成体系的JVM参数讲解，根本下不了手，这个时候你就需要一份较为通用的JVM参数模板了，不能保证性能最佳，但是至少能让JVM这一层是稳定可控的，相反，如果堆内存小，gc一次时间短，排队等待的线程等待时间变短，延迟减少，但一次请求的数量变小（并不绝对符合）。

controller默认是单例的，不要使用非静态的成员变量，否则会发生数据逻辑混乱。正因为单例所以不是线程安全的。我们首先访问 http://localhost:8080/testScope，得到的答案是1；然后我们再访问 http://localhost:8080/testScope2，得到的答案是 2。得到的不同的值，这是线程不安全的。接下来我们再来给controller增加作用多例 @Scope(“prototype”)

Java 进阶之字节码剖析中我曾经提到这么一段话int[128][2] ，int[256] 这两个数组看起来一样，但实际上前者比后者多了 246% 的额外开销针对这句话我收到了几位读者的私信，表示不明白为啥不过一个简单的二维数组会有这么大的开销，本来这个问题在我正在写的类加载机制中有详述，不过文章还没写完（估计本周发），所以我专门抽出这个问题探讨一下，五分钟就能看懂。

我们是基础架构部，腾讯云 CES/CTSDB 产品后台服务的支持团队，我们拥有专业的ES开发运维能力，为大家提供稳定、高性能的服务，欢迎有需求的童鞋接入，同时也欢迎各位交流 Elasticsearch、Lucene 相关的技术！在线上生产环境中，对于大规模的ES集群出现节点故障的场景比较多，例如，网络分区、机器故障、集群压力等等，都会导致节点故障。

Lucene 的 stored fields 主要用于行存文档需要保存的字段内容，每个文档的所有 stored fields 保存在一起，在查询请求需要返回字段原始值的时候使用。。例如。。用户定义的其它字段需要在 ES 的 mapping 中显示设置 field 的 store 属性为 true，该字段才会被 store。在查询的时候返回该字段的原始值。本文主要分析 stored fields 的三个流程及文件存储结构，基于 lucene 7.3.0 版本。

编译器的前端和后端。前端指的是编译器对程序代码的分析和理解。前端阶段只与语言的语法有关，而和目标机器无关。后端则是生成目标机器的目标代码有关。第一节说说编译器的前端技术。编译器将一般会将词法和语法解析器分开实现。

前两天面试的时候，面试官问我：一个ip发请求过来，是一个ip对应一个线程吗？我突然愣住了，对于SpringBoot如何处理请求好像从来没仔细思考过，所以面试结束后就仔细研究了一番，现在就来探讨一下这个问题。我们都知道，SpringBoot默认的内嵌容器是Tomcat，也就是我们的程序实际上是运行在Tomcat里的。所以与其说SpringBoot可以处理多少请求，到不如说Tomcat可以处理多少请求。关于Tomcat的默认配置，都在文件中，对应的配置类则是。：最少的工作线程数，默认大小是10。

实际上，如果不明确指明使用路由机制，实际上路由机制也是在发挥作用的，只是默认的路由值是文档的id而已。而个性化路由的需求主要是和业务相关的。默认的路由（如果是自动的生成的id）直观上会把所有的文档随机分配到一个分片上，而个性化的路由值就是和业务相关的了。这也会造成一些潜在的问题，比如user123本身的文档就非常多，有数十万个，而其他大多数的用户只有几个文档，这样的话就会导致user123所在的分片较大，出现数据偏移的情况，特别是多个这样的用户处于同一分片的时候，现象会更明显。

方法说明该方法更好的使用在跨版本ES集群迁移中，它允许 ES集群一次升级一个节点，因此在升级期间不会中断服务。不支持在升级持续时间之后在同一集群中运行多个版本的 ES，因为无法将分片从升级的节点复制到运行旧版本的节点。所以在升级前需要对当前使用版本进行备份，以便在升级出现异常时进行回滚。同时在升级过程中优先选择data节点，在data节点升级完成后，在对集群中master节点进行升级。同一主要版本的次要版本之间。

通过上面的分析我们已经完成了对@EnableXXX套路的了解，接下来我们自己动手实现下。首先需要准备一个 Spirng Boot的项目，这里我已经准备好了。根据我们分析源码的步骤我们首先需要准备一个配置类。接下来在 configuration包下，创建一个 HelloConfiguration。/*** Hello模块的配置} }这里被@Bean标注的方法，方法名会作为 bean对象的名称。而且当该 bean被加载的时候我们还会在控制台输出一段话。

不论是Collections.sort方法或者是Arrays.sort方法，底层实现都是TimSort实现的，这是jdk1.7新增的，以前是归并排序。TimSort算法就是找到已经排好序数据的子序列，然后对剩余部分排序，然后合并起来。

建议大家看原文。感觉上一篇文章，写的不是很好，又缺少一些，转载一篇补充一下。LSM树是HBase里非常有创意的一种数据结构，它和传统的B+树不太一样，下面先说说B+树。

在需要精确的小数计算时再使用BigDecimal，BigDecimal的性能比double和float差，在处理庞大，复杂的运算时尤为明显。故一般精度的计算没必要使用BigDecimal。尽量使用参数类型为String的构造函数。BigDecimal都是不可变的（immutable）的， 在进行每一次四则运算时，都会产生一个新的对象 ，所以在做加减乘除运算时要记得要保存操作后的值。

使用mybatis作为持久层的框架时，通过mybatis执行查询数据的请求执行成功后，mybatis返回的结果集不是一个集合或对象，而是一个迭代器，可以通过遍历迭代器来取出结果集，避免一次性取出大量的数据而占用太多的内存。

稍微总结下我粗略的对比（虽然粗略，但实验结果符合原理层面的理解），如果你想更准确地实验，可以使用JMH，并且测试更多组数（如 5000，10000等）的情况。批量保存方式数据量（条）耗时（ms）单条循环插入1000121011100059927mybatis-plus saveBatch(添加rewtire参数)10002589手动拼接sql10002275100055663jdbc executeBatch(添加rewtire参数)1000324。

首先，这是个 IPV4 地址。IPV4 地址有 32 位，一个字节有 8 位，共 4 个字节。其中127 开头的都属于回环地址 ，也是 IPV4 的特殊地址，没什么道理，就是人为规定的。而127.0.0.1是众多 回环地址中的一个。之所以不是 127.0.0.2 ，而是 127.0.0.1，是因为源码里就是这么定义的，也没什么道理。IPv4 的地址是 32 位的，2的32次方，大概是40+亿。地球光人口就76亿了，40亿IP这点量，塞牙缝都不够 ，实际上IP也确实用完 了。

因为 0.2 和 0.1 只是指数稍有不同，所以上图中只展示了 0.1 对应的单精度浮点数，从上图的结果我们可以看出，0.1 和 0.2 在浮点数中只能用近似值来代替，精度十分有限，因为单精度浮点数的小数位为 23，双精度的小数位为 52，同时都隐式地包含首位的 1，所以它们的精度在十进制中分别是。浮点数系统的设计是一个比较有趣的工程问题，因为操作系统一般都是 32 位或者 64 位的，浮点数充分利用了 32/64 位的比特，将每一位的作用都发挥到极致，使用最紧凑和简洁的方式实现了尽可能高的精度。