我的 个人网站 上线了，上面可以更好的检索历史文章，并且可以对文章进行留言，欢迎大家访问 可能大家都知道或者被问过一个问题，那就是很经典的「从浏览器输入 URL 再到页面展示，都发生了什么」。这个问题虽然简单，但是真的能够从回答的各种细节上看出不同人之间的水平差距。 这篇文章主要是聊一聊输入 URL 之后的第一步——域名解析 域名就类似于 www.google.com，而通过 ping 命令，就可以查询到对应域名的 IP 地址了。 那为什么又要有域名，又要有 IP 呢？ 域名、IP 共存 首先还是解释一下，为什么会出现现在这种域名、IP 地址共存的情况。主要有两个点： 提升用户体...
我的 个人网站 上线了，上面可以更好的检索历史文章，并且可以对文章进行留言，欢迎大家访问 之前讲了「从输入 URL 再到浏览器成功看到界面」中的域名是如何变成 IP 地址的，了解了 DNS 相关的东西。这篇文章就聊聊发生在 DNS 解析之后的操作——建立连接。也就是我们常说的三次握手。 看到三次握手你可能会说，这不是面试都被问烂了的题吗？ 三次握手不就是： 服务器开始为 CLOSE 状态，然后监听某个端口，此时服务器会进入 LISTEN 状态 客户端最初也是 CLOSE 状态，客户端会向服务器发送一个带 SYN 标志位的数据包，主动发起连接。此时客户端会变成 SYN-SENT 状...
可能我们对 RocketMQ 的消费者认知乍一想很简单，就是一个拿来消费消息的客户端而已，你只需要指定对应的 Topic 和 ConsumerGroup，剩下的就是只需要： 接收消息 处理消息 就完事了。 简略消费模型 当然，可能在实际业务场景下，确实是这样。但是如果我们不清楚 Consumer 启动之后到底会做些什么，底层的实现的一些细节，在面对复杂业务场景时，排查起来就会如同大海捞针般迷茫。 相反，你如果了解其中的细节，那么在排查问题时就会有更多的上下文，就有可能会提出更多的解决方案。 关于 RocketMQ 的一些基础概念、一些底层实现之前都已在文章 RocketMQ基础概...
首先，造成这个问题的 BUG RocketMQ 官方已经在 3月16号 的这个提交中修复了，这里只是探讨一下在修复之前造成问题的具体细节，更多的上下文可以参考我之前写的 《RocketMQ Consumer 启动时都干了些啥？》 ，这篇文章讲解了 RocketMQ 的 Consumer 启动之后都做了哪些操作，对理解本次要讲解的 BUG 有一定的帮助。 其中讲到了： 消息堆积 重复消费自不必说，你 ClientID 都相同了。本篇着重聊聊为什么会消息堆积。 文章中讲到，初始化 Consumer 时，会初始化 Rebalance 的策略。你可以大致将 Rebalance 策略理解为...
这篇文章的深度不会太深，重点就是了解一下用户态和内核态的区别就 OK 了。 先给不了解内核态、用户态的简单介绍一下，我们在什么时候会提到这两个概念。 例如我们的应用程序需要从磁盘读取某个文件的数据，此时并不是直接从磁盘加载到应用内存中，而是： 先将数据从「磁盘」复制到「内核 Buffer」 再将数据从「内核 Buffer」复制到「用户 Buffer」 以上就是用户态和内核态的概念。首先我们给他下个定义，这两个态是操作系统的运行级别。 然后我们知道，我们写的程序，最终运行的时候实际都会被编译、解释成一条一条的 CPU 指令被 CPU 执行。 解释成一条一条的指令 用户态、内核态的指...
为什么要讲 Buffer 首先为什么一个小小的 Buffer 我们需要单独拎出来聊？或者说，Buffer 具体是在哪些地方被用到的呢？ 例如，我们从磁盘上读取一个文件，并不是直接就从磁盘加载到内存中，而是首先会将磁盘中的数据复制到内核缓冲区中，然后再将数据从内核缓冲区复制到用户缓冲区内，在图里看起来就是这样： 从磁盘读取文件 再比如，我们往磁盘上写文件，也不是直接将数据写到磁盘。而是将数据从用户缓冲区写到内核缓冲区，由操作系统择机将其刷入磁盘，图跟上面这个差不多，就不画了，自行理解。 再再比如，服务器接受客户端发过来的数据时，也不是直接到用户态的 Buffer 中。而是会先从网卡...
最近越来越认为，在讲解技术相关问题时，大白话固然很重要，通俗易懂，让人有想读下去的欲望。但几乎所有的事，都有两面性，在看到其带来好处时，不妨想想是否也引入了不好的地方。 例如在博客中，过于大白话的语言的确会让你阅读起来更加顺畅，也更容易理解。但这都是其他人理解，已经咀嚼过了的，人家是已经完全理解了，你从这些信息中大概可能会观察不到全貌。所以，适当的白话是很好的，但这个度得控制一下。 接下来切入正文。 相信大家经常看到这个问题： BIO、NIO 和 AIO 有什么区别？ 看到这个问题，可能你脑海中就会浮现以下这些字眼。比如 BIO 就是如果从内核获取数据会一直阻塞，直到数据准备完毕...
Java NIO 中的 Channel 分类： FileChannel SocketChannel ServerSocketChannel DatagramChannel FileChannel: 主要用于文件的读写，可以从磁盘上读取文件，也可以向磁盘上写入文件。 SocketChannel：用于 Socket 的 TCP 连接的数据读写，既可以从 Channel 读数据，也可以向 Channle 中写入数据 ServerSocketChannel：通过 ServerSocketChannel 可以监听 TCP 连接，服务端监听到连接之后，会为每个请求创建一个 SocketCha...
之前的文章已经把 Java 中 NIO 的 Buffer、Channel 讲解完了，不太了解的可以先回过头去看看。这篇文章我们就来聊聊 Selector —— 选择器。 首先 Selector 是用来干嘛的呢？不熟悉这个概念的话我们其实可以这么理解： 把它当作 SQL 中的 select 语句，在 SQL 中无非就是筛选出符合条件的结果集合。而 NIO 中的 Selector 用途类似，只不过它选择出来的是有就绪 IO 事件的 Channel。 IO 事件代表了 Channel 对于不同的 IO 操作所处的不同的状态，而不是对 Channel 进行 IO 操作。总共有 4 种 IO 事件的定义…
前言 首先，synchronized 是什么？我们需要明确的给个定义——同步锁，没错，它就是把锁。 可以用来干嘛？锁，当然当然是用于线程间的同步，以及保护临界区内的资源。我们知道，锁是个非常笼统的概念，像生活中有指纹锁、密码锁等等多个种类，那 synchronized 代表的锁具体是把什么锁呢？ 答案是—— Java 内置锁。在 Java 中，每个对象中都隐藏着一把锁，而 synchronized 关键字就是激活这把隐式锁的把手（开关）。 先来简单了解一下 synchronized，我们知道其共有 3 种使用方式： 修饰静态方法：锁住当前 class，作用于该 class 的所有实例 修饰非静…
前言 事情是这样的，在某乎的邀请回答中看到了这个问题： – 然后当时我没多想就啪一下写下来这样的答案： 这个其实要通过 MySQL 后台线程来刷的，在 Buffer Pool 中被修改的过的 Page（页）都会被标记成脏页，放到一个链表（Flush 链表）里。 然后 MySQL 通过启动后台线程，在满足条件时将 Flush 链表中的脏页刷入磁盘。 满足的条件是：脏页的数量达到了 Buffer Pool 中页数量的 **10%，当然 10% 这个值是可变的，通过配置项 innodb_max_dirty_pages_pct_lwm 来配置的，其默认值为 10%，并且这个值...
一、前言 大家如果看过我之前发过的文章就知道，我写过很多篇关于 MySQL 的文章，从我的 Github 汇总仓库 中可以看出来： 可能还不是很全，算是对 MySQL 有一个浅显但较为全面的理解。之前跟朋友聊天也会聊到，基于现有的微服务架构，绝大多数的性能瓶颈都不在服务，因为我们的服务是可以横向扩展的。 在很多的 case 下，这个瓶颈就是「数据库」。例如，我们为了减轻 MySQL 的负担，会引入消息队列来对流量进行削峰；再例如会引入 Redis 来缓存一些不太常变的数据，来减少对 MySQL 的请求。 另一方面，如果业务往 MySQL 中灌入了海量的数据，不做优化的话，会影响 MySQL 的…