Hazelcast--Topic data type Chinese version

4.6 Topic

Overview:

Hazelcast provides a distributed mechanism for publishing messages to multiple consumers. The well-known publish/subscribe (pub/sub) message model.

Production and consumption operations are performed at the cluster level. In the topic, when a new member is added, you need to add a listener for it, which is actually a mechanism for registering messages for some members in the cluster.

NOTE: Publish operation is async. It does not wait for operations to run in remote nodes, it works as fire and forget.

Simple topic example

import com.hazelcast.core.Topic;
import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.MessageListener;

public class Sample implements MessageListener<MyEvent> {

  public static void main( String[] args ) {
    Sample sample = new Sample();
    HazelcastInstance hazelcastInstance = Hazelcast.newHazelcastInstance();
    ITopic topic = hazelcastInstance.getTopic( "default" );
    topic.addMessageListener( sample );
    topic.publish( new MyEvent() );
  }

  public void onMessage( Message<MyEvent> message ) {
    MyEvent myEvent = message.getMessageObject();
    System.out.println( "Message received = " + myEvent.toString() );
    if ( myEvent.isHeavyweight() ) {
      messageExecutor.execute( new Runnable() {
          public void run() {
            doHeavyweightStuff( myEvent );
          }
      } );
    }
  }

  // ...

  private final Executor messageExecutor = Executors.newSingleThreadExecutor();
}

4.6.2 Statistics

There are two kinds of statistical variables in Topic that can be accessed and queried. These values are maintained by local members, generally increasing.

HazelcastInstance hazelcastInstance = Hazelcast.newHazelcastInstance();
ITopic<Object> myTopic = hazelcastInstance.getTopic( "myTopicName" );

myTopic.getLocalTopicStats().getPublishOperationCount();
myTopic.getLocalTopicStats().getReceiveOperationCount();

getPublishOperationCount() The and getReceiveOperationCount ( ) methods will return the number of messages produced and the number of messages received since the node was started, respectively. Note that these values are not backed up and will be lost when the node is shut down.

Please refer to Topic Configuration .

NOTE: These statistics values can be also viewed in Management Center. Please see Topics.

4.6.3 Internals

Each node has a registration list of all nodes in the cluster. When a topic registers a new node, it will send a registration message to all members in the cluster. Similarly, when a new node joins the cluster, it It will receive the registration information of all nodes in this cluster until it is registered.

Configuring globalOrderEnabled can change the behavior of nodes in the topic.

If globalOrderEnabled is disabled:

Messages will be ordered, for example, if a consumer publishes a message, it will push a message to the order queue. Suppose cluster member M publishes many messages m1, m2, m3,...,mn to topic T, then Hazelcast will ensure that the information received by consumers in all topic T is also in the order of m1, m2, m3,...,mn.

This is how it works. Say we now have three nodes (node1, node2, node3), node1 and node2 are registered to a topic called news. Note that all three nodes will know that node1 and node2 are registered to the topic Oh in the news.

In this example node1 pushes two messages: a1 and a2. node3 pushes two messages: c1 and c2. When node1 and node3 publish a message, they check their respective local lists of registered nodes. They find that node1 and node2 is in this list. So, they send messages to these nodes in the list. Here is the sequence of messages they might receive:

Node1 -> c1, a1, a2, c2

Node2 -> c1, c2, a1, a2

If globalOrderEnabled is enabled:

When globalOrderEnabled is set to available, it will ensure that all nodes listening to the same topic receive messages in the same order.

Let's see what happens this time. Now we still have three nodes (node1, node2, node3), node1 and node2 are also registered in a topic named news. Note that all nodes know that node1 and node2 are registered to news middle.

In this example, node1 publishes news for two days: a1, a2. node3 publishes news for two days: c1, c2. When a node publishes news through topic news, it first calculates which partition the news id matches with. Next Send an operation to the owner of the partition, so the node publishes a message. We assume that news is consistent with the partition owned by node2. Next, node1

and node3 will send all messages to node2 first. Suppose the messages will be sent in the following order:

Node1 -> a1, c1, a2, c2

At this point, node2 will send these cautions to the various nodes in the locally stored node registration list. It will actually send these messages to node1 and node2 (it will set up an allocation mechanism for itself).

Node1 -> a1, c1, a2, c2

Node2 -> a1, c1, a2, c2

When using this method, it is guaranteed that all nodes receive message events in the same order.

In both cases, the EventService's StripedExecutor is used to distribute the received information. For all events in Hazelcast, the StripedExecutor is used to process them to keep them in order.

In, there are as much threads specified in the property(default is 5). For a specific event source (for topic, for a particular topic name),hash of that source's name % 5gives the ID of responsible thread. Note that, there can be another event source (entry listener of a map, item listener of a collection, etc.) corresponding to the same thread. In order not to make other messages to block, heavy process should not be done in this thread. If there is a time consuming work needs to be done, the work should be handed over to another thread. Please seeSample Topic Code. StripedExecutor hazelcast.event.thread.count

4.6.4 Topic Configuration Topic Configuration

Annotated configuration:

<hazelcast>
  ...
  <topic name="yourTopicName">
    <global-ordering-enabled>true</global-ordering-enabled>
    <statistics-enabled>true</statistics-enabled>
    <message-listeners>
      <message-listener>MessageListenerImpl</message-listener>
    </message-listeners>
  </topic>
  ...
</hazelcast>

Configure in the program:

TopicConfig topicConfig = new TopicConfig ();
topicConfig.setGlobalOrderingEnabled( true );
topicConfig.setStatisticsEnabled( true );
topicConfig.setName( "yourTopicName" );
MessageListener<String> implementation = new MessageListener<String>() {
  @Override
  public void onMessage( Message<String> message ) {
    // process the message
  }
};
topicConfig.addMessageListenerConfig( new ListenerConfig( implementation ) );
HazelcastInstance instance = Hazelcast.newHazelcastInstance()

Default value:

Global ordering is false, meaning there is no global order guarantee by default.
Statistics are true, meaning statistics are calculated by default.

Topic-related settings, but not topic-specific configuration variables:

hazelcast.event.queue.capacity: default value is 1,000,000
hazelcast.event.queue.timeout.millis: default value is 250
hazelcast.event.thread.count: default value is 5

RELATED INFORMATION

For description of these parameters, please see Global Event Configuration

Hazelcast--Topic data type Chinese version

Guess you like