Bảo Mật API & Rate Limiting Trong Go — Token Bucket, Leaky Bucket & Redis Lua

Điều kiện tiên quyết: Đây là Phần 11 của Khóa Học System Design. Các bài học trước đã hướng dẫn xây dựng các thành phần cốt lõi của hệ thống — bài học này sẽ trang bị các giải pháp bảo vệ API và kiểm soát lưu lượng truy cập (Rate Limiting) để đảm bảo tính ổn định khi hệ thống gặp đột biến lưu lượng (traffic spikes).

Answer-first: Đối mặt với các đợt lưu lượng khổng lồ do Bot và Agentic AI tạo ra năm 2026, cơ chế API Rate Limiting bảo vệ các dịch vụ backend bằng cách kiểm soát lượng request được phép xử lý trong một khoảng thời gian. Hệ thống bảo mật hiện đại bắt buộc phải triển khai mô hình bảo vệ đa lớp (Layered Defense): WAF ở rìa ngoài để dập tắt các đợt tấn công quá tải dung lượng (Volumetric Spikes/DDoS), API Gateway ở tầng L7 để xác thực vé truy cập (Credentials/Tokens) và kiểm soát hạn ngạch (Quotas), và Application Middleware ở tầng trong cùng để áp đặt các quy tắc nghiệp vụ chi tiết. Việc định danh client để rate limit cần xác định IP chính xác và an toàn (sử dụng PROXY protocol hoặc trích xuất đúng địa chỉ IP thực từ header X-Forwarded-For).

Kiến Trúc Bảo Vệ API Đa Lớp Về Rate Limiting Và Phòng Chống IP Spoofing

Answer-first: Một kiến trúc Rate Limiting hoàn chỉnh đòi hỏi phương pháp tiếp cận theo từng tầng: chặn các cuộc tấn công diện rộng ngay tại Edge WAF, kiểm soát hạn ngạch theo tài khoản/API Key tại L7 Gateway, và kiểm soát các hành động nghiệp vụ nhạy cảm tại Application Middleware. Để phòng tránh tấn công giả mạo địa chỉ IP (IP Spoofing), các lớp proxy trung gian phải loại bỏ các header X-Forwarded-For do client tự gửi lên và chỉ tin tưởng các địa chỉ IP được thêm vào bởi các proxy nội bộ đáng tin cậy hoặc áp dụng chuẩn PROXY protocol ở tầng TCP.

Các Tầng Bảo Vệ Rate Limiting

Hệ thống phân tán không bao giờ nên phụ thuộc vào một điểm kiểm soát duy nhất (Single Point of Failure). Việc xử lý Rate Limiting nên được chia làm 3 tầng bảo vệ:

graph TD
    Client([Client Traffic]) -->|"Chặn tấn công L3/L4 & Volumetric DDoS"| WAF["☁️ Edge WAF\n(Cloudflare WAF / AWS WAF)"]
    WAF -->|"Chuyển lưu lượng sạch qua"| GW["🔀 API Gateway (L7)\n(Kong / Envoy / Traefik)"]
    GW -->|"Xác thực JWT / API Key\nKiểm soát Quota theo Tenant"| App["⚙️ Go Application Middleware\n(Redis + Business Logic)"]
    App -->|"Giới hạn chi tiết:\nHành động User / Thanh Toán"| Svc["🗄️ Upstream Services\n(DB, Message Queue, Cache)"]

    style WAF fill:#ff6b6b,color:#fff
    style GW fill:#4a6cf7,color:#fff
    style App fill:#28a745,color:#fff
    style Svc fill:#6c757d,color:#fff

Phòng Chống Tấn Công Giả Mạo IP (X-Forwarded-For Spoofing)

Nếu hệ thống Rate Limiter phụ thuộc trực tiếp vào HTTP Header X-Forwarded-For để định danh client, kẻ tấn công có thể dễ dàng gửi kèm header giả mạo trong request:

GET /api/checkout HTTP/1.1
Host: api.vesviet.com
X-Forwarded-For: 8.8.8.8

Nếu Reverse Proxy không được cấu hình để làm sạch header này, ứng dụng backend sẽ nhận được chuỗi X-Forwarded-For: 8.8.8.8, <client_real_ip>. Nếu ứng dụng vô tình lấy## Thuật Toán Rate Limiting Trong Bộ Nhớ: Token Bucket vs. Leaky Bucket

