一种基于Redis且面向事务机制和多数据中心的数据分发方法和系统

摘要

本发明涉及一种基于Redis且面向事务机制和多数据中心的数据分发方法和系统。本发明提出的基于Redis的数据发布/订阅框架，能够保证跨地跨中心数据分发服务的低延迟、高可靠；本发明提出的基于Redis的数据一致性传递机制，能够解决网络异常或集群节点故障引起的数据丢失和重复问题；本发明提出的优化的Redis的主从同步机制，能够提升在跨中心的不稳定网络环境下数据同步的性能；本发明提出的基于智能日志分析的节点健康状态预测方法和基于服务发现的系统高可用保证方案，能够解决系统组件失效引起的数据分发服务不可用问题。

权利要求

1.一种基于Redis且面向事务机制和多数据中心的数据分发方法，其特征在于，包括以下步骤：

设置由数据分发节点Broker组成的数据分发节点集合BrokerSet，包括第一层BrokerSet和第二层BrokerSet，每一层BrokerSet包含多个Broker节点，每一个Broker节点上设置多个Redis实例，其中一个Redis实例为主实例，其余Redis实例为从实例；

第一层BrokerSet接收数据发布者发布的数据，存储至第一层BrokerSet的Broker节点的Redis实例中；

第一层BrokerSet将存储的数据转发至第二层BrokerSet，存储至第二层BrokerSet的Broker节点的Redis实例中；

根据数据订阅者的订阅，第二层BrokerSet将其Broker节点的Redis实例中存储的数据发送至数据订阅者。

2.如权利要求1所述的方法，其特征在于，所述第一层BrokerSet是核心层BrokerSet，所述第二层BrokerSet是接入层BrokerSet，在核心层BrokerSet、接入层BrokerSet之间设置汇接层BrokerSet；汇接层BrokerSet包含任意扩展的多层BrokerSet；核心层BrokerSet、接入层BrokerSet、汇接层BrokerSet既支持BrokerSet横向扩展，也支持BrokerSet纵向扩展。

3.如权利要求2所述的方法，其特征在于，数据发布者、数据订阅者位于应用层；核心层BrokerSet、接入层BrokerSet、汇接层BrokerSet位于服务层；在管理层，数据发布者、订阅者及BrokerSet与元数据管理器建立长连接，定时发送心跳信息，以便元数据管理器监控系统运行时的状态，评估系统的健康等级；管理层支持对元数据的查询，包括消息的生产情况、消费情况；管理层支持异常报警，能够间接保证系统的正确、稳定运行；管理层支持对系统的性能统计，包括数据的平均分发时间、系统的网络链路状态、每个Broker节点的运行状态。

4.如权利要求1所述的方法，其特征在于，采用基于Redis的数据一致性传递机制，保证数据发布者和订阅者之间的消息一致；所述基于Redis的数据一致性传递机制设计的具体的数据结构包括：版本号、数据更新状态、有效数据、过期数据、超时信息。

5.如权利要求4所述的方法，其特征在于，所述基于Redis的数据一致性传递机制包括：在数据发布者一侧，每一批次对Redis数据库中数据的操作均使用一个全局唯一的版本号Tensor_VERSION进行标识，通过Redis的事务机制严格保护同一批次中数据操作命令的完整性和时序性；在Redis中设置了一个名为“数据更新状态”的Sorted Set，其中Sorted Set的member部分为数据操作命令，而score部分为数据操作命令的全局唯一版本号Tensor_VERSION；

在数据订阅者一侧，每位订阅者均维护了一个本地的版本号Sub_VERSION，数据订阅行为由触发器驱动；触发器定时地比对每位订阅者维护的Sub_VERSION与全局唯一的Tensor_VERSION，若发现某个订阅者本地的Sub_VERSION落后于全局的Tensor_VERSION，则触发该订阅者订阅最新的数据操作命令；

数据操作命令的发布/订阅行为以及对Sub_VERSION和Tensor_VERSION的增加操作均会受到Redis事务机制的严格保护，从而避免数据的重复或丢失。

6.如权利要求4所述的方法，其特征在于，为每条数据操作命令设置确定的生命周期，命令的精确失效时间戳为其发布时间戳加上生命周期；使用一个名为“超时信息”的Sorted Set来存储上述信息，该Sorted Set的member部分为数据操作命令，score部分为这条命令对应的失效时间戳；到当前时刻为止的失效命令被触发器所标注，该触发器定时地从超时信息中获取失效时间戳在负无穷大到当前时刻之间的所有命令，并对相应的数据置失效，特定时间后清除失效数据。

7.如权利要求1所述的方法，其特征在于，采用基于指数回退策略的复制积压缓冲区动态调节方法进行Redis的主从同步优化，避免不稳定网络环境下Redis频繁执行完整重同步操作。

8.如权利要求7所述的方法，其特征在于，使用独立的触发器实时监测Redis主服务器的数据写入速率，同时记录每次Redis主从服务器断开的时长，并计算最近24小时内记录的各次主从服务器断开时长的平均值Aver_Disconnect_Time；并且，触发器以30秒为时间周期计算当前Redis主服务器数据写入速率与Aver_Disconnect_Time的乘积，记为Prediction_Space_Size，若Prediction_Space_Size的值小于复制积压缓冲区的当前大小，则无需执行任何操作，否则将该缓冲区的大小瞬时提升至Prediction_Space_Size。

