Question

我开始学习反应流，因为我很好奇使用RxJava作为更传统事件总线的替代品的新趋势。 This blog post是如何完成此操作的典型说明。如果我理解正确，RxJava 1.x并不是Reactive Streams的严格实现，但它非常相似。版本2.0包含一些符合要求的类，或者至少通过TCK，因此该代码的更新版本可能看起来有点不同。

public class UserLocationModel {

  private PublishSubject<LatLng> subject = PublishSubject.create();

  public void setLocation(LatLng latLng) {
    subject.onNext(latLng);
  }

  public Observable<LatLng> getUserLocation() {
    return subject;
  }
}

在Reactive Streams术语中，我认为subject是Processor，它既是Publisher又是Subscriber。

问题在于，onNext上没有订阅任何内容的Subscriber调用似乎违反了Reactive Streams规范，尤其是rule 1.9。

它只是一个实现细节吗？我是否认为你通常不能依赖这种方法来使用兼容的Reactive Streams实现？

Answer 1

标准RxJava 2的

Subject和Processor是放宽的，因此在调用其他方法之前，您不必在它们上面调用onSubscribe。这部分是由于传统性为1.x主题没有onSubscribe，部分原因是RxJava 2处理器不协调Subscriber侧与{{1}之间的请求因为选择而不能使用Publisher。

如果您订阅任何符合RS Subscription的RxJava Processor，他们似乎会请求Publisher并尽可能地传递信号。如果您订阅RS兼容Long.MAX_VALUE到RxJava Subscriber，他们将尊重那些Processor的背压并且永远不会溢出它们，但是，缺少请求可能会导致个人{{} 1}}被发射并且Subscriber被“抛出”了。 extensions library中有一个用于协调请求的自定义MissingBackpressureException。

我认为您通常不能依赖此处使用符合标准的Reactive Streams实施方式，这是正确的。

规范中没有任何内容，因此未在TCK中进行测试，Subscriber没有收到Publisher调用但是它需要它会发生什么，因此，我认为这已成为实施细节。

这里有两个更大的问题：

发明主题是为了将势在必行的世界与被动的世界联系起来，并在GUI案例和非背压案例中很好地作为事件的多重事件。在反应性反应多播中，它们是更好和更直接的替代方案，例如Processor。
在事件总线中思考是向后退一步，因为您通过在单个“轨道”上铲除和排除事件来创建单个阻塞点。相比之下，反应式设计有利于个别且通常独立的流，其中每个流可以根据需要在线程之间跳转，并且可能避免主线程直到最后一刻。

通常使用Reactive Streams Processor作为事件总线是否可以？

1 个答案: