全序广播随系统伸缩而遇到的四种限制场景

对足够小的系统，构建一个[[全序广播的两个安全属性与状态机复制]]所描述的完全有序事件日志完全可行（单主复制数据库正是这样的日志），但随着系统规模与复杂度增长，全序开始遇到限制，集中体现在四种场景：一是事件吞吐量超过单台计算机处理能力时，日志必须分区到多台机器，两个不同分区间的事件顺序就变得不明确；二是服务器地理分散在多个数据中心以容忍整个数据中心掉线时，通常每个数据中心各有独立主库（因为跨数据中心同步协调的网络延迟代价太高），源自两个不同数据中心的事件顺序因此未定义；三是微服务架构下每个服务及其持久状态作为独立单元部署、互不共享持久状态，来自不同服务的事件间顺序天然未定义；四是客户端在本地保存状态并立即响应用户输入（甚至支持离线工作）的应用里，客户端和服务器很可能以不同顺序看到事件。全序广播在形式上等价于[[共识问题的形式化定义与FLP不可能性结果的真实含义]]所属的共识，而大多数共识算法都是针对单节点吞吐量足以处理整个事件流的场景设计的，不提供多节点共享排序工作的机制——设计既能超越单节点吞吐量、又能在地理分散环境中良好工作的共识算法，至今仍是一个开放的研究问题。