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

คิวงานคืออะไร?

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

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

ขาดความสม่ำเสมอคือจุดอ่อน

จะเกิดอะไรขึ้นหากเราส่งข้อความ แต่เราขัดข้องก่อนที่จะบันทึกว่าเราเพิ่งส่งข้อความนั้นไป

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

เราจะแก้ไขได้อย่างไร? เมื่อเขียนคำจำกัดความของงาน เราคิดหนักมากเกี่ยวกับความเท่าเทียมและพฤติกรรมลองใหม่

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

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

รั้วที่ดีสร้างเพื่อนบ้านที่ดี

จะเกิดอะไรขึ้นกับการประมวลผลข้อมูลของบริษัทตัวอย่าง Consolidated Widgets เมื่อฐานข้อมูลสำหรับ Global Gizmos ล่ม

ในสถานการณ์สมมตินี้ หากกลยุทธ์การจัดส่งอย่างน้อยที่สุดของเราเกิดขึ้น เราก็คาดหวังว่างานการประมวลผลข้อมูลทั้งหมดสำหรับ Global Gizmos จะลองซ้ำแล้วซ้ำอีกจนกว่าจะสำเร็จ วิธีนี้ยอดเยี่ยม เราจะไม่สูญเสียข้อมูลใด ๆ แม้ว่าฐานข้อมูลจะหยุดทำงาน อย่างไรก็ตาม สำหรับ Consolidated Widgets อาจไม่ดีนัก หากพนักงานพยายามซ้ำๆ อย่างต่อเนื่องและล้มเหลว พวกเขาอาจยุ่งเกินกว่าจะประมวลผลงานของ Consolidated Widgets ได้ทันท่วงที

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

การรอคอยเป็นสิ่งที่เจ็บปวด

จะเกิดอะไรขึ้นถ้า Consolidated Widgets และ Global Gizmos ส่งแคมเปญอีเมลถึงผู้ใช้ 50 ล้านคนในแต่ละช่วงเวลา 5 นาที ใครไปก่อน?

ระบบการจัดคิวงานแบบธรรมดาจะมีคิว "งาน" แบบธรรมดาที่ผู้ปฏิบัติงานดึงงานออกมา เมื่อคุณมีงานและประเภทงานที่หลากหลายแล้ว คุณอาจจะเปลี่ยนไปมีคิวหลายประเภท โดยแต่ละประเภทมีลำดับความสำคัญหรือประเภทของผู้ปฏิบัติงานที่ดึงออกมาจากคิวเหล่านั้น ในแง่นั้น เรามีคิวง่ายๆ มากมายสำหรับการประมวลผลข้อมูล การส่งข้อความ และงานบำรุงรักษาต่างๆ

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

ระบบการจัดคิวแบบไดนามิกของเราพยายามที่จะจัดการกับปรากฏการณ์ที่เรียกว่า job starvation ซึ่งงานที่พร้อมดำเนินการจะรอเป็นเวลานานก่อนที่จะดำเนินการ ซึ่งมักเกิดจากลำดับความสำคัญบางอย่าง ในคิว "การส่งข้อความ" แบบธรรมดา ลำดับความสำคัญคือเวลาที่งานเข้าสู่คิว หมายความว่างานที่เพิ่มไปยังส่วนท้ายของคิวขนาดใหญ่อาจสิ้นสุดการรอเป็นเวลานานมาก

เมื่อเราไปจัดคิวแคมเปญและข้อความทั้งหมด แทนที่จะเพิ่มงานในคิว "การส่งข้อความ" ขนาดใหญ่ เราสร้างคิวใหม่ทั้งหมดสำหรับแคมเปญนี้ พร้อมชื่อพิเศษเพื่อให้เรารู้ว่ามันคืออะไรและ วิธีการหามัน หลังจากเพิ่มงานลงในคิวแล้ว เราจะคว้ารายการ "ไดนามิกคิว" และเพิ่มชื่อคิวใหม่นี้ต่อท้าย

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

ดังนั้นจึงมีประโยชน์อื่นๆ เช่น อัตราการเข้าถึงแคชที่สูงขึ้นและการเชื่อมต่อฐานข้อมูลน้อยลง เนื่องจากการเพิ่มขึ้นของพื้นที่ทำงานสำหรับผู้ปฏิบัติงานเฉพาะ ชนะทุกคน!

มีแผนสำรองเสมอ

จะเกิดอะไรขึ้นเมื่อฐานข้อมูลหยุดทำงาน บางคิวถูกหยุดชั่วคราว และคิวงานเริ่มเต็ม

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

กลยุทธ์หนึ่งที่เราใช้คือการเข้าคิวบนอุปกรณ์เอง อุปกรณ์หลายล้านเครื่องมีแอปพลิเคชันที่แตกต่างกันโดยใช้ Braze SDK และในแอปพลิเคชันเหล่านั้น เราใช้คิวในการส่งข้อมูลไปยัง API ของเรา

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

เคลื่อนไหวเร็วและไม่ทำลายสิ่งของ

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

หากวิศวกรรมระบบประสิทธิภาพสูงและมีเวลาแฝงต่ำประเภทนี้ในพื้นที่การตลาดอัตโนมัติทำให้คุณตื่นเต้น คุณควรตรวจสอบกระดานงานของเราอย่างแน่นอน!