Linux Namespaces Cache Strategy Redis — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

Linux Namespaces กับ Redis คืออะไร — ทำความเข้าใจพื้นฐานก่อนลงมือ

Linux Namespaces คือกลไกการแยกส่วน (isolation) ที่อยู่ใน kernel ของ Linux โดยตรง มันทำให้กระบวนการหนึ่ง ๆ เห็นทรัพยากรของระบบเฉพาะของตัวเอง เช่น

network ของตัวเอง process ID ชุดของตัวเอง จุดเมานท์ไฟล์ของตัวเอง โดยไม่รบกวนกระบวนการอื่น ส่วน Redis คือฐานข้อมูลแบบคีย์-ค่าที่ทำงานในหน่วยความจำ ซึ่งนิยมใช้เป็นชั้นแคช (cache layer) ให้กับแอปพลิเคชันเพื่อลดภาระฐานข้อมูลหลักอย่าง PostgreSQL หรือ MySQL เมื่อเรานำสองอย่างนี้มาผสมกัน ก็คือการวางกลยุทธ์การแคชด้วย Redis ภายใน namespace ที่แยกขาดจากระบบหลัก ซึ่งเป็นแนวทางที่ Docker และ Kubernetes ใช้เป็นรากฐานมาตั้งแต่ต้น

จากประสบการณ์ผมที่ดูแลเซิร์ฟเวอร์ระบบเทรดดิ้งและระบบสัญญาณ Forex มากว่าสิบสามปี ประเด็นที่พบบ่อยที่สุดคือปัญหา Redis กินหน่วยความจำจนลากระบบอื่นพัง หรือ Redis ที่เปิดพอร์ตไว้โดนสแกนและเข้ายึดเครื่องเอาไปขุดคริปโต การแยก Redis เข้าไปอยู่ใน namespace เฉพาะช่วยแก้ทั้งสองปัญหานี้ได้ตั้งแต่ต้นทาง เพราะเราจำกัดทั้งมุมมองของกระบวนการและทรัพยากรที่มันเข้าถึงได้

Namespace หลัก ๆ ที่เกี่ยวข้องกับการวาง Redis มีอยู่ด้วยกันหกชนิด ได้แก่ PID namespace ที่แยกการมองเห็นกระบวนการ NET namespace ที่ให้ stack เครือข่ายเป็นของตัวเอง MNT namespace ที่แยกระบบไฟล์ UTS namespace ที่แยกชื่อโฮสต์ IPC namespace ที่แยกคิวการสื่อสารระหว่างกระบวนการ และ USER namespace ที่แมปผู้ใช้ใน namespace ให้เป็นผู้ใช้ไม่มีสิทธิ์พิเศษในเครื่องจริง การรวมชุด namespace เหล่านี้กับ cgroups ที่จำกัดซีพียูและหน่วยความจำ คือหัวใจของกลยุทธ์แคชที่แข็งแรงและปลอดภัยในปี 2026

เหตุผลแรกคือความปลอดภัย โดยค่าเริ่มต้น Redis ไม่มีการเข้ารหัสและฟังอยู่บนพอร์ต 6379 หากโคนฟิกผิดพลาดให้ฟังบนทุกอินเทอร์เฟซ

ผู้ไม่หวังดีสามารถเชื่อมต่อเข้ามาและใช้คำสั่งบางอย่างเพื่อเขียนไฟล์ลงเซิร์ฟเวอร์ได้ ผมเคยเห็นเซิร์ฟเวอร์ของเพื่อนที่รันระบบสัญญาณเทรดถูกแทรกสคริปต์ขุดคริปโตผ่านช่องทางนี้มาแล้ว เมื่อ Redis อยู่ใน NET namespace ของตัวเอง มันจะมองเห็นเฉพาะเครือข่ายภายในที่เรากำหนด ภายนอกแตะไม่ถึงเลย

