多机房我们需要考虑的以下问题。
- 一切正常时用户应该访问哪个机房。
- 多个机房之间的数据应该怎么同步。
- 多个机房之间的数据如何保持一致性。
多机房负载均衡
最简单的策略是遵循用户就近访问的原则。
实现方式是通过DNS解析到不同的机房，实现方式通过部署四层负载均衡器VIP(基于IP+端口的负载均衡)，以及7层负载均衡器Ngnix(基于URL等应用层信息的负载均衡).，7层之后在发送给对应机器上的容器。进行处理请求。
摘自极客时间
理想情况是这样但是会遇到其他情况
- 某个机房的流量比较大，机器规模支撑不了这么多线上流量。
- 某个机房服务有问题，需要进行切一部分流量到另外的机房。
所以不能只根据地区进行访问，根据需要调配流量，达到均衡每个机房流量的目的。
两种方式来切换。 - DNS解析的时候，把一部分数据切换到其他机房的VIP中。
-
Ngnix进行转发的时候把其他容器的流量切换到当前的容器中。
摘自极客时间
多机房数据同步
多机房数据保持同步。
缓存层与数据库层都需要数据同步。
数据库同步一般都是通过Mysql的binlog同步机制实现数据同步。
独立的机房架构
摘自极客时间
利用中间件技术来实现数据同步的问题。
每个机房更新自己的缓存并且从数据库主库同步数据。
中间件怎么实现这个技术呢？
摘自极客时间
- 不同机房的数据写入通过中间件本地机房写入并且也写入到另外的机房中去。
消息同步怎么做呢？ - MCQ消息队列，每个机房把自己的数据写入到队列中，进行消费放到对方的队列中，处理机从队列中取出数据进行处理。
- RPC调用：直接通过RPC调用告知对方机房的collector RPC 进行消费处理。
多机房数据一致性
通过消息对账机制保证数据的最终一致性。
数据中保持全局唯一的requestId,每个环节全剧唯一的变量始终保持向下传递，成功与失败都记录包含一条requestId和机房处理日志。
日志保存到Elasticsearch 集群上去。找出同一个全局变量requestId的机房处理日志。验证机房是否成功，不成功继续尝试该阶段直到成功。进行保证数据的一致性。
image.png
