If inscribe

Read Apollo source code analysis – Some thoughts after Client polling configuration

This section describes how to synchronize the Config Service configuration on the Client

As shown in the figure, there are two ways to synchronize Client configuration

  1. Client Periodic polling.
  2. The Client initiates a long poll using Spring’s DeferredResult. If the Config Service listens for a new notification, it returns a new notification message. In this case, the Client immediately reads the configuration of the Namespace with the new notification.

From the second configuration synchronization method, the new notification does not contain the configuration information, so the Client needs to make another configuration synchronization request, so why not just return the updated configuration when the new notification is returned?

If the updated configuration is returned directly when a new notification is returned, we consider an extreme order of request and return,

  1. The Client initiates a long poll. The Config Service receives the long poll, listens for new notifications, and returns the poll to the Client.
  2. The Config Service receives the new configuration release and updates the configuration (for example, the Namespace that the Client listens to).
  3. The Client initiates scheduled polling. After receiving the polling request, the Config Service returns the configuration. After receiving the result, the Client updates the local configuration.
  4. When the Client terminal receives long polling returns the results of step 1 and update the local configuration according to the inside of the configuration, if these configurations include step 2 to update the configuration, the new configuration will be overwritten, and this configuration will again in the next polling or regularly launch long polling when listening to the change in the configuration has to return to the configuration update, So the configuration is out of date before it can be retrieved again.

Timed polling conflicts with push (long polling listener), which is why the updated result is not returned directly from the Client long polling result.

So how does Apollo deal with this conflict?

In addition to not returning the updated result directly from the Client’s long poll, but only returning the new message notification, and then the Client initiates a synchronization configuration request again, there is a key and clever processing,

Deal with regularly polling and long polling logic in the class of com. Ctrip. Framework. Apollo. Internals. RemoteConfigRepository, a Namespace correspond to a RemoteConfigRepository object, A thread pool, m_executorService, is defined

  private final static ScheduledExecutorService m_executorService;

  static {
    m_executorService = Executors.newScheduledThreadPool(1,
        ApolloThreadFactory.create("RemoteConfigRepository", true));
  }
Copy the code

The thread pool and is responsible for the configuration synchronization of timing polling and long polling thread has a new notice of mounting configuration synchronization thread, but because of the capacity of the thread pool is only 1, so both threads will not at the same time, must wait for synchronization results back to go to the next task execution, hence the above mentioned conflicts will happen, Each synchronization pulls the latest configuration of the Namespace.