เหตุผลแรกคือความปลอดภัย โดยค่าเริ่มต้น Redis ไม่มีการเข้ารหัสและฟังอยู่บนพอร์ต 6379 หากโคนฟิกผิดพลาดให้ฟังบนทุกอินเทอร์เฟซ ผู้ไม่หวังดีสามารถเชื่อมต่อเข้ามาและใช้คำสั่งบางอย่างเพื่อเขียนไฟล์ลงเซิร์ฟเวอร์ได้ ผมเคยเห็นเซิร์ฟเวอร์ของเพื่อนที่รันระบบสัญญาณเทรดถูกแทรกสคริปต์ขุดคริปโตผ่านช่องทางนี้มาแล้ว เมื่อ Redis อยู่ใน NET namespace ของตัวเอง มันจะมองเห็นเฉพาะเครือข่ายภายในที่เรากำหนด ภายนอกแตะไม่ถึงเลย

เหตุผลที่สองคือการจำกัดทรัพยากร ชั้นแคชมีนิสัยพองตัวตามข้อมูลที่ป้อนเข้าไป ถ้าปล่อยไว้ตัวใดตัวหนึ่งในเซิร์ฟเวอร์จะถูกแย่งหน่วยความจำจนระบบหลักล้ม ผมใช้หลักง่าย ๆ ว่าให้ Redis ได้จำกัดอยู่ที่ประมาณ 70 เปอร์เซ็นต์ของหน่วยความจำที่จัดสรรให้ เพราะการทำสแนปช็อต (snapshot) ไปยังดิสก์ต้องใช้หน่วยความจำเพิ่มอีกชั้นหนึ่ง การวางกรอบด้วย cgroups ภายใน namespace ทำให้ถึงแม้แคชจะเต็มก็แค่ตัวมันเองถูกบีบให้ลบคีย์เก่าตามนโยบาย แต่แอปพลิเคชันหลักและฐานข้อมูลยังหายใจได้ตามปกติ

เหตุผลที่สามคือการทำสภาพแวดล้อมทดสอบที่สะอาด เวลาเราอยากทดลองค่าคอนฟิกใหม่ เช่นเปลี่ยนนโยบายการลบคีย์จาก allkeys-lru เป็น volatile-ttl เราสามารถสร้าง namespace ใหม่รัน Redis เวอร์ชันทดลองบนพอร์ตเดียวกันได้เลยโดยไม่ชนกับตัวจริง เพราะ NET namespace แยกกันหมด นี่คือสิ่งที่ทำให้ทีมโอเพนซอร์สทั่วโลกหันมาใช้ namespace เป็นฐานของเทคโนโลยีคอนเทนเนอร์ทุกวันนี้

ตารางด้านล่างสรุปสิ่งที่แต่ละ namespace ให้ผลต่อการวาง Redis

Namespace	สิ่งที่แยก	ประโยชน์ต่อ Redis
PID	กระบวนการ	มองเห็นเฉพาะ Redis ตัวเอง ตรวจสอบง่าย
NET	เครือข่าย	ซ่อนพอร์ต 6379 จากภายนอก
MNT	ระบบไฟล์	แยกไฟล์ dump และ append-only ของตัวเอง
IPC	การสื่อสาร	ป้องกันความขัดแย้งหน่วยความจำร่วม
UTS	ชื่อโฮสต์	ระบุตัว Redis แต่ละตัวในเวลาเก็บบันทึก

หลายคนคิดว่าต้องติดตั้ง Docker ก่อนถึงจะใช้ namespace ได้ แต่จริง ๆ แล้วเราใช้เครื่องมือพื้นฐานของ Linux ล้วน ๆ ได้เลย เริ่มจากเซิร์ฟเวอร์ Ubuntu

22.04 ขึ้นไป ติดตั้ง Redis ปกติก่อนด้วยคำสั่งอัปเดตระบบแล้วติดตั้งแพ็กเกจ redis-server จากนั้นหยุดเซอร์วิสมาตรฐาน เพราะเราจะรันเองใน namespace

วิธีติดตั้งและรัน Redis ใน Namespace เอง — ทีละขั้นตอน

