🇬🇧 Read the English version of this article on tanhdev.com

Dapr State Store: Đánh Đổi Tính Nhất Quán (Strong vs Eventual Consistency)

Trong hành trình xây dựng các hệ thống phân tán chịu tải cao, bài toán quản lý trạng thái (State Management) luôn là một thử thách gai góc bậc nhất. Khi một ứng dụng phân rã thành hàng chục microservices, mỗi dịch vụ lại có những đòi hỏi lưu trữ hoàn toàn khác biệt: Tầng giỏ hàng và phiên làm việc (Session) cần tốc độ phản hồi cực nhanh dưới 1ms; trong khi tầng số dư ví điện tử và sổ cái giao dịch bắt buộc phải tuân thủ nghiêm ngặt tính toàn vẹn dữ liệu ACID, không chấp nhận bất kỳ sai lệch nào ngay cả khi mạng chập chờn.

Dapr (Distributed Application Runtime) giải quyết bài toán này bằng cách cung cấp một lớp trừu tượng hóa (State Store Abstraction). Ứng dụng không cần liên kết trực tiếp với các driver cơ sở dữ liệu độc quyền, mà chỉ cần tương tác với Dapr Sidecar qua các giao diện gRPC/HTTP chuẩn hóa.

Tuy nhiên, sự trừu tượng hóa không thể xóa bỏ các định luật vật lý của hệ thống phân tán. Định lý CAP vẫn luôn hiện hữu: Bạn phải lựa chọn đánh đổi giữa Strong Consistency (Nhất quán mạnh) và Eventual Consistency (Nhất quán cuối). Hiểu sai về cơ chế tính nhất quán và kiểm soát giao dịch đồng thời (Optimistic Concurrency Control - OCC) trong Dapr có thể dẫn đến thảm họa ghi đè mất dữ liệu (Lost Updates) hoặc tắc nghẽn toàn bộ luồng xử lý do lỗi HTTP 409 Conflict.

Bài viết này đi sâu vào giải phẫu kiến trúc Dapr State Management: So sánh bản chất giữa Strong và Eventual Consistency, hướng dẫn cấu hình Redis và CockroachDB, phân tích cơ chế thẻ phiên bản ETag, và cung cấp mã nguồn Golang 1.24+ triển khai OCC Retry Loop sẵn sàng cho môi trường Production.

⚡ Tóm Tắt Kiến Trúc Cốt Lõi (Executive BLUF)

• Mô hình Trừu Tượng Hóa Dapr State: Dapr tách biệt hoàn toàn mã nguồn nghiệp vụ khỏi hệ quản trị cơ sở dữ liệu ngầm (Redis, PostgreSQL, CockroachDB, AWS DynamoDB). Thay đổi backend lưu trữ chỉ cần sửa tệp Component YAML mà không cần biên dịch lại mã nguồn Go.
• Đánh đổi CAP cốt tử:
  • Strong Consistency (consistency: strong): Dapr đảm bảo dữ liệu đọc ra luôn là mới nhất qua giao thức Multi-Raft Quorum (CockroachDB). Đổi lại, độ trễ ghi tăng lên (5ms - 15ms) và hệ thống giảm khả năng phục vụ khi có phân mảnh mạng.
  • Eventual Consistency (consistency: eventual): Dapr xác nhận ghi ngay trên node Master (Redis), đồng bộ bất đồng bộ sang Replicas. Đạt độ trễ P99 < 1ms, thông lượng trên 100.000 TPS, nhưng chấp nhận dữ liệu đọc có thể bị cũ (Stale Read) trong vài mili-giây.
• Kiểm soát đồng thời lạc quan với ETag: Cấu hình concurrency: first-write kết hợp ETag ngăn chặn xung đột Race Conditions. Khi phát sinh xung đột (HTTP 409 Conflict), client Go phải thực thi quy trình Exponential Backoff Jitter Retry để đọc lại ETag mới và tính toán lại.

1. So Sánh Bản Chất: Strong vs Eventual Consistency Trong Dapr

Bảng so sánh định lượng chi tiết giữa hai mô hình nhất quán dữ liệu dưới góc nhìn kiến trúc hệ thống:

2. Kiểm Soát Giao Dịch Đồng Thời: Cơ Chế OCC & Thẻ ETag

