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

简介: 设计一种100%可用性服务的架构--适用于任何系统(B/S,C/S)[中英文版本] -- How to design an architecture which have 100 percent availability service?   版权所有,转载请注明出处http://blog.

设计一种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 ADbSync 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,谢谢!

目录
相关文章
|
24天前
|
存储 SQL 网络协议
C语言C/S架构PACS影像归档和通信系统源码 医院PACS系统源码
医院影像科PACS系统,意为影像归档和通信系统。它是应用在医院影像科室的系统,主要的任务是把日常产生的各种医学影像(包括核磁、CT、超声、各种X光机、各种红外仪、显微仪等设备产生的图像)通过各种接口(模拟、DICOM、网络)以数字化的方式海量保存起来,并在需要的时候在一定授权下能够快速地调回使用。同时,PACS系统还增加了一些辅助诊断管理功能。
40 11
|
17天前
|
安全 数据管理 中间件
云LIS系统源码JavaScript+B/S架构MVC+SQLSugar医院版检验科云LIS系统源码 可提供演示
检验科云LIS系统源码是医疗机构信息化发展的重要趋势。通过云计算技术实现数据的集中管理和共享可以提高数据利用效率和安全性;通过高效灵活的系统设计和可扩展性可以满足不同医疗机构的需求;通过移动性和智能化可以提高医疗服务的精准度和效率;通过集成性可以实现医疗服务的协同性和效率。因此,多医院版检验科云LIS系统源码将成为未来医疗机构信息化发展的重要方向之一。
26 2
|
5天前
|
前端开发 Java 关系型数据库
Java医院绩效考核系统源码B/S架构+springboot三级公立医院绩效考核系统源码 医院综合绩效核算系统源码
作为医院用综合绩效核算系统,系统需要和his系统进行对接,按照设定周期,从his系统获取医院科室和医生、护士、其他人员工作量,对没有录入信息化系统的工作量,绩效考核系统设有手工录入功能(可以批量导入),对获取的数据系统按照设定的公式进行汇算,且设置审核机制,可以退回修正,系统功能强大,完全模拟医院实际绩效核算过程,且每步核算都可以进行调整和参数设置,能适应医院多种绩效核算方式。
27 2
|
8天前
|
Kubernetes Cloud Native 持续交付
探索云原生架构的未来:如何优化资源管理和服务部署
【5月更文挑战第6天】 随着云计算的快速发展,云原生技术已成为企业数字化转型的关键驱动力。此篇文章深入探讨了云原生架构的核心组件及其在资源管理和服务部署方面的优化策略。通过分析容器化、微服务及自动化管理的实践案例,本文旨在为读者提供一套系统的方法论,以利用云原生技术实现更高效、灵活且可靠的IT基础设施。
27 2
|
12天前
|
负载均衡 Java API
构建高效微服务架构:API网关与服务熔断策略
【5月更文挑战第2天】 在微服务架构中,确保系统的高可用性与灵活性是至关重要的。本文将深入探讨如何通过实施有效的API网关和设计合理的服务熔断机制来提升分布式系统的鲁棒性。我们将分析API网关的核心职责,包括请求路由、负载均衡、认证授权以及限流控制,并讨论如何利用熔断器模式防止故障传播,维护系统的整体稳定性。文章还将介绍一些实用的技术和工具,如Netflix Zuul、Spring Cloud Gateway以及Hystrix,以帮助开发者构建一个可靠且高效的微服务环境。
|
14天前
|
存储 负载均衡 监控
【Go 语言专栏】构建高可靠性的 Go 语言服务架构
【4月更文挑战第30天】本文探讨了如何利用Go语言构建高可靠性的服务架构。Go语言凭借其高效、简洁和并发性能,在构建服务架构中备受青睐。关键要素包括负载均衡、容错机制、监控预警、数据存储和服务治理。文章详细阐述了实现这些要素的具体步骤,通过实际案例分析和应对挑战的策略,强调了Go语言在构建稳定服务中的作用,旨在为开发者提供指导。
|
14天前
|
API 开发者 UED
构建高效微服务架构:后端开发的新趋势移动应用与系统:开发与优化的艺术
【4月更文挑战第30天】 随着现代软件系统对可伸缩性、灵活性和敏捷性的日益需求,传统的单体应用架构正逐渐向微服务架构转变。本文将探讨微服务架构的核心概念,分析其优势,并着重讨论如何利用最新的后端技术栈实现一个高效的微服务系统。我们将涵盖设计模式、服务划分、数据一致性、服务发现与注册、API网关以及容器化等关键技术点,为后端开发者提供一份实操指南。 【4月更文挑战第30天】 在数字化时代的浪潮中,移动应用和操作系统的紧密交织已成为日常生活和商业活动的基石。本文将深入探讨移动应用开发的关键技术、跨平台开发工具的选择以及移动操作系统的架构和性能优化策略。通过分析当前移动应用开发的挑战与机遇,我们将
|
17天前
|
敏捷开发 运维 监控
【专栏】微服务架构,以敏捷、灵活著称,通过拆分大型应用为小型自治服务,简化开发运维
【4月更文挑战第27天】微服务架构,以敏捷、灵活著称,通过拆分大型应用为小型自治服务,简化开发运维。本文探讨其基本概念、起源,核心优势(如敏捷开发、高可伸缩性)及挑战(系统复杂度、数据一致性),并分享实施策略(服务划分、技术选型、CI/CD)与实践案例(Netflix、Uber、Spotify),展示微服务如何重塑软件开发,并成为未来复杂应用系统的基础。
|
18天前
|
消息中间件 监控 中间件
探索微服务架构下的系统弹性设计
【4月更文挑战第26天】 在当今快速迭代和持续部署的软件发展环境中,系统的弹性设计成为维护高可用性和稳定性的关键因素。本文将深入探讨在微服务架构下如何实现系统弹性,包括识别潜在的故障点、设计容错机制、以及通过实践案例分析提升系统整体的韧性。我们将讨论一系列策略,如服务降级、超时管理、重试策略、断路器模式等,旨在为开发者提供一套实用的系统弹性设计方案。
|
22天前
|
缓存 监控 算法
Python性能优化面试:代码级、架构级与系统级优化
【4月更文挑战第19天】本文探讨了Python性能优化面试的重点,包括代码级、架构级和系统级优化。代码级优化涉及时间复杂度、空间复杂度分析,使用内置数据结构和性能分析工具。易错点包括过度优化和滥用全局变量。架构级优化关注异步编程、缓存策略和分布式系统,强调合理利用异步和缓存。系统级优化则涵盖操作系统原理、Python虚拟机优化和服务器调优,需注意监控系统资源和使用编译器加速。面试者应全面理解这些层面,以提高程序性能和面试竞争力。
18 1
Python性能优化面试:代码级、架构级与系统级优化