ตามลำดับ, ครั้งเดียว, เร็ว

• Airbridge ทำการจับคู่เหตุการณ์แบบเรียลไทม์ เช่น การคลิกโฆษณา การติดตั้ง และการซื้อ ดังนั้นนอกจากการประมวลผลเหตุการณ์ให้รวดเร็วแล้ว การประมวลผลตามลำดับที่ต้องการและการป้องกันการสูญหายหรือการประมวลผลซ้ำก็เป็นสิ่งสำคัญด้วย
• เดิมทีระบบจะดึงข้อความจาก Kafka มาเป็นไมโครบॅตช์ แล้วประมวลผลตามลำดับแยกตามประเภทของเหตุการณ์
  • แม้จะควบคุมลำดับได้ง่าย แต่ระหว่างรอให้เหตุการณ์ก่อนหน้าถูกประมวลผล worker อื่น ๆ จะอยู่ในสถานะว่างงาน
  • เมื่อความเร็วในการประมวลผลของแต่ละ worker ต่างกันและเกิด hot partition พร้อมกัน ความเร็วในการประมวลผลจะตัน แม้จะเพิ่มจำนวนเซิร์ฟเวอร์ก็ตาม
• เพื่อแก้ปัญหานี้ จึงออกแบบ Project Differential ขึ้นมา
  • ยกเลิกไมโครบॅตช์ และให้ Consumer แยกตามประเภทเหตุการณ์อ่าน Kafka topic เดียวกันอย่างอิสระ
  • การรับประกันลำดับไม่ได้ทำในระดับทั้ง topic แต่ทำในระดับ partition และจัดให้เหตุการณ์ใน flow ของผู้ใช้คนเดียวกันที่ต้องคงลำดับสำคัญ เข้าไปอยู่ใน partition เดียวกันให้มากที่สุด
  • Consumer ที่ตามมาจะไม่สามารถแซงตำแหน่งการประมวลผลของ Consumer ก่อนหน้าได้ และจะเว้นระยะปลอดภัยโดยอิงจาก offset หรือ event time
  • ข้อความที่ Consumer ก่อนหน้าไม่ประมวลผลจะถูกส่งต่อให้ Consumer ถัดไปเพื่อนำกลับมาใช้ และเมื่อบัฟเฟอร์เต็มจะสลับไปใช้ Polling Mode ที่อ่านจาก Kafka โดยตรง
• ภายในระบบมี ConsumerSuite / PartitionedConsumerChain แยกตาม partition และ LimitedEventProcessor จะควบคุมไม่ให้ข้าม checkpoint ของ Consumer ก่อนหน้า
  • CommitManager จะจัดการให้ commit ไปยัง Kafka เฉพาะ offset แบบต่อเนื่องที่เสร็จสมบูรณ์จริง แม้อยู่ระหว่างการบัฟเฟอร์และประมวลผลแบบอะซิงก์ก็ตาม
• จากการทดสอบใช้งานจริง ยืนยันได้ว่าระบบทำงานโดยไม่มีการสูญหายหรือการประมวลผลซ้ำของเหตุการณ์ และมี ความเร็วในการประมวลผลดีขึ้นมากกว่า 10 เท่า เมื่อเทียบกับวิธีไมโครบॅตช์เดิม
• นี่เป็นกรณีตัวอย่างของการรักษาลำดับที่จำเป็นต่อธุรกิจจริงในแบบ best effort แทนการสร้างลำดับแบบ global ที่สมบูรณ์ เพื่อให้ได้ throughput ที่เพียงพอ
• ในอนาคตมีแผนพิจารณาการทำโครงสร้างให้เรียบง่ายขึ้น, adaptive flow control เพื่อรองรับสถานการณ์ที่ Spot Instance ถูกยุติการทำงาน, และการปรับสถาปัตยกรรมเพื่อลดความจำเป็นของการประมวลผลแบบลำดับลง