You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The same SQL database instance is required for all the producers and consumers to collaborate.
45
53
Therefore ensure all of the service instances point to the same database cluster.
46
54
47
-
- Single table is used to store all the exchanged messages (by default table is called `Messages`).
48
-
- Producers send messages to the messages table.
49
-
- There are two types of entities (queues, and topics for pub/sub).
50
-
- In the case of a topic:
51
-
- Each subscription gets a copy of the message.
52
-
- Subscription has a lifetime, and can expire after certain idle time. Along with it, all the messages placed on the subscription.
53
-
- Consumers (queue consumers, or subscribers in pub/sub) long poll the table to pick up their respective message.
54
-
- Queue consumers compete for the message, and ensure only one consumer instance is processing the message.
55
-
- Topic subscribers complete for the message within the same subscription.
56
-
- In the future we might consider:
57
-
- Table per each entity, so that we can minimize table locking.
58
-
- Sessions to ensure order of processing within the same message session ID - similar to how Azure Service Bus feature or Apache Kafka topic-partition works.
55
+
- A messages table is used to store exchanged messages (by default table is called `Messages`).
56
+
- A subscriptions table is used to store durable topic subscriptions configured by consumers.
57
+
- Producers send messages to the messages table.
58
+
- There are two types of entities (queues, and topics for pub/sub).
59
+
- In the case of a topic:
60
+
- Each configured durable subscription gets a copy of the message.
61
+
- Consumers (queue consumers, or subscribers in pub/sub) long poll the table to pick up their respective message.
62
+
- Queue consumers compete for the message, and ensure only one consumer instance is processing the message.
63
+
- Topic subscribers compete for the message within the same subscription.
64
+
- Message rows use a clustered `bigint identity` sequence for insert locality and a logical `uniqueidentifier` message id.
65
+
- The default client-side id generator is sequential-ish for SQL Server index locality. Random database ids and database-generated sequential ids can be selected through `cfg.IdGeneration`.
66
+
- In the future we might consider:
67
+
- Table per each entity, so that we can minimize table locking.
68
+
- Sessions to ensure order of processing within the same message session ID - similar to how Azure Service Bus feature or Apache Kafka topic-partition works.
0 commit comments