MySQL日志介绍
前言MySQL日志主要可以细分为错误日志、查询日志、慢查询日志、二进制日志、事务日志（重做日志和回滚日志)和中继日志等几类。本篇文章主要针对这几种日志进行分析，对每种日志的产生阶段和作用进行介绍，另外从整体上看清MySQL日志之间的关联。
错误日志错误日志包含了有关服务器运行时发生的各种错误和警告的信息。通常在MSQL的配置文件中指定。常见的配置文件包括my.cnf或my.ini,具体取决于操作系统。查看错误日志对我们解决日常问题是非常重要的。
查看错误日志文件的完整路径，通过执行以下SQL查询语句
SHOW VARIABLES LIKE ‘log_error’
Variable_name
Value
log_error
./err.log
查询日志查询日志在MySQL中被称为general log(通用日志)，查询日志里的内容不要被”查询日志”误导，它其实记录了数据库执行的所有命令，并不仅仅是查询命令。这对于性能调整和故障排除非常有用。
查询日志的位置通常在MySQL的配置文件中指定。可以通过执行以下SQL查询语句来查找查询日志文件的位置SHOW VAR ...
定时任务系统原理与实现分析
一、定时任务系统的实现方式定时任务核心接口：
接口名称
作用
tick
不同实现方式表示含义不同
addTimer
向容器中添加一个定时器，并返回定时器的指针
delTimer
根据传入的定时器指针删除容器中的一个定时器，并且销毁资源
resetTimer
重置一个定时器
getMinExpire
不同实现方式表示含义不同
各种实现方式对比：
实现方式
AddTimer
DelTimer
ToDoTimer
基于链表
O(1)
O(n)
O(n)
基于排序链表
O(n)
O(1)
O(1)
基于最小堆
O(lgn)
O(1) （后面分析）
O(1)
基于时间轮
O(1)
O(1)
O(1)(前提是使用多个轮子来实现，不过单个轮子也要比O(n)快得多)
1.1 最小堆
最小堆是一种特殊的完全二叉树，任意非叶子节点的值不大于其子节点
具体实现代表就是 JDK 中的 Timer 定时器
思考1：如何选取定时任务的键？
通常情况下，最小堆的键是定时器任务的到期时间（即任务需要执行的时间点）。这是因为最小堆的数据结构特性使得堆 ...
分布式事务
题记：之前总结过一篇关于分布式事务的文章，今天闲来无事再整理一下，发布出来，也是加深一下自己的记忆吧。感觉对分布式事务的理解和使用还是不太到位，等之后有空看下《RocketMQ技术内幕》书籍吧
基于RocketMQ分布式事务前言正式讲述之前，先来理解几个概念吧
半消息（HALF MESSAGE）：这是一个Rocket里的概念，指暂时不能被consumer消费。Producer已经把消息发送到Broker端，但是消息的状态被标记为不可投递，处于这种状态下的消息被称为半消息。事实上，该状态下的消息被投放在一个特殊主题下（RMQ_SYS_TRANS_HALF_TOPIC）。当Producer端对它进行二次确认后，Consumer端才可以消费到；如果Producer端对它进行rollback,那么消息被删除，永远不会被消费到。
看到半消息的概念感觉有一些似曾相识，其实Kafka里也有类似的概念，Kafka也是采用Leader-Follower的主从复制机制，但是客户端只能消费已经被写入到所有消息Follower副本的消息即HW水平范围。通过图也许更容易理解，示意图如下：
引申一下，可能大 ...
MySQL存储架构
之前看<<从根儿上理解MySQL>>，对MySQL的数据存储架构有了一定的理解。但是时间久了还是容易生疏，目前趁机进行梳理，更加细节的对MySQL的存储结构进行总结，进而来巩固自己的知识点
MySQL的逻辑存储结构
大家都知道InnoDB进行数据管理的最小单位是页，MySQL进行读写都是通过页为基本的单位。那么这些页是如何被管理起来的呢？下面咱们就一起来看一下吧
MySQL各个版本的架构图是不一样的，下面这张图是MySQL 8.0的存储架构图，示意图1-1如下：
InnoDB的数据页被逻辑存放在一个空间内，称为表空间（tablespace）。该表空间由段（segment）、区（extent）、页（page）组成。
在存储层面，MySQL表就是.frm和.ibd文件组成。在物理层面，MySQL表就是一个二进制文件。在二进制文件的基础上，分析其内部逻辑组织结构，示意图1-2如下：
InnoDB存储引擎的逻辑存储结构，示意图1-3如下：
表空间表空间是一个物理容器，表空间存储的对象是段，在一个表空间中可以看成是一个或多个段。MySQL数据库有多个表空间，如 ...
两阶段提交协议
背景：最近在看高性能MySQL，其中第7章节有简单讲到分布式（XA）事务，但是讲解的不够具体。另外自己之前对分布式事务的两阶段式提交原理理解不够深刻，借此机会来进行梳理一下。
1原文：存储引擎的事务特性能够保证在存储引擎级别实现ACID，而分布式事务则让存储引擎级别的ACID可以扩展到数据库层面，甚至可以扩展到多个数据库之间——这需要通过两阶段提交实现。
何为分布式（XA）事务首先分布式事务时针对分布式系统来讲的，在分布式系统中，事务的访问涉及的资源、参与计算的节点都部署在不同的节点上，这种情况下涉及到的事务称为分布式事务。
分布式事务的实现方式因为分布式数据库数据库集群分布在不同的部署节点，如果需要进行事务保证，就需要协同不同的节点，通过多重机制保障节点之间数据的一致性等，相交于单数据库事务，多数据事务的问题变得更加复杂。目前，比较经典的实现分布式事务的机制是二阶段提交（2PC：two phase commit）和三阶段式提交（three phase commit）。因为实现成本和效率问题，二阶段提交在实际应用系统使用更加广泛。接下来要讲的也是二阶段提交。
两阶段提交协议顾名思义 ...
Golang 大杀器性能剖析 PProf
原因：组内大部分同学接触Go时间不长，对Go的一些生态工具不是特别了解，比如PProf，通过技术分享共同学习
目标：对PProf的原理和使用有基本了解，提供一种分析线上问题的新思路，在以后的工作中能够已备不时之需
PProf简介PProf 是用于可视化和分析性能分析数据的工具，PProf 以 profile.proto 读取分析样本的集合，并生成报告以可视化并帮助分析数据。
PProf的实现位置：
runtime/pprof：采集器，负责采集应用程序的运行数据供给 pprof 可视化工具
net/http/pprof：通过一个 HTTP Server 将 prof 数据进行可视化分析，实际上其底层也是调用的 runtime/pprof 提供的函数，封装成接口对外提供网络访问。
PProf提供的类型：
CPU profiling（CPU 性能分析）：这是最常使用的一种类型。用于分析函数或方法的执行耗时
Heap profiling：这种类型也常使用。用于分析程序的内存占用情况
Block profiling：这是 Go 独有的，用于记录 ...
MySQL缓冲池的管理机制
初识内存管理因为Mysql的数据存储在磁盘，磁盘的读写速率远低于内存，但是我们执行一条SQL语句，其执行速率一般非常快，远高于磁盘的读写速率。这就不得不提今天要讲的主角-缓冲池（Buffer Pool), 简单来讲缓冲池就是内存的一块区域，主要用来高速缓冲数据和索引，正是因为缓冲池的引入，避免了磁盘的检索，才提高了SQL语句的执行速率。
何为Buffer PoolMySQL执行的SQL语句需要对数据进行增删改查，其都是在内存中进行的，即在Buffer Pool中。
MySQL在启动之初，会对缓冲区进行初始化，这时期的缓冲区都是空闲页，也就是未使用的内存。随着MySQL Server不断地运行，会将磁盘中的数据页逐渐的加载到内存，磁盘中磁盘页和缓冲池中的数据页的大小都是16KB。因此，一次磁盘IO，会将读取的数据放入到内存的数据页中进行存储，其过程如下：
当磁盘的数据被加载到内存后，对读写数据的影响：
当读取数据时，如果数据存在于 Buffer Pool 中，客户端就会直接读取 Buffer Pool 中的数据，否则就会将磁盘页中的数据加载到缓冲区，然后再从缓冲区进行读取。
写数据 ...
About Me
😂 很荣幸您能通过搜索引擎，在众多搜索中检测到本文，Nice to meet you。
本博客在滴滴工作期间搭建好，主要原因是为了用Markdown记录自己的技术积累，或许在以后求职的时候有些许的帮助。当然，搭建这个博客的初衷是想将学到的知识分享出来，但是一直以来并没有一个强大的驱动力去督促我来做这件事情。工作了接近4年后，日渐觉得需要有一些技术的沉淀，需要将学到的东西总结并分享出来。而且作为一位程序猿，日常读别人的博客时，看到一些很优秀的博客经常会很羡慕。感叹只能望其项背之时，内心也有着见贤思齐的冲动，想着自己也要分享一些东西出来，算是对自己程序员生涯的一种记录。
上学期间在CSDN写了一些博客，回头看文章质量都很低劣，大部分是工具使用和语言学习的文章，而且现在CSDN上面的内容良莠不齐，用户的信任度在逐渐下降，已经不想在上面更新内容了。现在倒是感觉segmentfault是很好的分享平台，上面的内容质量相对比较高，内容排版也比CSDN更好，虽然SF现在因为运营问题，其流量亦不如掘金，但是分享不用刻意追热度，并且个人本身是沧海一粟，大部分写作内容也是大浪淘沙，仅作为一种 ...