All Products
Document Center

Basic Principles

Last Updated: Aug 17, 2020

Overview of the MetaServer, DataServer, and SessionServer

The responsibilities of the three roles are as follows:

  • SessionServer connects to the client.
  • DataServer is used to store data.
  • MetaServer manages the metadata of clusters.

The functions of the three roles are as follows:

  1. SessionServer is separated from the DataServer role to solve the bottlenecks in the connection quantity and storage.
  2. MetaServer is introduced to simplify maintenance. The diversity of roles leads to a status-based SOFARegistry. The metadata is managed by MetaServer, eliminating the need to introduce a third-party metadata management component.
  3. MetaServer can be aware of the status of the SessionServer and DataServer roles, freeing them from status awareness and simplifying the architecture.

Service registration process


  1. The client initiates the service registration data publisher to the SessionServer.
  2. After receiving the publisher data, the SessionServer first writes the data to the memory and then sends the data to the DataServer (The SessionServer will save all publisher data sent by the client to the memory for subsequent regular checks performed with the DataServer).
  3. After receiving the publisher data, the DataServer also writes the data to the memory (the DataServer will summarize all SessionServer data by the dimension of dataInfoId).
  4. Then, the DataServer needs to synchronize the data to the replicates because it stores multiple replicates (three by default) for each shard on the basis of sharding using the consistent hashing algorithm. At the same time, the SessionServer notifies all SessionServers of the data change event (the event content includes the ID and version number: <dataInfoId> and <version>). After receiving the change event notice, the SessionServer checks the version of dataInfoId stored in its memory and finds that the version is earlier than that sent by the DataServer. Then, the SessionServer obtains the dataInfoId data, namely the specific publisher list data, from the DataServer.
  5. The SessionServer pushes the dataInfoId data to the corresponding client. The client receives the latest Publisher list data after the service registration.

Service subscription process


  1. The client initiates a service subscription request subscriber to the SessionServer. The Subscriber request mainly carries dataInfoId, specifying the service data to which the client subscribes.
  2. After receiving the s request, the SessionServer first writes the request to the memory and then attempts to access the data corresponding to dataInfoId from the cache. If the corresponding data is unavailable, the SessionServer will initiate a request to the DataServer to synchronize the dataInfoId data. (The SessionServer will save all subscriber data sent by the client to the memory to push data changes.)
  3. The SessionServer sends the dataInfoId data (namely, the publisher list) to the client.