9.如权利要求7所述的方法，其特征在于，在Redis主服务器的数据写入速率小于设定的阈值时，使用指数回退的策略，将复制积压缓冲区的空间占用降低，所述指数回退策略的数学表达式为：

其中，R_B_Size代表复制积压缓冲区的大小，t代表从执行最近一次复制积压缓冲区空间提升操作的时刻起到当前时刻止所经历的时间间隔。

10.如权利要求1所述的方法，其特征在于，采用基于智能日志分析的方法预测节点健康状态，采用基于服务发现的方法进行故障转移。

11.如权利要求10所述的方法，其特征在于，所述采用基于智能日志分析的方法预测节点健康状态，包括：

在系统的每个物理节点上采集8种信息：Redis进程是否崩溃、过去一定时间的时间窗口内Redis是否有#号日志产生、Redis上下级间心跳是否正常、Redis上下级间链路时延、机器内存占用情况、机器CPU占用情况、机器磁盘占用情况、Redis节点连接的客户端数量；

根据每种信息对系统服务可用性的威胁程度，使用决策树模型对物理节点的健康状态进行预测，在该决策树中，越靠近根节点的因素对系统服务可用性的危害越大；

若在最近一定时间的时间窗口内，某一物理节点的日志中出现上述8种信息之一，则判定该物理节点处于亚健康状态，并降低其在故障转移过程中的备选优先级。

12.如权利要求10所述的方法，其特征在于，所述采用基于服务发现的方法进行故障转移，包括：

实时监测第一层BrokerSet中的所有Redis节点，如果监测到Redis主服务器进入下线状态的时长超过设定的阈值D‑J‑Threshold，则启动选主算法，所述选主算法包含以下步骤：

(1)将已下线的Redis主服务器的所有从服务器保存到一个列表中；

(2)从列表中剔除决策树模型判定的亚健康节点；

(3)从列表中剔除最近一定时间内没有向故障转移系统发送过心跳信息的从服务器；

(4)从列表中剔除所有与已下线主服务器断开时长超过2*D‑J‑Threshold毫秒的从服务器，保证列表中剩余的服务器都没有过早地与主服务器断开连接；

(5)从列表中剩余的从服务器中选取出复制偏移量最大的从服务器，即保存着最新数据的从服务器；

选主成功后，将选取出的该从服务器升级为新的主服务器，并将其余服务器设置为它的从服务器；

同时，定时对第一层BrokerSet中所有的Redis节点做健康检查，及时地感知、保存其中的主从关系，并向数据发布者提供故障转移后最新的Redis主服务器的IP和PORT，当数据发布者需要发布数据时，保证其永远只会向最新的Redis主服务器发起写操作。

13.如权利要求10所述的方法，其特征在于，所述采用基于服务发现的方法进行故障转移，包括：

定时对第二层BrokerSet中所有的Redis节点做健康检查，并维护一份实时的可用Redis节点列表；初始时，所有数据订阅者默认均向本地数据中心的Redis节点发起读请求，获取所需数据；若本地数据中心的Redis节点发生异常，无法继续提供服务，会采用以下故障转移策略，保证受影响的数据订阅者能够获取第二层BrokerSet中新的可用Redis节点：(1)将经过健康检查后返回的所有可用Redis节点信息保存到一个列表中；

(2)从列表中剔除决策树模型判定的亚健康节点；

(3)从列表中剔除订阅者数量大于等于设定阈值的节点；

(4)从列表中剩余的节点中选取出距离数据订阅者地理位置最近的节点；

(5)数据订阅者以该节点作为新的可用Redis节点，向其发起读请求，获取所需数据；

当数据订阅者需要订阅数据时，保证其永远能够获取实时可用的Redis节点发起读操作。

14.一种基于Redis且面向事务机制和多数据中心的数据分发系统，其特征在于，包括由数据分发节点Broker组成的数据分发节点集合BrokerSet，BrokerSet包含第一层BrokerSet和第二层BrokerSet，每一层BrokerSet包含多个Broker节点，每一个Broker节点上设置多个Redis实例，其中一个Redis实例为主实例，其余Redis实例为从实例；第一层BrokerSet和第二层BrokerSet采用权利要求1～13中任一权利要求所述的方法进行数据的发布和订阅。

说明书

一种基于Redis且面向事务机制和多数据中心的数据分发方

法和系统

技术领域

[0001] 本发明属于分布式计算和系统领域，设计了一种基于Redis且面向事务机制和多数据中心的低延迟、高可靠数据分发方法和系统：Tensor。更进一步地，为了解决网络异常
或集群节点故障引起的Tensor数据丢失和重复问题，本发明设计了一种基于Redis的数据
一致性传递机制；为了提升Tensor在跨中心的不稳定网络环境下数据同步的性能，本发明
优化了Redis的主从同步机制；为了保证Tensor数据分发服务的高可用，本发明设计了一种
基于智能日志分析的节点健康状态预测方法和一种基于服务发现的系统高可用保证方案。

背景技术

[0002] 随着云计算、大数据、物联网、移动互联网、人工智能等新兴技术的快速发展与广泛应用，数据中心作为一种新型基础设施，已经成为支撑城市建设和经济运行的中枢系统。
为了保障数据安全、保证服务高可用、提升系统访问性能，大规模分布式系统往往采用跨数
据中心的方式部署，当集群协同工作时，会频繁地跨数据中心交换配置、控制、业务数据等
关键信息。