หลายคนคิดว่าต้องติดตั้ง Docker ก่อนถึงจะใช้ namespace ได้ แต่จริง ๆ แล้วเราใช้เครื่องมือพื้นฐานของ Linux ล้วน ๆ ได้เลย เริ่มจากเซิร์ฟเวอร์ Ubuntu 22.04 ขึ้นไป ติดตั้ง Redis ปกติก่อนด้วยคำสั่งอัปเดตระบบแล้วติดตั้งแพ็กเกจ redis-server จากนั้นหยุดเซอร์วิสมาตรฐาน เพราะเราจะรันเองใน namespace

วิธีที่ตรงไปตรงมาที่สุดคือใช้ยูทิลิตี้ unshare ซึ่งเป็นส่วนหนึ่งของแพ็กเกจ util-linux ที่มีมาให้พร้อมระบบ ตัวอย่างคำสั่งที่ผมใช้จริงบนเซิร์ฟเวอร์สัญญาณเทรดของผมคือ สร้าง namespace ชุดใหม่พร้อมทั้งเครือข่ายเสมือนด้วย unshare โดยระบุแฟล็ก pid, net, mount, ipc, uts และ fork จากนั้นเมานท์ระบบไฟล์เสมือน proc ใหม่ภายใน namespace เพื่อให้มองเห็นเฉพาะกระบวนการของตัวเอง แล้วค่อยสั่ง redis-server พร้อมไฟล์คอนฟิกเฉพาะ

การแยก Redis ลง namespace ทำให้เรากล้าตั้งค่าแบบเก็บประณีตขึ้น เพราะถ้าตัวนึงมีปัญหามันกระจายไม่ได้ กลยุทธ์ที่ผมใช้กับระบบเทรดดิ้งคือแบ่ง Redis

ออกเป็นสามตัวในสาม namespace ตัวแรกเก็บแคชข้อมูลราคาที่อัปเดตเร็ว ใช้นโยบาย allkeys-lru และจำกัดแรมไม่เกิน 512 เมกะไบต์ ตัวที่สองเก็บคิวข้อความและผลคำสั่งซื้อขาย ใช้การเก็บถาวรแบบ append-only ทุกวินาที เพราะข้อมูลพวกนี้หายไม่ได้ ตัวที่สามเก็บเซสชันผู้ใช้และระบบล็อกอิน ใช้นโยบาย volatile-ttl ให้คีย์หมดอายุเองตามเวลาที่กำหนด

ถ้าต้องการระดับผลิตภัณฑ์จริง ผมแนะนำให้ใช้ systemd-nspawn หรือ Docker แทนการทำมือ เพราะมันจัดการ namespace ทั้งหกชนิดรวมถึง cgroups ให้เอง โดยเฉพาะ Docker ที่ไฟล์ docker-compose ตัวเดียวก็ระบุจำกัดหน่วยความจำ นโยบาย allkeys-lru การเปิด append-only และการตรวจสุขภาพได้ครบ ผมเองใช้ Docker บนเครื่องทดลองและใช้ systemd-nspawn บนเซิร์ฟเวอร์ที่อยากให้เบาที่สุด ทั้งสองวิธีใช้กลไกเดียวกันใน kernel เพียงแต่ระดับความสะดวกต่างกัน

กลยุทธ์การแคชที่เหมาะกับระบบแยกส่วน — เลือกนโยบายให้ถูก

การแยก Redis ลง namespace ทำให้เรากล้าตั้งค่าแบบเก็บประณีตขึ้น เพราะถ้าตัวนึงมีปัญหามันกระจายไม่ได้ กลยุทธ์ที่ผมใช้กับระบบเทรดดิ้งคือแบ่ง Redis ออกเป็นสามตัวในสาม namespace ตัวแรกเก็บแคชข้อมูลราคาที่อัปเดตเร็ว ใช้นโยบาย allkeys-lru และจำกัดแรมไม่เกิน 512 เมกะไบต์ ตัวที่สองเก็บคิวข้อความและผลคำสั่งซื้อขาย ใช้การเก็บถาวรแบบ append-only ทุกวินาที เพราะข้อมูลพวกนี้หายไม่ได้ ตัวที่สามเก็บเซสชันผู้ใช้และระบบล็อกอิน ใช้นโยบาย volatile-ttl ให้คีย์หมดอายุเองตามเวลาที่กำหนด

