回滚是指当程序或者数据出错时，恢复到最近的一个正确版本的行为。最常见的如事务回滚、代码库回滚、部署版本回滚、数据版本回滚、静态资源版本回滚等。通过回滚机制，可以在发布系统出现故障时，保证系统的可用性。
事务回滚
提到事务回滚，单库的事务就不再多说了。对于跨库的事务，比较常见的解决方案有：两阶段提交、三阶段提交。但是这2种方式，在高可用的架构中一般都不可取，因为跨库锁表会消耗很大的性能。高可用的架构中一般不会要求强一致性，只要达到最终的一致性就可以了。可以考虑：事务表、消息队列、补偿机制、TCC模式（占位/确认或取消）、Sagas模式（拆分事务+补偿机制）来实现最终的一致性。
上面的流程图就体现出来了，分布式事务失败时，需要分别去执行回滚操作，从而达到最终的一致性。上面只是一种简单的流程，比如一次下单失败之后，可以对订单进行幂等重试。也可以减少失败的业务次数，提高系统的可用性。
发布回滚
发布版本时，需要考虑到发生错误后如何快速恢复。发布回滚主要包含：发布版本化、增量发布、灰度发布、架构升级并行发布。
发布版本化
每次发布时，应避免增量发布（只修改修改过的类或文件）。全量发布出问题时，可以直接回滚，不受限制。
增量发布
这里面的增量发布指的是：比如有100台机器，先发布1台机器。如果没有问题，陆续发布后面的机器。这里面需要注意的是：一般公司的发布都需要先到灰度环境，然后再到线上环境。
灰度发布
功能上线时，需要先通过线上引部分流量到灰度环境。灰度环境在一定的时间范围内如果没有发生故障，则发布线上环境。
架构升级并行发布
架构升级时，新的架构所带来的风险比较大。这里面就可以让新老版本并行运行，也就是切一少部分流量至新的架构系统。新系统慢慢稳定后，然后再下线老系统。
静态资源版本回滚
在前端开发中，静态资源一般都是放在CDN当中的。并且在客户端浏览器中也会有缓存。此时对静态资源的版本管理就比较重要了，当系统升级或者回滚时，页面中引用的JS/CSS文件如果是不同的版本号（也就是不同的URL）。此时就不用去管浏览器和CDN的缓存数据了。这里面需要注意一点的是，虽然浏览器的静态资源URL不同，但是页面缓存还是会影响到用户的浏览。此时控制好页面缓存的过期时间，以做到更好的用户体验。
参考：《亿级流量网站架构核心技术》