[0003] 分布式系统间传递的配置、控制、业务数据等信息对时延十分敏感，然而，跨数据中心的部署场景对集群间的低延迟数据分发造成了极大挑战：

[0004] (1)跨地部署的数据中心之间地理距离较远，网络传输延迟较高；

[0005] (2)不同的数据中心间的信息传输需要经过多跳路由，路由的选择和切换会带来较高的数据处理延迟；

[0006] (3)跨地的网络环境中，链路带宽资源争用严重。

[0007] 面对高价值、高敏感的数据，跨中心的数据分发服务在保证低延迟的同时，必须做到高可靠。然而，数据分发服务的可靠性同样面临一系列挑战：

[0008] (1)数据分发服务的底层物理节点面临失效的风险；

[0009] (2)火灾、地震、雷电等不可抗逆因素会对IDC机房的正常运转造成严重威胁，进而破坏数据分发服务的可靠性；

[0010] (3)跨地的网络链路不稳定，网络拥塞、丢包情况十分普遍，会对数据的正常传输造成威胁。

[0011] 目前，在数据分发领域，学术界、工业界的大部分中间件不能同时满足通用场景下跨数据中心关键配置/控制信息和大规模业务数据分发的高可用低延迟的需求。在学术界，
HBaseMQ是首个基于HBase云的高级消息队列，它支持“至少一次”或“最多一次”的消息传递
语义，并且对消息的大小没有限制，然而，HBaseMQ与Hadoop/HDFS生态系统紧耦合，不适合
通用场景下的数据分发服务。HDMQ使用层次型的分布式消息队列，适合跨地环境下的数据
传输，并且支持消息的时序一致性和“精确一次”语义，但是对消息的大小有限制，当数据大
小超过512KB时，无法提供数据分发服务。FaBRiQ是首个基于DHT(distributedhash table)
的分布式消息中间件，使用P2P的方式组成Broker集群，强调易扩展，它不支持消息的时序
一致性，订阅者接收的消息顺序不一定是发布者发送的消息顺序。RDDS基于数据发布/订阅
模型，它能够在不可预测的工作负载下保持系统的鲁棒性、高效性和数据一致性，主要应用
于空间跨度较小的实体间数据传输的场景。CoreDX DDS是目前唯一兼容OMG DDS标准的实
时发布/订阅消息中间件，能够满足分布式系统“在正确时间、正确位置获取正确数据”的需
求，它的主要应用场景是嵌入式系统的数据分发，且侧重于提升服务的整体性能，服务可靠
性相对较低。

[0012] 在工业界，Apache Kafka是一款具有高吞吐量的开源消息中间件，相同分区内的消息具有顺序性，Kafka支持“至少一次”或“最多一次”的消息传递语义，能够通过横向增加
Broker节点数以满足不断增长的数据处理需求，然而面向跨地跨中心通信的场景，其消息
传输服务表现出较大的延迟。RocketMQ是在阿里巴巴特定业务场景的驱动下应运而生的，
但是和Kafka一样，为了追求消息的高吞吐和低延迟，RocketMQ舍弃了系统的可靠性。
Amazon SQS是目前商业界应用广泛的消息中间件，具有良好的扩展性和服务可用性，支持
“至少一次”的消息传递语义，SQS对消息的大小有限制，为512KB。Tencent CMQ提供数据高
可靠、业务高可用、处理高性能的分布式消息队列服务，具备百亿级数据堆积和弹性扩容的
能力，然而Tencent CMQ使用两地三中心冷备的方式容错，故障恢复所需的时间较长。
Dragonfly是基于智能P2P技术的通用文件分发系统，能够有效解决大规模文件分发耗时
高、成功率低、带宽浪费等难题，进而有效提升跨中心服务发布部署、数据预热、镜像分发的
效率，Dragonfly对容器、镜像类大文件传输的支持很好，对增量类型配置/控制信息分发的
支撑相对较弱。

发明内容

[0013] 为了满足跨地跨中心数据分发服务的低延迟、高可靠的需求，本发明设计了一种基于Redis且面向事务机制和多数据中心的数据分发方法和系统。

[0014] 本发明提出了一套基于Redis的低延迟、高可靠数据发布/订阅框架：Tensor。本发明使用开源的经典NoSQL内存数据库Redis来存储、分发跨中心的大规模分布式系统中的关
键数据。Redis提供的键值数据的处理方式能够很好地满足数据中心的配置/控制等关键信
息的存储需求；同时，Redis提供了灵活的主从同步功能，其中，全量同步用于处理初次复制
的场景，增量同步用于处理服务器断线后重连的复制场景，能够为不稳定网络环境下的数
据传输提供一定的性能支撑。

[0015] 更进一步地，为了解决网络异常或集群节点故障引起的Tensor数据丢失和重复问题，本发明设计了一种基于Redis的数据一致性传递机制；为了提升Tensor在跨中心的不稳
定网络环境下数据同步的性能，本发明优化了Redis的主从同步机制；为了保证Tensor数据
分发服务的高可用，本发明设计了一种基于智能日志分析的节点健康状态预测方法和一种
基于服务发现的系统高可用保证方案。

[0016] 具体地，本发明采用的技术方案如下：

[0017] 一种基于Redis且面向事务机制和多数据中心的数据分发方法，包括以下步骤：

[0018] 设置由数据分发节点Broker组成的数据分发节点集合BrokerSet，包括第一层BrokerSet和第二层BrokerSet，每一层BrokerSet包含多个Broker节点，每一个Broker节点
上设置多个Redis实例，其中一个Redis实例为主实例，其余Redis实例为从实例；

