本地双活，同城容灾等高可用架构如何设计，数据一致性和可用性如何保证，主机回切后，对象存储如何回切？

楼上的回答很全面了。

这也从另外一个角度解释了对于企业级应用，强一致性的重要性。

主机可以就近同时访问不同的物理站点，而对象系统本身通过强一致性特性来处理数据的一致性要求，当出现不一致（数据在其它站点有修改）时，从最后版本“拉”数据过来已保证数据的“最新”。

主机切换访问站点，没关系，随便切换好了。

如果要做比较多的互切的操作，还是强一致性更有保证！

1 关于数据一致性的问题。第一角度对象存储没有没有修改的修改的操作，只有上传、下载、查询等操作，不会发生同时修改一份数据的问题。如果上传了了一个同名的文件，只有版本号增加不会覆盖原先的文件。第二个角度，两个站点的对象存储配置成同步复制的模式，主流厂家的对象存储支持两个站点双向复制，是不需要配置仲裁的。这一点与存放结构化数据的块存储有很大的不同，块存储配置成双活模式一定要在第三站点启用仲裁，当脑裂发生时，仲裁参与确定一个站点站点存活提供IO，绝不允许脑裂后两个站点的数据都都被访问，这样会造成存储层面的数据不一致。而对象存储没有此类考虑，举例来说，两个站点的应用分别访问各自站点的对象存储，对象存储双向复制，发生脑裂后，每个站点还是可以继续接受IO，如果站点1的应用需要访问站点2的应用生成的数据（注意前提两个站点应用访问一个数据库），而由于脑裂站点1的存储里没有站点2的数据，此时应用请求失败。双活的对象存储不需要仲裁。根本的原因还是对象存储不支持同时操作修改一个数据。
2 对象存储的容灾设计：有的厂商只支持复制的方案，即源站点的对象存储可以将元数据和数据和数据复制到备站点，但是备站点的用户和桶的信息与原站点不同，即业务不能使用原站点的用户的桶的信息直接访问备站点，业务访问备站点时需要修改，业务业务会中断。
容灾实现更优的方案是一些头部的厂商可以将两个站点的不仅数据层面，在用户、桶层面完全进行“镜像”，业务不要做任何修改h可以直接访问备站点的对象存储。
3 容灾设计需要关注的第三个问题是，访问对象存储通过http的请求，同时对象存储分布式架构通常是多节点的模式，容灾设计如果有全局dns和负载均衡会更好。