设计一种100%可用性服务的架构--适用于任何系统(B/S,C/S)[中英文版本]

设计一种100%可用性服务的架构--适用于任何系统(B/S,C/S)[中英文版本]

-- How to design an architecture which have 100 percent availability service?

版权所有,转载请注明出处http://blog.csdn.net/yangzhenping,谢谢!

本篇原创非译文,有需要设计和部署这种架构的,请私信我,谢谢!

最近一直在想怎样设计一种100%可用性的服务,于是有了最初的版本:

如上图,有多个备份的网页服务器和数据库服务器,还有一台同步服务器把主数据库A中的数据同步到其他副本从服务器

问题来了:

当数据库服务器A还没来得及被DBSync  Server同步到B上,这时A宕机了,我们可能会丢失部分数据。

那我们怎么才能不丢失数据呢?

As above graph, there are some backup web servers and database servers, also have one sync server to sync data from master database server A to other slave database servers.

Then problem comes:

We may lost some data when some data in DBS A didn’t sync toDBS B and it is outage!

How can we NOT to lose any data?

根据上面这个设计所碰到的问题,我又设计了下面的架构,当然这个架构还可以继续提升,文章结尾再说哈:

Based on above problem, I design another architecture like below, of course we can improve it again, talk it at the end of this article:

网页服务器A提交一个SQL脚本请求(包含requestId,它是一种Guid类型)给主数据库服务器A,
A的DbSync Service会将这个SQL脚本请求同步给副本服务器B,然后再在A上执行这个SQL脚本,最终把结果返回给网页服务器A。

同样数据库服务器接受到来自A的请求,会同步这个SQL脚本到下一个副本服务器C上,然后执行结果返回给RCS结果比较服务器(所有的副本服务器的DBSync 
Service都会返回结果给RCS)。

RCS结果比较服务器会根据同一个requestId比较主数据库服务器执行的结果和副本服务器执行的结果:

如果主DBS执行成功,副本执行失败,RCS会重新在副本上重新执行直到成功。

如果主DBS执行失败,副本也执行失败,RCS不会做任何事。

如果主DBS执行失败,副本执行成功,我们有两种选择:

选择一:RCS在主DBS上重新执行直到成功,然后通知用户他之前提交的失败任务现在成功了。

选择二:RCS在副本服务器上回滚已经成功的这个SQL脚本,在主DBS上不做任何事。

Web Server A request a SQL script (Contains requestId, it isa Guid type) to Master DBS A, in DBS A its sync service will sync the SQLscript to Slave B, then DBS A’s Sync service will do the SQL script and
thenreturn the result to Web Server A.

Also DBS B’s sync service receive the SQL script will syncthe SQL script to the next Slave DB server C, then execute the SQL script andreturn toResult Compare Server (allslave DB server’s
DB sync service will return the result toResult Compare Server).

Result Compare Server will compare the result usingrequestId, compare the Mater’s requestId result to Slave’s requestId result:

If Master execute pass, but Slave execute failure, RCS willrerun until pass on Slave.

If Master execute fail, and Slave execute failure, RCS willdo nothing on Slave.

If Master execute fail, but Slave execute pass,

Option 1, RCS will rerun on Master until pass and notifyuser about this request pass when it pass.

Option 2, RCS will roll back the SQL script action on Slave,and do nothing on Master.

文章的结尾顺便说下,这个可以继续提升为可用性更高的服务,就是搭建一台RCS的备份服务器。

本文主要提供一种100%可用性架构是针对网页服务器和数据库服务器,当然您也可以把它应用于C/S架构上。

At the end of this article, you can improve it to be a better service, that‘s deploy another RCS backup server.

This article provide a way to deploy 100% high availability web server and database server, of course, you can also use it in C/S, not only B/S, thanks.

版权所有,转载请注明出处http://blog.csdn.net/yangzhenping,谢谢!

时间: 2024-08-28 19:28:00

设计一种100%可用性服务的架构--适用于任何系统(B/S,C/S)[中英文版本]的相关文章

SpringCloud分布式微服务云架构 第四篇:断路器(Hystrix)(Finchley版本)

在微服务架构中,根据业务来拆分成一个个的服务,服务与服务之间可以相互调用(RPC),在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用.为了保证其高可用,单个服务通常会集群部署.由于网络原因或者自身的原因,服务并不能保证100%可用,如果单个服务出现问题,调用这个服务就会出现线程阻塞,此时若有大量的请求涌入,Servlet容器的线程资源会被消耗完毕,导致服务瘫痪.服务与服务之间的依赖性,故障会传播,了解springcloud架构可以加求求:三五三六二四七二五

