Việc chia sẻ thông tin đăng nhập trên các yêu cầu API sẽ 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 tốc độ. Hướng dẫn này giải thích cách tối ưu hoá việc 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 Google Ads API.
Chiến lược chia sẻ thông tin đăng nhập của bạn sẽ phụ thuộc vào việc ứng dụng của bạn có multithreaded hay đa quy trình (hoặc phân tán) hay không. Một ứng dụng vừa có nhiều quy trình vừa có nhiều 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 những 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 đăng nhập. Bạn cũng phải làm mới mã truy cập một cách đồng bộ để tránh tình trạng xung đột.
Thư viện máy khách 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, tự động làm mới đồng bộ khi mã truy cập hết hạn. Mỗi thư viện ứng dụng khách của chúng tôi đều có một đối tượng phiên (hoặc người dùng) có thông tin đăng nhập mà đối tượng đó sử dụng lại trong suốt vòng đời của mình. Để chia sẻ thông tin đăng nhập trên các luồng, bạn chỉ cần tạo từng phiên bằ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 tất cả các phiên.
Nhiều quy trình hoặc phân tán
Đối với các quy trình đa xử lý hoặc quy trình phân tán, bạn cần duy trì thông tin đăng nhập trước khi có thể chia sẻ thông tin đó. Để đảm bảo rằng nhiều quy trình hoặc máy chủ không cố gắng 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 quy trình 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 một kho dữ liệu được chia sẻ bởi một nhóm máy chủ. Sau đó, mỗi máy chủ có thể truy xuất thông tin đăng nhập từ kho dữ liệu khi đưa ra yêu cầu API.
Làm mới công việc
Tác vụ 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 rồi mới bắt đầu làm mới. Việc này có thể khiến ứng dụng bị dừng do thiếu thông tin đăng nhập hợp lệ; mặc dù vậy, 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à trả về kết quả.
Bạn nên theo dõi thời gian làm mới gần đây nhất của mã truy cập và buộc làm mới nếu còn ít hơn 5 phút nữa là hết hạn.
Nếu không biết lần gần đây nhất mã thông báo truy cập được làm mới là khi nào, bạn có thể thử làm mới mã thông báo đó giả sử mã thông báo đã hết hạn. Nếu mã truy cập sắp hết hạn, thì máy chủ sẽ trả về chính mã truy cập đó, cùng với số mili giây còn lại cho đến khi mã hết hạn.
Kho dữ liệu
Bạn có thể sử dụng một 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 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.
Kho dữ liệu phải đượ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 yêu cầu ghi. Ngoài ra, thông tin đăng nhập phải được lưu trữ một cách an toàn.
Khi lưu trữ thông tin đăng nhập, bạn nên lưu trữ expiry_time (hiện tại + expires_in) và refresh_token đã tính toán 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 đăng nhập mới nhất từ kho dữ liệu trước khi đưa ra yêu cầu. Miễn là tác vụ 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 đăng nhập 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 đăng nhập của chính 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 đăng nhập cho nhiều tài khoản
Bạn có thể dùng thông tin đăng nhập được tạo cho một tài khoản người quản lý Google Ads để truy cập vào tất 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ệ thống phân cấp tài khoản người quản lý duy nhất, thường thì việc tạo thông tin đăng nhập cho tài khoản người quản lý cấp cao nhất là đủ để sử dụng cho tất 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ì các 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 các hệ thống phân cấp độc lập mà bạn truy cập).
Bạn có thể làm theo các chiến lược tương tự cho ứng dụng multithreaded hoặc đa quy trình / phân tán với một số điểm sửa đổi nhỏ. Khi sử dụng một kho dữ liệu dùng chung, thông tin đăng nhập phải được lập chỉ mục theo mã 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, tác vụ làm mới 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, bạn có thể cần kích hoạt tác vụ 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 đăng nhập trên các luồng đang hoạt động trên tài khoản mà đối tượng thông tin đăng nhập được liên kết.