网站开发企业,gta5买房子网站正在建设,百度官方优化指南,wordpress 伪静态 tag上一文中提到延时双删等策略实现数据一致性的时候#xff0c;可能存在删除缓存失败的情况#xff0c;就会出现缓存和数据库不一致的问题。为了应对删除缓存失败而导致数据不一致的问题#xff0c;可以通过回溯数据库日志文件#xff0c;提供一个保障的重试机制即可。流程如… 上一文中提到延时双删等策略实现数据一致性的时候可能存在删除缓存失败的情况就会出现缓存和数据库不一致的问题。为了应对删除缓存失败而导致数据不一致的问题可以通过回溯数据库日志文件提供一个保障的重试机制即可。流程如下图所示(1)更新数据库数据(2)数据库会将操作信息写入binlog日志当中(3)订阅程序提取出所需要的数据以及key(4)另起一段非业务代码获得该信息(5)尝试删除缓存操作发现删除失败(6)将这些信息发送至消息队列(7)重新从消息队列中获得该数据重试操作。可以借鉴阿里的方法使用中间件canalCanal是什么canal 是阿里巴巴的一个开源项目基于java实现已经在很多大型的互联网项目生产环境中使用包括阿里、美团等都有广泛的应用是一个非常成熟的数据库同步方案基础的使用只需要进行简单的配置即可。canal是通过伪装成mysql 的从库监听mysql 的binlog日志来获取数据。binlog设置为row模式以后不仅能获取到执行的每一个增删改的脚本同时还能获取到修改前和修改后的数据基于这个特性canal就能高性能的获取到mysql数据数据的变更。Canal用途数据库镜像数据库实时备份索引构建和实时维护(拆分异构索引、倒排索引等)业务 cache 缓存刷新带业务逻辑的增量数据处理在理解canal的原理前我们先来看看关于MySQL数据库主从数据库的基础知识这样就能更高效的理解Canal。数据库的读写分离为了应对高并发场景MySQL支持把一台数据库主机分为单独的一台写主库(主要负责写操作)而把读的数据库压力分配给读的从库而且读从库可以变为多台这就是读写分离的典型场景。数据库主从同步实现数据库的读写分离是通过数据库主从同步让从数据库监听主数据库Binlog实现的。大体流程如下❝MySQL master 将数据变更写入二进制日志( binary log, 可以通过 show binlog events 进行查看)MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)MySQL slave 重放 relay log 中事件将数据变更反映它自己的数据❞可以看到这种架构下会有一个问题数据库主从同步会存在延迟那么就会有短暂的时间主从数据库的数据是不一致的。这种不一致大多数情况下非常短暂很多时候我们可以忽略他。但一旦要求数据一致就会引申出如何解决这个问题的思考。数据库主从同步一致性问题我们通常使用MySQL主从复制来解决MySQL的单点故障问题其通过逻辑复制的方式把主库的变更同步到从库主从之间无法保证严格一致的模式于是MySQL的主从复制带来了主从“数据一致性”的问题。MySQL的复制分为异步复制、半同步复制、全同步复制。异步复制MySQL默认的复制即是异步复制主库在执行完客户端提交的事务后会立即将结果返给给客户端并不关心从库是否已经接收并处理这样就会有一个问题主如果crash掉了此时主上已经提交的事务可能并没有传到从库上如果此时强行将从提升为主可能导致新主上的数据不完整。❝主库将事务 Binlog 事件写入到 Binlog 文件中此时主库只会通知一下 Dump 线程发送这些新的 Binlog然后主库就会继续处理提交操作而此时不会保证这些 Binlog 传到任何一个从库节点上。❞全同步复制指当主库执行完一个事务所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回所以全同步复制的性能必然会收到严重的影响。❝当主库提交事务之后所有的从库节点必须收到、APPLY并且提交这些事务然后主库线程才能继续做后续操作。但缺点是主库完成一个事务的时间会被拉长性能降低。❞半同步复制是介于全同步复制与全异步复制之间的一种主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可主库不需要等待所有从库给主库反馈。同时这里只是一个收到的反馈而不是已经完全完成并且提交的反馈如此节省了很多时间。❝介于异步复制和全同步复制之间主库在执行完客户端提交的事务后不是立刻返回给客户端而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制半同步复制提高了数据的安全性同时它也造成了一定程度的延迟这个延迟最少是一个TCP/IP往返的时间。所以半同步复制最好在低延时的网络中使用。❞事实上半同步复制并不是严格意义上的半同步复制MySQL半同步复制架构中主库在等待备库ack时候如果超时会退化为异步后也可能导致“数据不一致”。❝当半同步复制发生超时时(由rpl_semi_sync_master_timeout参数控制单位是毫秒默认为10000即10s)会暂时关闭半同步复制转而使用异步复制。当master dump线程发送完一个事务的所有事件之后如果在rpl_semi_sync_master_timeout内收到了从库的响应则主从又重新恢复为半同步复制。❞Canal工作原理了解了数据库从库的数据同步原理理解canal便十分简单其工作原理为:canal 模拟 MySQL slave 的交互协议伪装自己为 MySQL slave 向 MySQL master 发送dump 协议MySQL master 收到 dump 请求开始推送 binary log 给 slave (即 canal )canal 解析 binary log 对象(原始为 byte 流)总结来说canal将自己伪装成mysql的从库从主库那里消费并解析binlog通过日志来保持数据的一致性。Canal实战因为篇幅有限对canal的实际使用感兴趣的同学可以在我的个人博客查看https://blog.csdn.net/big_white_py/article/details/107826180