[0019] 第一层BrokerSet接收数据发布者发布的数据，存储至第一层BrokerSet的Broker节点的Redis实例中；

[0020] 第一层BrokerSet将存储的数据转发至第二层BrokerSet，存储至第二层BrokerSet的Broker节点的Redis实例中；

[0021] 根据数据订阅者的订阅，第二层BrokerSet将其Broker节点的Redis实例中存储的数据发送至数据订阅者。

[0022] 进一步地，所述第一层BrokerSet是核心层BrokerSet，所述第二层BrokerSet是接入层BrokerSet，在核心层BrokerSet、接入层BrokerSet之间设置汇接层BrokerSet；汇接层
BrokerSet包含任意扩展的多层BrokerSet；核心层BrokerSet、接入层BrokerSet、汇接层
BrokerSet既支持BrokerSet横向扩展，也支持BrokerSet纵向扩展。

[0023] 进一步地，数据发布者、数据订阅者位于应用层；核心层BrokerSet、接入层BrokerSet、汇接层BrokerSet位于服务层；在管理层，数据发布者、订阅者及BrokerSet与元
数据管理器建立长连接，定时发送心跳信息，以便元数据管理器监控系统运行时的状态，评
估系统的健康等级；管理层支持对元数据的查询，包括消息的生产情况、消费情况等；管理
层支持异常报警，能够间接保证系统的正确、稳定运行；管理层支持对系统的性能统计，包
括数据的平均分发时间、系统的网络链路状态、每个Broker节点的运行状态。

[0024] 进一步地，采用基于Redis的数据一致性传递机制，保证数据发布者和订阅者之间的消息一致；所述基于Redis的数据一致性传递机制设计的具体的数据结构包括：版本号、
数据更新状态、有效数据、过期数据、超时信息。

[0025] 进一步地，所述基于Redis的数据一致性传递机制包括：

[0026] 在数据发布者一侧，每一批次对Redis数据库中数据的操作均使用一个全局唯一的版本号Tensor_VERSION进行标识，通过Redis的事务机制严格保护同一批次中数据操作
命令的完整性和时序性；在Redis中设置了一个名为“数据更新状态”的Sorted Set，其中
Sorted Set的member部分为数据操作命令，而score部分为该批次数据操作命令的全局唯
一版本号Tensor_VERSION；

[0027] 在数据订阅者一侧，每位订阅者均维护了一个本地的版本号Sub_VERSION，数据订阅行为由触发器驱动；触发器定时地比对每位订阅者维护的Sub_VERSION与全局唯一的
Tensor_VERSION，若发现某个订阅者本地的Sub_VERSION落后于全局的Tensor_VERSION，则
触发该订阅者订阅最新的数据操作命令；

[0028] 数据操作命令的发布/订阅行为以及对Sub_VERSION和Tensor_VERSION的增加操作均会受到Redis事务机制的严格保护，从而避免数据的重复或丢失。

[0029] 进一步地，为每条数据操作命令设置确定的生命周期，命令的精确失效时间戳为其发布时间戳加上生命周期；使用一个名为“超时信息”的Sorted Set来存储上述信息，该
Sorted Set的member部分为数据操作命令，score部分为这条命令对应的失效时间戳；到当
前时刻为止的失效命令被触发器所标注，该触发器定时地从超时信息中获取失效时间戳在
负无穷大到当前时刻之间的所有命令，并对相应的数据置失效，特定时间后清除该部分失
效数据。

[0030] 进一步地，采用基于指数回退策略的复制积压缓冲区动态调节方法进行Redis的主从同步优化，避免不稳定网络环境下Redis频繁执行完整重同步操作。

[0031] 进一步地，使用独立的触发器实时监测Redis主服务器的数据写入速率，同时记录每次Redis主从服务器断开的时长，并计算最近24小时内记录的各次主从服务器断开时长
的平均值Aver_Disconnect_Time；并且，触发器以30秒为时间周期计算当前Redis主服务器
数据写入速率与Aver_Disconnect_Time的乘积，记为Prediction_Space_Size，若
Prediction_Space_Size的值小于复制积压缓冲区的当前大小，则无需执行任何操作，否则
将该缓冲区的大小瞬时提升至Prediction_Space_Size。

[0032] 进一步地，在Redis主服务器的数据写入速率小于设定的阈值时，使用指数回退的策略，将复制积压缓冲区的空间占用降低到一个较低的水平。

[0033] 进一步地，采用基于智能日志分析的方法预测节点健康状态，采用基于服务发现的方法进行故障转移。

[0034] 进一步地，所述采用基于智能日志分析的方法预测节点健康状态，包括：

[0035] 在系统的每个物理节点上采集8种信息：Redis进程是否崩溃、过去一定时间的时间窗口内Redis是否有#号日志产生、Redis上下级间心跳是否正常、Redis上下级间链路时
延、机器内存占用情况、机器CPU占用情况、机器磁盘占用情况、Redis节点连接的客户端数
量；

[0036] 根据每种信息对系统服务可用性的威胁程度，使用决策树模型对物理节点的健康状态进行预测，在该决策树中，越靠近根节点的因素对系统服务可用性的危害越大。

[0037] 若在最近一定时间的时间窗口内，某一物理节点的日志中出现上述8种信息之一，则判定该物理节点处于亚健康状态，并降低其在故障转移过程中的备选优先级。

