说说数据库主从同步延迟的一个解决方案



Photo by Alvaro Reyes on Unsplash



题外话：我被 泰稳老师回复了，随着用户的增多，可能这是唯一一次近距离接触了。哈哈



为什么要读写分离或者主从同步

我理解的产生原因

随着业务的逐渐变大，单个数据库就逐渐撑不住庞大的请求，外加读和写的比例严重的不平衡，读写分离也就产生了，写入的请求把数据发送到主库。读的请求从从库读取，这样压力各自承担，把写入的风险降低，数据安全得到了保障。当读的压力增大的时候只要扩展读库就好了。

带来的挑战1

数据同步。不过展开来我就总结了下面两个点

• 主从同步

• 多个从库之间的同步

不过上面两个点还可以这么说，主是只跟一台从同步，然后其他从库跟这个同步的从库继续同步数据，还是主库跟所有的从库同步。

我的思考

因为公司现在用的是阿里云提供的数据库，所以这个问题是被解决掉了。不过具体的方案还需要更多的思考，我在自己的实践中更倾向于主跟一台或者部分从同步，然后其他从库在跟这个被同步的从库同步，为什么这样呢，我的想法就是把主库的风险降到最低。因为有那么多连接跟主库连着我就心虚，哪怕这个连接是由 mysql自己维护的，我也依然担心出问题。（下篇文章写主从同步配置）



带来的挑战2

数据延迟。只要是网络请求都会带来延迟，不管是网络波动，还是没问题的情况下。多多少少都会延迟。



解决方案

这边也是分为了两个方式来解决这个问题，另外这里没有考虑服务器间网络波动的情况。毕竟网络波动不可控，我们在逻辑这边增加兜底方案即可。

1. 即时性要求强的请求

这种就是请求后立刻就需要结果的，我们还分为两个方案

• 第一种，更新前获取数据，然后，更新成功后，把更新的字段跟查询回来的数据做更新，然后直接返回查询的数据

• 第二种，更新成功后，直接从主库查询。

我个人更倾向第一种的方案，毕竟直接查主库，貌似有点不优雅，但是现实中，我们是两个方案都在采用的。



2. 即时性要求略不强的请求

比如请求后并没有实时获取数据，或者就网页来说需要跳转页面的。

一般这种请求，就看我们监控的数据同步时间是多久，如果同步的很快，都能完美的短过两次操作的时间。那么这个直接从从库读取就可以了。这个虽然写的很猥琐，但是真的是个方案，不过这个得看用户的容忍度，毕竟不能每次保证都能从库同步完毕。或许加上一个优美的提示文案，可能就会帮你解决一些技术上解决起来比较耗时或者复杂的任务😁。



还存在问题么

上面的解决方案说完了，那么还有其他问题么，有，真的有，有时候就是真的卡了，数据就是没有同步完，虽然第一次请求直接读主库解决了部分问题，但是我们并不能每次都读主库，所以当读到从库的时候数据就没有了。这个现实中不止发生了一次，这种怎么办？上人工智能，怎么个智能法，真人排查问题去啊，火速检查，并且赶紧把数据给追上，事后复盘完善兜底方案。



总结

只要有网络请求，就会有延迟就会有不同步，这是个大活，不同级别的项目遇到的问题也不同，所以一个坑一个坑的走吧。持续完善兜底和补偿方案才是硬道理。