การแชร์ข้อมูลเข้าสู่ระบบในคำขอ API จะช่วยปรับปรุงประสิทธิภาพและหลีกเลี่ยง ค่าใช้จ่ายที่มากเกินไปซึ่งอาจทำให้เกิดข้อผิดพลาดเกี่ยวกับอัตราการจำกัด คู่มือนี้อธิบายวิธี เพิ่มประสิทธิภาพการจัดการข้อมูลเข้าสู่ระบบ OAuth2 เพื่อให้แอปของคุณโต้ตอบกับ Google Ads API ได้อย่างมีประสิทธิภาพ
กลยุทธ์การแชร์ข้อมูลเข้าสู่ระบบจะขึ้นอยู่กับว่าแอปของคุณเป็นแบบmultithreadedหรือหลายกระบวนการ (หรือแบบกระจาย) แอปที่ทั้งแบบหลายกระบวนการและแบบหลายเธรดภายในแต่ละกระบวนการควรใช้ทั้ง 2 กลยุทธ์ นอกจากนี้ยังปรับกลยุทธ์เหล่านี้ให้เหมาะกับบัญชี Google Ads หลายบัญชีได้ด้วย
แบบหลายเธรด
แต่ละเซสชันหรือผู้ใช้ที่ดึงมาโดยเธรดควรใช้ออบเจ็กต์ข้อมูลเข้าสู่ระบบเดียวกัน นอกจากนี้ การรีเฟรชโทเค็นเพื่อการเข้าถึงต้องดำเนินการแบบพร้อมกันเพื่อ หลีกเลี่ยงสภาวะแข่งขัน
ไลบรารีไคลเอ็นต์ของเราช่วยให้มั่นใจว่าข้อมูลเข้าสู่ระบบเป็นออบเจ็กต์ที่ปลอดภัยต่อการทำงานแบบหลายเธรด ซึ่งจะ
รีเฟรชตัวเองแบบซิงโครนัสเมื่อโทเค็นเพื่อการเข้าถึงหมดอายุ ไลบรารีไคลเอ็นต์แต่ละรายการมีออบเจ็กต์เซสชัน (หรือผู้ใช้) ที่มีข้อมูลเข้าสู่ระบบซึ่งจะนำกลับมาใช้ใหม่
ตลอดอายุการใช้งาน หากต้องการแชร์ข้อมูลเข้าสู่ระบบในหลายเธรด คุณเพียงแค่
สร้างแต่ละเซสชันโดยใช้ข้อมูลเข้าสู่ระบบเดียวกัน ตัวอย่างเช่น ในไลบรารีไคลเอ็นต์ Java
คุณจะสร้าง Credential
singleton และแชร์ใน
ทุกเซสชัน
แบบหลายกระบวนการหรือแบบกระจาย
สำหรับกระบวนการแบบหลายกระบวนการหรือแบบกระจาย คุณต้องบันทึกข้อมูลเข้าสู่ระบบ ก่อนจึงจะแชร์ได้ เพื่อให้มั่นใจว่ากระบวนการหรือเซิร์ฟเวอร์หลายรายการจะไม่พยายามรีเฟรชข้อมูลเข้าสู่ระบบพร้อมกัน ซึ่งจะส่งผลให้มีคำขอรีเฟรชมากเกินไป คุณควรมอบหมายการรีเฟรชให้กับกระบวนการเดียว
เช่น งานหรือบริการแยกต่างหากอาจมีหน้าที่ในการรีเฟรชข้อมูลเข้าสู่ระบบเป็นระยะๆ และพุชข้อมูลเข้าสู่ระบบไปยังที่เก็บข้อมูลที่ แชร์โดยกลุ่มเซิร์ฟเวอร์ จากนั้นแต่ละเซิร์ฟเวอร์จะดึงข้อมูลเข้าสู่ระบบจาก ที่เก็บข้อมูลเมื่อส่งคำขอ API
รีเฟรชงาน
งานรีเฟรชไม่ควรรอจนกว่าข้อมูลเข้าสู่ระบบปัจจุบันจะหมดอายุก่อน เริ่มการรีเฟรช การดำเนินการดังกล่าวอาจส่งผลให้แอปหยุดทำงานเนื่องจากไม่มี ข้อมูลเข้าสู่ระบบที่ถูกต้อง อย่างไรก็ตาม หากโทเค็นเพื่อการเข้าถึงของข้อมูลเข้าสู่ระบบหมดอายุขณะที่ระบบกำลังประมวลผลคำขอ API คำขอจะยังคงดำเนินการจนเสร็จสมบูรณ์และแสดงผลลัพธ์
เราขอแนะนำให้ติดตามเวลาที่รีเฟรชโทเค็นเพื่อการเข้าถึงครั้งล่าสุด และบังคับให้รีเฟรชหากเหลือเวลาไม่ถึง 5 นาทีก่อนที่โทเค็นจะหมดอายุ
หากไม่ทราบว่าโทเค็นเพื่อการเข้าถึงได้รับการรีเฟรชครั้งล่าสุดเมื่อใด คุณอาจลอง รีเฟรชโทเค็นโดยถือว่าโทเค็นหมดอายุแล้ว หากโทเค็นเพื่อการเข้าถึงยังไม่ใกล้หมดอายุ เซิร์ฟเวอร์จะส่งโทเค็นเพื่อการเข้าถึงเดิมพร้อมกับเวลาที่เหลือเป็นมิลลิวินาทีก่อนที่โทเค็นจะหมดอายุ
ที่เก็บข้อมูล
คุณสามารถใช้ที่เก็บข้อมูลที่มีอยู่หรือติดตั้งใช้งานที่เก็บข้อมูลที่เฉพาะเจาะจงสำหรับการแชร์ ข้อมูลเข้าสู่ระบบระหว่างเซิร์ฟเวอร์ได้ โซลูชันรวมถึงเซิร์ฟเวอร์แคช เช่น Memcached หรือ Infinispan หรือ ที่เก็บข้อมูล NoSQL เช่น MongoDB
ควรเพิ่มประสิทธิภาพที่เก็บข้อมูลสำหรับการดำเนินการอ่านที่รวดเร็ว เนื่องจากจะมีคำขออ่านมากกว่าคำขอเขียน และต้องจัดเก็บ ข้อมูลเข้าสู่ระบบอย่างปลอดภัย
เมื่อจัดเก็บข้อมูลเข้าสู่ระบบ คุณควรจัดเก็บ expiry_time
ที่คำนวณแล้ว
(ตอนนี้ + expires_in
) และ refresh_token
ไว้ข้าง access_token
expiry_time
คำนวณจากเวลาของคำขอรีเฟรช access_token
บวกเวลา expires_in
พูลเซิร์ฟเวอร์
เซิร์ฟเวอร์หรือกระบวนการแต่ละรายการในพูลจะดึงข้อมูลเข้าสู่ระบบล่าสุดจาก ที่เก็บข้อมูลก่อนที่จะส่งคำขอ ตราบใดที่งานรีเฟรชทำงานอย่างถูกต้อง ข้อมูลเข้าสู่ระบบก็จะยังคงใช้งานได้ อย่างไรก็ตาม หากงานรีเฟรชหรือ ที่เก็บข้อมูลล้มเหลว คุณควรมีกลไกการทำงานสำรอง
หากเซิร์ฟเวอร์หรือกระบวนการไม่ได้รับข้อมูลเข้าสู่ระบบจากที่เก็บข้อมูล หรือหากข้อมูลเข้าสู่ระบบหมดอายุ เซิร์ฟเวอร์ควรอัปเดตข้อมูลเข้าสู่ระบบของตัวเองเพื่อให้แอปทำงานกับ API ต่อไปได้จนกว่าจะแก้ไขปัญหาได้
การจัดการข้อมูลเข้าสู่ระบบสำหรับหลายบัญชี
คุณใช้ข้อมูลเข้าสู่ระบบที่สร้างขึ้นสำหรับบัญชีดูแลจัดการ Google Ads เพื่อเข้าถึงบัญชีย่อยทั้งหมดได้ ดังนั้น สำหรับผู้ใช้ที่มีลำดับชั้นบัญชีดูแลจัดการเดียว โดยปกติแล้ว การสร้างข้อมูลเข้าสู่ระบบสำหรับบัญชีดูแลจัดการระดับบนสุด เพื่อใช้กับบัญชี Google Ads ทั้งหมดที่อยู่ภายใต้บัญชีดูแลจัดการนั้นก็เพียงพอแล้ว
หากแอปของคุณต้องเข้าถึงบัญชี Google Ads ที่ไม่เกี่ยวข้องกับบัญชีอื่นๆ ในลําดับชั้นของบัญชีดูแลจัดการ คุณควรสร้างและดูแลรักษาข้อมูลเข้าสู่ระบบที่แตกต่างกัน สําหรับบัญชีต่างๆ เช่น สําหรับบัญชีลูกค้า Google Ads แต่ละบัญชีที่คุณเข้าถึง หรือบัญชีดูแลจัดการระดับบนสุดแต่ละบัญชีในลําดับชั้นอิสระที่คุณเข้าถึง
คุณสามารถใช้กลยุทธ์เดียวกันนี้กับแอปแบบmultithreadedหรือหลายกระบวนการ / แบบกระจายได้โดยมีการปรับเปลี่ยนเล็กน้อย เมื่อ
ใช้ที่เก็บข้อมูลที่แชร์ ระบบจะต้องจัดทำดัชนีข้อมูลเข้าสู่ระบบตามตัวระบุบัญชี
customerId
เพื่อให้แน่ใจว่าข้อมูลเข้าสู่ระบบเชื่อมโยงกับบัญชีที่ถูกต้อง
นอกจากนี้ งานรีเฟรชควรทำให้ข้อมูลเข้าสู่ระบบทั้งหมดรีเฟรชอยู่เสมอ หากลิงก์บัญชีใหม่ คุณอาจต้องทริกเกอร์งานรีเฟรช
สุดท้ายนี้ ในแอปแบบมัลติเธรด คุณควรแชร์ออบเจ็กต์ข้อมูลเข้าสู่ระบบ ในเธรดที่ทำงานในบัญชีซึ่งเชื่อมโยงกับออบเจ็กต์ข้อมูลเข้าสู่ระบบ เท่านั้น