[0038] 进一步地，所述采用基于服务发现的方法进行故障转移，包括：

[0039] 实时监测第一层BrokerSet中的所有Redis节点，如果监测到Redis主服务器进入下线状态的时长超过设定的阈值D‑J‑Threshold，则启动选主算法，所述选主算法包含以下
步骤：

[0040] (1)将已下线的Redis主服务器的所有从服务器保存到一个列表中；

[0041] (2)从列表中剔除决策树模型判定的亚健康节点；

[0042] (3)从列表中剔除最近一定时间内没有向故障转移系统发送过心跳信息的从服务器；

[0043] (4)从列表中剔除所有与已下线主服务器断开时长超过2*D‑J‑Threshold毫秒的从服务器，保证列表中剩余的服务器都没有过早地与主服务器断开连接；

[0044] (5)从列表中剩余的从服务器中选取出复制偏移量最大的从服务器，即保存着最新数据的从服务器；

[0045] 选主成功后，将选取出的该从服务器升级为新的主服务器，并将其余服务器设置为它的从服务器；

[0046] 同时，定时对第一层BrokerSet中所有的Redis节点做健康检查，及时地感知、保存其中的主从关系，并向数据发布者提供故障转移后最新的Redis主服务器的IP和PORT，当数
据发布者需要发布数据时，保证其永远只会向最新的Redis主服务器发起写操作。

[0047] 进一步地，所述采用基于服务发现的方法进行故障转移，还包括：

[0048] 定时对第二层BrokerSet中所有的Redis节点做健康检查，并维护一份实时的可用Redis节点列表；初始时，所有数据订阅者默认均向本地数据中心的Redis节点发起读请求，
获取所需数据；若本地数据中心的Redis节点发生异常，无法继续提供服务，会采用以下故
障转移策略，保证受影响的数据订阅者能够获取第二层BrokerSet中新的可用Redis节点：

[0049] (1)将经过健康检查后返回的所有可用Redis节点信息保存到一个列表中；

[0050] (2)从列表中剔除决策树模型判定的亚健康节点；

[0051] (3)从列表中剔除订阅者数量大于等于设定阈值的节点；

[0052] (4)从列表中剩余的节点中选取出距离数据订阅者地理位置最近的节点；

[0053] (5)数据订阅者以该节点作为新的可用Redis节点，向其发起读请求，获取所需数据；

[0054] 当数据订阅者需要订阅数据时，保证其永远能够获取实时可用的Redis节点发起读操作。

[0055] 一种基于Redis且面向事务机制和多数据中心的数据分发系统，其包括由数据分发节点Broker组成的数据分发节点集合BrokerSet，BrokerSet包含第一层BrokerSet和第
二层BrokerSet，每一层BrokerSet包含多个Broker节点，每一个Broker节点上设置多个
Redis实例，其中一个Redis实例为主实例，其余Redis实例为从实例；第一层BrokerSet和第
二层BrokerSet采用本发明方法进行数据的发布和订阅。

[0056] 本发明的有益效果如下：

[0057] 本发明提出的基于Redis的低延迟、高可靠数据发布/订阅框架，使用开源的经典NoSQL内存数据库Redis来存储、分发跨中心的大规模分布式系统中的关键数据；Redis提供
的键值数据的处理方式能够很好地满足数据中心的配置/控制等关键信息的存储需求；同
时，Redis提供了灵活的主从同步功能，其中，全量同步用于处理初次复制的场景，增量同步
用于处理服务器断线后重连的复制场景，能够为不稳定网络环境下的数据传输提供一定的
性能支撑。本发明提出的基于Redis的数据一致性传递机制，能够解决网络异常或集群节点
故障引起的Tensor数据丢失和重复问题；本发明提出的优化的Redis的主从同步机制，能够
提升Tensor在跨中心的不稳定网络环境下数据同步的性能；本发明提出的基于智能日志分
析的节点健康状态预测方法和基于服务发现的系统高可用保证方案，能够保证Tensor数据
分发服务的高可用。

附图说明

[0058] 图1是基于Redis的低延迟、高可靠数据发布/订阅框架Tensor的基本架构图。

[0059] 图2是Tensor的详细结构图。

[0060] 图3是Tensor的模块设计图。

[0061] 图4是Tensor的数据一致性传递机制示意图。

[0062] 图5是Redis的复制积压缓冲区基本结构图。

[0063] 图6是基于智能日志分析的节点健康状态预测示意图。

[0064] 图7是Tensor的Tire1层级高可用保证方案示意图。

[0065] 图8是Tensor的Tire2层级高可用保证方案示意图。

具体实施方式

[0066] 为使本发明的上述目的、特征和优点能够更加明显易懂，下面通过具体实施例和附图，对本发明做进一步说明。

[0067] 1)Tensor的基本架构

[0068] 本发明的基于Redis的低延迟、高可靠数据发布/订阅框架称为Tensor，其基本架构如图1所示，其中DLRL表示数据本地重构层，DCPS表示以数据为中心的发布/订阅层。
Tensor主要分为三个部分：数据发布者、数据订阅者和数据分发节点(Broker)。其详细结构
如图2所示，其中数据发布者与数据生产者交互，数据订阅者与数据消费者交互，Broker指
的是数据分发集群中的物理节点，每一个Broker节点上均启动了多个Redis实例，其中一个
实例为主实例，其余的为从实例。本发明将同一层次中的所有Broker节点称为一个数据分
发节点集合(BrokerSet)。Tensor中的相应术语的解释如表1所示。