Trong môi trường phân tán với hàng ngàn request đồng thời, việc sử dụng khóa bi quan (Pessimistic Locking) sẽ gây nghẽn nghiêm trọng. Dapr State Store chuẩn hóa cơ chế Kiểm Soát Đồng Thời Lạc Quan (Optimistic Concurrency Control - OCC) thông qua thẻ định danh phiên bản ETag:

sequenceDiagram
    autonumber
    actor ClientA as Microservice A
    actor ClientB as Microservice B
    participant Dapr as Dapr Sidecar (:3500)
    participant Store as State Store DB (Redis / CockroachDB)

    Note over ClientA, ClientB: Tình huống 2 luồng cùng cập nhật số dư ví (Balance)
    ClientA->>Dapr: GET /v1.0/state/statestore/wallet_101
    Dapr->>Store: SELECT value, etag FROM state WHERE key='wallet_101'
    Store-->>Dapr: value = 100, etag = "v1"
    Dapr-->>ClientA: HTTP 200 OK (Balance: 100, ETag: "v1")

    ClientB->>Dapr: GET /v1.0/state/statestore/wallet_101
    Dapr->>Store: SELECT value, etag FROM state WHERE key='wallet_101'
    Store-->>Dapr: value = 100, etag = "v1"
    Dapr-->>ClientB: HTTP 200 OK (Balance: 100, ETag: "v1")

    rect rgb(235, 255, 235)
        Note over ClientA, Store: Client A ghi trước thành công (First-Write Wins)
        ClientA->>Dapr: POST /v1.0/state/statestore (value: 150, etag: "v1", concurrency: "first-write")
        Dapr->>Store: UPDATE state SET value=150, etag="v2" WHERE key='wallet_101' AND etag="v1"
        Store-->>Dapr: ✅ Rows Affected = 1 (Thành công, ETag mới là "v2")
        Dapr-->>ClientA: HTTP 204 No Content
    end

    rect rgb(255, 230, 230)
        Note over ClientB, Store: Client B ghi chậm hơn với ETag cũ -> BỊ TỪ CHỐI
        ClientB->>Dapr: POST /v1.0/state/statestore (value: 120, etag: "v1", concurrency: "first-write")
        Dapr->>Store: UPDATE state SET value=120 WHERE key='wallet_101' AND etag="v1"
        Store-->>Dapr: ❌ Rows Affected = 0 (Sai lệch ETag, hiện tại là "v2")
        Dapr-->>ClientB: HTTP 409 Conflict (Lỗi xung đột dữ liệu)
        Note over ClientB: Client B bắt lỗi 409, đọc lại etag="v2" và Retry!
    end

Hai Chính Sách Concurrency Trong Dapr

1. concurrency: first-write (Mặc định khuyến nghị): Thao tác ghi đầu tiên khớp ETag sẽ thành công. Mọi thao tác ghi sau đó mang theo ETag cũ đều bị từ chối với lỗi HTTP 409 Conflict. Đây là vũ khí chống ghi đè mất mát dữ liệu (Lost Updates).
2. concurrency: last-write: Dapr bỏ qua ETag, chấp nhận ghi đè giá trị mới nhất lên bản ghi. Chỉ nên dùng cho các trường hợp telemetry không quan trọng hoặc dữ liệu cảm biến IoT.

3. Cấu Hình Kubernetes Component Chuẩn Production

3.1 Cấu Hình Redis Cho Eventual Consistency (Hiệu Năng Cực Cao)

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore-cache
  namespace: production
spec:
  type: state.redis
  version: v1
  metadata:
    - name: redisHost
      value: "redis-cluster.database.svc.cluster.local:6379"
    - name: redisPassword
      secretKeyRef:
        name: redis-secret
        key: password
    - name: enableTLS
      value: "false"
    # Cấu hình tính nhất quán cuối
    - name: consistency
      value: "eventual"
    - name: maxRetries
      value: "3"
    - name: maxRetryBackoff
      value: "500ms"
    - name: ttlInSeconds
      value: "86400" # Tự động dọn dẹp cache sau 24h

3.2 Cấu Hình CockroachDB Cho Strong Consistency (An Toàn Tuyệt Đối)

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore-ledger
  namespace: production