Answer-first: Thuật toán Token Bucket cho phép xử lý các đợt bùng nổ lưu lượng ngắt quãng (traffic bursts) nhờ dung tích xô chứa sẵn token. Thuật toán Leaky Bucket đảm bảo làm mịn tốc độ đầu ra (smooth output rate) bằng cách cưỡng chế khoảng thời gian chờ giữa các request. Trong môi trường Go xử lý đồng thời cao (high concurrency), việc sử dụng một ổ khóa chung (sync.Mutex) cho Rate Limiter sẽ tạo ra điểm nghẽn xung đột khóa (Lock Contention); kỹ thuật Sharded Limiter hoặc các phép toán nguyên tử (Atomic CAS) giúp giải quyết triệt để vấn đề này.

So Sánh Thuật Toán Token Bucket và Leaky Bucket

Giải Quyết Lock Contention Khi Xử Lý Đồng Thời Cao

Thư viện chuẩn golang.org/x/time/rate áp dụng khóa sync.Mutex trên mỗi thao tác kiểm tra token:

func (lim *Limiter) AllowN(now time.Time, n int) bool {
    lim.mu.Lock()
    defer lim.mu.Unlock()
    return lim.reserveN(now, n, 0).ok
}

Khi hệ thống xử lý hàng trăm nghìn requests/giây đồng thời, phân tích CPU profile sẽ ghi nhận các goroutines bị treo tại sync.runtime_Semacquire do xung đột Mutex Lock trên Limiter instance.

Mô Hình Sharded Limiter Optimization

Để tối ưu, chia nhỏ map chứa limiters thành $N$ shards độc lập dựa trên chuỗi băm của key (Client IP hoặc User ID):

package limiter

import (
	"hash/fnv"
	"sync"
	"time"
	"golang.org/x/time/rate"
)

type ShardedLimiter struct {
	shards []*limiterShard
	size   uint32
}

type limiterShard struct {
	mu       sync.RWMutex
	limiters map[string]*rate.Limiter
}

func NewShardedLimiter(shardCount int) *ShardedLimiter {
	shards := make([]*limiterShard, shardCount)
	for i := 0; i < shardCount; i++ {
		shards[i] = &limiterShard{
			limiters: make(map[string]*rate.Limiter),
		}
	}
	return &ShardedLimiter{shards: shards, size: uint32(shardCount)}
}

func (sl *ShardedLimiter) getShard(key string) *limiterShard {
	h := fnv.New32a()
	h.Write([]byte(key))
	idx := h.Sum32() % sl.size
	return sl.shards[idx]
}

func (sl *ShardedLimiter) Allow(key string, r rate.Limit, b int) bool {
	shard := sl.getShard(key)
	
	shard.mu.RLock()
	lim, exists := shard.limiters[key]
	shard.mu.RUnlock()

	if !exists {
		shard.mu.Lock()
		// Double check lock
		lim, exists = shard.limiters[key]
		if !exists {
			lim = rate.NewLimiter(r, b)
			shard.limiters[key] = lim
		}
		shard.mu.Unlock()
	}

	return lim.Allow()
}

Hai Biến Thể Triển Khai Của Leaky Bucket

1. Biến Thể Hàng Đợi (Queue-Based): Sử dụng buffered channel đóng vai trò xô chứa. Một goroutine worker chạy theo nhịp time.Ticker để rút từng request ra xử lý. Nếu channel bị đầy, request mới đến sẽ bị từ chối ngay lập tức. Đánh đổi: Tốn bộ nhớ cấp phát cho channel và tăng thêm độ trễ khi queue bị tích tụ.
2. Biến Thể Bấm Giờ (Time-Gap / uber-go/ratelimit): Không sử dụng queue, chỉ lưu mốc thời gian dự kiến (expected execution time) của request tiếp theo. Nếu request đến quá nhanh, goroutine sẽ bị dừng (sleep) một khoảng ngắn để đảm bảo khoảng cách giữa 2 request: Đánh đổi: Tối ưu bộ nhớ ($O(1)$ memory). Goroutine tạm dừng theo cơ chế của Go Scheduler với chi phí tài nguyên thấp.

Triển Khai Distributed Rate Limiting Với Redis Và Lua Script

Answer-first: Distributed Rate Limiting cho phép đồng bộ hạn ngạch (quotas) xuyên suốt nhiều instances ứng dụng thông qua bộ lưu trữ tập trung Redis. Thuật toán Sliding Window Log/Counter sử dụng cấu trúc dữ liệu Sorted Set (ZSET) trong Redis để lưu mốc thời gian của từng request. Việc sử dụng Lua Script đảm bảo toàn bộ chuỗi lệnh (xóa log cũ, đếm số request hiện tại, chèn request mới) được thực thi nguyên tử (atomically) trên Redis server, loại bỏ rủi ro Race Condition.

                  +-----------------------------------+
                  |        Go Application Nodes       |
                  +-----------------------------------+
                       |                         |
                       |  EvalSHA (Lua Script)   | (Thực thi nguyên tử)
                       v                         v
        +-------------------------------------------------+
        |                  Redis Cluster                  |
        |  Lua Script Steps:                              |
        |  1. ZREMRANGEBYSCORE: Xóa bản ghi < window start|
        |  2. ZCARD: Đếm số bản ghi trong window          |
        |  3. ZADD + PEXPIRE: Thêm record mới nếu valid  |
        +-------------------------------------------------+