[0069] 表1 Tensor中的术语解释

[0070]

[0071] 在模块设计层面，Tensor共分为三个层次：应用层、管理层和服务层，如图3所示。在应用层，本发明提供了通用的应用层接口，规范、清楚地定义了各业务子系统之间的数据
通信模式；与此同时，本发明还提供了轻量级的客户端，包含多种类型数据的发布、订阅接
口。该接口和客户端会按照后文2.1节中规定的数据格式和存储方法进行数据的发布/订阅
操作。

[0072] 在管理层，数据发布者、订阅者及BrokerSet与管理者(即图3中的元数据管理器)建立长连接，定时发送心跳信息，以便管理者监控系统运行时的状态，评估系统的健康等
级；另外，管理层支持对元数据的查询，包括消息的生产情况、消费情况等；同时，管理层支
持异常报警，能够间接保证系统的正确、稳定运行；再者，管理层支持对系统的性能统计，包
括数据的平均分发时间、系统的网络链路状态、每个Broker节点的运行状态等。

[0073] 服务层是数据分发服务的核心，由上文所述的BrokerSet构成，本发明设计了三层BrokerSet以满足跨地数据分发的需求，依次为：核心层BrokerSet、汇接层BrokerSet和接
入层BrokerSet，其定义分别如下：

[0074] a.核心层BrokerSet：连接数据发布者；

[0075] b.汇接层BrokerSet：为了区分与数据发布者建立连接的核心层BrokerSet以及与数据订阅者建立连接的接入层BrokerSet，本发明将中间可以任意扩展的多层BrokerSet命
名为汇接层BrokerSet。如果数据订阅者数量较少或者网络规模较小，汇接层BrokerSet可
以不部署；

[0076] c.接入层BrokerSet：连接数据订阅者。

[0077] 由于该架构的多层次设计，Tensor系统既支持横向扩展，也支持纵向扩展。当业务数据量增加，单数据中心无法满足分布式系统的规模时，本架构可以横向增加同城或者异
地的Broker节点数量，实现系统的横向扩展；当数据订阅者数量增加或者网络规模增大，数
据需要跨地、甚至跨运营商传输时，本架构可以纵向增加BrokerSet的层数以满足需求。

[0078] 2)具体的方法设计

[0079] 2.1一种基于Redis的数据一致性传递机制

[0080] 为了避免物理节点、网络或者IDC机房的异常造成数据发布者和订阅者之间的消息不一致，本发明设计了一种基于Redis事务机制的异步数据发布/订阅方法，数据传输过
程中的每一步均会受到事务机制的严格保护。

[0081] 该方法的基本架构如图4所示，Tensor的数据分发服务支持多种不同的业务，每种业务的数据分别存储在不同的Redis数据库中，以有效实现业务隔离。表2展示了为了实现
数据一致性传递机制，本发明设计的具体的Redis数据结构。

[0082] 表2 Redis数据结构的具体设计

[0083]

[0084] 在数据发布者一侧，每一批次对Redis数据库中数据的操作均会使用一个全局唯一的版本号进行标识，即表2中的Tensor_VERSION，数据操作命令被分为两种类型：增加和
删除，这两种命令的格式分别为“ADD,ID”与“DEL,ID”，其中字符“ADD”和“DEL”指代数据操
作类型，而“ID”唯一标识数据库中的一条数据。每一次批次操作均由上述的一条或若干条
命令组成，Redis的事务机制会严格保护同一批次中数据操作命令的完整性和时序性。本发
明在Redis中设置了一个名为“Tensor_UPDATE_STATUS”的Sorted Set(有序集合)，其中
Sorted Set的member(成员)部分为数据操作命令，而score(分数)部分为该批次数据操作
命令的全局唯一版本号，即其对应的Tensor_VERSION。每当数据发布者向Tensor发布属于
同一批次的一组数据操作命令后，Tensor_VERSION会增加1，该次数据发布操作会被其对应
的Tensor_VERSION所唯一标识。

[0085] 在数据订阅者一侧，每位订阅者均维护了一个本地的版本号，记为Sub_VERSION，它们的数据订阅行为由名为Data_Traverser的触发器驱动。Data_Traverser定时地比对每
位订阅者维护的Sub_VERSION与全局唯一的Tensor_VERSION，若发现某个订阅者本地的
Sub_VERSION落后于全局的Tensor_VERSION，则会触发该订阅者向Tensor订阅最新的数据
操作命令，具体来说，使用Redis的ZRANGEBYSCORE命令从名为“Tensor_UPDATE_STATUS”的
Sorted Set中获取版本号在Sub_VERSION和Tensor_VERSION之间(包括Tensor_VERSION但
不包括Sub_VERSION)的数据。每当数据订阅者向Tensor订阅某个版本号的数据成功后，该
订阅者本地的Sub_VERSION会增加1。

[0086] 本发明中，数据操作命令的发布/订阅行为以及对Sub_VERSION和Tensor_VERSION的增加操作均会受到Redis事务机制的严格保护，从而避免数据的重复或丢失。

