การเปิดตัว Redis 7.0 อยู่ในระหว่างดำเนินการ และเราเพิ่งเผยแพร่ผู้สมัครรุ่นที่สอง ผู้สมัครรุ่นนี้เป็นเป้าหมายที่วางแผนไว้เพื่อให้คุณลักษณะของเวอร์ชันสมบูรณ์ แต่ยังเป็นโอกาสสำหรับเราในการนำเสนอเนื้อหาเพิ่มเติมในเวอร์ชันใหม่ ตัวอย่างเช่น ฟังก์ชัน Redis ได้พัฒนามาจากการรองรับสคริปต์ที่มีอยู่ซึ่ง Redis มีตั้งแต่เวอร์ชัน 2.6 ฟีเจอร์ของ Redis ก็มีการพัฒนามากขึ้นเช่นเดียวกัน
โดยธรรมชาติแล้ว วิวัฒนาการเกิดขึ้นได้จากการสุ่มและการคัดเลือกโดยธรรมชาติจะดูแลการแยกแยะผลลัพธ์ของมัน โดยทั่วไป ซอฟต์แวร์โดยทั่วไป และโดยเฉพาะกับ Redis กระบวนการนี้เกิดขึ้นย้อนหลัง:เราเลือกเส้นทางที่ต้องการและพัฒนาโครงการเพื่อให้เป็นไปตามนั้น แทนที่จะปล่อยให้การสุ่มมากำหนดอนาคต การวางแผนและการดำเนินการตามแผนงานของเราได้รับการชี้นำโดยหลักจากความคิดเห็นของผู้ใช้และกรณีการใช้งานใหม่ที่ Redis เหมาะสม
ใน Redis 7.0 รายการควบคุมการเข้าถึง (ACL) ได้ก้าวขึ้นบันไดวิวัฒนาการเช่นกัน เปิดตัวใน Redis 6.0 แล้ว ACL ได้ย้อนกลับมุมมองที่ยาวนานเกี่ยวกับความปลอดภัยว่าไม่อยู่ในขอบเขตของโปรเจ็กต์โดยเพิ่มกลไกในการจัดการผู้ใช้และการอนุญาตของพวกเขา อย่างไรก็ตาม ชุมชนของเราได้ให้ความรู้กับเราอย่างรวดเร็วว่าในขณะที่ดำเนินการไปในทิศทางที่ถูกต้อง แต่คุณลักษณะนี้ก็ยังขาดความสามารถที่จำเป็น
หนึ่งในช่องว่างใน ACL ได้รับการแก้ไขแล้วโดย Redis 6.2 นั่นคือการควบคุมรูปแบบที่อนุญาตของชื่อช่อง Pub/Sub แต่นั่นเป็นเพียงการหยุดช่องว่างบางส่วน และเราใช้เวลานานขึ้นกว่าจะคิดหาแนวทางที่ง่ายและมีประสิทธิภาพในการแก้ไขปัญหาที่เหลือ
การออกแบบดั้งเดิมของ ACL ได้จัดเตรียมไว้สำหรับกรณีการใช้งานการควบคุมสิทธิ์ขั้นพื้นฐานเท่านั้น เปิดใช้งานการอนุญาตหรือปฏิเสธการเข้าถึงเฉพาะชุดคำสั่ง คีย์ และรูปแบบชื่อช่องต่อผู้ใช้แต่ละราย ตัวอย่างเช่น เป็นไปไม่ได้ที่จะจำกัดคำสั่ง `SET` ไว้ที่ชุดย่อยของคีย์หนึ่งชุด และในขณะเดียวกันก็อนุญาตให้ `GET` เป็นชุดย่อยของคีย์อื่นสำหรับผู้ใช้ที่กำหนด อย่างมีประสิทธิภาพ ACL ไม่ใช่กลไกที่มีประสิทธิภาพสำหรับการนำนโยบายความปลอดภัยไปใช้
รายการควบคุมการเข้าถึงของ Redis 7.0 หรือเรียกสั้นๆ ว่า ACLv2 เข้ากันได้กับต้นฉบับ แต่เพิ่มการปรับปรุงที่สำคัญสองประการ ประการแรก ACLv2 เป็นข้อมูลเกี่ยวกับตัวเลือก ประการที่สอง ACLv2 อนุญาตให้ตั้งค่าการอนุญาตประเภทการเข้าถึงให้กับคีย์เฉพาะ ความสามารถนี้ทำให้ผู้ใช้สามารถจำกัดการดำเนินการแบบอ่านอย่างเดียว เขียนอย่างเดียว หรืออ่าน-เขียนได้เฉพาะกับชุดย่อยของคีย์เท่านั้น
การออกแบบ ACL ดั้งเดิมมีเพียงหนึ่งตัวเลือกต่อผู้ใช้ – ตัวเลือกเริ่มต้น ตัวเลือกอธิบายคีย์และช่องทางที่ผู้ใช้สามารถเข้าถึง หมวดหมู่ และคำสั่งได้ ACLv2 อนุญาตให้เพิ่มตัวเลือกจำนวนเท่าใดก็ได้ที่ด้านบนของค่าเริ่มต้นที่ใช้ตามลำดับ แนวทางนี้เป็นไปตามข้อกำหนดของนโยบายความปลอดภัยที่เข้มงวดมากขึ้น และทำให้ ACL เข้าใกล้ความสมบูรณ์ยิ่งขึ้น
ความสามารถในการคิดทบทวนของเซิร์ฟเวอร์เป็นอีกแง่มุมหนึ่งของ Redis ที่มีความก้าวหน้าอย่างมากในเวอร์ชัน 7.0 Redis เปิดเผย API ซึ่งเป็นพจนานุกรมของคำสั่งซึ่งโต้ตอบได้ เมื่อโปรเจ็กต์พัฒนาขึ้น จำนวนคำสั่งต่างๆ (และคำสั่งย่อยของคำสั่งเหล่านั้น) ก็เพิ่มขึ้น โดยมีจำนวนมากกว่า 380 คำสั่งในเวอร์ชัน 7.0 เนื่องจากทุกคำสั่ง Redis มีความเชี่ยวชาญเฉพาะสำหรับงานที่กำหนด การบันทึกอาร์กิวเมนต์และพฤติกรรมการเรียกใช้คำสั่งของแต่ละคำสั่งจึงเป็นหลักการสำคัญของโปรเจ็กต์ เอกสารนี้เป็นสัญญาฉบับเดียวระหว่างเซิร์ฟเวอร์และไคลเอ็นต์
ในอดีต คำสั่งต่างๆ ได้รับการบันทึกจากภายนอกไปยังโปรเจ็กต์ในที่เก็บโค้ดแยกต่างหาก เราเก็บเอกสารทั้งหมดในรูปแบบ (ส่วนใหญ่) ที่มนุษย์สามารถอ่านได้ เนื่องจากเอกสารนี้มีจุดประสงค์เพื่อให้คนอ่าน สิ่งนี้ทำให้เกิดความท้าทายสำหรับเครื่อง (หรือมากกว่าคนที่เขียนโปรแกรมเครื่อง) เนื่องจากการแปลร้อยแก้วเป็นโค้ดนั้นยุ่งเหยิงและเปราะบาง โดยเฉพาะอย่างยิ่ง ผู้เขียนลูกค้าของ Redis ทำได้เพียงหวังให้โครงการของพวกเขาเป็นปัจจุบันโดยการตรวจสอบการเปลี่ยนแปลงในเอกสารประกอบและอ่านบันทึกประจำรุ่น
ดังนั้น ในเวอร์ชัน 2.8 เราจึงตระหนักว่าเรายังต้องการวิธีการแบบเป็นโปรแกรมที่ช่วยให้เซิร์ฟเวอร์สามารถรายงานคำสั่งได้ คำสั่ง `COMMAND' ที่มีชื่อเหมาะสม (แต่ยังใช้ลิ้นลิ้น) แสดงรายการคำสั่งที่เซิร์ฟเวอร์สนับสนุนในรันไทม์ นอกจากนี้ คำสั่งย่อย `COMMAND GETKEYS` ช่วยให้ไคลเอนต์ส่งคำสั่งแบบคำต่อคำและอาร์กิวเมนต์เพื่อให้เซิร์ฟเวอร์แยกชื่อคีย์จากคำสั่งนั้น จำเป็นต้องแยกชื่อคีย์ออกจากคำสั่งเพื่อให้ไคลเอ็นต์สั่งการดำเนินการได้อย่างถูกต้องในการปรับใช้แบบคลัสเตอร์
ส่วนหนึ่งขับเคลื่อนโดยความพยายามที่เกี่ยวข้องกับ ACLv2 แต่ยังทำให้รายการคำสั่งรันไทม์มีประโยชน์มากขึ้นสำหรับไคลเอนต์ เวอร์ชัน 7.0 ยกเครื่องกลไกภายในส่วนใหญ่ของการจัดการคำสั่งของเซิร์ฟเวอร์ นอกจากนี้ เราได้ปรับปรุงข้อมูลเมตาที่เซิร์ฟเวอร์เก็บไว้เกี่ยวกับแต่ละคำสั่ง ทำให้สามารถสร้างไคลเอนต์ที่ซับซ้อนซึ่ง (แทบไม่) มีความรู้เกี่ยวกับความสามารถของเซิร์ฟเวอร์มาก่อน สุดท้าย ตารางคำสั่งที่ปรับปรุงใหม่ถูกสร้างขึ้นเพื่อให้โมดูล Redis สามารถขยายตารางคำสั่งที่เกี่ยวข้องได้ เพื่อให้มีการพิจารณาในระดับเดียวกับคำสั่งหลัก
ข้อมูลจำเพาะของคีย์คำสั่งใหม่ช่วยให้ไคลเอ็นต์แยกคีย์จากคำสั่งแบบคำต่อคำในเครื่องได้โดยไม่เกี่ยวข้องกับเซิร์ฟเวอร์ของคลัสเตอร์ ซึ่งจะช่วยปรับปรุงเวลาแฝงและลดแบนด์วิดท์ของเครือข่าย ข้อมูลเมตาเกี่ยวกับอาร์กิวเมนต์คำสั่งช่วยให้ลูกค้าค้นพบและปรับให้เข้ากับการเปลี่ยนแปลงในไวยากรณ์ของคำสั่งระหว่างเวอร์ชันของเซิร์ฟเวอร์ ลูกค้าสามารถรับข้อมูลเพิ่มเติมเกี่ยวกับการรันคำสั่งภายใต้สถานการณ์พิเศษและประเภทการใช้งานที่แตกต่างกันได้จากคำแนะนำคำสั่ง
ความพยายามนี้ยังรวมถึงการส่งเสริมคำสั่งย่อยให้กับพลเมืองชั้นหนึ่งของตารางคำสั่งของเซิร์ฟเวอร์ ในขั้นต้น คำสั่งย่อยได้รับการแนะนำให้รู้จักกับ Redis เพื่อต่อสู้กับคาร์ดินาลลิตี้ของ API ที่เพิ่มมากขึ้นเรื่อยๆ เหตุผลก็คือแทนที่จะเพิ่มคำสั่งใหม่สำหรับทุกงาน งานที่เกี่ยวข้องจะถูกเรียกใช้โดยการเรียกคำสั่ง “พาเรนต์” เพียงคำสั่งเดียว คำสั่ง "พาเรนต์" ยอมรับชื่อของคำสั่งย่อยเป็นอาร์กิวเมนต์แรกของอาร์กิวเมนต์ ซึ่งจะกำหนดการดำเนินการที่ดำเนินการ จากจุดยืนทางเทคนิค คำสั่งย่อยสืบทอดคุณลักษณะของคำสั่งพาเรนต์ทั้งหมด (เช่น หมวดหมู่ ACL แฟล็กการอ่าน/เขียน ข้อมูลจำเพาะของคีย์ และอื่นๆ) ทำให้ไม่สามารถรับความแตกต่างที่ละเอียดระหว่างพฤติกรรมที่แตกต่างกันได้
ตัวอย่างเช่น คำสั่ง `CLIENT' เป็นตะกร้าที่รับทั้งหมดสำหรับงานการจัดการการเชื่อมต่อที่มีคำสั่งย่อยไม่น้อยกว่า 15 คำสั่ง คำสั่งย่อยบางคำสั่ง เช่น `CLIENT SETNAME` ถูกเรียกใช้เป็นประจำโดยการเชื่อมต่อไคลเอ็นต์ปกติ ในขณะที่คำสั่งย่อยอื่นๆ เช่น `CLIENT KILL' มีศักยภาพในการใช้ในทางที่ผิด และดังนั้นจึงควรจำกัดให้ผู้ดูแลระบบใช้เพียงอย่างเดียว Redis เวอร์ชันก่อนหน้าขาดกลไกภายในที่สนับสนุนการสร้างความแตกต่างดังกล่าว ดังนั้นจึงนำนักพัฒนาไปที่เอกสารประกอบและทำให้เกิดความสับสน อย่างไรก็ตาม ใน Redis 7.0 ทุกคำสั่งย่อยมีชุดคุณลักษณะของตัวเอง โดยไม่คำนึงถึงพาเรนต์หรือพี่น้อง ซึ่งช่วยให้สามารถอธิบายได้อย่างแม่นยำ
โพสต์นี้กลายเป็นกำแพงข้อความที่อาจมีรายละเอียดทางเทคนิคมากเกินไปในตอนท้าย (หากมีรายละเอียดทางเทคนิคมากเกินไป) เราหวังว่ามันจะไม่น่าเบื่อทั้งหมด และเราได้ให้ความกระจ่างเกี่ยวกับเวอร์ชันใหม่และความเหมาะสมในโปรเจ็กต์ เรากำลังดำเนินการกับผู้สมัครรุ่นสุดท้ายเกี่ยวกับความพร้อมใช้งานทั่วไปของเวอร์ชันนี้ แต่โปรดคอยติดตามโพสต์ถัดไปในซีรีส์ที่จะทัวร์ชมเวอร์ชันใหม่ต่อไป
