Redux要解决什么问题？
随着 JavaScript 单页应用开发日趋复杂，JavaScript 需要管理比任何时候都要多的 state （状态）。 这些 state 可能包括服务器响应、缓存数据、本地生成尚未持久化到服务器的数据，也包括 UI 状态，如激活的路由，被选中的标签，是否显示加载动效或者分页器等等。
管理不断变化的 state 非常困难。如果一个 model 的变化会引起另一个 model 变化，那么当 view 变化时，就可能引起对应 model 以及另一个 model 的变化，依次地，可能会引起另一个 view 的变化。直至你搞不清楚到底发生了什么。state 在什么时候，由于什么原因，如何变化已然不受控制。 当系统变得错综复杂的时候，想重现问题或者添加新功能就会变得举步维艰。
Redux的设计借鉴Flux、 Elm、Immutable，它的出现就是为了解决state里的数据问题。Redux和Flux的主要区别是Redux里面是单一的数据源设计，而Flux（或者Reflux）里面有多个数据源。
Redux是如何工作的？
我们知道，在React中，数据在组件中是单向流动的。数据从一个方向父组件流向子组件(通过props)，由于这个特征，两个非父子关系的组件（或者称作兄弟组件）之间的通信并不是那么清楚。
React并不建议直接采用组件到组件的通信方式，尽管它有一些特性可以支持这么做(比如先将子组件的值传递给父组件，然后再由父组件在分发给指定的子组件)。这被很多人认为是糟糕的实践方式，因为这样的方式容易出错而且会让代码向“拉面”一样不容易理解。
当然React也没有直接建议如何去处理这种情形，以下是React的文档中关于这部分的描述：
对于非父子关系的组件，你可以自己建立一个全局的事件系统，Flux的模式也是一种可行的方式。
Redux的出现就让这个问题的解决变得更加方便了。Redux提供一种存储整个应用状态到一个地方的解决方案（可以理解为统一状态层），称为“store”，组件将状态的变化转发通知(dispatch)给store，而不是直接通知其它的组件。组件内部依赖的state的变化情况可以通过订阅store来实现。
使用Redux，所有的组件都从store里面获取它们依赖的state，同时也需要将state的变化告知store。组件不需要关注在这个store里面其它组件的state的变化情况，Redux让数据流变得更加简单。这种思想最初来自Flux，它是一种和React相同的单向数据流的设计模式。
