Advanced Operations, High Availability & Production Realities

ในฐานะวิศวกรสาย JVM/Spring Boot เรามักคุ้นเคยกับ @Transactional บน RDBMS ซึ่งอาศัย Row-Level Locks และ Transaction Isolation Levels (Read Committed / Serializable) แต่ในโลก In-Memory ของ Redis ที่ขับเคลื่อนด้วย Single-Threaded Event Loop กลไก Transaction ถูกออกแบบด้วยวิธีที่แตกต่างกันอย่างสิ้นเชิง

MULTI / EXEC / WATCH (Optimistic Locking) vs RDBMS Pessimistic Locking

คำสั่ง MULTI ใน Redis ไม่ใช่การเปิด Lock บนข้อมูล แต่เป็นเพียงการ "สั่งให้อัดคำสั่งลง Queue ฝั่ง Client/Connection Buffer" และคำสั่งทั้งหมดจะถูกยิงเข้าไปรันรวดเดียวเมื่อเรียก EXEC:

Server-Side Atomicity ด้วย Lua Scripting (EVAL / EVALSHA)

เพื่อแก้ปัญหา Round-Trip และ Concurrency Retry ทางออกระดับสถาปัตยกรรมธนาคารคือการย้าย Business Logic ไปรัน Atomic Server-Side ภายใน Event Loop ของ Redis ผ่านภาษา Lua:

-- atomic_withdraw.lua
-- KEYS[1]: ledger:balance:acc_id
-- ARGV[1]: withdraw_amount
-- ARGV[2]: txn_id

local current_bal = redis.call('GET', KEYS[1])
if not current_bal then
    return redis.error_reply("ACCOUNT_NOT_FOUND")
end

local bal_num = tonumber(current_bal)
local amount = tonumber(ARGV[1])

if bal_num < amount then
    return -1 -- INSUFFICIENT_FUNDS
end

-- Deduct balance and record transaction log atomically
redis.call('DECRBY', KEYS[1], amount)
redis.call('LPUSH', 'ledger:tx:' .. KEYS[1], ARGV[2])
return bal_num - amount

ในระบบการเงิน ความพร้อมใช้งาน (High Availability) และการป้องกันข้อมูลสูญหาย (Zero-Loss Tolerance) เป็นหัวใจสำคัญ การเข้าใจวงจร Failover จึงเป็นสิ่งจำเป็น

Master-Replica Synchronization Mechanics: PSYNC vs Full Sync

• Replication Backlog Buffer: Master จะกัน Buffer ขนาดหนึ่งใน RAM (เช่น 64MB) เก็บ Command Stream ล่าสุดไว้ หาก Replica หลุดการเชื่อมต่อไปเพียงชั่วคราว (Network Blip) เมื่อต่อกลับมาจะส่งค่า Replication Offset และ Master RunID มาขอทำ Partial Resynchronization (PSYNC) ซึ่ง Master จะส่งเฉพาะ Deltas ที่ตกค้างใน Backlog Buffer กลับไปให้ โดยไม่ต้อง Fork Snapshot
• Full Resynchronization: หาก Replica หลุดไปนานจน Offset หลุดขอบของ Backlog Buffer หรือเชื่อมต่อครั้งแรก Master จะต้องสั่ง BGSAVE สร้าง Full RDB Dump ส่งผ่าน Network ไปให้ Replica ทั้งก้อน ซึ่งก่อให้เกิด Disk I/O, Fork Latency, และ Network Spikes รุนแรง

Sentinel Consensus & Split-Brain Mitigation

Sentinel ทำหน้าที่เป็น Distributed Coordinator (แนะนำให้รัน 3 Nodes ขึ้นไปเพื่อให้เกิด Quorum):