[0087] 为了保证Tensor对于机器内存资源的低消耗率，本发明为每条数据操作命令设置了确定的生命周期，命令的精确失效时间戳为其发布时间戳加上生命周期，使用另一个名
为“Tensor_EXPIRE_TIMER”的Sorted Set来存储上述信息，该Sorted Set的member部分为
数据操作命令，score部分为这条命令对应的失效时间戳。Tensor中到当前时刻为止的失效
命令会被名为“Data_Scavenger”的触发器所标注，该触发器会定时地使用ZRANGEBYSCORE
命令从Tensor_EXPIRE_TIMER中获取失效时间戳在负无穷大到当前时刻之间的所有命令，
并使用EXPIRE命令对相应的数据置失效，特定时间后，Redis会清除该部分失效数据。

[0088] 2.2一种面向不稳定网络环境的Redis主从同步优化方法

[0089] 在生产环境中，Tensor每天会执行几十至上百次数据分发任务，其中三至四次操作是传递数据类型的大文件，单个文件的大小在1.5GB左右，其余各次数据分发任务均是传
递配置/控制类型的小消息，单次任务的数据传输量在几百KB至几MB之间。

[0090] 在Tensor中，数据分发的效率很大程度上取决于Redis主从同步的性能，Redis进行数据同步操作的原因在于主从服务器间的状态不一致(这里的主服务器是指在Redis主
从模式中被复制的服务器，从服务器是指对主服务器进行复制的服务器，下同)。主从服务
器正常连接时，使用命令传播(Command Propagate)的方式传输数据，在这种状态下，主服
务器不仅会将写命令发送给所有从服务器，还会将其入队到复制积压缓冲区(Replication 
Backlog)中。复制积压缓冲区是由Redis主服务器维护的一个固定长度、先进先出的环状队
列，如图5所示。入队时，使用Append(追加)的方式，从Tail指针(尾指针)处插入新数据，当
队列空间被写满后，从Head指针(头指针)处覆盖旧数据。主服务器的复制积压缓冲区中保
存着一部分最近传播的写命令。

[0091] 在Redis中，执行复制的双方——主服务器和从服务器会分别维护一个复制偏移量。在跨地的网络环境下，数据中心间的链路不稳定，Redis主从服务器间的连接异常几乎
不可避免。当主从服务器断开重连后，从服务器会将自身所维护的复制偏移量发送给主服
务器，将该复制偏移量记作Offset_Recv。在主服务器中，如果接收的从服务器的复制偏移
量Offset_Recv与主服务器自身所维护的复制偏移量之间的命令仍存在于复制积压缓冲区
中，则Redis执行部分重同步操作(将复制积压缓冲区中的该部分命令直接传播给从服务
器)，否则，Redis执行完整重同步操作。

[0092] 为了在最大程度上避免不稳定网络环境下Redis频繁执行完整重同步操作，本发明设计了一种基于指数回退策略的复制积压缓冲区动态调节方法：

[0093] 记Redis复制积压缓冲区的大小为R_B_Size，将其初始值设置为10MB(超过单次小消息数据分发任务的最大数据传输量)，并使用一个独立的触发器Buffer_Regulator实时
监测Redis主服务器的数据写入速率。同时，记录每次Redis主从服务器断开的时长，并计算
最近24小时内记录的各次主从服务器断开时长的平均值，记为Aver_Disconnect_Time。

[0094] 触发器Buffer_Regulator以30秒为时间周期计算当前Redis主服务器数据写入速率与Aver_Disconnect_Time的乘积，记为Prediction_Space_Size，如果Prediction_
Space_Size的值小于复制积压缓冲区的当前大小，则无需执行任何操作；否则将复制积压
缓冲区的大小瞬时提升至Prediction_Space_Size。

[0095] 以上将R_B_Size提升至Prediction_Space_Size是指在Redis主服务器数据写入速率很大(比如大于一设定的阈值)时，对复制积压缓冲区进行空间提升的操作。绝大多数
时间窗口内(执行配置/控制类型小消息数据分发任务或无任务执行时)，Redis主服务器的
数据写入速率很小(比如小于一设定的阈值)，这种情况下，本发明使用指数回退的策略，将
复制积压缓冲区的空间占用降低到一个较低的水平(10MB)，避免服务器内存资源的浪费。
该指数回退模型的数学表达式见公式(1)，其中，R_B_Size代表复制积压缓冲区的大小，t代
表从执行最近一次复制积压缓冲区空间提升操作的时刻起到当前时刻止所经历的时间间
隔。

[0096]

[0097] 2.3一种基于智能日志分析和服务发现方法的系统高可用保证方案

[0098] 面向跨地跨中心的大规模数据分发场景，Tensor的可靠数据分发服务面临着严峻挑战。为了保证服务的高可用，当系统组件失效时，必须及时进行故障转移。在大规模分布
式系统中，系统组件失效前往往会有一系列较为明显的特征，例如心跳异常，链路时延过
高，CPU、内存、磁盘长期满负荷工作等。凭借这些特征，可以对组件的失效状态进行预判，在
进行故障转移时，应当有意识地避开准失效组件，目前，大多数常见的故障转移方法并没有
对此进行充分探索。

[0099] 在本发明中，使用基于智能日志分析的方法预测节点健康状态，使用基于服务发现的方法进行故障转移，并以前者作为后者的策略支撑，保证跨地跨中心场景下Tensor数
据分发服务的高可用。

[0100] 在Tensor系统的每个物理节点(即Broker节点)上采集“Redis进程是否崩溃”、“过去2分钟的时间窗口内Redis是否有#号日志产生”、“Redis上下级间心跳是否正常”、“Redis
上下级间链路时延”、“机器内存占用情况”、“机器CPU占用情况”、“机器磁盘占用情况”、
“Redis节点连接的客户端数量”这8种不同的信息，其中每种信息对Tensor数据分发服务可
用性的威胁程度如表3所示。

