VTRC Knowledge Manual (V2)

ธีม

14.6 Redis operations ​

บทนี้รวบรวมการดำเนินงานที่เกี่ยวข้องกับ Redis — เข้าถึง, ดู key, จัดการ session, restart, recovery

ภาพรวม Redis ในระบบ ​

InstanceContainerใช้โดยUse case
vtrc-redisvtrc-redis (port 6379)vtrc-apicache ผลลัพธ์บาง query เป็นหลัก — เกือบ vestigial; ไม่ใช่ที่เก็บ OTP
cu-centralize-rediscu-centralize-redis (port 6379)cu-central-apisession (sess:{userUid}_{sessionId}), profile/org cache, rate limit

Redis แต่ละ instance เป็น container ใน docker-compose ของ service นั้น ๆ — ไม่ใช่ cluster, ไม่มี replica

OTP ไม่ได้อยู่ใน Redis ​

Registration / forget-password OTP ถูกเก็บใน MariaDB ตาราง OTP ของ cu-central ผ่าน Models.Otp (cu-central-api/main-api/src/lib/otp/sendOtp.model.js)

  • vtrc-api เพียง proxy requestOtpCD ไปยัง cu-central GraphQL
  • TTL เริ่มต้น 3 นาที (SMS_OTP_EXPIRE_MINUTES = 3 ใน cu-central-api/main-api/src/config.js)

ห้าม ใช้ otp:* บน vtrc-redis เป็นที่ตรวจหรือลบ OTP ของระบบ — pattern นั้นไม่ใช่ที่เก็บ OTP

การตรวจ / ลบ OTP ทำผ่าน SQL บน DB ของ cu-central เช่น:

sql
-- ดู OTP ที่ยังไม่หมดอายุ (ตาราง otp — Models.Otp, tableName: 'otp')
SELECT * FROM otp
WHERE sentTo = '0812345678'
  AND expiredAt > NOW()
ORDER BY otpId DESC;

-- บังคับให้ขอใหม่
DELETE FROM otp WHERE sentTo = '0812345678';

การเข้าถึง Redis CLI ​

เข้า Redis ของ vtrc-api ​

bash
# เปิด redis-cli ใน container
docker exec -it vtrc-redis redis-cli

# ระบุ password ถ้ามี (ดูใน redis.conf)
docker exec -it vtrc-redis redis-cli -a <password>

ภายใน redis-cli:

127.0.0.1:6379> PING
PONG

127.0.0.1:6379> DBSIZE
(integer) 1234

เข้า Redis ของ cu-central-api ​

bash
docker exec -it cu-centralize-redis redis-cli

การดู key ทั้งหมด ​

ระวัง — KEYS * บน Redis ที่มี key เยอะจะ block ทุก operation — ใช้ SCAN แทน

bash
# ดู key ทั้งหมด (ใช้กับ key น้อย ๆ เท่านั้น)
KEYS *

# ดู key ทีละ batch (แนะนำ)
SCAN 0 COUNT 100

# ดู key ที่ตรง pattern (cu-central session)
SCAN 0 MATCH sess:* COUNT 100

การดู key เฉพาะเจาะจง ​

ดูค่าของ key ​

GET sess:<userUid>_<sessionId>

ดู type ของ key ​

TYPE sess:<userUid>_<sessionId>

ดู TTL ของ key ​

TTL sess:<userUid>_<sessionId>

คืนค่า:

  • ตัวเลข = วินาทีที่เหลือ
  • -1 = ไม่มี expiry
  • -2 = key ไม่มีอยู่

ดูข้อมูลทั้งหมดของ key ​

DEBUG OBJECT sess:<userUid>_<sessionId>

การจัดการ session (cu-central Redis) ​

cu-central-api เก็บ session ใน Redis ด้วย prefix sess (main-api/src/lib/redis.controller.js → SESSION: prefixGenerator('sess', '1d'))

รูปแบบ key: sess:{userUid}_{sessionId} (buildSessionPattern ใน main-api/src/lib/session/session.js)

ดู session ของ user ​

SCAN 0 MATCH sess:<userUid>_* COUNT 100

ลบ session ของ user หนึ่งคน ​

# แทนที่ userUid จริง
docker exec cu-centralize-redis redis-cli --scan --pattern 'sess:<userUid>_*' | xargs -I {} docker exec cu-centralize-redis redis-cli DEL {}

ลบ session ทั้งหมด (force logout ทุกคนฝั่ง cu-central) ​

bash
docker exec cu-centralize-redis redis-cli --scan --pattern 'sess:*' | xargs -I {} docker exec cu-centralize-redis redis-cli DEL {}

ระวัง — จะ logout ผู้ใช้ทุกคน รวม admin ที่กำลังใช้งาน (ฝั่ง session ของ cu-central)

หมายเหตุ: session หลักของ vtrc-api อยู่ตาราง MariaDB Sessions — ไม่ได้อยู่ใน vtrc Redis (ดู Volume 13.7)

การ flush (ล้างทั้ง database) ​

ใช้เฉพาะในกรณีฉุกเฉินจริง ๆ

bash
# ล้างเฉพาะ database index ปัจจุบัน (ปกติคือ 0)
docker exec vtrc-redis redis-cli FLUSHDB

# ล้างทุก database index
docker exec vtrc-redis redis-cli FLUSHALL

หลัง FLUSH ข้อมูลที่หาย:

  • vtrc-redis: cache ของ query — OTP ไม่กระทบ
  • cu-centralize-redis: session sess:* และ cache — ผู้ใช้ฝั่ง cu-central ต้อง login ใหม่