1. SDOWN (Subjective Down): Sentinel ตัวหนึ่งตัวใด PING หา Master แล้วไม่ตอบกลับภายใน down-after-milliseconds
2. ODOWN (Objective Down): เมื่อ Sentinel ได้รับการยืนยันจาก Sentinel ตัวอื่นจนครบ Quorum (เช่น 2 ใน 3) จะยกระดับเป็นภาวะล่มจริง และทำ Leader Election ผ่าน Raft algorithm เพื่อเลือก Sentinel ตัวทำ Failover
3. Split-Brain Protection: หากเกิด Network Partition แล้ว Master เดิมถูกตัดขาดไปอยู่ฝั่งเสียงข้างน้อย มันอาจยังรับ Write จาก Client เก่าต่อไป เพื่อป้องกันเหตุการณ์นี้ ต้องคอนฟิกใน Redis Master:

   min-replicas-to-write 1
   min-replicas-max-lag 10

   หาก Master ไม่ได้รับการยืนยัน ACK จาก Replica อย่างน้อย 1 โหนดภายใน 10 วินาที Master จะปฏิเสธการ Write ทันที ป้องกันไม่ให้เกิด Split-Brain และ Data Divergence

เมื่อปริมาณ Write Throughput หรือขนาด Memory ใน RAM พุ่งเกินขีดจำกัดของเซิร์ฟเวอร์เครื่องเดียว Redis จะเปลี่ยนผ่านสู่ Multi-Master Distributed Sharding ผ่านสถาปัตยกรรม Redis Cluster

ทำไมต้องมี 16,384 Slots พอดี? (Hardware & Network Physics)

ทำไม Salvatore Sanfilippo ถึงเลือกตัวเลข 2¹⁴ = 16,384 แทนที่จะเป็น 65,536 (2¹⁶)?:

• Heartbeat Packet Overhead: โหนดใน Cluster จะยิง Gossip Protocol แลกเปลี่ยนสถานะกันตลอดเวลา ใน Packet จะบรรจุ Slot Bitmap หากใช้ 16,384 slots จะใช้พื้นที่ Bitmap เพียง 2 KB (16,384 / 8 bytes) แต่ถ้าใช้ 65,536 slots จะกินพื้นที่ 8 KB ต่อ Ping Packet ซึ่งสร้างขยะ Overhead บน Network Interface Controller (NIC) มหาศาลเมื่อ Cluster มีขนาด 500–1000 โหนด
• Optimal Sharding Density: ในทางปฏิบัติ คลัสเตอร์ Redis ไม่ควรมี Master เกิน 1,000 โหนด ดังนั้น 16,384 สล็อตจึงเพียงพอต่อการกระจายข้อมูลเฉลี่ยโหนดละ 16-30 slots ได้อย่างสมบูรณ์แบบ

The Multi-Key Limitation & Hash Tags ({...}) Solution

ใน Redis Cluster คำสั่งที่ต้องแตะหลาย Keys พร้อมกัน (เช่น MGET, Transaction MULTI/EXEC, หรือ EVAL Lua) จะ ล้มเหลวทันทีด้วย Error: CROSSSLOT Keys in request don't hash to the same slot หาก Keys เหล่านั้นตกอยู่คนละเครื่อง

-- ทั้งสอง Keys จะได้ค่า CRC16 จากคำว่า "acc_9871" เหมือนกัน 100%
-- ทำให้วิ่งไปตกบน Node เดียวกันเสมอ รองรับ Multi-key Atomic Lua ได้อย่างราบรื่น
KEYS[1] = "ledger:{acc_9871}:balance"
KEYS[2] = "ledger:{acc_9871}:audit_log"

1. Hotkey Mitigation: เมื่อ Key เดียวรองรับ 100,000 TPS

เกิดจากข้อมูลเพียงชิ้นเดียวได้รับความนิยมสูงลิ่ว เช่น ข้อมูลสต็อกสินค้า Flash Sale หรืออัตราแลกเปลี่ยนเงินตราประจำวัน ส่งผลให้ CPU Core ของ Redis Node นั้นทำงานแตะ 100% ขณะที่โหนดอื่นว่างงาน

2 กลยุทธ์หลักในการทลาย Hotkey:

