360的云安全服务涉及分布式系统，设计一个分布式锁服务，用于高并发场景下的资源竞争（如多个节点同时处理同一用户的请求，避免重复操作），说明使用的技术（如Redis分布式锁）和优缺点。
答案
1) 【一句话结论】：在360云安全服务的高并发资源竞争场景下，推荐采用Redis结合Lua脚本实现分布式锁，通过精细化的锁粒度、动态超时计算（业务处理时间×1.5+网络缓冲）和指数退避重试机制，确保锁的可靠性，同时兼顾性能。
2) 【原理/概念讲解】：分布式锁的核心是保证多节点对共享资源的互斥访问。以Redis为例，利用SET命令的NX（仅当key不存在时设置）和EX（设置过期时间）参数，结合Lua脚本（单命令执行，保证原子性），实现“加锁-业务-解锁”流程。锁的粒度选择需根据业务场景：细粒度（如用户级锁）适合资源访问模式频繁的场景（如360云安全服务处理用户敏感数据时，不同用户请求可并发），粗粒度（如请求级锁）适合资源访问模式稀疏的场景。超时时间计算需考虑业务处理时间（T_process）和网络延迟（T_network），公式为T_timeout = T_process × 1.5 + T_network（缓冲时间）。Lua脚本的作用是确保加锁和解锁操作原子执行，避免中间状态导致死锁。类比：锁就像资源的“唯一通行证”，只有拿到通行证的节点才能操作资源，其他节点需等待。
3) 【对比与适用场景】：
| 实现方式 | 定义 | 核心特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Redis分布式锁 | 基于Redis的SET命令（NX+EX）+Lua脚本 | 原子性操作（Lua保证）、可配置过期时间 | 高并发、对性能要求高的场景（如360云安全服务资源竞争） | 需手动处理锁超时（避免死锁）、释放锁需检查锁是否为自己持有 |
| Zookeeper分布式锁 | 基于Zookeeper的临时顺序节点 | 自动管理锁（获取/释放）、有序性 | 需要更复杂的锁管理（如多级锁、公平锁） | 依赖Zookeeper集群，部署成本较高 |
| 数据库分布式锁 | 基于数据库的表（如加锁表） | 数据库事务保证原子性 | 数据库本身支持事务的场景 | 依赖数据库性能，高并发下可能成为瓶颈 |
4) 【示例】（伪代码）：
获取锁（含超时计算、重试逻辑）：
import redis
import time
import random
r = redis.Redis(host='localhost', port=6379, db=0)
lock_key = "user_resource_lock"
resource_id = "user_123"
process_time = 3 # 假设业务处理3秒
network_buffer = 1 # 网络延迟缓冲1秒
lock_timeout = process_time * 1.5 + network_buffer # 5秒
def acquire_lock():
script = """
if redis.call("SETNX", KEYS[1], ARGV[1]) == 1 then
redis.call("EXPIRE", KEYS[1], ARGV[2])
return 1
else:
return 0
end
"""
result = r.eval(script, args=(lock_key, resource_id, lock_timeout))
if result == 1:
print("获取锁成功，开始处理资源")
process_resource(resource_id)
r.delete(lock_key)
print("释放锁")
else:
print("获取锁失败，等待重试")
backoff = 1
while True:
time.sleep(backoff)
result = r.eval(script, args=(lock_key, resource_id, lock_timeout))
if result == 1:
break
backoff *= 2 # 指数退避
def process_resource(resource_id):
print(f"处理资源 {resource_id}...")
time.sleep(process_time)
acquire_lock()
5) 【面试口播版答案】（约90秒）：
“面试官您好，针对360云安全服务的高并发资源竞争场景，我推荐使用Redis结合Lua脚本实现分布式锁。核心是通过SET命令的NX和EX参数，结合Lua脚本保证原子性，实现加锁和解锁。锁的粒度选择上，比如处理用户敏感数据时采用用户级锁（细粒度），避免不同用户请求因锁冲突影响性能。超时时间计算采用业务处理时间（假设3秒）乘以1.5（缓冲）加上网络延迟（1秒），共5秒，既避免死锁又减少资源浪费。锁超时后采用指数退避重试（第一次1秒，第二次2秒…），避免死锁。Redis集群故障时，通过RDB/AOF持久化和主从复制确保锁状态一致性，故障恢复后锁能正常工作。”
6) 【追问清单】：
- 问：锁超时后，原节点如何重新获取锁？
答：原节点在超时后，通过指数退避算法重试，避免立即重试导致死锁。 - 问：如何保证解锁的原子性？
答：通过Lua脚本或事务保证解锁操作原子执行，避免锁未释放导致其他节点无法获取。 - 问：分布式锁的粒度如何选择？
答：细粒度（如用户级）适合资源访问频繁的场景，粗粒度（如请求级）适合访问稀疏的场景，需根据360云安全服务的业务模式（如用户请求频率）权衡。 - 问：Redis集群故障时，锁会失效吗？
答：通过持久化（RDB/AOF）和主从复制，确保锁状态一致性，故障恢复后锁能正常工作，不会失效。
7) 【常见坑/雷区】：
- 锁的过期时间设置不当：若过期时间过短（如业务处理5秒，设置3秒），会导致锁自动释放，造成重复操作；若过长（如10秒），资源被占用时间过长，影响并发效率。
- 未检查锁是否为自己持有就释放：可能导致误删其他节点的锁，破坏锁的互斥性。
- 锁的粒度过大：如锁住整个资源，导致多个节点无法并发处理不同部分，降低系统吞吐量。
- 超时机制不完善：没有重试逻辑或重试间隔不合理（如固定1秒），导致死锁或性能下降。
- 忽略分布式环境中的网络延迟：锁的获取和释放可能因网络延迟导致超时判断不准确，需考虑网络抖动。