ระบบแคชที่ดีต้องมีตา และตานั้นคือ Prometheus กับ Grafana ในสถาปัตยกรรมแบบ namespace เราเปิดตัวเก็บตัวชี้วัดภายใน Redis แล้วให้ Prometheus

มาดึงที่พอร์ตภายใน ซึ่งเข้าถึงได้เฉพาะจากเครือข่ายภายในเท่านั้น ตัวชี้วัดที่ผมเฝ้าจริงจังมีอยู่ห้าตัว ได้แก่ อัตราการเรียกใช้แคชสำเร็จซึ่งควรอยู่เหนือ 90 เปอร์เซ็นต์ หน่วยความจำที่ใช้เทียบกับ maxmemory จำนวนคีย์ที่ถูกไล่ออกต่อนาที จำนวนการเชื่อมต่อปัจจุบัน และอัตราการเรียกคำสั่งต่อวินาที ถ้าอัตราการไล่คีย์พุ่งสูงผิดปกติแปลว่าขนาดแคชไม่พอกับปริมาณข้อมูลจริง ต้องขยายลิมิตหรือกลั่นกรองข้อมูลที่ป้อนเข้า

อีกเรื่องที่สำคัญในปี 2026 คือการตั้ง maxmemory ให้สอดคล้องกับลิมิตของ cgroups ห้ามตั้ง maxmemory 1 กิกะไบต์ในขณะที่คอนเทนเนอร์ได้ลิมิตแค่ 1.2 กิกะไบต์ เพราะตอน Redis ทำการบันทึกสแนปช็อตมันจะแตกแฟร์กหน้าข้อมูลออกมาทำงานเพิ่ม ทำให้หน่วยความจำโตขึ้นเกือบเท่าตัวชั่วขณะ ถ้าโดน cgroups ตัดจะเจอปัญหาหยุดทำงานเฉียบพลัน สูตรที่ปลอดภัยคือ maxmemory ประมาณ 60 ถึง 70 เปอร์เซ็นต์ของลิมิตคอนเทนเนอร์ ผมเจอเคสพังเพราะเรื่องนี้มาหลายสิบครั้งแล้วจำขึ้นใจ

สุดท้ายคือเรื่อง pipeline และการจับกลุ่มคำสั่ง เมื่อแอปพลิเคชันกับ Redis อยู่ในเครือข่ายที่แยกกัน แม้ latency จะต่ำเพราะผ่าน veth ก็ยังดีที่รวมคำสั่งหลาย ๆ ตัวส่งพร้อมกันด้วย pipeline ลดการวิ่งไปกลับ ระบบสัญญาณของผมลดเวลาการตอบสนองจากแปดมิลลิวินาทีเหลือสองมิลลิวินาทีแค่เปลี่ยนวิธีเขียนโค้ดฝั่งลูกค้าเฉย ๆ ไม่ต้องอัปเกรดเครื่องเลย

การเฝ้าระวังและรักษาความปลอดภัยชั้นแคชใน Namespace

