这个手册其实老早就搞到了，只是最近实在太懒了一直没动- - ，希望能坚持把主要的内容翻译完。翻译的过程中会加入一些自己的看法，如果有不准确或错误的地方欢迎各种提意见指出~。简单来说就是将数据从持久化存储中加载到cache中。这个模式可以提升系统性能，并且保证cache和底层存储中数据的一致性。PS:下文会用“存储空间”来表示data store，在实际的工程中可以代表数据库、文件等

当连接使用远端服务或资源时，可能需要花不少精力来做好错误处理。这个模式可以有效提高程序的稳定性和弹性。Context and Problem    在像云这种分布式的环境中，应用程序的操作经常访问远端的资源和服务。然而这类操作有可能因为网络响应慢、超时、资源暂时不可用等瞬时性故障（transient faults）而失败。这些故障通常情况下会在一小段时间后自动恢复，而对于一个好的云应用来说

这个模式所做的事情概括一下就是把多个不同的任务和操作合并到一个计算单元中，从而使云计算应用提高计算资源利用率，降低管理开销和任务之间连接交互的开销。PS:我这里对后文中所翻译的“计算单元”做个小小的注释，这里的计算单元可以认为是逻辑的运行容器，可以是基于cgroup的各种container，也可以是像Storm中的worker，Spark中的Executor等等。这个模式除了在自己设计分布式系

简单地来说，这个模式能够使多个并行的consumer处理同一个信道中收到的消息，从而使系统能够并发地处理大量消息来优化系统的吞吐量，提高系统的可扩展性和可用性，平衡负载。Context and Problem    一般来说，一个运行在云端的应用通常都需要处理大量的请求。相比于同步的方式来处理每一个请求来说，一个更加通用的技术是实现一个消息系统来实现异步地处理各个请求。另外，这种策略也能够

先说明一下：这个模式的中文我一直找不到一个比较恰当的中文来表述，姑且在本文中称之为事务修正模式吧，如果各位觉得有更合适的称呼欢迎提出。    这个模式指的是对于一个由一系列步骤组成、并遵循最终一致性的操作来说，如果一个或多个中间步骤发生错误，那么就必须要对这次操作的步骤进行撤销。对于一个实现了复杂业务逻辑和工作流的云端应用来说，遵循最终一致性的操作随处可见，所以本模式应用场景还是比较多得。