中间件系统的架构设计

中间件系统的架构设计

1. Master-Slave架构

 　　该系统的本质是但愿可以用分布式的方式来处理一些数据，核心思想，就是把数据分发到不少台机器上来处理，而后须要有一台机器来控制N多台机器的分布式处理：

 　　分布式的处理，就会确定涉及到在Master中要维护这个集群的一些核心元数据。数据的分发处理的调度，处理的具体过程的进度，对集群里存放数据进行描述的一些核心元数据。

　　　这些核心元数据会不断的频繁的修改，不管你是基于外部的文件仍是数据库，或者是zookeeper来存放这些元数据的话，其实都会致使他的元数据更新性能下降，由于要访问外部依赖。这种复杂的元数据不必定能经过数据库来存放，它的非格式化有可能的。

　　　　核心的设计是：将核心元数据直接存放在Master的内存里，这样能够保证高并发更新元数据的时候，性能极高，可直接基于内存来提供对外的更新服务。若是Master部署在高配置物理机上，好比32核128GB的那种，每秒支持10万+的请求都没问题。

 

　　2.异步日志持久化机制

　　　　Master进程重启或者忽然宕机，内存中的数据不就丢失了?针对这个问题，采起异步持久化日志的机制，来经过异步化的方式把元数据的更新日志写入磁盘文件。每次Master收到一个请求，在内存里更新元数据以后，就须要生成一条元数据的更新日志，把这个更新日志须要写入到一个内存缓冲里去。而后等内存缓冲满了以后，由一个后台线程把这里的数据刷新到磁盘上去。

　　　　那若是一条更新日志刚写入缓冲区，结果Master宕机了，此时不是仍是会丢失少许数据吗？由于还没来得及进入磁盘。

　　　　没错，需采用异步持久化磁盘的模式，要容忍极端宕机状况下，丢失几秒钟的数据的状况。

　　　　若是是正常的Master重启：必须先把日志缓冲区清空刷入磁盘，而后才能正常重启Master，保证数据都在磁盘上不会丢失。重启的时候，从磁盘上读取更新日志，每一条都依次回访到内存里，恢复出来核心元数据便可。

 

　　　3.检查点机制：定时持久化全量数据

 

　　　　元数据不断的在更新，不断在产生最新的变动日志写入磁盘文件，因此磁盘上的日志文件愈来愈大，系统运行一段时间之后，每次重启都须要从磁盘读取历史所有日志，一条一条回放到内存来恢复核心元数据吗？不，须要引入检查点机制。

　　　　每隔一段时间，就须要开启一个后台线程，把内存里的所有核心元数据序列化后写入磁盘上的元数据文件，做为这个时间的一个快照文件，同时清空掉日志文件，这个叫作检查点操做。下次重启，只要把元数据文件读取出来直接反序列化后方入内存，而后把上次检查点以后的变动日志从日志文件里读出来回放到内存里，就能够恢复出来完整的元数据了。

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

 　　　4.引入检查点节点

　　　　Master内存里的元数据须要高并发的被人访问和修改，同时每隔一段时间还要检查点写入磁盘。因此在检查点过程当中，是否须要须要把内存数据所有加锁，不容许别人修改？

　　　　在加锁的时候，把不会变更的数据写入磁盘文件中，这个过程很慢，这样会致使系统在几秒内出现卡顿没法响应请求的问题。此时须要在架构设计里引入一个检查点节点，专门负责同步Master的变动日志。而后在本身内存里维护一份如出一辙的核心元数据，每隔一段时间由检查点节点来负责将内存数据写入磁盘，接着上传发送给Master。这样就不须要Master本身执行检查点的时候对本身内存数据进行加锁了。对Master来讲，它只须要一个后台线程负责接收检查点进程定时传送过来的元数据文件快照而后写入本地磁盘就能够了。