#1.1 简介
- 如今我们在互联网上使用服务包含很多种情况的流数据，包括从某个服务下载数据、上传数据到服务以及点对点的数据传输。关于将数据作为流的元素而不是一个整体是非常有用的，因为这与计算机的发送和接收方式是匹配的(类似通过TCP)，而且这也是也必要的，因为数据集往往太大而难以作为一个整体处理。我们分散计算或者分析了大型集群，并将它称为“大数据”，其中的原则是通过某些CPUS依次传递这些数据流
- Actor可以通过从一个地点传输知识（或者数据）到另一个而被看作处理流以及流的发送与接收的一些列信息。我们发现采取适当的措施以实现在actor中稳定的数据流是繁琐而且容易出错的，因为除了发送和接收，我们还需要考虑缓冲区和邮箱在进程中不会溢出，Actor的消息可以丢失，并且在这种情况下需要重传而避免流在接收端的漏洞。当以固定的方式处理流的元素是，Actor目前也是不提供没有连接错误时良好的静态保障，类型安全在这一点上应该被改善。
- 由于这些原因的存在，我们决定通过akka streams的API统一的解决这些问题，目的是提供一个直观的，安全的方式来制定流处理机制以至于我们能高效的在资源有限的情况下使用他而避免过多的内存溢出错误。为了实现上述功能流处理需要能限制他们使用的缓冲，这需要能在消费者无法及时处理的时候减缓生产者的生产速度，这功能称为back-pressure，这是Reactive Streams措施的核心，其中akka是初始成员。这对你来说意味着在akka tream设计之初已经解决了back-pressure在传输和回应时的问题，这也意味着akka stream能无缝的与其他的Reactive streams实现互操作（其中Reactive Streams接口定义了互操作的SPI，而akka stream的实现则提供了一个良好的用户API）
和Reactive Streams的关系
- Akka Stream的API被完全从Reactive Stream的接口中分离，虽然Akka Stream关注的是制定数据转化而Reactive Stream的范围仅仅是定义一个如何移动数据跨越异步边界而不损失缓冲或者资源的情况下common机制。
- 这两者的关系是，Akka stream的API面向最终用户，而Akka Stream的实现使用的是Reactive Stream接口来在不同的进程中传递数据。出于这个原因，你找不到Reactive Stream接口和Akka StreamAPI之间的相似之处。这是和Reactive Stream项目的期望值是一致的，其主要目的是定义接口，使得不同的数据流的实现可以互操作，并不是Reactive Stream去描述一个最终用户的API的目的。
##1.1.2 如何阅读这些doc 流处理和以Actor模型或者Future组合是不同的，因此需要仔细的研究这个课题，直到你觉得你熟悉的使用工具和技术，该文档是为了帮助和达到最佳效果，我们建议采取以下措施：
- 阅读快速入门指南，通过Reactive Tweets来了解Streams怎么样和感受下他们能做什么
- 条理清晰的学者可能期望了解the Design Principles behind Akka Streams
- 思路严明的学着通过Stream CookBook可能更有归属感
- 可以通过阅读the Design Principles behind Akka Streams对内置的processing状态的了解整个概述
- 其他部分可以按顺序读或者根据需求采取前面的步骤深一步挖掘