0Pricing
AWS Solutions Architect · บทเรียน

Redis เทียบกับ Memcached: การเลือกกลไกที่เหมาะสม

เปรียบเทียบ Redis (การคงอยู่ของข้อมูล การจำลองข้อมูล ชุดข้อมูลเรียงลำดับ และการเผยแพร่/สมัครรับข้อมูล) กับ Memcached (ความเรียบง่ายและการทำงานหลายเธรด) แล้วเลือกตามข้อกำหนดของกรณีใช้งาน

Redis เทียบกับ Memcached: การเลือกกลไกที่เหมาะสม เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

Amazon ElastiCache คืออะไร

Amazon ElastiCache เป็นบริการแคชในหน่วยความจำที่มีการจัดการเต็มรูปแบบ ช่วยให้ปรับใช้ จัดการ และเพิ่มหรือลดขนาดคลังข้อมูลในหน่วยความจำแบบโอเพนซอร์สยอดนิยมบนคลาวด์ได้ง่าย บริการนี้รองรับสองเอนจิน ได้แก่ Redis และ Memcached ด้วยการให้บริการข้อมูลที่มีการเรียกใช้บ่อยจากหน่วยความจำแทนฐานข้อมูล ElastiCache จึงลดภาระของฐานข้อมูลได้หลายลำดับขนาด และลดเวลาแฝงของการตอบสนองจากระดับมิลลิวินาทีเหลือระดับไมโครวินาที การเลือกระหว่าง Redis กับ Memcached เป็นคำถามที่พบบ่อยในการสอบ SAA-C03

Memcached: ความเรียบง่ายอย่างแท้จริง

Memcached เป็นคลังข้อมูลคีย์-ค่าแบบกระจายและอยู่ในหน่วยความจำ ซึ่งเน้นความเรียบง่ายและการขยายขนาดในแนวนอน ลักษณะสำคัญ ได้แก่ การทำงานหลายเธรด (ใช้คอร์ CPU ทั้งหมดบนโหนดเดียวได้), การจัดเก็บคีย์-ค่าแบบง่าย (รองรับเฉพาะสตริง ไม่มีโครงสร้างข้อมูลที่ซับซ้อน), ไม่มีการคงอยู่ของข้อมูล (ข้อมูลจะสูญหายเมื่อโหนดเริ่มทำงานใหม่), ไม่มีการจำลองข้อมูล (ไม่มีโหนดสำรองหรือแบบจำลอง) และ การแบ่งส่วนในแนวนอน ผ่านการแฮชแบบสอดคล้องที่ฝั่งไคลเอ็นต์ Memcached เป็นตัวเลือกที่เหมาะสมเมื่อคุณต้องการแคชขนาดใหญ่ที่เรียบง่าย และไม่จำเป็นต้องมีการคงอยู่ของข้อมูล ชนิดข้อมูลที่ซับซ้อน หรือความพร้อมใช้งานสูง

# Create a Memcached cluster with 3 nodes
aws elasticache create-cache-cluster \
  --cache-cluster-id my-memcached \
  --engine memcached \
  --cache-node-type cache.r7g.large \
  --num-cache-nodes 3 \
  --cache-subnet-group-name my-subnet-group

# Memcached auto-discovers nodes via the config endpoint
# Application connects to: my-memcached.cfg.use1.cache.amazonaws.com:11211

Redis: คลังข้อมูลในหน่วยความจำที่มีความสามารถหลากหลาย

