架构设计之道

(1)Master-Slave架构

这个中间件系统的本质是希望能够用分布式的方式来处理一些数据,但是具体的作用涉及到核心技术,所以这里不能直接说明。

但是他的核心思想,就是把数据分发到很多台机器上来处理,然后需要有一台机器来控制N多台机器的分布式处理

那么既然是分布式的处理,就肯定涉及到在Master中要维护这个集群的一些核心元数据。

比如说数据的分发处理是如何调度的,处理的具体过程现在什么进度了,还有就是对集群里存放数据进行描述的一些核心元数据。

这些核心元数据肯定会不断的频繁的修改,大家此时可以想,无论你是基于外部的文件还是数据库,或者是zookeeper来存放这些元数据的话,其实都会导致他的元数据更新性能降低,因为要访问外部依赖。

何况这种复杂的元数据其实还不一定能通过zk或者数据库来存放,因为他可能是非格式化的。

所以这里一个核心的设计,就是将核心元数据直接存放在Master的内存里,这样可以保证高并发更新元数据的时候,他的性能是极高的,而且直接基于内存来提供对外的更新服务。

如果Master部署在高配置物理机上,比如32核128GB的那种,每秒支持10万+的请求都没问题。

(2)异步日志持久化机制

但是这里有一个问题,假如说Master进程重启,或者是突然宕机了,那么内存里的数据不就丢失了么?

对,所以针对这个问题,既然已经否决掉了基于外部存储来写入元数据,那么这里就可以采取异步持久化日志的机制,来通过异步化的方式把元数据的更新日志写入磁盘文件。

每次Master收到一个请求,在内存里更新元数据之后,就需要生成一条元数据的更新日志,把这个更新日志需要写入到一个内存缓冲里去。

然后等内存缓冲满了之后,由一个后台线程把这里的数据刷新到磁盘上去,

肯定会有人说,那如果一条更新日志刚写入缓冲区,结果Master宕机了,此时不是还是会丢失少量数据吗?因为还没来得及刷入磁盘。

没错啊,这个为了保证高并发请求都是由内存来处理的,你必须得用异步持久化磁盘的模式,所以必然要容忍极端宕机情况下,可能丢失比如几秒钟的数据。

那么如果是正常的Master重启呢?

那简单,必须先把日志缓冲区清空刷入磁盘,然后才能正常重启Master,保证数据都在磁盘上不会丢失。

接着重启的时候,从磁盘上读取更新日志,每一条都依次回访到内存里,恢复出来核心元数据即可。

(3)检查点机制:定时持久化全量数据

但是这里又有一个问题了,那个磁盘上的日志文件越来越大,因为元数据不断的在更新,不断在产生最新的变更日志写入磁盘文件。

那么系统运行一段时间以后,每次重启都需要从磁盘读取历史全部日志,一条一条回放到内存来恢复核心元数据吗?

不可能,所以这里一定要配合引入检查点机制。

也就是说,每隔一段时间,就需要开启一个后台线程,把内存里的全部核心元数据序列化后写入磁盘上的元数据文件,作为这个时间的一个快照文件,同时清空掉日志文件,这个叫做检查点操作。

下次重启,只要把元数据文件读取出来直接反序列化后方入内存,然后把上次检查点之后的变更日志从日志文件里读出来回放到内存里,就可以恢复出来完整的元数据了。

这种方式,可以让Master重启很快,因为大部分数据都是在检查点写入的那个元数据文件里。

(4)引入检查点节点

但是这个时候又有一个问题了。

大家可以想一下,Master内存里的元数据需要高并发的被人访问和修改,同时每隔一段时间还要检查点写入磁盘。

那么在检查点过程中,是不是需要把内存数据全部加锁,不允许别人修改?

在加锁的时候,把不会变动的数据写入磁盘文件中,但是这个过程是很慢的,意味着此时别人高并发的写入操作都需要等待核心元数据的锁。

