Continue doc organization
This commit is contained in:
Oleg Zhurakousky
@@ -1,3 +1,4 @@
|
||||
* xref:preface.adoc[]
|
||||
* xref:index.adoc[]
|
||||
* xref:spring-cloud-stream.adoc[]
|
||||
** Main Concepts and Abstractions
|
||||
@@ -6,7 +7,23 @@
|
||||
*** xref:spring-cloud-stream/overview-persistent-publish-subscribe-support.adoc[Persistent publish-subscribe support]
|
||||
*** xref:spring-cloud-stream/consumer-groups.adoc[Consumer group support]
|
||||
*** xref:spring-cloud-stream/overview-partitioning.adoc[Partitioning support]
|
||||
|
||||
** xref:spring-cloud-stream/programming-model.adoc[]
|
||||
*** xref:spring-cloud-stream/destination-binders.adoc[]
|
||||
*** xref:spring-cloud-stream/bindings.adoc[]
|
||||
*** xref:spring-cloud-stream/producing-and-consuming-messages.adoc[]
|
||||
** xref:spring-cloud-stream/binders.adoc[]
|
||||
*** xref:spring-cloud-stream/overview-binder-api.adoc[A pluggable Binder SPI]
|
||||
*** xref:spring-cloud-stream/binder-detection.adoc[]
|
||||
*** xref:spring-cloud-stream/multiple-binders.adoc[]
|
||||
*** xref:spring-cloud-stream/multiple-systems.adoc[]
|
||||
* Binders
|
||||
** Apache Kafka
|
||||
** RabbitMQ
|
||||
** Apache Pulsar
|
||||
** https://github.com/SolaceProducts/solace-spring-cloud/tree/master/solace-spring-cloud-starters/solace-spring-cloud-stream-starter#spring-cloud-stream-binder-for-solace-pubsub[Solace]
|
||||
** https://github.com/spring-cloud/spring-cloud-stream-binder-aws-kinesis/blob/main/spring-cloud-stream-binder-kinesis-docs/src/main/asciidoc/overview.adoc[Amazon Kinesis]
|
||||
|
||||
|
||||
#** xref:spring-cloud-stream/overview-application-model.adoc[]
|
||||
#** xref:spring-cloud-stream/overview-binder-abstraction.adoc[]
|
||||
|
||||
@@ -1,7 +1,15 @@
|
||||
[[producers-and-consumers]]
|
||||
= Producers and Consumers
|
||||
[[binders]]
|
||||
= Binder abstraction
|
||||
:page-section-summary-toc: 1
|
||||
|
||||
Spring Cloud Stream provides a Binder abstraction for use in connecting to physical destinations at the external middleware.
|
||||
This section provides information about the main concepts behind the Binder SPI, its main components, and implementation-specific details.
|
||||
|
||||
|
||||
[[producers-and-consumers]]
|
||||
== Producers and Consumers
|
||||
|
||||
|
||||
The following image shows the general relationship of producers and consumers:
|
||||
|
||||
.Producers and Consumers
|
||||
@@ -16,4 +24,3 @@ As with a producer, the consumer can be bound to an external message broker.
|
||||
When invoking the `bindConsumer()` method, the first parameter is the destination name, and a second parameter provides the name of a logical group of consumers.
|
||||
Each group that is represented by consumer bindings for a given destination receives a copy of each message that a producer sends to that destination (that is, it follows normal publish-subscribe semantics).
|
||||
If there are multiple consumer instances bound with the same group name, then messages are load-balanced across those consumer instances so that each message sent by a producer is consumed by only a single consumer instance within each group (that is, it follows normal queueing semantics).
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[bindings]]
|
||||
= Bindings
|
||||
:page-section-summary-toc: 1
|
||||
|
||||
As stated earlier, _Bindings_ provide a bridge between the external messaging system (e.g., queue, topic etc.) and application-provided _Producers_ and _Consumers_.
|
||||
|
||||
|
||||
@@ -207,11 +207,3 @@ the specific retry bean per binding.
|
||||
----
|
||||
spring.cloud.stream.bindings.<foo>.consumer.retry-template-name=<your-retry-template-bean-name>
|
||||
----
|
||||
|
||||
|
||||
[[spring-cloud-stream-overview-binders]]
|
||||
== Binders
|
||||
|
||||
Spring Cloud Stream provides a Binder abstraction for use in connecting to physical destinations at the external middleware.
|
||||
This section provides information about the main concepts behind the Binder SPI, its main components, and implementation-specific details.
|
||||
|
||||
|
||||
@@ -1,10 +1,28 @@
|
||||
[[spring-cloud-stream-overview-partitioning]]
|
||||
= Partitioning
|
||||
|
||||
Spring Cloud Stream provides support for partitioning data between multiple instances of a given application.
|
||||
In a partitioned scenario, the physical communication medium (such as the broker topic) is viewed as being structured into multiple partitions.
|
||||
One or more producer application instances send data to multiple consumer application instances and ensure that data identified by common characteristics are processed by the same consumer instance.
|
||||
|
||||
Spring Cloud Stream provides a common abstraction for implementing partitioned processing use cases in a uniform fashion.
|
||||
Partitioning can thus be used whether the broker itself is naturally partitioned (for example, Kafka) or not (for example, RabbitMQ).
|
||||
|
||||
.Spring Cloud Stream Partitioning
|
||||
image::SCSt-partitioning.png[width=800,scaledwidth="75%",align="center"]
|
||||
|
||||
Partitioning is a critical concept in stateful processing, where it is critical (for either performance or consistency reasons) to ensure that all related data is processed together.
|
||||
For example, in the time-windowed average calculation example, it is important that all measurements from any given sensor are processed by the same application instance.
|
||||
|
||||
NOTE: To set up a partitioned processing scenario, you must configure both the data-producing and the data-consuming ends.
|
||||
|
||||
|
||||
Partitioning in Spring Cloud Stream consists of two tasks:
|
||||
|
||||
* `xref:spring-cloud-stream/overview-partitioning.adoc#spring-cloud-stream-overview-configuring-output-bindings-partitioning[Configuring Output Bindings for Partitioning]`
|
||||
* `xref:spring-cloud-stream/overview-partitioning.adoc#spring-cloud-stream-overview-configuring-input-bindings-partitioning[Configuring Input Bindings for Partitioning]`
|
||||
|
||||
xref:spring-cloud-stream/overview-partitioning.adoc#spring-cloud-stream-overview-configuring-output-bindings-partitioning[Configuring Output Bindings for Partitioning]
|
||||
|
||||
xref:spring-cloud-stream/overview-partitioning.adoc#spring-cloud-stream-overview-configuring-input-bindings-partitioning[Configuring Input Bindings for Partitioning]
|
||||
|
||||
[[spring-cloud-stream-overview-configuring-output-bindings-partitioning]]
|
||||
== Configuring Output Bindings for Partitioning
|
||||
|
||||
@@ -1,29 +0,0 @@
|
||||
[[partitioning]]
|
||||
= Partitioning Support
|
||||
|
||||
Spring Cloud Stream provides support for partitioning data between multiple instances of a given application.
|
||||
In a partitioned scenario, the physical communication medium (such as the broker topic) is viewed as being structured into multiple partitions.
|
||||
One or more producer application instances send data to multiple consumer application instances and ensure that data identified by common characteristics are processed by the same consumer instance.
|
||||
|
||||
Spring Cloud Stream provides a common abstraction for implementing partitioned processing use cases in a uniform fashion.
|
||||
Partitioning can thus be used whether the broker itself is naturally partitioned (for example, Kafka) or not (for example, RabbitMQ).
|
||||
|
||||
.Spring Cloud Stream Partitioning
|
||||
image::SCSt-partitioning.png[width=800,scaledwidth="75%",align="center"]
|
||||
|
||||
Partitioning is a critical concept in stateful processing, where it is critical (for either performance or consistency reasons) to ensure that all related data is processed together.
|
||||
For example, in the time-windowed average calculation example, it is important that all measurements from any given sensor are processed by the same application instance.
|
||||
|
||||
NOTE: To set up a partitioned processing scenario, you must configure both the data-producing and the data-consuming ends.
|
||||
|
||||
[[programming-model]]
|
||||
== Programming Model
|
||||
|
||||
To understand the programming model, you should be familiar with the following core concepts:
|
||||
|
||||
* *Destination Binders:* Components responsible to provide integration with the external messaging systems.
|
||||
* *Bindings:* Bridge between the external messaging systems and application provided _Producers_ and _Consumers_ of messages (created by the Destination Binders).
|
||||
* *Message:* The canonical data structure used by producers and consumers to communicate with Destination Binders (and thus other applications via external messaging systems).
|
||||
|
||||
image::SCSt-overview.png[width=800,scaledwidth="75%",align="center"]
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[producing-and-consuming-messages]]
|
||||
= Producing and Consuming Messages
|
||||
:page-section-summary-toc: 1
|
||||
|
||||
You can write a Spring Cloud Stream application by simply writing functions and exposing them as `@Bean` s.
|
||||
You can also use Spring Integration annotations based configuration or
|
||||
@@ -28,6 +29,7 @@ For these rare scenarios you can disable auto-discovery by providing `spring.clo
|
||||
|
||||
Here is the example of the application exposing message handler as `java.util.function.Function` effectively supporting
|
||||
_pass-thru_ semantics by acting as consumer and producer of data.
|
||||
|
||||
[source,java]
|
||||
----
|
||||
@SpringBootApplication
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
[[programming-model]]
|
||||
= Programming Model
|
||||
|
||||
To understand the programming model, you should be familiar with the following core concepts:
|
||||
|
||||
* *Destination Binders:* Components responsible to provide integration with the external messaging systems.
|
||||
* *Bindings:* Bridge between the external messaging systems and application provided _Producers_ and _Consumers_ of messages (created by the Destination Binders).
|
||||
* *Message:* The canonical data structure used by producers and consumers to communicate with Destination Binders (and thus other applications via external messaging systems).
|
||||
|
||||
image::SCSt-overview.png[width=800,scaledwidth="75%",align="center"]
|
||||
|
||||
Reference in New Issue
Block a user