Redis (เซิร์ฟเวอร์พจนานุกรมระยะไกล) เป็นคลังโครงสร้างข้อมูลในหน่วยความจำที่มีความสามารถหลากหลายและทำงานแบบเธรดเดียว (ต่ออินสแตนซ์) รองรับสตริง แฮช รายการ เซต เซตเรียงลำดับ บิตแมป HyperLogLogs สตรีม และดัชนีเชิงภูมิศาสตร์ ข้อได้เปรียบสำคัญเหนือ Memcached ได้แก่ การคงอยู่ของข้อมูลแบบเลือกได้ (สแนปช็อต AOF และ RDB), การจำลองข้อมูล (แบบจำลองสำหรับอ่านและการสลับระบบอัตโนมัติ), การรับส่งข้อความแบบ Pub/Sub, การเขียนสคริปต์ Lua, ธุรกรรม (MULTI/EXEC) และ โหมดคลัสเตอร์ สำหรับการแบ่งส่วนในแนวนอน Redis เป็นตัวเลือกที่เหมาะสมสำหรับสถานการณ์การแคชในโลกจริงส่วนใหญ่

# Redis data structure examples

# String
# SET user:1:name 'Alice'
# GET user:1:name

# Hash (object-like)
# HSET product:42 name 'Widget' price '9.99' stock '100'
# HGETALL product:42

# Sorted set (leaderboard)
# ZADD leaderboard 9500 'alice' 8700 'bob' 9100 'carol'
# ZREVRANGE leaderboard 0 2 WITHSCORES

# Pub/Sub
# PUBLISH notifications 'order_shipped:12345'
# SUBSCRIBE notifications

การคงอยู่ของข้อมูลใน Redis: AOF และ RDB

Redis รองรับกลไกการคงอยู่ของข้อมูลสองแบบ ได้แก่ RDB (Redis Database) — สแนปช็อต ณ จุดเวลาหนึ่งที่บันทึกลงดิสก์เป็นระยะตามช่วงเวลาที่กำหนดค่าได้ (เริ่มทำงานใหม่ได้รวดเร็ว แต่อาจสูญเสียข้อมูลระหว่างสแนปช็อต) และ AOF (Append-Only File) — บันทึกการดำเนินการเขียนทุกครั้ง เมื่อเริ่มทำงานใหม่ Redis จะเล่นบันทึกดังกล่าวซ้ำเพื่อสร้างสถานะขึ้นใหม่ (เพิ่มความทนทานของข้อมูล แลกกับการใช้ไฟล์ขนาดใหญ่ขึ้นและการเริ่มทำงานใหม่ที่ช้าลง) ใน ElastiCache คุณสามารถเปิดใช้ AOF เพื่อคงข้อมูลไว้ข้ามการเริ่มทำงานใหม่ของโหนดได้ ซึ่งมีความสำคัญอย่างยิ่งเมื่อใช้ ElastiCache ไม่ใช่เพียงแคช แต่เป็นคลังข้อมูลหลัก เช่น สำหรับข้อมูลเซสชัน

# Create an ElastiCache Redis cluster with AOF enabled
aws elasticache create-replication-group \
  --replication-group-id my-redis \
  --replication-group-description 'Redis with persistence' \
  --cache-node-type cache.r7g.large \
  --engine redis \
  --num-cache-clusters 2 \
  --cache-parameter-group-name default.redis7 \
  --snapshot-retention-limit 5

# Note: Enable AOF via parameter group: appendonly=yes

การจำลองข้อมูลและการสลับระบบอัตโนมัติของ Redis

Redis รองรับ กลุ่มการจำลองข้อมูล ที่มีโหนดหลักหนึ่งโหนดสำหรับจัดการการเขียนทั้งหมด และมี แบบจำลองสำหรับอ่านได้สูงสุด 5 โหนดสำหรับจัดการการอ่าน เมื่อเปิดใช้ Multi-AZ และการสลับระบบอัตโนมัติ ElastiCache จะเลื่อนแบบจำลองสำหรับอ่านขึ้นเป็นโหนดหลักโดยอัตโนมัติเมื่อโหนดหลักขัดข้อง โดยทั่วไปการสลับระบบจะเสร็จสิ้นภายใน 60 วินาที ความสามารถนี้ทำให้แอปพลิเคชันที่ใช้ Redis มีความพร้อมใช้งานสูง ซึ่ง Memcached ไม่สามารถเทียบได้ (Memcached ไม่มีการจำลองข้อมูล) สำหรับแอปพลิเคชัน Production ที่ต้องการแคชแบบ HA ให้ใช้ Redis พร้อมการสลับระบบอัตโนมัติเสมอ

