蘑菇蘑菇不会开花的专栏

最近一直在使用MACOS的M1系列电脑开发，发现在Centos8虚拟机环境下安装docker的各种问题，在这里进行总结，以备后期使用和参考。

工厂模式通过引入一个工厂类来负责对象的创建，解决了这些问题。工厂类封装了对象创建的逻辑，使得客户端代码只需要与工厂类交互，而不需要了解对象的具体创建过程。这样，当对象的创建逻辑发生变化时，只需要在工厂类中进行修改，而不会影响到客户端代码。

单一职责原则：一个类应该只有一个引起它变化的原因。也就是说，一个类只负责一项职责。开闭原则：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。里氏替换原则：所有引用基类（父类）的地方必须能透明地使用其子类的对象。依赖倒置原则：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。接口隔离原则：客户端不应该被迫依赖于它不使用的接口；一个类对另一个类的依赖应该建立在最小的接口上。迪米特法则：一个对象应该对其他对象有最少的了解。也叫最少知识原则。

RocketMQ的存储都基于MappedFile实现，如CommitLog、Index索引、ConsumeQueue等，本文则主要介绍的实现机制，包括MappedFileQueue类介绍、MappedFile类介绍、预热、MappedFile预分配服务AllocateMappedFileService、MappedFile刷盘等内容。

通过上面的分析，我们了解了RocketMQ的两种刷盘策略：一种是类似强一致的，保证消息存储到文件中的同步策略。一种是提交到内存中就算存储成功，在后台异步进行刷盘的异步策略。无论是哪种策略，肯定都有自己的优点和缺点，大家可以根据自己生成环境，选择合适的刷盘策略。

总结一下，RocketMQ 会创建多个MappedFile用来存储文件，每个MappedFile大小固定，有自己的内存缓冲区和对应的系统文件，所有的MappedFile由CommitLog中的MappedFileQueue统一维护。本篇文章主要讲解了消息从接收到存储到内存中的过程，但是事情到这还没结束，因为消息最终是要存放到文件中的，下一篇文章就要来说说RocketMQ的文件刷盘策略。

Broker负责接收生产者发送的消息并存储、同时为消费者消费消息提供支持。为了实现这些功能，Broker包含几个重要的子模块：● 通信模块：负责处理来自客户端（生产者、消费者）的请求。● 客户端管理模块:负责管理客户端（生产者、消费者）和维护消费者的Topic订阅信息。● 存储模块：提供存储消息和查询消息的能力，方便Broker将消息存储到硬盘。

Namesrv是RocketMQ最简单的一部分，骨头我们先挑最软的一根啃，本次引用的源码来于4.8.0版本，由于笔者水平有限欢迎大家批评指正。从上面的源码我们可以找到一开始我们抛出的三个问题的答案。①：Namesrv通过定时扫描Broker主动上报心跳信息来判断Broker是否存活。②：通过方法获取类维护的路由信息。

分布式队列因为有高可靠性的要求，所以数据要进行持久化存储。

所谓 MySQL 主从，就是建立两个完全一样的数据库，一个是主库，一个是从库，主库对外提供读写的操作，从库对外提供读的操作。

在实际项目开发中，我们经常将 MySQL 作为业务数据库，ES 作为查询数据库，用来实现读写分离，缓解 MySQL 数据库的查询压力，应对海量数据的复杂查询。这其中有一个很重要的问题，就是如何实现 MySQL 数据库和 ES 的数据同步，今天和大家聊聊 MySQL 和 ES 数据同步的各种方案。我们先看看下面 4 种常用的数据同步方案。

本来是一个平静而美好的下午，其他部门的同事要一份数据报表临时汇报使用，因为系统目前没有这个维度的功能，所以需要写个SQL马上出一下，一个同事接到这个任务，于是开始在测试环境拼装这条 SQL，刚过了几分钟，同事已经自信的写好了这条SQL，于是拿给DBA，到线上跑一下，用客户端工具导出Excel 就好了，毕竟是临时方案嘛。就在SQL执行了之后，意外发生了，先是等了一下，发现还没执行成功，猜测可能是数据量大的原因，但是随着时间滴滴答答流逝，逐渐意识到情况不对了，一看监控，

