其次就是现在很多公司推荐并在使用的，也就是3AZ部署，在这里我们会介绍我们的场景的主管模式，我们在消费和终端里都有用到。比如图中的双AZ副本，它的优点也很明显，你如果client的话，你正常只会访问本地DC（图中对应的是AZ），但问题是成本高，还有要自己考虑故障切换。
3AZ3副本的优点是，我们可以把每个AZ当一个虚拟rack来看待，那读写一致性就可以用QUORUM，这样成本就会低一些，任意AZ的故障也不会影响可用性。但它也有的缺点，你因为跨AZ随机访问会增加访问时延，这取决于你AZ间网络时延。一般像公有云厂商AZ间时延说的是不高于两毫秒，但如果你的业务对这种时延比较敏感的话，那可能这种并不是特别适合。对它的性能可能也会有一定的下降，我们测试出来大概是会降低15%～20%。
现在很多初创型公司都会部署到公有云的服务器上，你们可以尝试一下这种3AZ部署方式，做一下性能测试看看效果如何。
在Cassandra原来是一个DC的情况下，如果要拓展到多个DC，我们要考虑如何同步这些数据。
首先我们既可以用nodetool rebuild也可以用sstableloader。这两种方式也有不一样的地方，build只能从原AZ(DC)其中的一个副本节点获取数据, 如果三个AZ副本不一致，那有可能无法获取一致的数据，我们因此建议在同步之前要做repair操作。sstableloader的问题是拷贝的数据量是原来的三倍，因此磁盘需要申请额外的存储空间，数据迁移完成后还要用nodetool cleanup删除冗余的数据。这两种方式可以根据你的使用情况来选择性的使用。
接着我们来谈一下数据一致性所遇到的一些问题，虽然我们使用quorum或local quorum，但这也是Cassandra会面临比较多的一个问题。因为你始终会面临坏盘、节点宕机，或某些公司出现的集群网络、负载不稳定等问题。这些都会导致数据不一致。如果你通过自己的DBA管理这些物理机，这样的成本还是比较高的。现在很多都是在云上的，包括我们也是通过云将数据迁移到虚拟机。将硬盘换成云硬盘，数据一致性相对就会好很多了。当然，它也会带来一些问题，比如成本会有小幅上升。还有hint的保留时长也可以从默认的3小时改为24小时，这对磁盘的存储增加不会很大，如果你的集群网络环境比较稳定的话，就不会有什么问题。
最后就是要对数据做一个定期地修复，也就是所谓的repair操作。你一般两周到一个月做一次，其实不会有太大的问题。但不用做的太频繁，因为修复太频繁会占用过多资源。同时你要控制修复段足够的小，并发量要控制好，尽量不要影响在线的业务。
我们其实有多个场景，用的两个最直接的部署，我们也会定期去做一个对比。在华为终端云这里，我们早期也用了ES(ElasticSearch)来弥补Cassandra二级索引的不足，但这也会带来一些问题。因为ES和Cassandra数据会有不一致，你要定期做一些检查修复。
接下来我们介绍一下数据备份，这是为了一些极端的场景，其实大部分情况下你是用不到的。但对于我们这么大的规模来说，有很多重要核心数据，因此我们一定是要考虑这种备份，这里有几个场景，我就不详细介绍了。备份其实还是基于原生Cassandra的快照(snapshot)的能力。它其实本质上就用的是Hard Link，这样我们便会把这数据备份到我们的OBS存储中。目前我们RPO可以做到5分钟以内，RTO大概就是根据数据的下载的时间，一般1T数据大概要2~3小时。