spec:
  type: state.postgresql # Dapr tương thích với CockroachDB qua Postgres driver
  version: v1
  metadata:
    - name: connectionString
      secretKeyRef:
        name: cockroachdb-secret
        key: connection-string
    - name: tableName
      value: "dapr_state_ledger"
    # Ép buộc Strong Consistency ở cả 2 chiều Đọc & Ghi
    - name: readConsistency
      value: "strong"
    - name: timeoutInSeconds
      value: "5"

4. Cài Đặt Mã Nguồn Production: Go Client Với OCC ETag Retry Loop

Dưới đây là mã nguồn Golang 1.24+ sử dụng Dapr Go SDK chính thức. Đoạn mã triển khai hàm trừ tiền trong ví điện tử an toàn tuyệt đối trước hàng trăm luồng truy cập đồng thời, tích hợp cơ chế Exponential Backoff có Jitter để xử lý lỗi HTTP 409 Conflict:

// Package main triển khai cơ chế Optimistic Concurrency Control (OCC) với Dapr Go SDK.
// Đảm bảo không bao giờ xảy ra lỗi ghi đè dữ liệu (Lost Updates) trong môi trường phân tán.
package main

import (
	"context"
	"encoding/json"
	"errors"
	"fmt"
	"log"
	"math/rand"
	"net/http"
	"time"

	dapr "github.com/dapr/go-sdk/client"
	"google.golang.org/grpc/codes"
	"google.golang.org/grpc/status"
)

const (
	StateStoreLedger = "statestore-ledger"
	MaxRetries       = 5
	BaseBackoffMs    = 50
)

// WalletState đại diện cho trạng thái ví điện tử trong State Store
type WalletState struct {
	UserID    string    `json:"user_id"`
	Balance   int64     `json:"balance"` // Số dư tính theo đơn vị VND
	UpdatedAt time.Time `json:"updated_at"`
}

// DeductBalanceAtomic thực hiện trừ tiền trong ví an toàn tuyệt đối bằng OCC ETag
func DeductBalanceAtomic(ctx context.Context, client dapr.Client, userID string, amount int64) error {
	stateKey := fmt.Sprintf("wallet:%s", userID)

	for attempt := 1; attempt <= MaxRetries; attempt++ {
		// 1. Đọc số dư hiện tại kèm ETag phiên bản
		item, err := client.GetState(ctx, StateStoreLedger, stateKey, nil)
		if err != nil {
			return fmt.Errorf("không thể đọc số dư ví: %w", err)
		}

		if len(item.Value) == 0 {
			return fmt.Errorf("ví người dùng %s không tồn tại", userID)
		}

		var wallet WalletState
		if err := json.Unmarshal(item.Value, &wallet); err != nil {
			return fmt.Errorf("lỗi giải mã dữ liệu ví: %w", err)
		}

		// 2. Kiểm tra điều kiện nghiệp vụ
		if wallet.Balance < amount {
			return fmt.Errorf("số dư không đủ (hiện có: %d, cần trừ: %d)", wallet.Balance, amount)
		}

		// 3. Chuẩn bị dữ liệu cập nhật
		wallet.Balance -= amount
		wallet.UpdatedAt = time.Now()

		updatedBytes, err := json.Marshal(wallet)
		if err != nil {
			return err
		}

		// 4. Ghi đè có điều kiện: ETag bắt buộc phải khớp (First-Write Wins)
		saveItem := &dapr.SetStateItem{
			Key:   stateKey,
			Value: updatedBytes,
			Etag: &dapr.ETag{
				Value: item.Etag,
			},
			Options: &dapr.StateOptions{
				Concurrency: dapr.StateConcurrencyFirstWrite,
				Consistency: dapr.StateConsistencyStrong,
			},
		}

		err = client.SaveBulkState(ctx, StateStoreLedger, saveItem)
		if err == nil {
			log.Printf("✅ Trừ thành công %d VND cho User %s tại lần thử thứ %d (Số dư mới: %d)",
				amount, userID, attempt, wallet.Balance)
			return nil
		}

		// 5. Kiểm tra xem lỗi có phải do xung đột ETag (Conflict) hay không
		if isConflictError(err) {
			// Tính toán thời gian ngủ Exponential Backoff kèm Jitter ngẫu nhiên
			jitter := rand.Intn(30)
			sleepDuration := time.Duration((BaseBackoffMs*(1<<attempt))+jitter) * time.Millisecond
			log.Printf("⚠️ Xung đột ETag (409 Conflict) ở lần thử %d. Thử lại sau %v...", attempt, sleepDuration)
			
			select {
			case <-ctx.Done():
				return ctx.Err()
			case <-time.After(sleepDuration):
				continue // Tiếp tục vòng lặp retry
			}
		}

		// Nếu là lỗi mạng hoặc lỗi khác, dừng ngay
		return fmt.Errorf("lỗi không thể phục hồi khi lưu state: %w", err)
	}

	return fmt.Errorf("vượt quá số lần thử tối đa (%d) do xung đột dữ liệu liên tục", MaxRetries)
}

