hadoop 跨机房 跨机房部署

目录

一、多机房部署的难点是什么

1.直接跨机房读取从库：

2.在机房B部署一个从库，跨机房同步主库的数据，然后机房B的应用就可以读取这个从库的数据

 二、逐步迭代多机房部署方案

1.同城双活

2.异地多活

---

一、多机房部署的难点是什么

多机房部署的含义是： 在不同的IDC机房中部署多套服务，这些服务共享同一份业务数据，并且都可以承接来自用户的流量

这种架构听起来非常美好，但是在实现上却是非常复杂和困难的

假如我们有两个机房A和B都部署了应用服务，数据库的主库和从库部署在A机房，那么机房B的应用如何访问到数据呢？有两种思路。

1.直接跨机房读取从库：

 2.在机房B部署一个从库，跨机房同步主库的数据，然后机房B的应用就可以读取这个从库的数据

 

都涉及到跨机房的数据传输， 这就对机房之间延迟情况有比较高的要求了。而机房之间的延迟和机房之间的距离息息相关 

1. 北京同地双机房之间的专线延迟一般在1ms~3ms
2. 国内异地双机房之间的专线延迟会在50ms之内 (北京到上海的延迟就会提高到接近30ms,北京和广州部署双机房，那么延迟就会到达50ms),要想保证接口的响应时间在200ms之内，就要尽量减少跨机房的服务调用，更要避免跨机房的数据库和缓存操作了。
3. 国际化的服务，需要部署跨国的双机房,国内想要访问部署在美国西海岸的服务，这个延迟会在100ms~200ms左右.在这个延迟下，就要避免数据跨机房同步调用，而只做异步的数据同步。

---

 二、逐步迭代多机房部署方案

1.同城双活

同城机房之间的延时在1ms~3ms左右，对于跨机房调用的容忍度比较高，所以，这种同城双活的方案复杂度会比较低。它只能做到机房级别的容灾，无法做到城市级别的容灾。

假设这样的场景： 你在北京有A和B两个机房，A是联通的机房，B是电信的机房，机房之间以专线连接，方案设计时，核心思想是尽量避免跨机房的调用。具体方案如下

• 首先，数据库的主库可以部署在一个机房中，比如部署在A机房中，那么A和B机房数据都会被写入到A机房中。然后，在A、B两个机房中各部署一个从库，通过主从复制的方式，从主库中同步数据，这样双机房的查询请求可以查询本机房的从库。一旦A机房发生故障，可以通过主从切换的方式将B机房的从库提升为主库，达到容灾的目的。
• 缓存也可以部署在两个机房中，查询请求也读取本机房的缓存，如果缓存中数据不存在，就穿透到本机房的从库中加载数据。数据的更新可以更新双机房中的数据，保证数据的一致性。
• 不同机房的RPC服务会向注册中心注册不同的服务组，而不同机房的RPC客户端，也就是Web服务，只订阅同机房的RPC服务组，这样就可以实现RPC调用尽量发生在本机房内，避免跨机房的RPC调用

2.异地多活

异地部署不能太近，否则发生自然灾害时，很可能会波及。所以，如果你的主机房在北京，那么异地机房就尽量不要建设在天津，而是可以选择上海、广州这样距离较远的位置。也不能太远，会造成更高的数据传输延迟。

据同步的方案有两种

• 一种基于存储系统的主从复制，比如MySQL和Redis。也就是在一个机房部署主库，在异地机房部署从库，两者同步主从复制实现数据的同步。
• 另一种是基于消息队列的方式。一个机房产生写入请求后，会写一条消息到消息队列，另一个机房的应用消费这条消息后再执行业务处理逻辑，写入到存储服务中

你需要对用户做分片，让一个用户每次的读写都尽量在同一个机房中