因为此时别人锁住了,你无法加锁去写数据进去,这会导致系统在几秒内出现卡顿无法响应请求的问题。

所以此时需要在架构设计里引入一个检查点节点,专门负责同步Master的变更日志。

然后在自己内存里维护一份一模一样的核心元数据,每隔一段时间由检查点节点来负责将内存数据写入磁盘,接着上传发送给Master。

这样做,就不需要Master自己执行检查点的时候对自己内存数据进行加锁了,

5)总结 & 思考

总结一下这个架构设计,其实就是Master基于内存维护元数据,这样一台物理机可以支撑每秒10万+的高并发请求。

每次元数据出现更新,写一条日志到内存缓冲区,然后后台线程去刷新日志到日志文件里去,同时需要发送一条日志到Checkpoint节点去。

Checkpoint节点会在自己内存里维护一份一模一样的元数据,然后每隔一段时间执行checkpoint检查点写一份元数据文件快照。

接着上传给Master节点后清空掉他的日志文件。然后Master节点每次重启的时候直接读取本地元数据文件快照,加上回放上次checkpoint之后的日志即可。

这里可能大家会提几个问题,比如说Master节点突然宕机会如何?

那很简单,直接影响就是他内存缓冲里的那些日志丢了,导致少量数据丢失,这个在我们的场景下可以容忍。

如果Checkpoint节点宕机怎么办?

那不要紧,因为他之前上传过元数据文件的快照,所以对Master而言最多就是无法同步数据过去。

但是Master重启,还是可以读取最近一次的元数据快照,然后回放日志即可。

等Checkpoint节点恢复了,可以继续接着上一次同步日志,然后继续执行checkpoint操作。

原文链接:https://mp.weixin.qq.com/s/9R9aIScVfY0oLDDiGTJk9g

原文地址:https://www.cnblogs.com/liushiqiang123/p/11054878.html

时间: 2024-11-07 01:40:53

架构设计之道的相关文章

滴滴出行分而治之的架构设计之道

[本文是WOT2016互联网运维与开发者大会的现场干货,  新一届主题为WOT2016企业安全技术峰会将在2016年6月24日-25日于北京珠三角JW万豪酒店隆重召开!] 如今,我们去任何一个地方都要先问问有没有Wi-Fi,网络已经明显影响到我们的生活. 互联网生下来就是为了服务海量用户,在这个时代,几乎没有哪个应用再为单机而生.每个公司的每个产品将要面临的都是不可预知的用户海量请求.显然这个靠分布式程序来解决,比依靠单机靠谱得多.然而不幸的是,如果一开始你的架构设计不可扩展,有再多的机器,有再

mysql性能调优与架构设计笔记

1.mysql基本介绍 mysql支持多线程高并发的关系型数据库; 数据库存储引擎InnoDB.MyISAM; mysql快速崛起的原因就是他是开源的; 性能一直是mysql自豪的一大特点; 2.mysql架构组成 麻雀虽小五脏俱全,mysql虽然简单但其内部结构并不简单; mysql物理文件组成之日志文件: 错误日志error log这里记录mysql运行时严重的警告和错误,以及mysql启动和关闭的日志信息 二进制日志 binary log 记录mysql运行时所有的query和query执

架构设计的方法论

作者 田伟宇 发布于 2015年4月17日 | 注意:QCon全球软件开发大会(北京)2016年4月21-23日,了解更多详情!7 讨论 分享到:微博微信FacebookTwitter有道云笔记邮件分享 稍后阅读 我的阅读清单 摘要:iOS客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答iOS应用架构中的种种问题,本文是其中的第一篇,主要讲架构设计的通识和方法论等,同时还讨论了大家关心的架构分层.是否要有common文件夹等问题. 缘由 之前安居客iOS app

IM系统架构设计之浅见

