让我结合分布式数据库（比如Cassandra这类常用多DC架构）的实践经验，来拆解你的两个问题：

首先得明确：异步复制的速度没有固定的“标准答案”，它完全取决于你的实际环境，核心影响因素包括这些：

• 网络条件：这是最关键的。如果两个数据中心在同一个城市（甚至同园区），RTT（往返延迟）可能只有几毫秒，正常负载下复制延迟能控制在几十毫秒；要是跨大洲（比如北美到亚太），RTT本身就有几百毫秒，复制延迟很容易到秒级，极端情况甚至会更高。
• 数据负载情况：写入的吞吐量、单条数据的大小都会影响。比如你每秒写10万条大体积的日志，和每秒写1万条小的业务数据，复制速度肯定差很多。另外，开启数据压缩（比如Snappy、LZ4）能大幅减少传输的数据量，直接提升复制效率。
• 集群配置：比如数据库的异步复制线程数（像Cassandra的concurrent_replicates参数）、复制队列的大小，如果队列满了，复制就会阻塞，延迟瞬间拉长。还有是否开启了流量控制，也会间接影响复制速度。

实际运维里，你可以通过监控工具（比如看复制延迟的metrics）来跟踪自己环境的具体速度，一般同区域DC的异步复制能做到亚秒级到秒级的延迟。

这种架构下（主DC用LOCAL_QUORUM提交写入，灾备DC异步复制），灾备数据的时效性本质上就是异步复制的延迟窗口，具体情况分几种：

• 正常稳定状态：如果网络通畅、主DC负载不高，灾备DC的数据延迟通常是亚秒级到数秒级，可以认为是“准实时”的，大部分场景下这个延迟是可以接受的。
• 异常波动场景：要是主DC突然爆发高写入负载、跨DC网络出现抖动或者丢包，复制队列就会堆积，延迟可能会拉长到几十秒甚至几分钟，这时候灾备的数据就会明显滞后于主DC。
• 故障边界情况：这里要特别注意：因为LOCAL_QUORUM只保证主DC内的副本写入成功就返回，灾备DC的复制是异步的，所以如果主DC突然完全故障，灾备DC会丢失最后一部分还没来得及同步的数据，丢失的数据量就等于故障发生前的复制延迟窗口内的写入量。

如果想提升灾备的时效性，可以调整复制线程数、优化跨DC网络，但本质上异步复制做不到和主DC强一致，只能尽可能缩小延迟窗口。

内容的提问来源于stack exchange，提问作者Glide