我们使用mysql时，使用xx!='aa'这种条件为什么无法筛选出值为NULL的字段呢。是的，MySQL 中null 值确实无法通过这种条件筛选出来，因为 null 值的定义就跟普通值不一样。第一条 SQL 表达的意思是：不知道这个人的手机号码，。第二条 SQL 表达的意思是：这个人就是。按照这个角度去看待群里同学的提问，其实不难理解为什么 xx!=‘xx’ 查询不出 null 的数据了。因为 null 值表示未知，它的值可能是任意你能想到的值，目前还不能定义它。

两者的语法区别在于，group by可以进行单列去重，group by的原理是先对结果进行分组排序，然后返回每组中的第一条数据。且是根据group by的后接字段进行去重的。如果列具有NULL值，并且对该列使用DISTINCT子句，MySQL将保留一个NULL值，并删除其它的NULL值，因为DISTINCT子句将所有NULL值视为相同的值。distinct多列的去重，则是根据指定的去重的列信息来进行，即只有所有指定的列信息都相同，才会被认为是重复的信息。的内容），我们对这两条sql进行分析，可以看到，在。

当我们对一张数据表中的记录进行统计的时候，习惯都会使用 count 函数来统计，但是 count 函数传入的参数有很多种，比如count(1)count(*)count(字段)等。到底哪种效率是最好的呢？是不是count(*)效率最差？我曾经以为count(*)是效率最差的，因为认知上会读取所有表中的字段，所以凡事带有字符的就觉得会读取表中所有的字段，当时网上有很多博客也这么说。但是，当我深入 count 函数的原理后，被啪啪啪的打脸了！

Redis 是一款广泛使用的高性能键 - 值存储数据库。在数据分片方面，Redis 采用了哈希槽（Hash Slot）的方式，而非一致性哈希（Consistent Hashing），这是基于多方面的考量。Redis 集群预先分配了 16384 个哈希槽。这种固定数量的哈希槽使得数据分布的管理更加容易。每个节点负责一定数量的哈希槽，例如，在一个有 N 个节点的集群中，每个节点大致负责 16384/N 个哈希槽。相比之下，一致性哈希的数据分布相对更 “自由”，可能导致在节点数量变化时数据迁移的不可预测性增加。

先来说说 MySQL 的预读机制。程序是有空间局部性的，靠近当前被访问数据的数据，在未来很大概率会被访问到。所以，MySQL 在加载数据页时，会提前把它相邻的数据页一并加载进来，目的是为了减少磁盘 IO。但是可能这些被提前加载进来的数据页，并没有被访问，相当于这个预读是白做了，这个就是预读失效。如果使用简单的 LRU 算法，就会把预读页放到 LRU 链表头部，而当 Buffer Pool空间不够的时候，还需要把末尾的页淘汰掉。

大家都知道 mysql 中数据是存储在物理磁盘上的，而真正的数据处理又是在内存中执行的。由于磁盘的读写速度非常慢，如果每次操作都对磁盘进行频繁读写的话，那么性能一定非常差。为了上述问题，InnoDB 将数据划分为若干页，以页作为磁盘与内存交互的基本单位，一般页的大小为 16KB。这样的话，一次性至少读取 1 页数据到内存中或者将 1 页数据写入磁盘。通过减少内存与磁盘的交互次数，从而提升性能。时间维度：如果一条数据正在在被使用，那么在接下来一段时间内大概率还会再被使用。

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

在 MySQL 中，虽然 MVCC 是一个非常强大的并发控制机制，但它不能完全解决幻读问题。幻读问题在不同的事务隔离级别下有不同的表现，而在可重复读隔离级别下，Next - Key 锁通过对记录和间隙的锁定，弥补了 MVCC 在防止幻读方面的不足。对于开发人员和数据库管理员来说，深入理解 MVCC 和 Next - Key 锁的工作原理，有助于在设计和管理数据库应用时，正确处理并发事务，确保数据的一致性和准确性。