1. L1 In-Process Cache (Caffeine): เก็บ Hotkey ไว้ใน JVM Heap Memory โดยตรง มีอายุสั้นๆ (TTL 1-5 วินาที) สามารถสกัดกั้น Traffic ได้มากกว่า 90% โดยไม่ให้คำขอหลุดไปยัง Redis Network Socket
2. Random Suffix Sharding (Write-Spread): หากต้อง Write/Increment Hotkey ให้กระจาย Key ออกเป็น M ส่วน:

   val shardIndex = ThreadLocalRandom.current().nextInt(10) // 0 to 9
   val shardKey = "flash_sale:stock_item_99:$shardIndex"
   redisTemplate.opsForValue().increment(shardKey, -1)
   
   // เวลาอ่านยอดรวม: ใช้ MGET ดึงทั้ง 10 Shards มารวมผลบวกที่ JVM App

2. Big Key Diagnostics & Elimination

Big Key คือ Key ที่มีขนาดข้อมูลใหญ่เกินมาตรฐาน (เช่น String ขนาด > 5MB หรือ Hash/List/Set ที่มีสมาชิกเกิน 10,000 รายการ) ซึ่งทำให้เกิด:

• Network NIC saturation ในจังหวะดึงข้อมูล
• Event Loop Blocked ขณะรันคำสั่งลบ (DEL) หรือ Serialize ลง RDB

เครื่องมือตรวจสอบใน Production (CLI Diagnostics):

# 1. สแกนหา Big Keys ทั่วระบบโดยไม่บล็อก Event Loop (ใช้ SCAN ภายใน)
redis-cli -h 10.0.0.1 -p 6379 --bigkeys

# 2. สแกนหา Hotkeys แบบ Real-time (ต้องเปิด maxmemory-policy LFU)
redis-cli -h 10.0.0.1 -p 6379 --hotkeys

# 3. ดูประวัติคำสั่งที่กินเวลา CPU เกินเกณฑ์ (Default: 10,000 microseconds)
SLOWLOG GET 20

3. Memory Eviction Policies Deep Dive

สถาปัตยกรรมป้องกันการจ่ายเงินซ้ำซ้อน (Idempotent Payment Ingestion) และการหักบัญชีความเร็วสูงระดับ Core Banking โดยผสาน Redis และ PostgreSQL อย่างสมบูรณ์แบบ:

@Service
class BankingPaymentService(
    private val redisTemplate: StringRedisTemplate,
    private val ledgerRepository: PostgresLedgerRepository
) {
    // โหลด Compiled Lua Script ไว้ล่วงหน้า (ใช้ EVALSHA อัตโนมัติ)
    private val paymentScript = DefaultRedisScript(
        """
        local set_idemp = redis.call('SET', KEYS[1], 'PROCESSING', 'EX', ARGV[2], 'NX')
        if not set_idemp then
            return -1 -- ALREADY_PROCESSED_OR_IN_FLIGHT
        end
        
        local bal = redis.call('GET', KEYS[2])
        if not bal then
            return -2 -- ACCOUNT_CACHE_MISS
        end
        
        local current_bal = tonumber(bal)
        local deduct = tonumber(ARGV[1])
        if current_bal < deduct then
            return -3 -- INSUFFICIENT_FUNDS
        end
        
        redis.call('DECRBY', KEYS[2], deduct)
        return current_bal - deduct
        """.trimIndent(), Long::class.java
    )

    @Transactional
    fun processPayment(requestId: String, accountId: String, amount: Long): PaymentResult {
        val keys = listOf("idemp:{$accountId}:$requestId", "balance:{$accountId}")
        val result = redisTemplate.execute(paymentScript, keys, amount.toString(), "300")

        return when (result) {
            -1L -> throw DuplicateRequestException("Duplicate transaction: $requestId")
            -3L -> throw InsufficientBalanceException("Balance insufficient in account $accountId")
            -2L -> {
                // Cache Miss: โหลดจาก PostgreSQL Buffer Pool แล้ว Hydrate กลับเข้า Redis
                hydrateCacheAndRetry(accountId, requestId, amount)
            }
            else -> {
                // Success In-Memory: ยิง Event เข้า Kafka Transactional Outbox ส่งต่อให้ RDBMS Persistence
                persistLedgerAsync(accountId, amount, requestId)
                PaymentResult.Success(remainingBalance = result)
            }
        }
    }
}