Ràng Buộc Slot Trong Redis Cluster Khi Chạy Lua Script

Trong cụm Redis Cluster, các khóa được phân bổ trên 16,384 Hash Slots. Nếu Lua script thao tác trên nhiều key nằm ở các slots (hoặc nodes) khác nhau, Redis sẽ trả về lỗi CROSSSLOT Keys in request don't hash to the same slot.

Giải Pháp Hash Tags Đảm Bảo Cùng Slot

Để đảm bảo tất cả các key liên quan đến một rate limit check rơi vào cùng một Hash Slot, bọc phần chuỗi định danh bằng dấu ngoặc nhọn {}:

• Không dùng Hash Tag: rate:127.0.0.1:log và rate:127.0.0.1:metadata rơi vào 2 slots khác nhau -> Lỗi CROSSSLOT.
• Có Hash Tag: {rate:127.0.0.1}:log và {rate:127.0.0.1}:metadata chỉ tính toán hash dựa trên chuỗi rate:127.0.0.1 -> Đảm bảo rơi vào cùng 1 slot.

Kịch Bản Lua Script Triển Khai Sliding Window Rate Limiting

-- KEYS[1]: Limit Key, ví dụ: "{rate:user_1029}:log"
-- ARGV[1]: Mốc thời gian hiện tại UNIX (ms)
-- ARGV[2]: Độ dài cửa sổ trượt (ms), ví dụ: 60000 cho 1 phút
-- ARGV[3]: Hạn ngạch tối đa (Max requests)
-- ARGV[4]: Unique Request ID (UUID/Random string)
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local limit = tonumber(ARGV[3])
local request_id = ARGV[4]

-- Bước 1: Xóa các mốc thời gian ngoài cửa sổ trượt
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)

-- Bước 2: Đếm số lượng request còn lại trong cửa sổ
local count = redis.call('ZCARD', key)

-- Bước 3: Kiểm tra hạn ngạch
if count < limit then
    -- Thêm request hiện tại vào ZSET
    redis.call('ZADD', key, now, request_id)
    -- Gán thời gian hết hạn TTL cho key
    redis.call('PEXPIRE', key, window)
    return {1, count + 1} -- Trả về: {Cho Phép=1, Số Request Hiện Tại}
else
    return {0, count}     -- Trả về: {Từ Chối=0, Số Request Hiện Tại}
end

Triển Khai Complete Go Middleware Cho Rate Limiting

Ví dụ triển khai HTTP Middleware trong Go sử dụng go-redis/v9 để gọi Lua Script và thiết lập các HTTP headers tiêu chuẩn (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After):

package middleware

import (
	"context"
	"crypto/rand"
	"encoding/hex"
	"net/http"
	"strconv"
	"time"

	"github.com/redis/go-redis/v9"
)

var slidingWindowScript = redis.NewScript(`
	local key = KEYS[1]
	local now = tonumber(ARGV[1])
	local window = tonumber(ARGV[2])
	local limit = tonumber(ARGV[3])
	local request_id = ARGV[4]
	redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
	local count = redis.call('ZCARD', key)
	if count < limit then
		redis.call('ZADD', key, now, request_id)
		redis.call('PEXPIRE', key, window)
		return {1, count + 1}
	else
		return {0, count}
	end
`)

type RedisRateLimiter struct {
	rdb    *redis.Client
	limit  int
	window time.Duration
}

func NewRedisRateLimiter(rdb *redis.Client, limit int, window time.Duration) *RedisRateLimiter {
	return &RedisRateLimiter{
		rdb:    rdb,
		limit:  limit,
		window: window,
	}
}

