高可用之路·观测篇-指标失明
紧接上篇<<高可用之路-闲聊监控指标的局限。上篇说到,指标只是事实的投影,由于代价的存在它无法无限的逼近真实。因此,指标自身的局限有时不仅无法帮助我们发现问题,反而可能迷惑甚至误导我们。本文将详细讨论指标局限最常见的一种表现——指标失明,即问题已经发生,指标却无法有效反映。
6 min read
分布式系统 / Linux 内核 / 线上排障
博客就是将自己的内心赋予形态!出现吧,苍天环绕的小世界!
紧接上篇<<高可用之路-闲聊监控指标的局限。上篇说到,指标只是事实的投影,由于代价的存在它无法无限的逼近真实。因此,指标自身的局限有时不仅无法帮助我们发现问题,反而可能迷惑甚至误导我们。本文将详细讨论指标局限最常见的一种表现——指标失明,即问题已经发生,指标却无法有效反映。
6 min read
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核),当然由于listen的backlog参数和半连接hash表以及全连接...
5 min read
日常问题排查系列都是一些简单Bug的排查。在分享的同时也积累素材,方便我的AI分身蒸馏^_^。 在容灾演练的时候,为了验证当前单元能够承载所有的线上流量,我们会将另一个互备单元的所有流量调拨过来过一个高峰期来验证。在收集验证数据的过程中,我们的虾反馈: A应用一共20台机器,有3台CPU明显偏高达到...
4 min read
笔者最近解决了一个非常曲折的问题,从抓包开始一路排查到不同内核版本间的细微差异,最后才完美解释了所有的现象。在这里将整个过程写成博文记录下来,希望能够对读者有所帮助。(篇幅可能会有点长,耐心看完,绝对物有所值) 先来介绍一下出问题的环境吧,调用拓扑如下图所示: 合作方的多台机器用NAT将多个源ip映...
13 min read
在我和GPT探讨了很多天的人生之后,他终于说动了我,让我开启迟迟不想动笔的高可用系列。感谢GPT们让我从大量繁琐技术文档中解放出来,让我有时间进行真正的思考。写博客对我来说最大的收益是强制自己思考,如果连博客本身都被GPT代劳,那还不如不写。所以本文文字AI含量基本为0,纯手敲,顶多听取了一些AI在...
7 min read
研发突然反馈一个版本上线后线上系统younggc时间变长,而这个版本修改的代码就是非常普通的CRUD,但是younggc时间就硬生生暴涨了100%。导致天天告警,虽然问题不大,但非常想知道原因,于是向我求助。 如下图所示,younggc一个版本后从60ms涨到了120ms。而告警的阈值在100ms,...
4 min read
最近买了台mac mini用来写博客,但迟迟没有动笔。虽然积累了非常多的素材,但写一篇《解Bug之路》系列的博客实在是太累人了。同时也很久没有那种让我感到兴奋的问题了。但总归不能让这台新买的mac mini成为摆设,于是就写一些平时遇到的小问题吧。 问题是喜闻乐见的调用超时。这个问题的显著特征是:
5 min read
日常 Bug 排查系列都是一些简单 Bug 的排查。笔者将在这里介绍一些排查 Bug 的简单技巧,同时顺便积累素材。 国际化的兄弟团队向笔者反映了一个问题。我们在访问一个非洲的服务商提供服务的时候,根据DNS解析却是一个美国的IP。但通过登陆非洲节点的机器来看,还确实找到了相应的请求日志,如下图所示...
2 min read
日常问题排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材。 先描述这个问题出现的业务场景。这是一个支付的场景,如果支付成功了,我们就把支付状态置为success(主单据更新)同时写入支付成功时间戳为t1(子单据更新)。支付成功之后,我们还需要做其它的动作,...
2 min read
日常问题排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材。 又是喜闻乐见的读数据不一致的问题。这次的问题是这样,业务在一个事务中更新A和B两个表的两个数据。但是在另一个事务中只看到了A的更新,而B依旧是更新之前的值。说好的原子性感觉又被打破了。如下图所示:
1 min read
日常问题排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材。 线上连续两天出现NP异常,而且都是凌晨低峰期才出现,在凌晨的流量远没有白天高峰期大。而出问题的接口又是通常的业务请求。于是,很自然的,我们就想凌晨有什么特殊的运维动作,翻了下时间线。发现,每天凌晨...
3 min read
日常问题排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材。 最近碰到一个问题,一台机器上的连接数在达到一定连接数(大概4.5W)连接数之后会突然急速下降到几百。在应用上的表现就是大量的连接报错,系统失去响应,如下图所示:
3 min read
日常问题排查系列都是一些简单问题排查。笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材^_^ 最近碰到一个产线问题,表现为某个应用集群所有的节点全部下线了。导致上游调用全部报错。而且从时间线分析来看。这个应用的节点是逐步失去响应的。因为请求量较小,直到最后一台也失去响应后,才发现这个集群有...
5 min read
监控指标诚然是发现问题于微末之时的极佳手段,但指标往往有其表达的极限。在很多情况下,单独看一个黄金指标并不能表征系统的健康程度,反而有可能被其迷惑,进而忽略相关问题。(本文所提及的Linux Kernel源码版本为4.18.10) 某天中午,某应用的999线突然升高。由于是个QPS高达几十万的查询服...
9 min read
日常问题排查系列都是一些简单问题排查,笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材^_^。 同事反馈应用出现了一个诡异的问题。mq在应用启动10分钟之后就开始堆积。反复重启了几次都是如此。 这种问题的分析思路还是比较直接的,直接jstack一下看看mq消费线程在干嘛。
3 min read
日常问题排查系列都是一些简单问题排查。问题虽小,但经常遇到,了解这些问题,会让我们少走点弯路,提升效率。说不定有些问题你遇到过哦:) 业务开发同学突然问了笔者一个问题,从库读会不会没有原子性?我下意识的反应怎么可能,只要是遵守MySQL主从Replication协议的原子性至少是能够保证的。但他们遇...
2 min read
Seconds_behind_master是我们观察主从延迟的一个重要指标。但任何指标所能表示的精度都是有限的。例如用精度只能到秒的指标去衡量毫秒级的表现就会产生非常大的误差。如果再以此误差去分析问题,就会让思维走上弯路。例如用Seconds_behind_master去评估1s内的主从延迟就是一个...
4 min read
监控指标是我们日常分析排查问题的利器。但指标所能表示的精度也是有限的,用这些指标去衡量超出其表示范围的数据往往就会造成一些"误判"。而用Seconds_behind_master去评估1s内的主从延迟就是一个经典的例子。 笔者最近发现了一个很奇怪的现象。不同的从库表现出来的主从延迟(Seconds_...
4 min read
最近笔者阅读资料的时候,发现竟然会有这种坑。如下图所示: 这个坑触发需要以下几个条件: 在这种情况下,Server竟然会认为没有收到的第一个packet是确认了的,导致客户端认为第一个"dog"收到了,实际Server应用端完全没有感知! 如果第一个包3bytes的时候,在上面的情况下,由于chec...
1 min read
ZooKeeper作为dubbo的注册中心,可谓是重中之重,线上ZK的任何风吹草动都会牵动心弦。最近笔者就碰到线上ZK Leader宕机后,选主无法成功导致ZK集群拒绝服务的现象,于是把这个case写出来分享给大家(基于ZooKeeper 3.4.5)。 一天早上,突然接到电话,说是ZooKeepe...
7 min read
Linux作为一个强大的操作系统,提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中,笔者积累了一些在内网环境应该进行调优的参数。在此分享出来,希望对大家有所帮助。 好了,在这里先列出调优清单。请记住,这里只是笔者在内网进行TCP内核参数调优的经验,仅供...
6 min read
我们的服务器时间校准一般是通过ntp进程去校准的。但由于校准这个动作,会导致时钟跳跃变化的现象。 而这种情况里面,往往回拨最能引起我们的困扰,回拨如下所示: 假设有一个任务每天0点时候获取昨天所有的数据进行对账,正常情况和时钟回拨的情况如下图所示: 针对这种情况,笔者让业务调整了调度触发时间,不要精...
1 min read
日常问题排查系列都是一些简单问题排查,笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材^_^。 开发反应线上系统出现失去响应的现象,收到业务告警已经频繁MarkAndSweep(Full GC)告警。于是找到笔者进行排查。 首先呢,当然是看我们的监控了,找到对应失去响应的系统的ip,看下我...
3 min read
磁盘故障是个非常常见的现象。而磁盘坏道便是其中最常见的问题。而当我们的应用做磁盘操作的时候 正巧落在坏道上面,就会导致卡住的现象。如果坏道比较小的话,会在一段时间内恢复响应。但是,如果下次操作又落到坏道上面,依旧会卡主-_-! 开发陆续收到服务器负载过高以及业务报错告警。表现为偶尔的调用超时。经排查...
1 min read
在前面的文章中,笔者详细的阐述了Prometheus的数据插入存储查询等过程。但作为一个监控神器,报警计算功能是必不可少的。自然的Prometheus也提供了灵活强大的报警规则可以让我们自由去发挥。在本篇文章里,笔者就带读者去看下Prometheus内部是怎么处理报警规则的。
3 min read
数据库主从切换是个非常有意思的话题。能够稳定的处理主从切换是保证业务连续性的必要条件。今天笔者就来讲讲主从切换过程中一个小小的问题。 最近线上进行主从切换,大部分应用都切过去了,但是某些应用的连接确还在老的主(新的从)上面。 这让对应应用的开发百思不得其解,于是求助了笔者一探究竟。
5 min read
产线一些应用其JVM只占了8G中的2个G的空间。Page cache也只占了1个G,但是free -g出来内存确已经耗尽: 这个看上去很吓人。遇到这种情况,我们先cat /proc/meminfo看下具体的内存占用情况 我们可以看到有将近3.6G被耗尽在Slab这一项里面,紧接着下面一项SRecla...
1 min read笔者最近担起了公司监控的重任,而当前监控最流行的数据库即是Prometheus。按照笔者打破砂锅问到底的精神,自然要把这个开源组件源码搞明白才行。在经过一系列源码/资料的阅读以及各种Debug之后,对其内部机制有了一定的认识。今天,笔者就来介绍下Prometheus的存储结构。
4 min read
在之前的文章里,笔者详细的阐述了数据的存储/写入以及查询过程。那么Prometheus又是怎么去主动获得数据的呢?这个问题,笔者将在本篇文章详细阐述。 Prometheus是通过pull从各个Target(目标)Exporter中去获取数据。 作为一个成熟的监控系统,自然可以这对这些Target进行...
4 min read
在之前的博客里,笔者详细阐述了Prometheus数据的插入过程。但我们最常见的打交道的是数据的查询。Prometheus提供了强大的Promql来满足我们千变万化的查询需求。在这篇文章里面,笔者就以一个简单的Promql为例,讲述下Prometheus查询的过程。
4 min read
在之前的文章里,笔者详细的阐述了Prometheus时序数据库在内存和磁盘中的存储结构。有了前面的铺垫,笔者就可以在本篇文章阐述下数据的插入过程。 在这里,笔者并不会去讨论Promtheus向各个Endpoint抓取数据的过程。而是仅仅围绕着数据是如何插入Prometheus的过程做下阐述。对应方法...
2 min read
之前的文章里,笔者详细描述了监控数据在Prometheus内存中的结构。而其在磁盘中的存储结构,也是非常有意思的,关于这部分内容,将在本篇文章进行阐述。 首先我们来看Prometheus运行后,所形成的文件目录结构 在笔者自己的机器上的具体结构如下: 一个Block就是一个独立的小型数据库,其保存了...
4 min read
笔者最近完成了一个非常有意思的隧道机制(已在产线运行),可以让注册到不同zookeeper之间的dubbo集群之间能够正常进行通信。如下图所示: 例如图中A/B两个网络隔离的集群,两者只能通过专线进行通信。但是对于在里面的应用来说,调用另外一个集群的dubbo服务(例如app1调用app3)依旧和原...
5 min read
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。 今天笔者就从Linux源码的角度看下Server端的Socket在进行Accept的时候到底做了哪些事情(基于Linux 3.10内核)。 众所周知,一个Server端Socket的建立,需要socket、b...
5 min read
笔者一直以为在Linux下TIME_WAIT状态的Socket持续状态是60s左右。线上实际却存在TIME_WAIT超过100s的Socket。由于这牵涉到最近出现的一个复杂Bug的分析。所以,笔者就去Linux源码里面,一探究竟。 TIME_WAIT这个参数通常和五元组重用扯上关系。在这里,笔者先...
6 min read
笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后的工作中能够少踩点坑。 TCP是流的概念,解释如下 出Bug的系统是做与外部系统进行对接之用。这两者并不通过http协议进行交互,而是在通过...
7 min read
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行bind的时候到底做了哪些事情(基于Linux 3.10内核)。 众所周知,一个Server端Socket的建立,需要socket、bi...
6 min read
最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章。 这是一个偶发的性能问题。在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过1s,让我们业务耗时监控的99.99线变得很尴尬。如下图所示: 为了精益求精,更为了消除这个尴尬的指标,笔者开始探...
5 min read
DPVS是一款爱奇艺开源的基于DPDK的优秀软件(https://github.com/iqiyi/dpvs)。利用DPDK工作在用户空间的特性,相比于内核空间的LVS,我们可以使用用户空间的一系列工具/中间件等完成很多在内核空间很难完成的功能。 虽然笔者日常工作中是搞Java中间件开发的,但一直都...
4 min read
事实证明,读过Linux内核源码确实有很大的好处,尤其在处理问题的时刻。当你看到报错的那一瞬间,就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。笔者读过一些Linux TCP协议栈的源码,就在解决下面这个问题的时候有一种非常流畅的感觉。
6 min read
我们的分库分表中间件在线上运行了两年多,到目前为止还算稳定。在笔者将精力放在处理各种灾难性事件(例如中间件物理机宕机/数据库宕机/网络隔离等突发事件)时。竟然发现还有一些奇怪的corner case。现在就将排查思路写成文章分享出来。 应用通过中间件连后端多个数据库,sql会根据路由规则路由到指定的...
5 min read
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。上篇博客讲了socket的阻塞和非阻塞,这篇就开始谈一谈socket的close(以tcp为例,且基于linux-2.6.24内核版本) 众所周知,TCP的close过程是四次挥手,状态机的变迁也逃不出TCP状...
7 min read
和外部联调一直是令人困扰的问题,尤其是一些基础环境配置导致的问题。笔者在一次偶然情况下解决了一个调用外网服务概率性失败的问题。在此将排查过程发出来,希望读者遇到此问题的时候,能够知道如何入手。 笔者的新系统上线,需要PE执行操作。但是负责操作的PE确和另一个开发在互相纠缠,让笔者等了半个小时之久。本...
6 min read
当今互联网中的大千世界都驻足于TCP/IP协议之上。而通过Socket操作TCP/IP协议已经成为了事实上的标准,Socket甚至已经成为了网络编程的同义词。当然了,由于我们早已习惯于各种封装/框架,很少裸用Socket,所以对它的理解始终有一种模糊的感觉。 今天,我就来介绍一下Socket。
2 min read
高可用真是一丝细节都不得马虎。平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug。偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题,特别是偶发性出现的问题更难排查。今天,笔者就给大家带来一个存储偶发性故障的排查过程。 我们的积分应用由于量非常大,所以需要进行分库分表,所以...
4 min read
在阅读了大量关于数据库的资料后,笔者情不自禁产生了一个造数据库轮子的想法。来验证一下自己对于数据库底层原理的掌握是否牢靠。在笔者的github中给这个database起名为Freedom。 既然造轮子,那当然得从前端的网络协议交互到后端的文件存储全部给撸一遍。下面是Freedom实现的整体结构,里面...
6 min read
dubbo是一个成熟且被广泛运用的框架。饶是如此,在某些极端条件下基于dubbo的应用还会出现无法重连zookeeper的问题。由于此问题容易导致比较大的故障,所以笔者费了一番功夫去定位,现将排查过程写成博文分享出来。 这是一起在测试环境出现的故障。起因是网工做交换机切换演练,可能由于姿势不对,使得...
6 min read
新冠疫情让笔者不禁回忆起10多年前甲流流行的那段过往。也就是那时,在封闭的大学宿舍里,笔者开启了自己的编程之旅。 初涉编程时那个C语言展示hello world的黑框并没有激起笔者的任何兴趣。为什么寥寥几句就可在屏幕上展示输出成为萦绕笔者心头的一个疑问。在全校封闭、无法组团dota、百无聊赖的境遇下...
5 min read网络编程中超时时间是一个重要但又容易被忽略的问题,对其的设置需要仔细斟酌。在经历了数次物理机宕机之后,笔者详细的考察了在网络编程(tcp)中的各种超时设置,于是就有了本篇博文。本文大部分讨论的是socket设置为block的情况,即setNonblock(false),仅在最后提及了nonblock...
8 min read
在linux的高性能网络编程中,绕不开的就是epoll。和select、poll等系统调用相比,epoll在需要监视大量文件描述符并且其中只有少数活跃的时候,表现出无可比拟的优势。epoll能让内核记住所关注的描述符,并在对应的描述符事件就绪的时候,在epoll的就绪链表中添加这些就绪元素,并唤醒对...
8 min read
笔者最近解决了一个困扰了业务系统很久的问题。这个问题只在发布的出现,每次只影响一两次调用,相较于其它的问题来说,这个问题有点不够受重视。由于种种原因,使得这个问题到了业务必须解决的程度,于是就到了笔者的手上。 我们采用的是dubbo服务,这是个稳定成熟的RPC框架。但是我们在某些应用中会发现,只要这...
9 min read
MySQL是当今最流行的开源数据库,阅读其源码是一件大有裨益的事情(虽然其代码感觉比较凌乱)。而笔者阅读一个Server源码的习惯就是先从其网络IO模型看起。于是,便有了本篇博客。 看源码,首先就需要找到其入口点,mysqld的入口点为mysqld_main,跳过了各种配置文件的加载
3 min read
分库分表中间件在我们一年多的锤炼下,基本解决了可用性和高性能的问题(只能说基本,肯定还有隐藏的坑要填),问题自然而然的就聚焦于高可用。本文就阐述了我们在这方面做出的一些工作。 作为一个无状态的中间件,高可用问题并没有那么困难。但是尽量减少不可用期间的流量损失,还是需要一定的工作的。这些流量损失主要分...
7 min read
笔者在阅读了一大堆源码后,就会情不自禁产生造轮子的想法。于是花了数个周末的时间用C语言撸了一个DBProxy(MySQL协议)。在笔者的github中给这个DBProxy起名为Hero。 笔者一直有C情节,求学时候一直玩C。工作之后,一直使用Java,就把C渐渐放下了。在笔者最近一年阅读了一堆关于l...
7 min read
最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章。 我们的分库分表中间件在经过一年的沉淀之后,已经到了比较稳定的阶段。而且经过线上压测的检验,单台每秒能够执行1.7W条sql。但线上情况还是有出乎我们意料...
7 min read
机器一般过质保之后,就会因为各种各样的问题而宕机。而这一次的宕机,让笔者观察到了平常观察不到的tcp在对端宕机情况下的行为。经过详细跟踪分析原因之后,发现可以通过调整内核tcp参数来减少宕机造成的影响。 笔者所在的公司用某个中间件的古老版本做消息转发,此中间件在线上运行有些年头了,大约刚开始部署的时...
7 min read
作为一个数据库爱好者,自己动手写过简单的SQL解析器以及存储引擎,但感觉还是不够过瘾。<<事务处理-概念与技术诚然讲的非常透彻,但只能提纲挈领,不能让你玩转某个真正的数据库。感谢cmake,能够让我在mac上用xcode去debug MySQL,从而能去领略它的各种实现细节。
5 min read
JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存,同时对物理内存的使用做了定量的分析,从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客,以飨读者。 由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识,读者如果有兴趣了解请看...
6 min read
此篇博客主要是讲述MySql(仅限innodb)的两阶段加锁(2PL)协议,而非两阶段提交(2PC)协议,区别如下: MySql本身针对性能,还有一个MVCC(多版本控制)控制,本文不考虑此种技术,仅仅考虑MySql本身的加锁协议。 在对记录更新操作或者(select for update、lock...
3 min read
笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后的工作中能够少踩点坑。 此Bug是Druid低版本的Bug,此Bug至少在1.0.12版本就已经修复。
4 min read
笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后的工作中能够少踩点坑。 由于某个系统大量的hget、hset操作将Redis拖垮,通过监控发现Redis的CPU和IO有大量的尖刺,CPU示...
4 min read
TCP是流的概念,解释如下 由于TCP流的特性,经常发生一个收到多于(长连接)或者小于当前包字节数的情况,看起来像一个包后面"粘着"后面包的一点内容,所以被应用层的人形象的称为"粘包",这个概念不是笔者发明的,老早就这么叫了。 TCP流本身就是操作系统在屏蔽了mac帧、ip包这些底层概念与细节后抽象...
7 min read
笔者觉得Cobar之类的分库分表最神奇的部分就是靠一条sql查询不同schema下(甚至不同实例下)的不同的表。例如 以笔者这种刨根到底的性格当然要把这个过程DIY出来。 由于Cobar对MySql的连接是BIO的。而笔者喜欢NIO,于是用NIO将Corbar的多节点查询全部重写(基于Netty)。...
2 min read
本篇Blog在总体层面介绍了SQL查询引擎Rider的功能及设计,其细节部分将会在后面的篇章中一一道来。 笔者在实际工作中经常需要解析文件,每次文件稍有变化,都得拷贝粘贴一堆代码。 于是就想着能不能做一个通用的服务,通过配置的方式解析文件。 最通用的方法就是自己定义一个文件描述语言,用语言去描述文件...
2 min read
在开发过程中,由于频繁的修改数据库的字段,导致rd和qa环境的数据库表经常不一致。 而由于这些修改数据库的操作可能由多个rd操作,很难一次性收集全。人手工去和QA环境对字段又特别繁琐,容易遗漏。 于是笔者就写了一个能够自动比较两个数据库的表结构,并生成alter语句的程序。同时还可以进行配置从而自动...
1 min read
MyBatis能够通过获取MySql中的information_schema从而获取表的字段等信息,最后通过这些信息生成代码。 笔者受此启发,将MyBatis-Generator中的核心结构体剥离出来,写成了能自动生成简单CRUD的工具。 mysql本身存在一个information_schema,...
1 min read
紧接上篇流程篇,本篇主要将binlog的event报文。 event报文主要分三层。 (1)MySql报文都有的length-body防粘包结构。 (2)Event Header (2)Event Body 总体结构如下图所示: Event Header结构如下图所示:
1 min read
MySql-Binlog在MySql主从不同方面发挥着不可或缺的作用,同时我们也能通过Binlog实时监控数据的变化。本系列就讲述了怎样接收并解析Binlog。本篇就主要对接收binlog的流程做了一下探讨。 流程如下图所示: (1)第一步和上篇blog一样,通过HandShake协议进行Clien...
1 min read
MySql事务协议主要是通过set autocommit、commit以及rollback这三个报文(命令)来实现的。 autocommit,顾名思义,是否自动提交(事务)。如果设置为1,表明自动提交,设置为0,则是非自动提交,这样就隐式的开启了事务。 值得注意的是,一但运行了set autocom...
1 min read
一般对DB的CRUD操作都由com_query报文封装并发送给DB。com_query报文如下图所示: PacketLength:3byte表示body长度,防"粘包"。 sequenceId:1byte防串包。 body部分:是一个以0x00结尾的字符串,这个字符串就是想要执行的SQL,实际操作中...
2 min read
各位有没有对Cobar、MyCat这些MySqlProxy感到新奇。反正笔者在遇到这些proxy时,感受到其对代码的无侵入兴感到大为惊奇。于是走上了研究MySql协议的不归路。现在我就在博客里面将其中所得分享出来,以飨大家。 下图是笔者整理的HandShake协议交互流程
3 min read