数码产品网站模板,运用photoshop设计网站首页,有诗意的设计公司名字,佛山网站推广市场两地三中心这个架构#xff0c;如下图#xff1a; 这种架构具备容灾能力#xff0c;比如生产数据中心停电了#xff0c;那么可以把所有流量都切到同城灾备中心或异地灾备中心#xff0c;那么现在的问题是假如真到了停电的那一天#xff0c;你敢把所有的流量都切到灾备中心…两地三中心这个架构如下图 这种架构具备容灾能力比如生产数据中心停电了那么可以把所有流量都切到同城灾备中心或异地灾备中心那么现在的问题是假如真到了停电的那一天你敢把所有的流量都切到灾备中心去吗上篇文章说了灾备中心它主要的功能是作为生产数据中心的一个备份所以它并没有如同生产数据中心一样不停的在对外提供服务那么就有问题了灾备相当于一个新人一个一直在模仿大哥的一个新人现在大哥受伤了按道理是应该小弟顶上但是小弟还是个新人硬顶上去是不是很有可能会出错也就是说 第一不能保证灾备中心有能力接管线上所有的用户流量可能刚已接收灾备中心被压垮或者出现其他各种各样预估不到的错误 第二如果生产数据中心接收了用户的写请求还没来得及同步到灾备中心这个时候停电了这种情况下也不能直接把用户流量切到灾备中心。
所以基于上面的分析并不是说灾备中心一定不能顶上只是在顶上之前可能还要做很多其他的检查和准备这个时间是不确定的至少不会很快...。
那么问题来了该怎么办
首先对于上面列出来的两点中的第一点如果我们能够让灾备中心不再仅仅只能用来做灾备还能和生产数据中心一样正常的对外提供服务呢如下图 可以看到上面的架构图 不再区分生产数据中心和灾备数据中心只有数据中心而且数据中心之间相互备份数据保证每个数据中心都是全量数据。 用户可以在任意一个数据中心上进行读写操作。
好首先我们不管这种架构能不能实现至少它的好处是非常明显的 每个数据中心一直在对外提供服务不是一个新手所以当一个数据中心停电后直接把用户流量切到另外一个数据中心也是问题不大的。 用户可以就近访问数据中心这样用户的体验更好并且整个架构的流量也比较平均。
优点很明显如果能实现就再好不过了那么这种架构实现起来最重要的一点就是用户同时向不同数据中心写入数据数据中心双向同步数据时如果出现冲突该如何解决那么这个问题目前阿里和蚂蚁金服的解决办法是将用户按某一个规则进行分组每组用户写入数据时只能写入到指定的数据中心相当于用户与数据中心绑定在一起了这样保证了数据中心在双向同步之前数据是不会冲突的因为按用户分组了不同用户的数据不会冲突。当然思路非常简单但是实现起来肯定是非常麻烦的但是思路肯定是可以的阿里也用实践证明了我们先把上面的架构稍微完善一下 用户使用网站时由运营商网络或CDN选择最近的机房机房内部署一个负载均衡由这个负载均衡最终判断用户属于机房前文中的数据中心也就是可能出现用户在注册时在北京那么他的uid就和北京某个机房绑定了那么当这个用户在上海使用时会由上海的负载均衡按照用户分组规则将请求转发到北京绑定的那个机房去当然并不是所有请求比如读请求肯定可以直接在上海机房进行读取所以具体的实现都要看业务怎么实现了以及负载均衡具体的配置这里只是把最简单易懂的思路说一下。
所以我们现在可以 假设北京机房1应用程序或数据库对应的机器停电了那么我们可以调整负载均衡是原本属于这个机房的用户流量转移到机房2去注意这里不要有疑问将用户进行分组是为了防止用户同时写两个数据库发生冲突那么现在机房1里其实已经不能写入数据了所以将流量迁移到机房2是没有问题的。 假设北京机房1整个停电了那么可以通过运营商网络或CDN将流量迁移到北京机房2。 假设北京停电了那么一样可以将流量迁移到上海。
这个架构中最重要的其实就是用户分组所以包括我们的应用程序、数据库负载均衡、数据库分表等等都需要按用户进行分组我们要保证针对同一个用户的请求与操作都在同一个机房内不去跨机房这样才是最快的这就是单元化。
那么上面这个架构实际上就是一个高级版的“两地三中心”只是这种单元化架构我们可以任意去扩展只要你足够有钱因为搭一套全配置的数据中心是需要很高成本的比如你在上海在增加一个数据中心在杭州也增加一个那么就如下图 这就叫三地五中心。
