异地多活常见误区及认识
全业务覆盖异地多活
并非所有业务都需要异地多活，重点应该保护核心业务。比如登录和注册模块，用户1000W每天注册1W，那么很明显登录是相对更重要一些。
实时一致性
在异地多活方案下很难保障数据的实施一致性，通常我们只保障最终一致性。如何在最终一致性下做到业务正常？通常有以下几种方式:
- 考虑机房间物理距离
- 业务设计上允许延迟。
- 二次读取。比如数据写的A库，然后去B库读取，这时由于延迟导致B库中没数据，我们要做的是在B库没数据情况下再去A库查询一次。
只使用存储系统本身同步功能
以MySQL为例，MySQL5.1版本的复制是单线程的复制，在网络抖动或者大量数据同步的时候，经常发生延迟较长的问题，短则延迟十几秒，长则可能达到十几分钟。而且即使我们通过监控的手段知道了MySQL同步时延较长，也难以采取什么措施，只能干等。
Redis又是另外一个问题，Redis 3.0之前没有Cluster功能，只有主从复制功能，而为了设计上的简单，Redis主从复制有一个比较大的隐患：从机宕机或者和主机断开连接都需要重新连接主机，重新连接主机都会触发全量的主从复制，这时候主机会生成内存快照，主机依然可以对外提供服务，但是作为读的从机，就无法提供对外服务了，如果数据量大，恢复的时间会相当的长。
解决的方案就是拓开思路，避免只使用存储系统的同步功能，可以将多种手段配合存储系统的同步来使用，甚至可以不采用存储系统的同步方案，改用自己的同步方案
- 如通过消息队列进行数据同步等等
要保障100%可用性
这是系统的理想状态，通常那只能做到99.9%的可用性。但这不表示我们没有响应的措施。
- 挂公告，说明目前存在问题，正在努力解决
- 事后补偿
- 补充体验