背景:除去大名鼎鼎的QQ这款即时聊天工具,还有许多细分行业的IM,比如淘宝阿里旺旺.网易泡泡.YY语音.......恰巧公司产品也要开发一款基于我们自己行业的类IM系统,很有幸我担当了这个产品的架构师,核心代码编写.实现者.下面我近年来从技术上我对IM系统(即时消息的传输,不包括语音,视频,文件的传输)的理解和设计分享出来,浅薄之见,望大家别见笑,欢迎给出批评意见. 一.网络传输协议的选择 目前我知晓的所有IM系统传输即时消息无外乎使用UDP.TCP.基于TCP的http这几种协议中的一种或几种

小钢的架构思考:架构设计

原创文章,转载请注明:转载自Keegan小钢并标明原文链接:http://keeganlee.me/post/architecture/20160621微信订阅号:keeganlee_me写于2016-06-21 小钢的架构思考:什么是架构小钢的架构思考:架构规划小钢的架构思考:架构设计 最近一个多月因为忙于工作上的项目重构,所以文章一直没能更新.现在,重构终于暂时告一段落,于是,赶紧抽时间把文章写完更新发布.下面进入正文. 当架构规划的结果,整理出一堆不同优先级的需求,尤其是质量需求之后,接下

架构/设计

随笔分类 -架构/设计 软件架构设计模式简述 2014-03-25 20:33 by 破狼, 2465 阅读, 收藏, 编辑 在软件开发设计中我们经常会面对业务分析,提取领域问题,从而实现软件架构设计.关于 软件架构设计Martin Fowler在2004出版的<企业应用架构模式>中 概括了四种方式的架构模式.它们分别为事务性脚本,表驱动模式,活动记录模式,领域驱动设计.前两者事务性脚本,表驱动模式作为 面向过程方式架构设计,后两者为面向对象架构设计.它们适合于不同的业务场景,它们也各有长短.

HT图形组件设计之道(三)

上篇我们通过定制了CPU和内存展示界面,体验了HT for Web通过定义矢量实现图形绘制与业务数据的代码解耦及绑定联动,这类案例后续文章还会继续以便大家掌握更多的矢量应用场景,本篇我们先切换个话题,谈谈模型-视图-事件之间的关系. 图形组件设计架构上主要就是在规划Data模型,View视图和Event事件之间的关系,这些年业界逐渐将各种GUI设计模式提炼成理论归类,MVC.MVP和MVVM的主要大类常被统称为MV*,有很多文章进行各种设计模式的定义和比较,本篇不打算深入展开理论的讨论,不同图形

【项目总结】扯一扯电商网站前端css的整体架构设计(1)

最近半忙不忙的写了一个外包网站,网站主要功能是艺术品竞拍和艺术衍生品的销售.工程已经完成了80%左右,现在前后端代码量已经50W行左右,我主要负责的是前端设计和前端布局.下面就先放一个网站的设计图吧,因为涉及到甲方的"商业机密",所以打一下马赛克: 这篇文章主要算是我对于这个项目的总结或者说是对于这阶段自己看的一些前端书或者经验的一个总结吧,所以设计图就不贴那么多了.整个项目的设计图由最开始的ui定了个首页稿基调,剩下的界面大部分都是我在首页稿基础上做出来的,以后有机会再唠.PS:不过

HT图形组件设计之道(二)

上一篇我们自定义CPU和内存的展示界面效果,这篇我们将继续采用HT完成一个新任务:实现一个能进行展开和合并切换动作的刀闸控件.对于电力SCADA和工业控制等领域的人机交互界面常需要预定义一堆的行业标准控件,以便用户能做可视化编辑器里,通过拖拽方式快速搭建具体电力网络或工控环境的场景,并设置好设备对应后台编号等参数信息,将拓扑图形与图元信息一并保存到后台,实际运行环境中将打开编辑好的网络拓扑图信息,连接后台实时数据库,接下来就是接受实时数据库发送过来的采集信息进行界面实时动态刷新,包括用户通过客户