Flux 是什么？
Flux 是一种架构思想，专门解决软件的结构问题。它跟MVC 架构是同一类东西，但是更加简单和清晰。
Flux存在多种实现：
Flux将一个应用分成四个部分：
View： 视图层；是用户看得见摸得着的地方，同时也是产生主要用户交互的地方，这个概念在 MVC 和 MVVM 架构中都是有的，有些观点认为虽然这几种架构里都有 View，但是定义不太一致，有细微的差别，我自己觉得这种差异确实是存在的，但在一开始这并不妨碍我们理解 View 这个名词。
Action（动作）：视图层发出的消息（比如mouseClick）；就是一个结构化的信息，从一个地方传递到另一个地方，整个过程就是一个 Action/Event。
Dispatcher（派发器）：用来接收Actions、执行回调函数；Dispatcher 算是从 Action 触发到导致 Store 改变的镇流器。比一般架构设计里直接在“Event”逻辑中修改“Data”更“正规”。
Store（数据层）：对应我们传统意义上的 Data，和 MVC、MVVM 里的 Model 有一定对应关系，用来存放应用的状态，一旦发生变动，就提醒Views要更新页面
基于 Servlet 容器的 Web MV
对 Web 开发者来说，Spring 中的 Web MVC 框架，也一直随着 Spring 而成长，然而由于基于 Servlet 容器，早期被批评不易测试
实现 Reactive Streams 的 Reacto
Web Flux 不依赖 Servlet 容器是事实，然而，在谈及 Web Flux 之前，我们必须先知道 Reactor 项目，它是由 Pivotal 公司，也就是目前 Spring 的拥有者推出，实现了 Reactive Streams 规范，用来支持 Reactive Programming 的实作品。
但是，从实操 Controller 介面搭配 XML 设定，到后来的标注搭配 JavaConfig，Web MVC 使用越来越便利。如果愿意，也可采用渐进的方式，将基于 Servlet API 的 Web 应用程序，逐步重构为几乎没有 Servlet API 的存在，在程序代码层面达到屏蔽 Servlet API 的效果。
由于不少 Java 开发者的 Web 开发经验，都是从 Servlet 容器中累积起来的，在这个时候，Web MVC 框架基于 Servlet API，就会是一项优点。因为，虽然运用 Web MVC 编写程序时，可做到不直接面对 Servlet API，然而，也意味着更强烈地受到 Spring 的约束，有时则是无法在设定或 API 中找到对应方案，有时也因为心智模型还是挂在 Servlet 容器，经验上难以脱离，在搞不出 HttpSession、ServletContext 对应功能时，直接从 HttpSession、ServletContext 下手，毕竟也是个方法。
编写程序时，就算没用到 Servlet API，Web MVC 基于 Servlet 容器仍是事实，因为，底层还是得借助 Servlet 容器的功能，例如 Spring Security，本质上还是基于 Servlet 容器的 Filter 方案。
然而在今日，Servlet 被许多开发者视为陈旧、过时技术的象征，或许是因为这样，在 Java EE 8 宣布推出的这段期间，当在某些场合谈及 Servlet 4.0 之时，总会听到有人提出“Web Flux 可以脱离 Servlet 了”之类的建议。
示例：
如果按领域拆分store，那对应reflux和redux：
reflux下可以放在View层，让component去管，而这个开闭状态本质上和POST_TODO_COMPLETED 这个action是有关的，想要实现这个功能，就必须让UI层直接监听请求成功的Action。
通常在reflux中我们会利用异步action的triggerPromise，在view层
当然，这显然违背了FLUX的 数据流，算是action和view的私相授受。在redux中，由于没有triggerPromise这样的“后门”，domain则是和页面无关的，这个矛盾很难调和：两个页面展示和操作同一个领域对象，却有完全不同的展现和行为，这样的场景并不少见。
如果总结一下的话，大家应该会有一种感觉，前端开发在很长一段时间内是服务于后端的，因此在框架、概念上都有颇深的后端印记，而FLUX、Redux们的出现，代表着开发者们真正从前端的角度在思考、组织和前进。
总结
Flux 带来的好处就是，发生的任何事情都在 dispatcher 中提前定义好了（没定义的话就 不会发生任何事情），所以任何事件都是可预测的。
閱讀更多 咱小二 的文章