# Create a Redis replication group with Multi-AZ failover
aws elasticache create-replication-group \
  --replication-group-id prod-redis \
  --description 'Production Redis with HA' \
  --cache-node-type cache.r7g.xlarge \
  --engine redis \
  --multi-az-enabled \
  --automatic-failover-enabled \
  --num-cache-clusters 3 \
  --cache-subnet-group-name multi-az-subnet-group

# 1 primary + 2 replicas across 3 AZs

เซตเรียงลำดับของ Redis สำหรับ Leaderboard

เซตเรียงลำดับเป็นหนึ่งในโครงสร้างข้อมูลที่ทรงพลังที่สุดของ Redis สมาชิกแต่ละรายมีคะแนนแบบทศนิยมกำกับอยู่ และสมาชิกจะถูกจัดเรียงตามลำดับอยู่เสมอ จึงทำให้เซตเรียงลำดับเหมาะอย่างยิ่งสำหรับ Leaderboard (จัดอันดับตามคะแนน), คิวลำดับความสำคัญ (ประมวลผลงานที่มีลำดับความสำคัญสูงสุดก่อน) และ การจำกัดอัตรา (หน้าต่างแบบเลื่อนโดยใช้เวลาประทับเป็นคะแนน) การดำเนินการ ZADD, ZRANGE, ZREVRANGE, ZRANK และ ZRANGEBYSCORE ล้วนมีความซับซ้อน O(log n) จึงมีประสิทธิภาพสูงมากแม้มีรายการหลายล้านรายการ

# Leaderboard operations using Redis sorted sets

# Add/update scores
# ZADD game:leaderboard 10500 'player:alice'
# ZADD game:leaderboard 9800  'player:bob'
# ZADD game:leaderboard 11200 'player:carol'

# Get top 3 players (highest scores first)
# ZREVRANGE game:leaderboard 0 2 WITHSCORES
# Result: carol 11200, alice 10500, bob 9800

# Get a player's rank (0-indexed)
# ZREVRANK game:leaderboard 'player:alice'
# Result: 1 (second place)

Redis Pub/Sub สำหรับการรับส่งข้อความ

Redis Pub/Sub ช่วยให้ผู้เผยแพร่กระจายข้อความไปยังช่องต่าง ๆ ได้โดยไม่ต้องทราบว่าใครสมัครรับอยู่ ผู้สมัครรับจะได้รับข้อความทั้งหมดที่เผยแพร่ไปยังช่องที่ตนสมัครรับแบบเรียลไทม์ ข้อความ Pub/Sub จะไม่ถูกคงอยู่ หากผู้สมัครรับออฟไลน์ ก็จะพลาดข้อความนั้น หากต้องการการรับส่งข้อความแบบคงอยู่และรับประกันการส่ง ให้ใช้ Redis Streams (โครงสร้างข้อมูลที่มีความทนทานมากขึ้นและเพิ่มเข้ามาใน Redis 5) หรือบริการรับส่งข้อความที่ออกแบบมาโดยเฉพาะ เช่น SQS หรือ SNS สำหรับการสอบ SAA-C03 Redis Pub/Sub เป็นตัวเลือกสำหรับการแจ้งเตือนแบบเรียลไทม์ที่มีน้ำหนักเบาระหว่างบริการต่าง ๆ

# Publisher side (broadcasts to 'notifications' channel)
# PUBLISH notifications '{"type":"order_shipped","orderId":"12345"}'

# Subscriber side (listens for messages)
# SUBSCRIBE notifications

# Pattern subscribe (wildcard channel matching)
# PSUBSCRIBE order:*
# Receives messages from: order:created, order:shipped, order:delivered

# Note: Unlike SQS, pub/sub is fire-and-forget — no acknowledgement

Memcached เทียบกับ Redis: ตารางตัดสินใจ