// isConflictError kiểm tra mã lỗi trả về từ gRPC Dapr Client
func isConflictError(err error) bool {
	if s, ok := status.FromError(err); ok {
		return s.Code() == codes.Aborted || s.Code() == codes.FailedPrecondition
	}
	return false
}

func main() {
	// Khởi tạo Dapr Client kết nối tới local sidecar (:50001 gRPC)
	client, err := dapr.NewClient()
	if err != nil {
		log.Fatalf("Không thể khởi tạo Dapr Client: %v", err)
	}
	defer client.Close()

	ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
	defer cancel()

	// Khởi tạo dữ liệu ví mẫu
	initWallet := WalletState{
		UserID:    "user_888",
		Balance:   1000000, // 1.000.000 VND
		UpdatedAt: time.Now(),
	}
	initBytes, _ := json.Marshal(initWallet)
	_ = client.SaveState(ctx, StateStoreLedger, "wallet:user_888", initBytes, nil)

	log.Println("🚀 Bắt đầu chạy thử nghiệm giao dịch đồng thời với Dapr OCC...")

	// Thực hiện trừ tiền
	if err := DeductBalanceAtomic(ctx, client, "user_888", 250000); err != nil {
		log.Printf("❌ Giao dịch thất bại: %v", err)
	}
}

5. Ma Trận Đánh Đổi Kiến Trúc (Architecture Decision Matrix)

Dưới đây là khung hướng dẫn ra quyết định khi lựa chọn cấu hình Dapr State Store cho từng phân hệ nghiệp vụ:

                            YÊU CẦU TOÀN VẸN DỮ LIỆU (DATA INTEGRITY)
                                              ▲
                                              │
                      CÂN NHẮC DAPR WORKFLOW  │      DAPR STRONG CONSISTENCY
                      HOẶC SAGA DISTRIBUTED   │         + COCKROACHDB
                                              │
                      (Thanh toán xuyên dịch  │    (Số dư tài khoản ví,
                       vụ, giải ngân ngân     │     sổ cái giao dịch, trừ kho
                       hàng, đặt vé máy bay)  │     vĩnh viễn, hợp đồng pháp lý)
                                              │
               ───────────────────────────────┼───────────────────────────────► THÔNG LƯỢNG
                                              │                                TRUY VẤN
                       DAPR EVENTUAL          │        DAPR EVENTUAL          (THROUGHPUT)
                       + POSTGRESQL           │         + REDIS CLUSTER
                                              │
                      (Lưu cấu hình hệ thống, │    (Giỏ hàng tạm, đếm view,
                       thông tin hồ sơ người  │     lưu phiên JWT session,
                       dùng ít thay đổi)      │     rate limit token bucket)
                                              │

6. Benchmark Độ Trễ & Thông Lượng Các Backend Dapr State Store (OCC Lock Contention)

Dưới đây là kết quả kiểm thử thực nghiệm bằng công cụ k6 qua Dapr gRPC Sidecar (cổng :50001) trên cụm EKS 3 worker nodes c6i.xlarge với 10.000 tác vụ ghi đồng thời kèm kiểm tra ETag OCC:

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

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

• Làm Chủ Kiến Trúc Hướng Sự Kiện Với Dapr Pub/Sub — Xây dựng hệ thống microservices phi tập trung với Dapr.
• Temporal Saga Pattern Trong Golang — Quản lý distributed transactions tin cậy.
• Kiến Trúc Microfinance Core Banking — Xử lý giao dịch tài chính ACID không sai số.
• MySQL Scaling Sharding & TiDB Architecture — Phân tán cơ sở dữ liệu quan hệ với NewSQL.
• Các Mẫu Goroutine Pool Trong Go: Từ errgroup Đến Bounded Worker Pool — Kỹ nghệ lập trình đồng thời và quản lý worker pools.