Việc chia sẻ thông tin đăng nhập giữa các yêu cầu API sẽ giúp cải thiện hiệu suất và tránh chi phí 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á hoạt độ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 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 tiến trình vừa đa luồng trong mỗi quy trình sẽ 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ạt động 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. Bạn cũng phải thực hiện làm mới mã truy cập một cách đồng bộ để tránh điều kiện tranh đấu.
Thư viện ứng dụng của chúng tôi đảm bảo rằng thông tin xác thực 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 xác thực mà thông tin này có thể sử dụng lại trong suốt vòng đời. Để chia sẻ thông tin xác thực giữa các luồng, bạn chỉ cần tạo từng 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ẻ singleton đó trên mọi phiên hoạt động.
Đa tiến trình hoặc được phân phối
Đối với các quy trình đa tiến trình hoặc được phân phối, bạn cần lưu giữ thông tin xác thực trước khi có thể chia sẻ. Để đảm bảo nhiều quy trình hoặc máy chủ không tìm cách làm mới thông tin đăng nhập cùng một lúc, dẫn đến tình trạng yêu cầu làm mới quá mức, bạn nên chỉ định làm mới cho một quy trình.
Ví dụ: một công việc hoặc dịch vụ riêng có thể chịu trách nhiệm làm mới thông tin xác thực định kỳ và chủ động đẩy thông tin đó đến một kho dữ liệu do 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 gửi yêu cầu API.
Làm mới việc làm
Công việc làm mới không được đợi cho đến khi thông tin xác thực hiện tại hết hạn rồi mới bắt đầu làm mới. Việc này có thể khiến ứng dụng bị treo 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 của mình lần gần đây nhất và buộc làm mới nếu còn chưa đầy 5 phút nữa là hết hạn.
Nếu không biết thời điểm mã truy cập được làm mới lần gần đây nhất, bạn có thể thử làm mới mã đó với giả sử mã đã hết hạn. Nếu mã truy cập chưa gần hết vòng, máy chủ sẽ trả về cùng một mã truy cập, cùng với thời gian còn lại của mã truy cập cho đến khi mã thông báo hết hạn.
Lưu trữ 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 đăng nhập giữa các máy chủ. Các giải pháp bao gồm máy chủ lưu vào bộ nhớ đệm, chẳng hạn như Memcached hoặc Infinispan hoặc kho dữ liệu NoSQL, chẳng hạn như MongoDB.
Kho dữ liệu nên được tối ưu hoá cho các thao tác đọc nhanh vì sẽ có nhiều yêu cầu đọc hơn so với ghi. Đồng thời, thông tin đăng nhập 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 (hiện tại + expires_in) và refresh_token cùng với access_token. expiry_time được tính bằng thời gian của 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 sẽ 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, thì bạn sẽ có 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 đăng nhập đã hết hạn, thì máy chủ phải làm mới thông tin xác thực của riêng mình để cho phép ứng dụng tiếp tục hoạt động với API cho đến khi vấn đề được giải quyết.
Quản lý thông tin xác thực cho nhiều tài khoản
Bạn có thể dùng thông tin xác thực đã tạo cho tài khoản người quản lý Google Ads để 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 người dùng có một hệ phân cấp tài khoản người quản lý duy nhất, 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 bên dưới.
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 các tài khoản khác nhau — chẳng hạn như cho mỗi tài khoản khách hàng Google Ads mà bạn truy cập hoặc mỗi 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 / được phân phối với một số điều chỉnh nhỏ. Khi sử dụng kho dữ liệu dùng chung, thông tin đăng nhập phải được lập chỉ mục theo giá trị nhận dạng tài khoản customerId để đảm bảo thông tin đăng nhập được liên kết với đúng tài khoản.
Ngoài ra, công việc làm mới cũng phải 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, thì 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.