If you want to achieve real-time updates: you need to use push. After A modifies his avatar, he notifies the server, and the server then sends a push notification to A's friends to update A's avatar.
The first thing to pull must be the avatar URL. The local cache is based on the URL. Every time the local cache pulls the avatar URL and then loads it through the loading module, it will judge whether the currently cached image is consistent with this URL. Otherwise, it will be inconsistent. Download through the new url.
Let’s speculate, the process in brackets is a wild guess: User A uploads a new avatar → the server processes the new avatar → stores the new avatar URL in a field in the user table, recording the change time (→ synchronizes the avatar to CDN → updates The avatar URL field of the user table records the change time) → the server sends a push to the online client → the client updates the avatar.
Take a guess, you can set a identification field, the default is 0, set it to 1 when the user updates the avatar, and push this identification at the same time when pushing messages or regular synchronization. While processing messages or regularly synchronizing contact information, the mobile phone determines this identifier. If the identifier is 1, it means that the friend has uploaded a new avatar. At this time, a GET request is made to pull the new avatar and cache it locally, and at the same time, the server-side identifier is updated. 0, to prevent repeated requests for avatars during the next synchronization. (PS: Just some personal thoughts.)
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
If you want to achieve real-time updates: you need to use push. After A modifies his avatar, he notifies the server, and the server then sends a push notification to A's friends to update A's avatar.
The first thing to pull must be the avatar URL. The local cache is based on the URL. Every time the local cache pulls the avatar URL and then loads it through the loading module, it will judge whether the currently cached image is consistent with this URL. Otherwise, it will be inconsistent. Download through the new url.
Save a field in the database: the last avatar modification time.
Let’s speculate, the process in brackets is a wild guess:
User A uploads a new avatar → the server processes the new avatar → stores the new avatar URL in a field in the user table, recording the change time (→ synchronizes the avatar to CDN → updates The avatar URL field of the user table records the change time) → the server sends a push to the online client → the client updates the avatar.
Take a guess, you can set a identification field, the default is 0, set it to 1 when the user updates the avatar, and push this identification at the same time when pushing messages or regular synchronization.
While processing messages or regularly synchronizing contact information, the mobile phone determines this identifier. If the identifier is 1, it means that the friend has uploaded a new avatar. At this time, a GET request is made to pull the new avatar and cache it locally, and at the same time, the server-side identifier is updated. 0, to prevent repeated requests for avatars during the next synchronization.
(PS: Just some personal thoughts.)