Generator work insider Analysis

The notification service consists of the components shown in. When the event provider collects events, it submits all these events to the generator at a time. This operation is managed as a transaction. Therefore, either all events are committed or all are not submitted. Every event in the defined ADF file will correspond to two tables (NS <event> eventbatches and NS <event> events) after the notification service instance is generated ), corresponding batch and single event records. The two fields startcollectiontime and endcollectiontime in the batch table correspond to the start time of a batch and the completion time of batch record insertion respectively.

The table corresponding to each scheduled subscription is named NS <subscriptionclassname> schedules. The execution time and interval of the subscription are recorded in this table. The table name corresponding to the event-driven subscription is NS <subscriptionclassname> subscriptions.

The generator internally maintains two clocks: system clock and range clock. The system clock corresponds to the real time, and the range clock divides the time into time periods based on the value specified by the quantumduration element in the ADF.

The relationship between the system clock and the range clock is shown in:

You can see that the range clock always lags behind the system clock at a range interval. If all the subscriptions can be processed within this interval, the range clock will sleep. It is not executed again until the next range starts.

So what operations have the generator completed during each interval?

First, it will be in the rule according to the start time and end time of the range (that is, in the SQL statement that generates the message) the corresponding event batch table in the referenced event table fills the event table within this range into a materialized view with the same name as the event table based on the value of endcollectiontime. This is why we didn't filter events when defining matching rules in the ADF. If the end time of a batch is exactly the end time of a range, the batch of this event matches in the next range. In all the rules we define, the accessed objects are actually materialized views created by generators. Therefore, this also brings problems when debugging rules, because these views can only be created through generation. The online document describes the stored procedures provided internally for debugging.

After selecting an event, the system checks which events are referenced in the event-driven subscription. Then, all the subscription information related to the corresponding event is selected and also materialized into a view.

Finally, select the subscription to be executed within the specified interval in the scheduled subscription. Because scheduled subscriptions and event classes are not associated. Therefore, the generator calculates whether any subscription that meets the conditions exists in the planned subscription table. Instead of event-driven subscription, you only select subscription information related to the event.

The preceding steps ensure that all events are sent to the subscriber in a timely manner, but the message sending sequence is not guaranteed (the real-time messaging depends on the execution interval of each component and network reasons ). To ensure that messages are sent in the order of events, you only need to configure <processeventsinorder> true </processeventsinorder> In the ADF.Range sequence and subrange SequenceBut this will affect the generator performance. Therefore, the default value of processeventsinorder is false. However, if the internal system load is too heavy, or there are too many events, or the Generator service is stopped, the range clock lags far behind the system clock. At this time, the generator will continue to run and will not sleep, trying to catch up with the system clock until it remains in sync with the system clock. For example:

This delay may cause some outdated messages to the subscriber. In the stock price subscription, if the Generator service is restarted one hour after it is stopped. At this time, the range clock continues to match events from the stop time to generate messages (so that all events can be sent to the subscriber ). The user may not care about the stock information one hour ago. In this case, to let the generator filter out these spam events, we need to specify how many events within the range that the generator matches. As specified in, only match events within 40 intervals and Match 10 scheduled subscriptions. If the range interval is set too small, the response speed of the message will be accelerated, but this also increases the burden on the machine where the Generator service is located. Setting too large will reduce the timeliness of messages. Therefore, this interval is reasonably set based on the event and subscribed data volume.

The notification service is also a Windows service, but it provides better scalability, scalability, security control, and rapid development model than our custom notification service. We no longer need to worry about how messages are sent, when to send messages, processing upon sending failure, and maintenance of historical data, you only need to write the corresponding T-SQL statement according to the message, subscription rules to execute these matching operations. After the generated message is obtained, you can expand the message sending method. By default, the message sending method is provided to files and emails. With the data, how can you show that you can play it freely.