ระบบแคชที่ดีต้องมีตา และตานั้นคือ Prometheus กับ Grafana ในสถาปัตยกรรมแบบ namespace เราเปิดตัวเก็บตัวชี้วัดภายใน Redis แล้วให้ Prometheus มาดึงที่พอร์ตภายใน ซึ่งเข้าถึงได้เฉพาะจากเครือข่ายภายในเท่านั้น ตัวชี้วัดที่ผมเฝ้าจริงจังมีอยู่ห้าตัว ได้แก่ อัตราการเรียกใช้แคชสำเร็จซึ่งควรอยู่เหนือ 90 เปอร์เซ็นต์ หน่วยความจำที่ใช้เทียบกับ maxmemory จำนวนคีย์ที่ถูกไล่ออกต่อนาที จำนวนการเชื่อมต่อปัจจุบัน และอัตราการเรียกคำสั่งต่อวินาที ถ้าอัตราการไล่คีย์พุ่งสูงผิดปกติแปลว่าขนาดแคชไม่พอกับปริมาณข้อมูลจริง ต้องขยายลิมิตหรือกลั่นกรองข้อมูลที่ป้อนเข้า

ฝั่งความปลอดภัย นอกจากการซ่อนพอร์ตด้วย NET namespace แล้ว ยังต้องตั้งรหัสผ่านด้วย requirepass เสมอ และตั้ง rename-command เพื่อเปลี่ยนชื่อคำสั่งอันตรายอย่าง flushall และ config ให้เป็นชื่อที่ยาวเหยียดหรือปิดไปเลย การตั้งค่า bind ให้ผูกเฉพาะไอพีภายใน namespace ก็เป็นอีกชั้น แม้จะมี firewall แล้วก็ไม่เสียหายที่จะซ้อนกันไว้ หลักการเดียวกับการเทรดของผมครับ กันไว้หลายชั้นเพราะตลาดไม่เคยให้อภัย ระบบก็เหมือนกัน

การสำรองข้อมูลของ Redis ใน namespace ทำได้สองแนวทาง แนวแรกคือปล่อยให้ Redis เขียนไฟล์สแนปช็อตไปยังไดเรกทอรีที่เมานท์ผ่าน MNT namespace แล้วมีงานตามเวลาคัดลอกไฟล์นั้นไปยังที่เก็บภายนอกอย่าง S3 ทุกวัน แนวที่สองคือการตั้งอินสแตนซ์รอง (replica) ใน namespace อื่นที่เก็บข้อมูลจากตัวหลักแบบเรียลไทม์ หากตัวหลักพังก็โปรโมตตัวรองขึ้นมาทำงานแทน ตัวเลือกที่สองให้เวลากู้คืนสั้นกว่ามากแต่แลกมาด้วยหน่วยความจำเพิ่มอีกชุด ระบบของผมใช้ทั้งสองอย่างควบคู่กัน ตัวรองสำหรับต่อเนื่องการทำงานทันที สำรองรายวันสำหรับกรณีที่ลืมลบคีย์ด้วยมือแล้วข้อมูลพังทั้งชุด

เครื่องมือวินิจฉัยที่ต้องมีในมือ ได้แก่ redis-cli พร้อมคำสั่ง info memory และ info stats สำหรับดูสถานะภายใน slowlog get สำหรับดูคำสั่งที่ช้า htop ที่รันเข้าไปใน namespace ผ่าน nsenter เพื่อดูการใช้ซีพียูของกระบวนการเฉพาะตัว และ dmesg สำหรับตรวจว่ามีการสังหารกระบวนการเพราะหน่วยความจำเต็มหรือไม่ การรู้วิธีเข้าไปดูข้างใน namespace ด้วย nsenter นี่แหละที่แยกช่างที่เข้าใจระบบออกจากคนที่แค่พิมพ์ตามคู่มือ

ตัวอย่างการใช้งานจริง — เคสระบบสัญญาณและร้านค้าออนไลน์

