本文记录是京东双11前夕一次线上系统问题，从问题这方面入手，引发的对系统稳定性因素的思考及总结。“千里之堤毁于蚁穴“，如何发现系统中”蚁穴“是我们系统开发者不断追求的目标。
夜幕降临
方法异常线上报警，定位日志，空指针异常，查询数据库结果为空，定位此业务线查询从库，数据库正常，查询结果正常，初步确定是主从延迟。问题在几秒钟恢复，影响次数个位数，接下来几个月数次出现此问题，直到双11备战第一天延迟更加严重了。
长夜慢慢
定位主从同步延迟问题了，查看从库的机器情况及慢日志。从库执行大量的删除某表记录操作，性能非常差。在看其执行语句，发现没有索引，在看下主库这张表上有这个索引。这种情况下为什么出现主从延迟高呢？在这里简单介绍下mysql主从同步原理。
mysql主从复制需要三个线程，master（binlog dump thread）、slave（I/O thread 、SQL thread）。
master
（1）binlog dump线程：当主库中有数据更新时，那么主库就会根据按照设置的binlog格式，将此次更新的事件类型写入到主库的binlog文件中，此时主库会创建log dump线程通知slave有数据更新，当I/O线程请求日志内容时，会将此时的binlog名称和当前更新的位置同时传给slave的I/O线程。
slave
（2）I/O线程：该线程会连接到master，向log dump线程请求一份指定binlog文件位置的副本，并将请求回来的binlog存到本地的relay log中，relay log和binlog日志一样也是记录了数据更新的事件，它也是按照递增后缀名的方式，产生多个relay log（ hostname-relay-bin.000001）文件，slave会使用一个index文件（ hostname-relay-bin.index）来追踪当前正在使用的relay log文件。
3）SQL线程：该线程检测到relay log有更新后，会读取并在本地做redo操作，将发生在主库的事件在本地重新执行一遍，来保证主从数据同步。此外，如果一个relay log文件中的全部事件都执行完毕，那么SQL线程会自动将该relay log 文件删除掉。
下面是整个复制过程的原理图：
结合以上的mysql主从同步原理，我们线上这次问题原因已经出来了，其实慢SQL只是我们原因的表象，更加深层次的原因是从库 SQL thread顺序执行Relay log的事件。执行任意事件性能不好的话都会给我们在来主从的高延迟。
黎明曙光
从库建立索引，降低主从延迟性，对线上业务影响无感知。
我们系统架构情况如下：
为了减少数据库主库的压力，每条业务线都有自己从库，目前我们数据库的情况是1主8从。如果说主从延迟非常高的话最明显的影响就是我们每条业务线的读延迟，依赖读的业务都会有问题。
主从延迟是影响我们系统稳定性的因素之一。如何降低主从延迟减少其对我们系统的影响？业界内减少主从延迟方案有多种下面简单介绍几种：
- 服务的基础架构在业务和mysql之间加入memcache或者Redis的cache层。降低mysql的读压力；
- 使用比主库更好的硬件设备作为slave；
- sync_binlog在slave端设置为0；
- –logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志；
- 禁用slave的binlog。
获取以上Java高级架构最新视频，欢迎
加入Java进阶架构交流群：142019080。直接点击链接加群。https://jq.qq.com/?_wv=1027&k=5lXBNZ7