ใช้กรอบแนวคิดนี้ในการเลือกคำตอบสำหรับการสอบ SAA-C03: เลือก Memcached เมื่อคุณต้องการแคชแบบง่ายที่ไม่ต้องการ HA ประสิทธิภาพแบบหลายเธรด และการขยายขนาดในแนวนอนด้วยการเพิ่มโหนด (แคชอย่างเดียว) เลือก Redis เมื่อคุณต้องการ การคงอยู่ของข้อมูล (คลังเซสชัน), การจำลองข้อมูลและการสลับระบบ (HA), ชนิดข้อมูลที่ซับซ้อน (เซตเรียงลำดับสำหรับ Leaderboard, เซต, รายการ), Pub/Sub, ธุรกรรม Lua หรือ Cluster Mode สำหรับการขยายขนาดในแนวนอนแบบหลายส่วน หากคำถามในการสอบกล่าวถึงความสามารถใดก็ตามที่นอกเหนือจากการแคชคีย์-ค่าแบบง่าย คำตอบมักจะเป็น Redis

ชนิดและตระกูลของโหนดแคช

ElastiCache มีตระกูลชนิดโหนดหลายแบบ ได้แก่ r7g (Graviton 3 ปรับให้เหมาะกับหน่วยความจำ — อัตราส่วนราคาและประสิทธิภาพดีที่สุด แนะนำสำหรับการแคชส่วนใหญ่), m7g (สมดุลระหว่างการประมวลผลและหน่วยความจำ) และ t4g (ประสิทธิภาพเพิ่มเป็นช่วง ๆ ค่าใช้จ่ายต่ำสำหรับ dev/test) ขนาดโหนดมีตั้งแต่ cache.t4g.micro (500 MB) ถึง cache.r7g.16xlarge (425 GB) สำหรับ Production ให้เลือกขนาดโหนดที่ทำให้ชุดข้อมูลอยู่ในหน่วยความจำได้ โดยเหลือพื้นที่สำรอง 20–25% หน่วยความจำไม่เพียงพอจะทำให้เกิดการขับข้อมูลออก (Memcached) หรือข้อผิดพลาด OOM (Redis)

# Get available cache node types
aws elasticache describe-cache-engine-versions \
  --engine redis \
  --query 'CacheEngineVersions[?contains(EngineVersion, '7')].{Engine:Engine,Version:EngineVersion}'

# Check memory and vCPU for a node type
aws elasticache describe-cache-engine-versions \
  --cache-parameter-group-family redis7

# Monitor evictions to detect memory pressure
# CloudWatch: Evictions metric > 0 means cache is full

ความปลอดภัยของ ElastiCache

ElastiCache ติดตั้งอยู่ภายใน VPC ของคุณ โดยมีกลุ่มความปลอดภัยควบคุมการเข้าถึง — ตามค่าเริ่มต้นจะไม่มีการเข้าถึงจากอินเทอร์เน็ตสาธารณะ สำหรับ Redis ให้เปิดใช้ โทเค็น AUTH (รหัสผ่านที่ไคลเอ็นต์ต้องระบุ) และ การเข้ารหัสระหว่างการส่งข้อมูล (TLS) สำหรับการเชื่อมต่อ รวมถึง การเข้ารหัสขณะจัดเก็บโดยใช้ KMS สำหรับ Memcached จะมีเฉพาะ TLS ระหว่างการส่งข้อมูลเท่านั้น (ไม่มีการเข้ารหัสขณะจัดเก็บหรือ AUTH) เมื่อต้องย้ายจาก Redis ที่ไม่ได้เข้ารหัสไปเป็นแบบเข้ารหัส จะไม่สามารถย้ายภายในระบบเดิมได้ คุณต้องสร้างคลัสเตอร์ใหม่ที่เข้ารหัสแล้วทำให้แคชอุ่นเครื่อง

# Create a Redis cluster with TLS and AUTH token
aws elasticache create-replication-group \
  --replication-group-id secure-redis \
  --description 'Encrypted Redis' \
  --cache-node-type cache.r7g.large \
  --engine redis \
  --transit-encryption-enabled \
  --at-rest-encryption-enabled \
  --auth-token 'MySecretPassword123!'