ขอเล่าเคสจริงที่ผมทำเมื่อต้นปี 2026 ลูกค้าร้านค้าออนไลน์ขนาดกลางมีปัญหาเว็บโหลดช้าช่วงหลังเที่ยง เขาเข้าใจว่าเครื่องไม่แรงและอยากอัปเกรดเซิร์ฟเวอร์ซึ่งแพงขึ้นเป็นเท่าตัว พอผมเข้าไปดูพบว่า MySQL เองช้าเพราะโดนคิวรีค้นหาสินค้ายอดนิยมถามซ้ำ ๆ ทุกการโหลดหน้า ผมวาง Redis แยก namespace หนึ่งตัว แคชผลค้นหาห้านาทีด้วยการตั้งเวลาหมดอายุ และตั้ง allkeys-lfu ผลคือเวลาโหลดหน้าแรกจากสองวินาทีเหลือสองร้อยมิลลิวินาทีโดยไม่ซื้อเครื่องใหม่เลย เครื่องเดิมสบายขึ้นทั้งระบบเพราะฐานข้อมูลไม่ต้องทำงานหนัก

อีกเคสคือระบบส่งสัญญาณเทรดของผมเอง ตัวสแกนตลาดดึงราคาจากหลายโบรกเกอร์พร้อมกัน ถ้าดึงตรงเข้ากระบวนการหลักทุกครั้งจะเกิดการชนกันของคำขอ ผมแยก Redis เป็นชั้นกลางเก็บราคาล่าสุดด้วยโครงสร้างข้อมูลแบบเรียงลำดับเวลา แล้วให้กระบวนการวิเคราะห์ดึงจากแคชแทน กระบวนการเทรดเองจึงไม่เคยต้องรอเครือข่ายภายนอก ปัญหาสลิปเพจที่เคยเจอตอนตลาดผันผวนก็ลดลงชัดเจน นี่คือพลังของการแยกบทบาทระหว่างชั้นเก็บชั่วคราวกับชั้นตัดสินใจ

สำหรับคนที่อยากลองวันนี้ แผนลงมือแบบสี่สัปดาห์ของผมคือ สัปดาห์แรกลองรัน Redis ใน namespace ที่สร้างด้วย unshare บนเครื่องเสมือนในโน้ตบุ๊ก สัปดาห์ที่สองเขียนสคริปต์สร้าง veth และเมานท์ให้ครบอัตโนมัติ สัปดาห์ที่สามต่อ Prometheus และสร้างแดชบอร์ดดูอัตราแคชสำเร็จ สัปดาห์ที่สี่จึงทดลองใช้กับแอปจริงบนเครื่อง staging ทดสอบโหลดด้วยเครื่องมือทำแรงเทียมก่อนขึ้นระบบจริง ข้อควรระวังสุดท้ายคืออย่าลืมตั้งค่าการหมดอายุของคีย์ทุกตัวที่เป็นแคชปกติ เพราะแคชที่ไม่มีวันหมดอายุคือหลุมฝังศพของหน่วยความจำ กฎของผมคือถ้าคีย์ไหนไม่มีเหตุผลที่จะอยู่ถาวรก็ให้มันหมดอายุภายในยี่สิบสี่ชั่วโมง

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

Linux Namespaces คืออะไร และเกี่ยวข้องกับ Redis อย่างไร?

Linux Namespaces คือกลไกการแยกส่วน (isolation) ที่อยู่ใน kernel ของ Linux โดยตรง ทำให้กระบวนการหนึ่ง ๆ เห็นทรัพยากรของระบบเฉพาะของตัวเอง เช่น เครือข่าย, process ID, จุดเมานท์ไฟล์ โดยไม่รบกวนกระบวนการอื่น ส่วน Redis คือฐานข้อมูลแบบคีย์-ค่าที่ทำงานในหน่วยความจำ นิยมใช้เป็นชั้นแคชให้แอปพลิเคชันเพื่อลดภาระฐานข้อมูลหลักอย่าง PostgreSQL หรือ MySQL เมื่อนำสองอย่างมาผสมกัน ก็คือการวางกลยุทธ์การแคชด้วย Redis ภายใน namespace ที่แยกขาดจากระบบหลัก ซึ่งเป็นรากฐานของ Docker และ Kubernetes มาตั้งแต่ต้น Namespace ที่เกี่ยวข้องมีหกชนิด ได้แก่ PID, NET, MNT, UTS, IPC และ USER ซึ่งเมื่อรวมกับ cgroups ที่จำกัดซีพียูและหน่วยความจำ จะช่วยให้ชั้นแคชแข็งแรงและปลอดภัย