[0101] 表3选取的日志信息及其对Tensor数据分发服务可用性的威胁程度

[0102]

[0103] 使用图6所示的决策树模型对节点的健康状态进行预测，在该决策树中，越靠近根节点的因素对Tensor服务可用性的危害越大。

[0104] 若在最近30分钟的时间窗口内，某一物理节点的日志中出现上述八种信息之一，本发明则会判定该节点处于亚健康状态，并降低其在故障转移过程中的备选优先级。

[0105] 接下来，介绍本发明设计的基于服务发现的系统高可用保证方案，该方案分为Tier1，Tier2两个层级，其中Tier1层级面向数据发布服务，Tier2层级面向数据订阅服务。

[0106] Tier1层级高可用保证方案的基本原理如图7所示，本发明设计并实现的故障转移系统会实时监测第一层BrokerSet中的所有Redis节点，如果监测到Redis主服务器进入下
线状态的时长超过设定的阈值(D‑J‑Threshold)，则会启动选主算法，本发明提出的选主算
法包含以下五个基本步骤：

[0107] (1)将已下线的Redis主服务器的所有从服务器保存到一个列表中；

[0108] (2)从列表中剔除本发明中决策树模型(图6)判定的亚健康节点；

[0109] (3)从列表中剔除最近10秒内没有向故障转移系统发送过心跳信息的从服务器；

[0110] (4)从列表中剔除所有与已下线主服务器断开时长超过2*D‑J‑Threshold毫秒的从服务器，保证列表中剩余的服务器都没有过早地与主服务器断开连接；

[0111] (5)从列表中剩余的从服务器中选取出复制偏移量最大的从服务器(即保存着最新数据的从服务器)。

[0112] 选主成功后，本发明的故障转移系统会将该从服务器升级为新的主服务器，并将其余服务器设置为它的从服务器。当下线的旧的主服务器重新上线后，会及时确认自己的
新身份(新的主服务器的从服务器)。

[0113] 图7中的第一层BrokerSet以2秒为时间周期，定时地与Consul Cluster(Consul集群)交互，Consul Cluster对所有的Redis节点做健康检查，并及时地感知、保存其中的主从
关系。

[0114] 当数据发布者需要发布数据时，它首先向Consul Cluster发起HTTP请求，Consul Cluster返回第一层BrokerSet中Redis主服务器的IP和PORT。接下来，数据发布者会向
Redis主服务器发起数据写操作(图7中用“Write Master”表示)。

[0115] 当第一层BrokerSet中发生故障转移时，Consul Cluster的健康检查机制会及时感知Redis主从关系的变化，如果有数据发布者发起新的HTTP请求，Consul Cluster返回的
是新的Redis主服务器的IP和PORT，此过程对数据发布者透明。

[0116] 无论第一层BrokerSet中是否发生节点故障，数据发布者永远只会向故障转移后最新的Redis主服务器发起写操作，由此，数据写入服务的高可用得到保障。

[0117] Tier2层级高可用保证方案的基本原理如图8所示，其中，第二层BrokerSet以5秒为时间周期，定时地与Consul Cluster交互，Consul Cluster对所有的Redis节点做健康检
查，并维护一份实时的可用Redis节点列表(第二层BrokerSet中节点数量较多，因此本发明
适当延长了心跳周期，以减轻Consul Cluster的负担)。

[0118] 初始时，所有数据订阅者默认均向本地数据中心的Redis节点发起读请求，获取所需数据。若本地数据中心的Redis节点发生异常，无法继续提供服务，受影响的数据订阅者
会向Consul Cluster发起HTTP请求，获取新的可用Redis节点。

[0119] Consul Cluster每次均会向请求者返回所有可用的Redis节点以及它们的地理位置信息，本发明设计的故障转移策略包含以下几个基本步骤：

[0120] (1)将Consul Cluster返回的所有节点信息保存到一个列表中；

[0121] (2)从列表中剔除本发明中决策树模型(图6)判定的亚健康节点；

[0122] (3)从列表中剔除订阅者数量>＝10的节点；

[0123] (4)从列表中剩余的节点中选取出距离数据订阅者地理位置最近的节点；

[0124] (5)数据订阅者以该节点作为新的可用Redis节点，向其发起读请求，获取所需数据。

[0125] 无论第二层BrokerSet中是否发生节点故障，数据订阅者永远能够获取实时可用的Redis节点并发起读操作，由此，数据读取服务的高可用得到保障。

[0126] 综上，本发明的主要关键点和创新点包括：

[0127] 1)基于Redis的低延迟、高可靠数据发布/订阅框架Tensor，及其基本架构设计；

[0128] 2)基于Redis事务机制的数据一致性传递机制；

[0129] 3)面向不稳定网络环境的Redis主从同步优化方法；

[0130] 4)基于智能日志分析和服务发现方法的系统高可用保证方案。

[0131] 尽管为说明目的公开了本发明的具体实施例和附图，其目的在于帮助理解本发明的内容并据以实施，但是本领域的技术人员可以理解：在不脱离本发明及所附的权利要求
的精神和范围内，各种替换、变化和修改都是可能的。本发明不应局限于本说明书最佳实施
例和附图所公开的内容，本发明的保护范围以权利要求书界定的范围为准。