步性,本文设计分布式GWAC数据模拟生成器为主从结构,时钟同步器由主节点控制。详细来说,生成器分为主节点、模拟CCD(从节点)、监控端和客户端等4部分组成:1)主节点负责整体时钟同步、与客户端交互、整体集群控制和监控集群数据产生情况;2)模拟CCD负责产生星表数据,将数据发送一级缓存,并向主节点汇报当次数据产生情况;3)监控端负责开启、关闭模拟CCD并监控模拟CCD的性能情况向主节点汇报;4)客户端用于控制整体集群状态,目前设计的有addAbormalStarClient向某个模拟CCD加入异常星、getStatisticsDataClient获取整个集群数据产生情况,并向UI节点输出展示和stopClusterClient用于正常或强制关闭集群所有服务。
2.2两级缓存架构
如图4所示,每个CCD各自产生星表数据,通过各自的交叉认证模块匹配模板星表。随后将认证后的星表发送给一级缓存管理器,一般交叉认证模板和缓存管理器在同一物理服务器上,通过命名管道完成数据交互。由于要实时进行异常检测,缓存管理器将整个星表拆分为若干块,并行进行异常检测,如图4中CCD 2的一级缓存。检测完成后将星表写入二级缓存,供天文科研人员快速查询。综上,本文使用各子CCD数据在本地处理的策略,将整个大星表数据分而治之,在一级缓存中进一步拆分星表,进行实时异常检测和快速写二级缓存。以上即可完成多镜头输出数据不堆积,且实时进行异常检测的目的。
本文使用Redis cluster作为二级缓存,Rediscluster是典型的KV(key-value)式缓存。从不同星的角度看,星表结构本身就是一个典型的KV结构,星名为key,随后的属性为value.从同一颗星的时间序列来看,可以用list结构存储。因此,如图4所示,随时间累积的整个星表是一个典型的KV-list结构,而Redis cluster支持该结构,并通过优化可以达到很好的性能。
Redis cluster是一个无中心的集群结构,每个逻辑的Master节点,一般都会加入一个对应的Slave节点备份其数据以提供读服务,因此会形成很多的〈Master,Slave〉节点对。然而,若某节点对中Master或Slave故障后,虽然整个集群还可以工作,但会存在单点风险。介于此,本文向整个Redis cluster再加入部分Slave节点作为整个集群的后备,以进一步提高集群可用性。如图4中,Slave 1和Slave 4都属于Master 1节点的从节点,若Slave 2节点(Master 2节点的从节点)故障,Slave 4节点会自动迁移为Master 2的从节点,以预防潜在的单点风险。需要注意的是,加入过多的后备Slave节点会提高网络和内存开销,使整体性能下降。
本文 并 不 认 为Redis cluster是 可 靠 的,在Redis cluster故障后,恢复阶段的写操作会引起数据丢失。如图4所示,在Redis cluster恢复阶段,一级缓存管理器将未写完的上一个15s数据挂起实现延时存储,以承接下一次15s的星表数据。该策略可以实现CCD产生数据的及时处理和数据的高可靠性。
着时域天文观测对超长时序、多站点多设备协调观测需求的增长, 全自动、无人值守联合观测成为光学天文观测发展的趋势之一.观测系统调度管理作为其中的重要组成。...
随着时域天文观测对超长时序、多站点多设备协调观测需求的增长, 全自动、无人值守联合观测成为光学天文观测发展的趋势之一.观测系统调度管理作为其中的重要组成, 在提高观测效率。...