4.7.6　Global Zone（强一致性）

前面两种解决方案在一致性和网络延迟上各有优缺点，全球单地域只保证了数据一致性但是网络延迟很高，核心业务区和非核心业务区将业务和数据靠近用户部署，降低了网络延迟但数据非一致性强。结合这两种方案可以得到Global Zone的方式，首先业务区还是分为核心业务区和非核心业务区，将全球用户分配到不同业务区进行处理，在此基础上设置横跨业务区的Global Zone，用于处理所有需要跨业务区的用户业务，Global Zone也就形成了新的业务区，数据保持强一致性，用户的业务只有在Global Zone所在的地域内写操作成功才会返回给前端。

以实现全球服的游戏场景为例，核心业务区部署在上海地域，非核心业务区通过新加坡地域覆盖东南亚、通过洛杉矶地域覆盖北美洲、通过法兰克福地域覆盖欧洲，其他地域都会接入上海地域（当然也可以将业务部署到更多地域中，形成更多的非核心业务区）。当用户无须跨业务区处理游戏请求时，在当前地域内完成所有业务逻辑，再将非核心业务区的数据定时同步到上海地域。当东南亚玩家、北美洲玩家、欧洲玩家及其他的地域玩家需要进入全球服在一个“房间”进行游戏对战时，进行业务部署时按照网络质量假定选择新加坡地域提供Global Zone，这些玩家的数据会实时写入新加坡地域，写操作成功后再返回成功，数据也会实时同步到洛杉矶和法兰克福地域的数据库中，只读业务在当前地域内读取数据。当然，用户会通过全球动态加速就近接入新加坡、洛杉矶、法兰克福地域，洛杉矶地域与新加坡地域、法兰克福地域与新加坡地域之间均通过高速通道相连，在数据跨地域读写操作时起到加速效果。

既然是覆盖全球玩家的Global Zone，那么为什么将写入数据库的操作放在新加坡地域呢？为什么不能放在其他地域？根据用户业务，可以组成多个Global Zone，每个Global Zone根据包含的用户所在地区及就近的地域来综合评定一个最佳的地域。例如，同一个Global Zone中的东南亚玩家相对较多，北美洲和欧洲玩家相对较少，那么适合选择位于东南亚的新加坡地域来部署业务，相对来说“牺牲”北美洲和欧洲玩家的访问体验，尽可能保证玩家一致的访问体验，在游戏业务设计时也应该考虑网络延迟的影响，不一定是减少一部分用户的网络延迟，而是尽量保持同一Gloabal Zone内的所有用户具有相同的网络延迟。AWS提供GameLift，能够实现游戏托管，自动调度到全球多个地域中。