【面试】主从延迟导致的线上事故-＞排查-＞解决方案-＞吐槽

主从延迟问题背景

数据库主库写操作太频繁,从库监听binlog的线程同步不及时,就会导致主从有延迟,这个大家都知道.这里分享一个因为拆中台导致的主从延迟问题,十分坑爹.
这里介绍下背景, 之前因为组里各个业务都有自己的单据表,而单据表的核心内容大同小异,于是架构师们就想着吧单据抽出来作为一个单独的服务,叫单据中心,负责单据的存储,状态流转,流程驱动等.问题就出在这个服务上.

线上事故描述

创建A单据的时候,会写B单据(A的父单据)的一个已完成数量  
之后我们会读B单据(A的父单据)的已完成数量和总数量,
比较两个数是否相等,来将B单据流转到不同的状态  
也就是说 更新完B单据后,立即读取了B单据(因为主从延迟读到的还是旧单据)
因为主从延迟,导致主库更新了B单据的已完成数量 
但读到到的从库的已完成数量还是0 
不相等所以把状态流转到了错误的节点

典型的因为主从延时导致的问题,关键是偶发,排查起来真的很痛苦

排查

1.找到出问题的单据
2.根据单据号找到相关读和写请求的trace
3.根据trace找到关键调用单据中心服务RPC的请求和响应,比对参数
4.日志打的太粗糙,关键参数没有,反馈给下游单据中心,让他们排查
5.发现是写的参数和读的参数不一致
6.发现是主从延迟导致的

解决方案

1.看能否优化代码,避免这种写完立马读的场景
2.如果不能避免,可以强制走主库(提前让DBA同学评估下主库压力是否允许强制走,DBA没时间可以在线下测下有没有性能问题)
3.如果评估了不能强制走主库,可以使用乐观锁.表加一个version字段,写之后返回最新(主库)version,
读出来记录的version如果和该version不一致,抛出异常,让用户重试.

这里大家注意下,除了写完立即读,高并发写的场景会导致主从延迟过高以外,还有大事务也会导致主从延迟过高.因为大事务产生的binlog文件会很大,binlog的网络传输,从库重放binlog里SQL,以及里面SQL涉及到一些锁资源的冲突,都会很消耗时间,所以大事务很容易导致主从延迟.

吐槽

所有单据拆出来收敛成单据中心是否合理呢?

优点
1.能避免一些创建删除单据的重复代码
2.单据都维护在一起,做一些跨单据维度的报表方便
3.对账方便

缺点
1.沟通成本,协作成本提高
	比如如果单据在我自己的服务里我要加乐观锁直接就加了,现在单据在单据中心
	加乐观锁还得看维护的同学排期
2.耦合单据
	不同的单据有不同的特性,耦合在一起如果在公共的单据结构里面加字段,还需要考虑对其他单据的影响,加字段很不方便,虽然可以用类似ext这样的扩展字段来做存储,但扩展字段中存储的信息是无法做筛选条件的