常见技术难点及方案

1. 分布式锁

1.1 难点

1.1.1 锁延期

同一时间内不允许多个客户端同时获得锁；

1.1.2 防止死锁

需要确保在任何故障场景下，都不会出现死锁；

1.2.3 可重入

特殊的锁机制，它允许同一个线程多次获取同一个锁而不会被阻塞。

1.2.4 高可用

同时，加锁、释放锁的过程性能开销应尽量低，并保证高可用，避免单点故障。

1.2 技术方案

1.2.1 基于Redis

• 技术要点

• 技术实践

1.2.2 基于Zookeeper

• 技术要点

• 技术实践

Apache Curator是一个流行的ZooKeeper客户端库，它提供了高级的分布式锁实现，包括可重入锁。以下是一个使用Curator实现可重入锁的示例：

Curator is a keeper or custodian of a museum or other collection - A ZooKeeper Keeper.

Apache Curator is a Java/JVM client library for Apache ZooKeeper, a distributed coordination service. It includes a high level API framework and utilities to make using Apache ZooKeeper much easier and more reliable. It also includes recipes for common use cases and extensions such as service discovery and a Java 8 asynchronous DSL.

Welcome to Apache Curator | Apache Curator

import org.apache.curator.framework.CuratorFramework;  
import org.apache.curator.framework.recipes.locks.InterProcessReentrantLock;  
  
public class ZooKeeperReentrantLockExample {  
    private final CuratorFramework client;  
    private final InterProcessReentrantLock lock;  
  
    public ZooKeeperReentrantLockExample(CuratorFramework client, String lockPath) {  
        this.client = client;  
        this.lock = new InterProcessReentrantLock(client, lockPath);  
    }  
    public void acquireLock() throws Exception {  
        lock.acquire(); // 如果当前线程已经持有锁，则重入  
    }  
    public boolean tryAcquireLock(long time, TimeUnit unit) throws Exception {  
        return lock.tryLock(time, unit); // 尝试获取锁，支持重入  
    }  
    public void releaseLock() throws Exception {  
        lock.release(); // 释放锁，如果本地锁计数器减至0，则删除ZooKeeper中的节点  
    }  
}

2. 限流

2.1 难点

2.1.1 突发流量

在实际应用中，流量往往是不稳定的，存在高峰期和低谷期。如何根据流量的变化动态地调整限流策略，是限流算法需要解决的问题。此外，还需要考虑突发流量的情况，如突然出现的大量请求可能导致系统过载。

2.1.2 平滑

计数器限流算法是一种直观的限流方法，它通过累加在特定时间窗口内的请求数量，并在达到设定的阈值时执行限流操作。然而，这种方法存在一个显著的问题，那就是在时间窗口的末期，如果计数器接近或达到限流阈值，那么新到来的请求很可能会触发限流，即使这些请求在实际上并不会对系统造成过载。

观察请求量曲线图，计数器这种限流器会容易呈现出锯齿状而不是平滑的曲线。

2.2 方法

2.2.1 计数器

2.2.2 基于滑动窗口的计数器

2.2.3 令牌桶

2.2.4 漏斗算法

比较两者的特点，漏桶算法更侧重于强制限制数据的传输速率，确保系统接收的请求速率稳定。而令牌桶算法则在限制平均传输速率的同时，允许一定程度的突发传输，以适应流量变化的实际情况。

在适用场景上，漏斗算法更多地用于保护系统，防止因流量过大而崩溃。而令牌桶算法则更适用于那些需要应对突发流量的场景，比如在秒杀活动中，用户的请求速率不固定，令牌桶算法可以确保系统既能处理稳定的请求流，又能应对突发的请求高峰

2.3 方案

2.3.1 单机限流

2.3.1.1 Guava限流

• Guava RateLimiter———-限制时间窗口内的凭据速率
  • 平滑突发限流（SmoothBurst）
  • 平滑预热限流（SmoothWarningUp）
  • 主要方法：RateLimiter.create()和limiter.acquire()

2.3.2 分布式限流

2.3.2.1 Ngnix+Lua

2.3.2.2 Redis+Lua

​思路上就很粗暴！比如当前限流为10000QPS/s，直接将当前秒作为key，每一个请求到达的时候都将这个key自增，当一个请求将其自增到10000后，就拒绝访问！具体的实现见张开涛的《亿级流量网络架构核心技术》p75—-“分布式限流”。

3. 负载均衡

4. 分布式事务

4.1 难点

4.2 技术方案

5. 幂等

5.1 CAS

5.2 数据库Unique Key

6. 分库分表