diff --git a/public/api/i/2025/09/13/lqg62s-1.webp b/public/api/i/2025/09/13/lqg62s-1.webp
new file mode 100644
index 0000000..946408e
Binary files /dev/null and b/public/api/i/2025/09/13/lqg62s-1.webp differ
diff --git a/src/content/posts/中间件/Redis/Redis如何实现分布式锁.md b/src/content/posts/中间件/Redis/Redis如何实现分布式锁.md
new file mode 100644
index 0000000..b05408e
--- /dev/null
+++ b/src/content/posts/中间件/Redis/Redis如何实现分布式锁.md
@@ -0,0 +1,42 @@
+---
+title: Redis如何实现分布式锁
+published: 2025-09-13
+description: ''
+image: ''
+tags: ['Redis','中间件','分布式锁']
+category: '中间件 > Redis'
+draft: false 
+lang: ''
+---
+
+
+# 分布式锁
+在Redis中实现分布式锁的常见方法是通过 set ex nx命令+lua脚本组合使用，确保多个客户端不会获得同一个资源锁的同时，也保证了安全解锁和意外情况下锁的自动释放。
+
+## 理解Redis实现的分布式锁
+如果基于Redis来实现分布式锁，需要使用set ex nx命令+ lua脚本
+
+加锁： `SET lock_key uniqueValue EX expiretime NX`
+解锁： 使用lua脚本，先get获取key的value判断锁是否是自己加的，如果是则del
+```lua
+if redis.call("GET",KEYS[1]) == ARGV[1]
+then
+    return redis.call("DEL",KEYS[1])
+else
+    return 0
+end
+```
+
+锁需要有过期机制，假设某个客户端加锁后宕机了，锁没设置过期机制，就会让其他客户端抢不到锁。
+
+EX expiretime 设置的单位是秒，PX expiretime设置的是毫秒
+
+上面为啥要用`uniqueValue`呢，这个就是唯一的值，是为了防止锁被其他客户端释放掉。
+
+## 实现分布式锁的步骤
+1. 加锁：使用`SET lock_key uniqueValue EX expiretime NX`命令加锁
+2. 解锁：使用lua脚本，先get获取key的value判断锁是否是自己加的，如果是则del
+3. 锁需要有过期机制，假设某个客户端加锁后宕机了，锁没设置过期机制，就会让其他客户端抢不到锁。
+4. EX expiretime 设置的单位是秒，PX expiretime设置的是毫秒
+5. 上面为啥要用`uniqueValue`呢，这个就是唯一的值，是为了防止锁被其他客户端释放掉。
+6. 锁需要有过期机制，假设某个客户端加锁后宕机了，锁没设置过期机制，就会让其他客户端抢不到锁。
diff --git a/src/content/posts/中间件/Redis/Redis实现分布式锁的时候可能遇到的问题有哪些.md b/src/content/posts/中间件/Redis/Redis实现分布式锁的时候可能遇到的问题有哪些.md
new file mode 100644
index 0000000..ae4500f
--- /dev/null
+++ b/src/content/posts/中间件/Redis/Redis实现分布式锁的时候可能遇到的问题有哪些.md
@@ -0,0 +1,11 @@
+---
+title: Redis实现分布式锁的时候可能遇到的问题有哪些
+published: 2025-09-13
+description: ''
+image: ''
+tags: ['Redis','中间件','分布式锁']
+category: '中间件 > Redis'
+draft: false 
+lang: ''
+---
+![](https://blog.meowrain.cn/api/i/2025/09/13/lqg62s-1.webp)
\ No newline at end of file
diff --git a/src/content/posts/中间件/Redis/单点故障问题.md b/src/content/posts/中间件/Redis/单点故障问题.md
new file mode 100644
index 0000000..5e2afd5
--- /dev/null
+++ b/src/content/posts/中间件/Redis/单点故障问题.md
@@ -0,0 +1,32 @@
+---
+title: Redis单点故障问题
+published: 2025-09-13
+description: ''
+image: ''
+tags: ['Redis','单点故障']
+category: '中间件 > Redis'
+draft: false 
+lang: ''
+---
+
+# 单点故障问题
+
+单台Redis实现分布式锁存在单点故障问题，如果采用主从读写分离架构，如果一个客户端在主节点上锁成功，但是主节点突然宕机，由于主从延迟导致节点还没有同步到这个锁，此时可能有另一个客户端抢到新晋升的主节点，这个时候会导致两个客户端抢到了锁，产生数据不一致。
+
+# 红锁
+红锁基本思想：
+- 部署多个Redis实例（通常5个）
+- 客户端在大多数实例（至少3个）上请求锁，并在一定时间内获得成功，表示加锁成功。
+- 使用RedLock可以提供更高的容错性，即使部分Redis实例故障，仍然能获得锁。
+
+## 红锁实现步骤
+- 客户端尝试在每个Redis实例上加锁，必须在有限时间内完成所有实例的加锁。
+- 如果大多数实例（N / 2 + 1）加锁成功，就表示加锁成功。
+- 否则，客户端将会释放所有已经加锁的实例，重新尝试。
+
+## 红锁缺点
+- 复杂性： 实现ReadLock要多个Redis实例，会增加复杂性。
+- 性能： 需要多个Redis实例，会增加性能开销。
+- 可靠性： 需要多个Redis实例，会增加可靠性开销。
+- 成本： 需要多个Redis实例，会增加成本。
+