# Store the AUTH token in Secrets Manager, not in your app code

นโยบายการขับข้อมูลออก

เมื่อแคช Redis หรือ Memcached เต็ม นโยบายการขับข้อมูลออกจะกำหนดว่าจะลบคีย์ใดเพื่อให้มีพื้นที่ว่าง นโยบายการขับข้อมูลออกของ Redis ที่พบบ่อย ได้แก่ noeviction (ส่งคืนข้อผิดพลาด OOM — เหมาะเมื่อแคชเป็นคลังข้อมูลหลัก), allkeys-lru (ขับคีย์ที่ไม่ได้ใช้งานมานานที่สุดออกจากคีย์ทั้งหมด — เหมาะกับแคชทั่วไป), volatile-lru (ใช้ LRU กับคีย์ที่ตั้งค่า TTL — รักษาคีย์ที่ไม่มีวันหมดอายุไว้), allkeys-random (ขับข้อมูลออกแบบสุ่ม) และ allkeys-lfu (ขับคีย์ที่ถูกใช้งานน้อยที่สุดออก) สำหรับกรณีการแคชทั่วไป แนะนำให้ใช้ allkeys-lru หรือ allkeys-lfu

# Set eviction policy via parameter group
aws elasticache create-cache-parameter-group \
  --cache-parameter-group-name redis7-lru \
  --cache-parameter-group-family redis7 \
  --description 'LRU eviction policy'

aws elasticache modify-cache-parameter-group \
  --cache-parameter-group-name redis7-lru \
  --parameter-name-values ParameterName=maxmemory-policy,ParameterValue=allkeys-lru

# Apply the parameter group to your cluster:
aws elasticache modify-replication-group \
  --replication-group-id prod-redis \
  --cache-parameter-group-name redis7-lru

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิดของ AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า Memcached เรียบง่าย ทำงานหลายเธรด และไม่มี HA — เหมาะที่สุดสำหรับการขยายขนาดในแนวนอนของแคชแบบง่าย, Redis รองรับโครงสร้างข้อมูลที่ซับซ้อน การคงอยู่ของข้อมูล Pub/Sub และการสลับระบบแบบ Multi-AZ — เหมาะที่สุดสำหรับสถานการณ์การแคชใน Production ส่วนใหญ่ และ เซตเรียงลำดับทำให้ Redis เป็นตัวเลือกโดยธรรมชาติสำหรับ Leaderboard และคิวลำดับความสำคัญ บทถัดไปเราจะสำรวจกลุ่มการจำลองข้อมูลของ Redis และโหมดคลัสเตอร์สำหรับการแบ่งส่วนในแนวนอน

คำถามที่พบบ่อย

บทเรียน “Redis เทียบกับ Memcached: การเลือกกลไกที่เหมาะสม” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “Redis เทียบกับ Memcached: การเลือกกลไกที่เหมาะสม” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “Redis เทียบกับ Memcached: การเลือกกลไกที่เหมาะสม”

เปรียบเทียบ Redis (การคงอยู่ของข้อมูล การจำลองข้อมูล ชุดข้อมูลเรียงลำดับ และการเผยแพร่/สมัครรับข้อมูล) กับ Memcached (ความเรียบง่ายและการทำงานหลายเธรด) แล้วเลือกตามข้อกำหนดของกรณีใช้งาน คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “Redis เทียบกับ Memcached: การเลือกกลไกที่เหมาะสม” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม

ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. Redis เทียบกับ Memcached: การเลือกกลไกที่เหมาะสม
  2. กลุ่มการจำลองข้อมูล Redis ของ ElastiCache และโหมดคลัสเตอร์
  3. กลยุทธ์การแคช: การโหลดแบบขี้เกียจและการเขียนผ่าน
  4. การจัดเก็บเซสชันและรูปแบบกระดานผู้นำ
← กลับไปที่ AWS Solutions Architect