步性，本文设计分布式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产生数据的及时处理和数据的高可靠性。
