diff --git a/public/api/i/2025/09/10/k90qnk-1.webp b/public/api/i/2025/09/10/k90qnk-1.webp
new file mode 100644
index 0000000..752fefc
Binary files /dev/null and b/public/api/i/2025/09/10/k90qnk-1.webp differ
diff --git a/src/content/posts/中间件/MySQL/如何处理MySQL的主从同步延迟.md b/src/content/posts/中间件/MySQL/如何处理MySQL的主从同步延迟.md
index e130d89..b90e6b8 100644
--- a/src/content/posts/中间件/MySQL/如何处理MySQL的主从同步延迟.md
+++ b/src/content/posts/中间件/MySQL/如何处理MySQL的主从同步延迟.md
@@ -9,3 +9,18 @@ draft: false
 lang: ''
 ---
 
+# 如何处理MySQL的主从同步延迟
+
+当我们开启主从同步以后，这种延迟就是必然存在的，不论怎么优化都是没办法避免延迟的存在的，只能说去减少延迟的时间。
+
+常见的解决方案： 
+- 二次查询。如果说从库查不到数据，就去主库查一遍，用API封装这个逻辑就行，当作兜底策略。不过这样等于读的压力又转移到主库上去了，如果有人故意查询不存在的记录，那就会把查询的读请求都打到主库上了。
+- 强制把写之后立马读的操作转移到主库上（写后读主策略）。 写请求完成后，后续一段时间或者同一会话内的查询强制路由到主库，或者在从库追上指定位点前都读主。这个方法虽然简单可靠，能保证用户操作后的可见性，但是会增加主库的读压力，削弱负载分摊。
+- 关键业务读写都走主库。像我们用户注册这种，就可以读写主库，就不会出现说登录报用户不存在的问题了，这种访问量的频率也不高。
+- 使用缓存。 主库写入一行同步到缓存里面，这样查询的时候可以先查缓存，避免延迟，但是这样又有数据一致性问题了，我们就要去考虑数据库和缓存的数据一致性问题了。
+
+
+还有可能是 **主库的配置高，从库的配置低**，这样的话，也会导致主从同步延迟，我们可以提高从库的配置。
+
+
+![](https://blog.meowrain.cn/api/i/2025/09/10/k90qnk-1.webp)
\ No newline at end of file