谈一款MOBA类游戏《码神联盟》的服务端架构设计与实现

一.前言 <码神联盟>是一款为技术人做的开源情怀游戏,每一种编程语言都是一位英雄.客户端和服务端均使用C#开发,客户端使用Unity3D引擎,数据库使用MySQL.这个MOBA类游戏是笔者在学习时期和客户端美术策划的小伙伴一起做的游戏,笔者主要负责游戏服务端开发,客户端也参与了一部分,同时也是这个项目的发起和负责人.这次主要分享这款游戏的服务端相关的设计与实现,从整体的架构设计,到服务器网络通信底层的搭建,通信协议.模型定制,再到游戏逻辑的分层架构实现.同时这篇博客也沉淀了笔者在游戏公司实践五

移动App服务端架构设计

移动App服务端架构设计 我从事手机app服务端开发现在已经是3个年头,自己也整理出了一套相对好用的服务架构,写出来,跟大家一起分享.如有不足,还请多指教. 一:基础流程图. 其实有一点还需要加上,就是对json的压缩和加密,一来给用户节约流量,二来防止请求被截取破解我们的参数.具体先压缩后加密还是先加密后压缩这个问题看需求. 看到这个架构设计时,你们可能会说如果程序入口挂了,所有的服务都不可以用了. 所以这个架构的弱点在程序入口处,因此要有一(多)台机器做负载,负载的工具可以是HaProxy(

从服务端架构设计角度,深入理解大型APP架构升级

随着智能设备普及和移动互联网发展,移动端应用逐渐成为用户新入口,重要性越来越突出.但企业一般是先有PC端应用,再推APP,APP 1.0版的功能大多从现有PC应用平移过来,没有针对移动自身特点考虑APP的架构.随着APP越来越复杂,功能和非功能要求越来越高,架构的先天不足逐渐成为大型APP升级的瓶颈. 本文作者结合大型移动应用的落地实践,从服务端架构设计角度,阐述如何进行升级优化,为后续APP做大做强奠定架构基础,供大家参考. 本文主要内容包括: V1架构 问题分析 V2架构 智能升降级 总结

MMOPRG服务端架构设计

早期的服务端架构是采用Client-->GameServer-->DB的模式,所有的业务和数据都集中在GameServer上一起处理,导致服务器压力很巨大,一个BUG可能导致服务器全程崩溃,以至于造成玩家流失.还有当开服的时候,所有玩家堆积在一个服务器,大量场景消息和广播风爆造成服务器卡.中期然后通过改进增加GameServer,达到分线缓解服务器压力,缺点是运营到后期,随着每条线玩家的减少, 互动大大减少.后期采用了按地图划分服务器,这样大大缓解了服务器的业务和数据压力.现在主流的服务器构架

一种面向云服务的UCON多义务访问控制方法及系统

本发明公开了一种面向云服务的UCON多义务访问控制方法及系统.本方法为:1)设置每一云服务的义务项:建立每一云服务所包含的义务图:2)根据用户所请求的云服务查找该云服务的所有强制义务图和可选义务图,并提取该用户对该云服务的历史完成情况:3)对每一强制义务图,监控其每一义务项所对应属性的属性值,判断该义务项是否完成,并检查所有强制义务图是否已经完成,如果完成则进行步骤4):4)对每一可选义务图,监控其每一义务项所对应属性的属性值,并根据该义务项的历史完成情况判断该义务项的完成概率:然后计算该云服务

高吞吐高并发Java NIO服务的架构(NIO架构及应用之一)

高吞吐高并发Java NIO服务的架构(NIO架构及应用之一) http://maoyidao.iteye.com/blog/1149015 Java NIO成功的应用在了各种分布式.即时通信和中间件Java系统中.证明了基于NIO构建的通信基础,是一种高效,且扩展性很强的通信架构. 基于Reactor模式的高可扩展性架构这个架构的基本思路在“基于高可用性NIO服务器架构”(http://today.java.net/pub/a/today/2007/02/13/architecture-of-

架构-SOA:SOA(面向服务的架构)

ylbtech-架构-SOA:SOA(面向服务的架构) 面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和契约联系起来.接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台.操作系统和编程语言.这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互. 1.返回顶部 1. 中文名:面向服务的结构 外文名:Service-Oriented Architecture 外语缩写:SOA 本    质:组件模型

SOA 面向服务的架构

定义 面向服务的架构(SOA,Service-Oriented Architecture)是一个组件“模式” (或 “思想”,它不是一种“技术”),它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和协议联系起来.接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台.操作系统和编程语言.这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互. SOA vs Web服务 在理解SOA和Web服务的关系上,经常发生混淆.根据2003年4月的Gar