ทำไมต้องแยก Redis ด้วย Namespaces ให้เกิดประโยชน์อะไรบ้าง?

มีเหตุผลหลักสามข้อจากสนามจริง ข้อแรกคือความปลอดภัย เพราะโดยค่าเริ่มต้น Redis ไม่มีการเข้ารหัสและฟังอยู่บนพอร์ต 6379 หากคอนฟิกผิดพลาดให้ฟังบนทุกอินเทอร์เฟซ ผู้ไม่หวังดีสามารถเชื่อมต่อเข้ามาและใช้คำสั่งบางอย่างเขียนไฟล์ลงเซิร์ฟเวอร์ได้ เคยมีเคสถูกแทรกสคริปต์ขุดคริปโตผ่านช่องทางนี้ เมื่อ Redis อยู่ใน NET namespace ของตัวเองจะมองเห็นเฉพาะเครือข่ายภายในที่กำหนด ข้อสองคือการจำกัดทรัพยากรด้วย cgroups เพราะชั้นแคชมีนิสัยพองตัวตามข้อมูลที่ป้อนเข้าไป ถ้าปล่อยไว้อาจแย่งหน่วยความจำจนระบบหลักล้ม แนะนำให้ Redis ใช้ประมาณ 70 เปอร์เซ็นต์ของหน่วยความจำที่จัดสรร เพราะการทำสแนปช็อตยังต้องใช้หน่วยความจำเพิ่ม ข้อสามคือการทำสภาพแวดล้อมทดสอบที่สะอาด สามารถรัน Redis เวอร์ชันทดลองบนพอร์ตเดียวกันได้โดยไม่ชนกับตัวจริง

Namespace แบบไหนบ้างที่เกี่ยวข้องกับการวาง Redis และแต่ละตัวทำอะไร?

มีอยู่ด้วยกันหกชนิด ได้แก่ PID namespace ที่แยกการมองเห็นกระบวนการ ทำให้ Redis มองเห็นเฉพาะกระบวนการของตัวเองและตรวจสอบได้ง่าย NET namespace ที่ให้ stack เครือข่ายเป็นของตัวเอง ช่วยซ่อนพอร์ต 6379 จากภายนอก MNT namespace ที่แยกระบบไฟล์ ทำให้ไฟล์ dump และ append-only ของ Redis แยกเป็นของตัวเอง IPC namespace ที่แยกคิวการสื่อสารระหว่างกระบวนการ ป้องกันความขัดแย้งของหน่วยความจำร่วม UTS namespace ที่แยกชื่อโฮสต์ ช่วยให้ระบุตัว Redis แต่ละตัวได้ง่ายเวลาเก็บบันทึก และ USER namespace ที่แมปผู้ใช้ใน namespace ให้เป็นผู้ใช้ไม่มีสิทธิ์พิเศษในเครื่องจริง ทำให้ Redis รันด้วยสิทธิ์ต่ำแม้ดูเหมือนรูท การรวมชุด namespace เหล่านี้กับ cgroups คือหัวใจของกลยุทธ์แคชที่แข็งแรงและปลอดภัย

ต้องติดตั้ง Docker ก่อนถึงจะรัน Redis ใน Namespace ได้หรือไม่?

ไม่จำเป็นเลย หลายคนเข้าใจผิดว่าต้องติดตั้ง Docker ก่อนถึงจะใช้ namespace ได้ แต่ความจริงเราใช้เครื่องมือพื้นฐานของ Linux ล้วน ๆ ได้เลย โดยเริ่มจากเซิร์ฟเวอร์ Ubuntu 22.04 ขึ้นไป ติดตั้ง Redis ปกติด้วยคำสั่งอัปเดตระบบแล้วติดตั้งแพ็กเกจ redis-server จากนั้นหยุดเซอร์วิสมาตรฐาน เพราะเราจะรันเองใน namespace

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6