การทำงานร่วมกันของโค้ดแบบเรียลไทม์ขับเคลื่อนโดย Upstash Redis

บทนำ

คุณเคยสงสัยหรือไม่ว่าแพลตฟอร์มอย่าง Codeshare ถูกสร้างขึ้นมาอย่างไร? คุณเคยพยายามที่จะรับมือกับความท้าทายในการปรับขนาดบริการเช่นนั้นโดยยังคงรักษาประสบการณ์นักพัฒนาที่ดีสำหรับตัวคุณเองหรือไม่ เมื่อฉันตัดสินใจสร้าง Bytecrowds ฉันต้องเรียนรู้วิธีทำทั้งหมดนี้ จากการค้นคว้าอย่างเข้มงวดตามด้วยการตัดสินใจใช้ Yjs สำหรับความสามารถในการแบ่งปันข้อความ ถึงเวลาที่ต้องเลือกฐานข้อมูล เนื่องจากมีตัวเลือกมากมายในตลาด ฉันจึงจำกัดรายการให้แคบลงโดยใช้คำหลักที่สำคัญเพียงคำเดียว:ความเรียบง่าย

ทำไมต้องอัพสเตช?

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

ข้อเสนอ Upstash Redis ตรงกับเกณฑ์สำคัญของฉัน 3 ข้อ:ใช้งานง่าย , ปรับขนาดได้ง่าย และ ยืดหยุ่น . รวมเข้ากับเวลาแฝงที่ต่ำ REST sdk แบบสำเร็จรูปเพื่อใช้ในไคลเอนต์แบบไร้เซิร์ฟเวอร์ (ข้อกำหนด สำหรับ Bytecrowds ด้วยเช่นกัน) การจำลองแบบทั่วโลก และแผนการจ่ายตามการใช้งานจริงสำหรับพลังการประมวลผล และอื่นๆ อีกมากมาย แล้วคุณจะเข้าใจว่าทำไมฉันถึงเลือกสิ่งนี้สำหรับโครงการของฉัน

การใช้ Redis® ทั่วทั้งแอป

มาดูกันว่า Redis® สามารถใช้เป็นฐานข้อมูลหลักของโปรเจ็กต์ได้อย่างไร เพื่อตอบสนองความต้องการของบริการต่างๆ ได้อย่างไร เพื่อให้เข้าใจบริบท นี่คือแผนภาพโฟลว์ของ Bytecrowds:

ใช้ Ably เพื่อซิงค์ข้อความระหว่างไคลเอนต์และกลไกการวิเคราะห์แบบกำหนดเองที่รวบรวมข้อมูลตามที่อยู่ IP ของคำขอ

ที่เก็บข้อมูลหลัก

bytecrowd อยู่ในรูปแบบของแฮช Redis® ที่มีคุณสมบัติดังต่อไปนี้:

{
 text: string,
 language: string,
 authorizedEmails: undefined || string array
}

เราอัปเดตแฮชเมื่อคุณสมบัติอย่างใดอย่างหนึ่งเปลี่ยนแปลง โดยมีความล่าช้า "x" วินาทีระหว่างการอัปเดต ในการผลิต ขณะนี้ตั้งค่าไว้ที่ 100 มิลลิวินาที

การรับรองความถูกต้องและการอนุญาต

การรับรองความถูกต้อง

เนื่องจาก Bytecrowds ใช้ Next.js ตัวเลือกที่ดีสำหรับการรวม GitHub OAuth ก็คือ Auth.js โชคดีที่เรายังใช้ประโยชน์จากอะแดปเตอร์ Upstash เพื่อจัดเก็บเซสชันได้ ทำให้เราสามารถใช้ Redis® ได้ทั่วทั้งแอปของเรา

การอนุญาต

Bytecrowds จัดการการอนุญาตโดยการสร้าง 06 ตามความต้องการ ฟิลด์ที่ไม่เปลี่ยนรูปจาก API เมื่อตั้งค่าแล้ว สิ่งหนึ่งที่ฉันชอบเกี่ยวกับ Redis® คือฟังก์ชันมากมายที่พร้อมใช้งานทันทีสำหรับการทำงานตามปกติที่ได้รับการออกแบบตามอัลกอริทึมเพื่อให้มีประสิทธิภาพเช่นกัน เพื่อยกตัวอย่าง สิ่งที่เราต้องทำเพื่อตรวจสอบว่า 14 หรือไม่ ได้ถูกตั้งค่าไว้แล้วให้ใช้คำสั่ง HEXISTS ซึ่งมีความซับซ้อน O(1)

การวิเคราะห์

Bytecrowds ใช้ระบบการวิเคราะห์ที่จัดการข้อมูลสองประเภท:

• สถิติของวัน ซึ่งอยู่ในรูปแบบของแฮช Redis® ซึ่งมีชื่อว่า 23 ด้วยคุณสมบัติดังต่อไปนี้:

{
 countries: string array,
 hits: integer,
 pages: string array,
 uniqueVisitors: integer,
 addresses: string array,
 continents: string array
}

โดยที่ 35 คืออาร์เรย์ของที่อยู่ IP ที่เข้ารหัส SHA256 ซึ่งใช้ในการระบุจำนวนเฉพาะของผู้เยี่ยมชมเว็บไซต์

• 3 คีย์ชื่อ 47 , 54 และ 64 สำหรับชุดที่เรียงลำดับของ Redis® ที่ใช้ในการจัดเก็บข้อมูลด้วยการจัดเก็บทุกสถิติพร้อมกับการนับ ("คะแนน" สำหรับชุดที่เรียงลำดับ) เราสามารถสืบค้นหรือเรียงลำดับได้อย่างง่ายดายโดยใช้คำสั่งเช่น SORT หรือ SORT_RO ความเรียบง่ายของ Redis แสดงให้เห็นอีกครั้ง