1. 什么是 binlog
binlog 是 mysql 的一种二进制日志文件,用来记录数据的变化.mysql 使用 binlog 进行主从复制,如图:
客户端向 master 的 mysql sever 写入数据
当数据发生变化时,master 将变更的数据记录写入到二进制文件中,即 binlog.
slave 订阅了 master 的 binlog,所以会通过一个 I/O THREAD 与 master 的 DUMP THREAD 进行通信,同步 binlog
I/O THREAD 读取到 binlog 后会吸入到 relay log 中,准备重放.
slave 会通过 SQL THREAD 读取 relay log,重放数据的改动并执行相应的改动.
这里有几点需要注意:
主从复制不是强一致性,只能保证最终一致
master 配合 binlog 复制会影响性能,所以尽量不要在 master 上挂太多的 slave,如果对时间要求不高,可以在 slave 上挂 slave
2.binlog 的业务应用
上面介绍了 mysql 中应用 binlog 的场景,而我们的业务可以伪装成 master 的 slave 节点,感知数据的变化,这就给了我们很多的业务运用空间.
2.1 数据异构
经常有这样一个场景:
原来业务是一个很单一的系统,所以表也在一起.随着业务的发展,系统开始拆分,总有一些表是各个业务都关注的表,但是对相关的字段的运用场景不同,所以这样一份元数据怎样更好的为各个系统服务就成了问题.当然,多写或者读写分离可以从物理节点上减少对数据服务器的压力,但是对业务并没有做到足够的支持,因为这些表都是一样的.因此我们可以通过 binlog 进行数据异构.
如图所示,订单系统生成订单后,通过 binlog 可以解析生成用户维度的订单信息供用户中心查询,商户维度订单表供运营管理,以及搜索系统的搜索数据,提供全文搜索功能.
这样,我们就通过原始的订单数据异构到三个系统中,提供了丰富的数据访问功能.不仅从节点上降低了数据服务器的压力,数据表现形式也更贴近自己的服务,减少不必要的字段冗余.
2.2 缓存数据的补充
对于高并发的系统,数据库往往是系统性能的瓶颈,毕竟 IO 响应速度是远远小于电子的运算速度的.因此,很多查询类服务都会在 CPU 与数据库之间加上一层缓存.即现从缓存获取,命中后直接返回,否则从 DB 中获取并存入缓存后返回.而如果原始数据变化了但缓存尚未超时,则缓存中的数据就是过时的数据了.当数据有变更的时候主动修改缓存数据.
当客户端更改了数据之后,中间件系统通过 binlog 获得数据变更,并同步到缓存中.这样就保证了缓存中数据有效性,减少了对数据库的调用,从而提高整体性能.
2.3 基于数据的任务分发
有这样一个场景:
很多系统依赖同一块重要数据,当这些数据发生变化的时候,需要调用其他相关系统的通知接口同步数据变化,或者 mq 消息告知变化并等待其主动同步.这两种情况都对原始系统造成了侵入,原始系统改一块数据,并不想做这么多其他的事情.所以这时候可以通过 binlog 进行任务分发.
当原始业务系统修改数据后,不需要进行其他的业务关联.由调度系统读取 binlog 进行相应的任务分发,消息发送以及同步其他业务状态.这样可以将其他业务与原始业务系统解耦,并从数据的角度将所有管理功能放在了同一个调度系统中,责任清晰.
3. 总结
binlog 是 mysql 提供的数据同步机制,很好的解决了主从分离,读写库分离等业务.而我们可以构建一个中间件系统,"伪造" 成 master 的一个 slave.当读取了 binlog 中的数据变化后,根据相应的业务场景做各种业务处理.而目前我接触到的最常见的就是第一个场景--数据异构,可以异构到其他表中,也可以异构到其他数据引擎中,比如 Elastic Search.
来源: https://www.cnblogs.com/kingszelda/p/8362612.html