数据库同步原理及常见问题解决方案-运维实记

mysql问题

mysql 主从同步原理

同步过程：
1.在备库B上通过change master命令，设置主库A的IP、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量
2.在备库B上执行start slave命令，这时备库会启动两个线程，就是图中的io_thread和sql_thread。其中io_thread负责与主库建立连接
3.主库A校验完用户名、密码后，开始按照备库B传过来的位置，从本地读取binlog，发给B
4.备库B拿到binlog后，写到本地文件，称为中转日志
5.sql_thread读取中转日志，解析出日志里的命令，并执行
日志：
undo_log:回滚日志
redo_log:重做日志
binlog: 二进制日志
relay_log:中继日志

日志作用参考

主备延迟、主从延迟

数据同步延迟情况参考: show slave status;  --> seconds_behind_master , 此参数表示同步延迟时间为多少秒
延迟时间点：
1.主库A执行完成一个事务，写入binlog，时间点time1
2.之后传给备库B，备库B接收完这个binlog,时间点time2
3.备库B执行完这个事务，时间点 time3
time3 减去 time1 的时间差为同步延迟时间，主要是在执行一个事务中备库与主库执行执行完的时间偏差
seconds_behind_master 计算方式：
1.每个事务的binlog里面都有一个时间字段，用于记录主库上写入的时间
2.备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到seconds_behind_master
如果主备库机器的系统时间设置不一致，不会导致主备延迟的值不准。备库连接到主库的时候，会通过SELECTUNIX_TIMESTAMP()函数来获得当前主库的系统时间。如果这时候发现主库的系统时间与自己不一致，备库在执行seconds_behind_master计算的时候会自动扣掉这个差值，网络正常情况下，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差，主备延迟最直接的表现是，备库消费中转日志的速度，比主库生产binlog的速度要慢。

主备、主从延迟原因

1、从库配置较主库偏低
2、主库提供写操作，备库和从库提供读操作，读操作频繁，导致备库或从库压力大。
3、执行事务较大，一般是执行比较大的DDl语句。
解决方案：
1、提升从库数量或从库配置
2、sql语句的优化

主备切换

双M结构下，从状态1到状态2切换的详细过程如下：
1.判断备库B现在的seconds_behind_master，如果小于某个值继续下一步，否则持续重试这一步
2.把主库A改成只读状态，即把readonly设置为true
3.判断备库B的seconds_behind_master的值，直到这个值变成0为止
4.把备库B改成可读写状态，也就是把readonly设置为false
5.把业务请求切到备库B

redis 问题

什么是缓存穿透？如何避免？什么是缓存雪崩？何如避免？
缓存穿透
一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。
如何避免？
1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。
2：对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。
缓存雪崩
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压力。导致系统崩溃。
如何避免？
1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
2：做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期
3：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。