Việc chia sẻ thông tin xác thực giữa các yêu cầu API giúp cải thiện hiệu suất và tránh tình trạng hao tổn quá mức có thể dẫn đến lỗi giới hạn số lượng yêu cầu. Hướng dẫn này giải thích cách tối ưu hoá tính năng quản lý thông tin đăng nhập OAuth2 để ứng dụng của bạn có thể tương tác hiệu quả với API Google Ads.
Chiến lược chia sẻ thông tin xác thực của bạn sẽ phụ thuộc vào việc ứng dụng của bạn là đa luồng hay đa quy trình (hoặc được phân phối). Một ứng dụng vừa đa quy trình và đa luồng trong mỗi quy trình nên sử dụng cả hai chiến lược. Bạn cũng có thể điều chỉnh các chiến lược này cho nhiều tài khoản Google Ads.
Đa luồng
Mỗi phiên hoặc người dùng do một luồng vẽ phải sử dụng cùng một đối tượng thông tin xác thực. Việc làm mới mã truy cập cũng phải được thực hiện một cách đồng bộ để tránh tình trạng tương tranh.
Thư viện ứng dụng của chúng tôi đảm bảo rằng thông tin đăng nhập là một đối tượng an toàn cho luồng và tự làm mới đồng bộ khi mã truy cập hết hạn. Mỗi thư viện ứng dụng của chúng tôi có một đối tượng phiên (hoặc người dùng) có thông tin đăng nhập mà thư viện đó sử dụng lại trong suốt thời gian hoạt động. Để chia sẻ thông tin xác thực giữa các luồng, bạn chỉ cần tạo mỗi phiên bằng cách sử dụng cùng một thông tin đăng nhập. Ví dụ: trong thư viện ứng dụng Java, bạn sẽ tạo một singleton Credential và chia sẻ nó trên tất cả các phiên.
Đa quy trình hoặc được phân phối
Đối với các quy trình đa quy trình hoặc quy trình được phân phối, bạn cần duy trì thông tin đăng nhập trước khi có thể chia sẻ. Để đảm bảo rằng nhiều quy trình hoặc máy chủ không cố làm mới thông tin đăng nhập cùng một lúc, dẫn đến quá nhiều yêu cầu làm mới, bạn nên chỉ định việc làm mới cho một quy trình duy nhất.
Ví dụ: một công việc hoặc dịch vụ riêng biệt có thể chịu trách nhiệm làm mới thông tin đăng nhập định kỳ và chủ động đẩy thông tin đó vào kho dữ liệu mà một nhóm máy chủ dùng chung. Sau đó, mỗi máy chủ có thể truy xuất thông tin xác thực từ kho dữ liệu khi đưa ra yêu cầu API.
Làm mới công việc
Công việc làm mới không nên đợi cho đến khi thông tin đăng nhập hiện tại hết hạn trước khi bắt đầu làm mới. Làm như vậy có thể khiến ứng dụng ngừng hoạt động do thiếu thông tin đăng nhập hợp lệ. Tuy nhiên, nếu mã truy cập của thông tin đăng nhập hết hạn trong khi yêu cầu API đang được xử lý, thì yêu cầu vẫn sẽ hoàn tất và kết quả được trả về.
Bạn nên theo dõi thời điểm làm mới mã truy cập gần đây nhất và buộc làm mới nếu còn chưa đến 5 phút nữa là hết hạn.
Nếu không biết mã truy cập được làm mới lần gần đây nhất là khi nào, bạn có thể thử làm mới nếu mã đó đã hết hạn. Nếu mã truy cập chưa sắp được phân phối, thì máy chủ sẽ trả về cùng một mã truy cập, cùng với số mili giây còn lại cho đến khi mã thông báo hết hạn.
Kho dữ liệu
Bạn có thể tận dụng kho dữ liệu hiện có hoặc triển khai một kho dữ liệu dành riêng cho việc chia sẻ thông tin xác thực giữa các máy chủ. Các giải pháp bao gồm các máy chủ lưu vào bộ nhớ đệm, chẳng hạn như Memcached hoặc Infinispan hoặc các kho dữ liệu NoSQL, chẳng hạn như MongoDB.
Bạn nên tối ưu hoá kho dữ liệu cho các thao tác đọc nhanh vì sẽ có nhiều yêu cầu đọc hơn so với lượt ghi. Ngoài ra, thông tin xác thực phải được lưu trữ an toàn.
Khi lưu trữ thông tin xác thực, bạn nên lưu trữ expiry_time đã tính toán (hiện là + expires_in) và refresh_token cùng với access_token. expiry_time được tính bằng thời gian yêu cầu làm mới access_token cộng với thời gian expires_in.
Nhóm máy chủ
Mỗi máy chủ hoặc quy trình trong nhóm truy xuất thông tin xác thực mới nhất từ kho dữ liệu trước khi đưa ra yêu cầu. Miễn là công việc làm mới đang chạy đúng cách, thông tin đăng nhập sẽ hợp lệ. Tuy nhiên, nếu công việc làm mới hoặc kho dữ liệu không thành công, bạn nên có một cơ chế dự phòng.
Nếu một máy chủ hoặc quy trình không thể lấy thông tin xác thực từ kho dữ liệu hoặc nếu thông tin xác thực đã hết hạn, thì máy chủ phải làm mới thông tin đăng nhập của riêng mình để cho phép ứng dụng tiếp tục làm việc với API cho đến khi vấn đề được giải quyết.
Quản lý thông tin đăng nhập cho nhiều tài khoản
Thông tin đăng nhập được tạo cho tài khoản người quản lý Google Ads có thể dùng để truy cập vào tất cả các tài khoản con của tài khoản đó. Do đó, đối với những người dùng có một hệ phân cấp tài khoản người quản lý, thông thường, bạn chỉ cần tạo thông tin xác thực để tài khoản người quản lý cấp cao nhất được sử dụng cho tất cả các tài khoản Google Ads phụ thuộc.
Nếu ứng dụng của bạn cần truy cập vào các tài khoản Google Ads không liên quan đến nhau trong bất kỳ hệ thống phân cấp tài khoản người quản lý nào, thì bạn nên tạo và duy trì thông tin đăng nhập khác nhau cho nhiều tài khoản, chẳng hạn như cho từng tài khoản khách hàng Google Ads mà bạn truy cập hoặc từng tài khoản người quản lý cấp cao nhất trong hệ phân cấp độc lập mà bạn truy cập.
Bạn có thể áp dụng các chiến lược tương tự cho ứng dụng đa luồng hoặc đa quy trình / phân phối với một số sửa đổi nhỏ. Khi sử dụng kho dữ liệu dùng chung, thông tin xác thực phải được giá trị nhận dạng tài khoản customerId lập chỉ mục để đảm bảo thông tin xác thực được liên kết với đúng tài khoản.
Ngoài ra, công việc làm mới phải luôn làm mới tất cả thông tin đăng nhập. Nếu một tài khoản mới được liên kết, bạn có thể cần kích hoạt công việc làm mới.
Cuối cùng, trong các ứng dụng đa luồng, bạn chỉ nên chia sẻ đối tượng thông tin xác thực trên các luồng đang hoạt động trên tài khoản mà đối tượng thông tin xác thực được liên kết.