การ restart Redis ​

bash
docker restart vtrc-redis
# หรือ
docker restart cu-centralize-redis

ผลกระทบ:

  • ข้อมูลที่อยู่ใน memory หาย (ยกเว้นมี persistence)
  • Node service จะ reconnect อัตโนมัติ
  • OTP ใน MariaDB ยังอยู่ จนถึง expiredAt — restart Redis ไม่บังคับให้ขอ OTP ใหม่

การตรวจสอบสถานะ Redis ​

ดู info ทั่วไป ​

INFO

หัวข้อสำคัญ:

  • connected_clients — จำนวน connection
  • used_memory_human — memory ที่ใช้
  • total_commands_processed — จำนวนคำสั่งที่ประมวลผล
  • rejected_connections — ถ้า > 0 แสดงว่า Redis เต็ม

ดู memory ละเอียด ​

MEMORY STATS

ดู client ที่เชื่อมต่อ ​

CLIENT LIST

ดู slow log ​

SLOWLOG GET 10

แสดง 10 command ล่าสุดที่ช้ากว่า threshold (default 10ms)

การตั้งค่า persistence ​

ตรวจสอบ config ปัจจุบัน:

bash
docker exec vtrc-redis cat /usr/local/etc/redis/redis.conf | grep -E "^(save|appendonly)"

ถ้าไม่มี save directive, Redis จะไม่ persist ข้อมูล — ทุกอย่างหายเมื่อ restart

การตั้ง RDB snapshot:

save 900 1     # save ถ้ามีการเปลี่ยนแปลง 1 key ใน 15 นาที
save 300 10    # save ถ้ามีการเปลี่ยนแปลง 10 key ใน 5 นาที
save 60 10000  # save ถ้ามีการเปลี่ยนแปลง 10000 key ใน 1 นาที

การตั้ง AOF (append-only file):

appendonly yes
appendfsync everysec

การ monitor Redis แบบ live ​

bash
docker exec -it vtrc-redis redis-cli MONITOR

แสดงทุก command ที่เข้ามา — รบกวน performance ห้ามใช้นานใน production

การ backup Redis ​

ใช้ BGSAVE (snapshot) ​

bash
docker exec vtrc-redis redis-cli BGSAVE

# รอจนกว่าจะเสร็จ
docker exec vtrc-redis redis-cli LASTSAVE

ไฟล์ RDB จะอยู่ใน /data/dump.rdb ใน container — สอดคล้องกับ volume ./redis-db/data บน host

bash
# คัดลอกไฟล์ไปยังที่เก็บ backup
cp /home/dev/vtrc-api/redis-db/data/dump.rdb /backup/redis-$(date +%Y%m%d).rdb

ใช้ COPY บน host ​

bash
# หยุด Redis ชั่วคราว (จะกระทบ service)
docker-compose stop vtrc-redis-db

# คัดลอกไฟล์
cp -r /home/dev/vtrc-api/redis-db/data/ /backup/redis-$(date +%Y%m%d)/

# start Redis ใหม่
docker-compose start vtrc-redis-db

วิธีนี้จะกระทบ service — ใช้ BGSAVE ที่ไม่ต้องหยุดดีกว่า

การ restore Redis ​

bash
# หยุด Redis
docker-compose stop vtrc-redis-db

# คัดลอก backup ไปที่ data directory
cp /backup/redis-20250711.rdb /home/dev/vtrc-api/redis-db/data/dump.rdb

# start Redis
docker-compose start vtrc-redis-db

การ debug ปัญหา Redis ​

Redis ไม่ตอบ ​

อาการ: Connection refused ใน log ของ vtrc-api / cu-central-api

bash
# ตรวจสอบว่า Redis รัน
docker ps | grep redis

# ถ้าไม่รัน
docker-compose up -d vtrc-redis-db

# ทดสอบ
docker exec vtrc-redis redis-cli PING

Redis ช้า ​

อาการ: cache miss สูง / session lookup ช้า (cu-central) — ไม่ใช่สาเหตุหลักของ OTP ช้า (OTP อยู่ MariaDB + SMS gateway)

bash
# ดู slow log
docker exec vtrc-redis redis-cli SLOWLOG GET 10
docker exec cu-centralize-redis redis-cli SLOWLOG GET 10

# ดูจำนวน key — ถ้าเยอะมากอาจทำให้ช้า
docker exec vtrc-redis redis-cli DBSIZE

Memory เต็ม ​

อาการ: OOM command not allowed ใน log

bash
# ดู memory
docker exec vtrc-redis redis-cli INFO memory

# ดู key ที่ใช้ memory มากที่สุด
docker exec vtrc-redis redis-cli --bigkeys

แก้: ตั้ง maxmemory policy ใน redis.conf:

maxmemory 1gb
maxmemory-policy allkeys-lru

แนะนำ ​

  1. เปิด persistence — อย่างน้อย RDB snapshot ทุกชั่วโมง (สำคัญกับ cu-central session)
  2. ตั้ง maxmemory — ป้องกัน OOM
  3. ทำ backup ทุกวัน — และทดสอบ restore
  4. เพิ่ม Redis replica สำหรับ HA ของ cu-central session (ปัจจุบันเป็น single instance)
  5. **อย่าใช้ KEYS *** ใน production — ใช้ SCAN เสมอ
  6. จำกัดการเข้าถึง Redis port จากภายนอก host
  7. อย่าสับสน OTP กับ Redis — debug OTP ที่ตาราง MariaDB ของ cu-central และ SMS gateway