func (rl *RedisRateLimiter) Middleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		ctx := r.Context()
		
		// Định danh client theo IP kết nối thực sự
		ip := r.RemoteAddr
		key := "{rate:" + ip + "}:log"
		
		now := time.Now().UnixNano() / int64(time.Millisecond)
		windowMs := rl.window.Milliseconds()
		
		// Tạo unique request ID bằng chuỗi ngẫu nhiên
		randBytes := make([]byte, 8)
		if _, err := rand.Read(randBytes); err != nil {
			http.Error(w, "Internal System Error", http.StatusInternalServerError)
			return
		}
		reqID := hex.EncodeToString(randBytes)

		// Thực thi Lua script nguyên tử trên Redis
		res, err := slidingWindowScript.Run(ctx, rl.rdb, []string{key}, now, windowMs, rl.limit, reqID).Result()
		if err != nil {
			http.Error(w, "Rate limiting service unavailable", http.StatusServiceUnavailable)
			return
		}

		results := res.([]interface{})
		allowed := results[0].(int64)
		count := results[1].(int64)

		// Thiết lập các HTTP response headers tiêu chuẩn
		w.Header().Set("X-RateLimit-Limit", strconv.Itoa(rl.limit))
		w.Header().Set("X-RateLimit-Remaining", strconv.FormatInt(int64(rl.limit)-count, 10))

		if allowed == 0 {
			w.Header().Set("Retry-After", strconv.FormatInt(rl.window.Milliseconds()/1000, 10))
			http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
			return
		}

		next.ServeHTTP(w, r)
	})
}

Case Study: Kiến Trúc Request Shielding Trong Sự Kiện Flash Sale Tại Shopee

🔥 [Kiến Trúc Production: Giải Pháp Request Shielding Của Shopee] Trong các đợt Flash Sale cao điểm, lượng ghi (Write Traffic) đột biến có rủi ro làm quá tải hệ thống cơ sở dữ liệu chính. Shopee áp dụng cơ chế Request Shielding đa tầng kết hợp Redis và Message Queue:

1. Chặn Đứng Tại Cache (Immediate Shielding): Trạng thái tồn kho sản phẩm được lưu trữ trên Redis. Ngay khi Redis xác nhận kho hàng đã hết (stock = 0), các bản tin cache nội bộ (sync.Map) trên từng app node sẽ lập tức từ chối tất cả các yêu cầu mua hàng tiếp theo mà không cần gửi request truy vấn tới Redis hay Database.
2. Đệm Qua Hàng Đợi (Queue Buffering): Khi còn hàng, các yêu cầu hợp lệ được đưa vào hàng đợi Kafka Message Queue để chờ xử lý bất đồng bộ.
3. Xử Lý Bất Đồng Bộ (Asynchronous Drain): Các worker pool rút từng yêu cầu từ Kafka để ghi vào database với tốc độ được kiểm soát an toàn, đảm bảo cơ sở dữ liệu không bao giờ bị quá tải.

Câu Hỏi Thường Gặp (FAQ)

Cách phòng chống IP Spoofing trong cơ chế Rate Limiting?

Không nên tin tưởng trực tiếp giá trị của header X-Forwarded-For do client gửi lên. Cần loại bỏ các header không hợp lệ tại lớp Edge Reverse Proxy, hoặc chỉ trích xuất giá trị IP từ các proxy nội bộ đáng tin cậy. Cách an toàn nhất ở tầng hạ tầng mạng là áp dụng PROXY protocol để lấy IP kết nối thực từ tầng TCP.

Lựa chọn In-Memory Rate Limiter hay Distributed Redis Rate Limiter?

• In-Memory Rate Limiter (golang.org/x/time/rate): Độ trễ cực thấp, throughput cao. Thích hợp cho việc giới hạn lưu lượng trên từng node lẻ hoặc bảo vệ tài nguyên nội bộ của tiến trình.
• Distributed Redis Rate Limiter: Cho phép chia sẻ và đồng bộ hạn ngạch xuyên suốt nhiều node trong cụm microservices (Global Quota). Thích hợp cho việc giới hạn hạn ngạch theo API Key, User Account hoặc IP trên toàn hệ thống.

Cơ chế Rate Limiting trong Envoy Proxy hoạt động như thế nào?

Envoy Proxy hỗ trợ gRPC Rate Limit Filter (envoy.filters.http.ratelimit). Mỗi khi nhận được request, Envoy sẽ gọi tới một dịch vụ Rate Limit bên ngoài (tuân thủ API RateLimitService của Lyft) để kiểm tra hạn ngạch trên Redis Cluster trước khi quyết định cho phép request đi tiếp hay trả về HTTP 429 Too Many Requests.

🔗 Bay Sang Bài Tới: Phần 12: Giao Thức Truyền Thông Trong Microservices — So Sánh gRPC, REST & GraphQL Trong Go

🔗 Đọc thêm các chuyên đề liên quan:

• Kiến trúc Microservices Golang & DDD
• Triển khai Agentic AI Swarm trong Production với OpenClaw & LiteLLM
• Kiến trúc Microservices Golang gRPC: Protobuf, TLS & Middleware