CN112099977A - 一种分布式跟踪***的实时数据分析引擎 - Google Patents
一种分布式跟踪***的实时数据分析引擎 Download PDFInfo
- Publication number
- CN112099977A CN112099977A CN202011058075.7A CN202011058075A CN112099977A CN 112099977 A CN112099977 A CN 112099977A CN 202011058075 A CN202011058075 A CN 202011058075A CN 112099977 A CN112099977 A CN 112099977A
- Authority
- CN
- China
- Prior art keywords
- data
- module
- real
- tracking system
- analysis engine
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000007405 data analysis Methods 0.000 title claims abstract description 56
- 238000012545 processing Methods 0.000 claims abstract description 57
- 230000005540 biological transmission Effects 0.000 claims abstract description 16
- 238000006116 polymerization reaction Methods 0.000 claims abstract description 10
- 230000002776 aggregation Effects 0.000 claims abstract description 9
- 238000004220 aggregation Methods 0.000 claims abstract description 9
- 230000004044 response Effects 0.000 claims abstract description 6
- 230000007246 mechanism Effects 0.000 claims description 23
- 238000000034 method Methods 0.000 claims description 16
- 238000013480 data collection Methods 0.000 claims description 13
- 230000008569 process Effects 0.000 claims description 13
- 238000013500 data storage Methods 0.000 claims description 11
- 238000005192 partition Methods 0.000 claims description 10
- 238000011144 upstream manufacturing Methods 0.000 claims description 6
- 230000006854 communication Effects 0.000 claims description 3
- 238000004891 communication Methods 0.000 claims description 3
- 239000000284 extract Substances 0.000 claims description 2
- 238000012546 transfer Methods 0.000 claims description 2
- 238000007726 management method Methods 0.000 description 8
- 238000002474 experimental method Methods 0.000 description 7
- 238000002955 isolation Methods 0.000 description 6
- 238000005457 optimization Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000009825 accumulation Methods 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 238000011156 evaluation Methods 0.000 description 3
- 238000010223 real-time analysis Methods 0.000 description 3
- 241000529895 Stercorarius Species 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000005065 mining Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种分布式跟踪***的实时数据分析引擎，包括数据处理模块及与数据处理模块连接的数据采集模块和数据分析模块，所述的数据采集模块和数据处理模块通过数据接收模块连接，数据接收模块和数据处理模块之间采用Kafka集群作为中间层，所述Kafka与数据接收模块中的数据接收节点之间采用异步传输方式，Kafka统计特定时间间隔内每个URL的访问的响应时间，数据处理模块采用基于时间窗口的数据预聚合，通过比较响应时间对应的字段，进行数据聚合，并将新数据添加到聚合的结果中，数据预聚合的结果存储在Redis缓存中，提取数据汇总结果并存储，同时删除Redis缓存中的数据。
Description
技术领域
本发明涉及分布式应用程序技术领域，尤其是涉及了一种分布式跟踪***的实时数据分析引擎。
背景技术
典型的分布式跟踪***主要由3个部分组成：数据收集、数据存储、数据展示。根据分布式***的大小不同，每一部分的结构又还会根据实际情况进行相应的变化。例如，对于大规模分布式***而言，数据存储可分为实时数据和全量数据两部分，实时数据用于故障排查（Trouble Shooting），全量数据用于***优化；数据收集除了支持平台无关和开发语言无关***的数据收集，还包括异步数据收集；数据展示涉及到数据的挖掘与分析。分布式跟踪***使用户能够通过分布在多个应用程序、服务和数据库以及代理等中介上的软件***来进行跟踪请求。这样做的好处是可以更深入地了解软件***中发生的情况。这些***生成图形表示，显示请求步骤和花费的时间资源。
现代微服务体系结构技术的最新进展使构建大规模分布式应用程序成为可能。通过利用大量协作的服务节点以分散的方式，应用程序可以潜在地实现高可伸缩性、可用性、可靠性和QoS/性能。分布式跟踪***在微服务执行期间收集数据，后端数据分析引擎收集、分析数据并构建服务节点的调用拓扑序列。但是，收集的数据的无序性、相关性、并发性和突发性给后端数据分析引擎带来了以下挑战：1）需要有效的数据传输和并发的数据接收。对于数据收集节点来说，使用HTTP请求的数据传输效率很低，由于分布式跟踪***中收集数据的并发性，数据接收节点应支持并发数据并提供可伸缩性；2）分布式应用中微服务调用拓扑的实时分析。从分布式跟踪***中收集的用于调用拓扑的数据是无序的和相关的，传统的数据存储和分析方案可以相互协作的对相关和无序的数据进行分析，但是，它们只提供离线数据处理，并且在处理期间需要密集的I/O操作，它们不能有效地支持分布式跟踪***的实时分析。传统的数据流处理框架由于不包含缓存，不适用于分布式跟踪***的实时分析；3）在密集的数据存储量中进行高效的数据查询，分布式跟踪***的数据分析引擎无法保证每次数据突发时所收集数据的完整性，这导致了数据存储的负担，并可能损害数据查询的效率；4）数据接收和处理速度不匹配。数据处理的速度远低于数据接收的速度。这可能会导致数据传输效率低和数据丢失。
目前的分布式跟踪***理论大多数基于Google的Dapper框架， 其设计是为了追踪在线服务***中的请求处理过程：例如在搜索***场景中，对于快速准确定位出现异常的环节，是十分关键的。但是Dapper只是为了解决请求调用这个单一问题，并不能提供全面的方案。
Zipkin 是基于Dapper 论文设计而来一款分布式实时数据跟踪***。Zipkin通过在事务上下文中仅传输跟踪ID来通知接收者表示正在进行跟踪，从而保证***的安全。然后将每个报告器中收集的数据异步传输到收集器。收集器将这些数据存储在数据库中，并且Web UI通过可以使用的格式将该数据呈现出来。
Jaeger受到了Dapper和OpenZipkin的启发，是用于监控和排查微服务的分布式***。Jaeger的架构与Zipkin类似，不同之处在于它在每个主机上都有一个本地聚合数据的代理，代理通过UDP连接接收数据，并将其批处理后发送给收集器。收集器以Thrift协议的形式接收该数据，并将该数据存储在Cassandra或Elasticsearch中。查询服务可以直接访问数据存储并将该信息提供给Web UI。但是该分布式***接入过程有存在一定的侵入性，并且更多专注于链路追踪，日志和指标功能支持比较有限。
在传统的分布式跟踪***数据分析引擎体系结构中，数据处理模块直接处理收集到的数据。然而，数据处理逻辑通常是复杂的。数据处理的速度很可能跟不上数据收集的速度。在***运行的早期阶段，***资源通常是充足的。收集到的数据可以直接存储在内存中。然而，一旦内存变得不足，数据丢失或阻塞的情况很可能发生。数据阻塞导致数据收集模块内存中的数据累积。这将进一步影响整个数据分析引擎的性能。因此，在分布式跟踪***中，传统的数据分析引擎体系结构已不能满足实时数据分析的需求。
发明内容
为解决现有技术的不足，支持实时数据分析，本发明采用如下的技术方案：
一种分布式跟踪***的实时数据分析引擎，包括数据处理模块及与数据处理模块连接的数据采集模块和数据分析模块，所述的数据采集模块和数据处理模块通过数据接收模块连接，数据接收模块和数据处理模块之间采用Kafka集群作为中间层，用于处理数据接收与处理之间的速度不匹配，集群模式部署以负载平衡消息，避免了单点故障等问题，数据采集模块包括一组数据采集节点，数据接收模块包括一组数据接收节点，所述Kafka与数据接收模块中的数据接收节点之间采用异步传输方式，保证数据接收的效率，使用来自Kafka集群的服务调用数据来统计特定时间间隔内每个URL访问的响应时间，数据处理模块采用基于时间窗口的数据预聚合，通过比较响应时间对应的字段，进行数据聚合，并将新数据添加到聚合的结果中，数据预聚合的结果存储在Redis缓存中，及时提取数据汇总结果并存储，同时删除Redis缓存中的数据。基于时间窗口的数据预聚合可以避免对大量采集到的数据直接进行聚合查询遇到的操作效率低下的问题，有助于压缩数据存储，提高查询效率。
在Kafka中，每个消息被封装到一个ProducerRecord结构中，所述ProducerRecord结构包括Topic、Parition、Key、Value和Timestramp字段，Topic、Parition字段用于决定消息将被存储的位置，Key用于计算分区值，使用唯一标识符TraceId标识Key。
数据采集节点与数据接收节点之间使用推/拉模式的ZeroMQ消息传输队列机制，每个数据采集节点生成的消息被推到消息传输队列中，数据接收节点从消息队列中接收消息。推/拉模式可以有效的防止数据收集节点和数据接收节点之间的启动顺序不一致而造成的数据丢失问题。
数据采集节点和数据接收节点之间，使用一组负载均衡器，用于平衡多个数据接收节点之间的流量，负载均衡器配置Keepalived增加备用负载均衡器节点的数量，当负载超过数据接收模块的当前吞吐量时，可以通过负载均衡器中的配置，扩展数据接收服务节点。
多线程并发访问时，服务器收到客户端的打开事务状态的命令时，服务器设置一个标志用于指示事务状态。
所述数据分析模块采用Redis缓存，直接查询上下游节点的数据，通过使用数据字段分析数据关联来恢复微服务的调用拓扑，数据字段包括：AgentId、TraceId、SpanId、ParentSpanId、URL和Interval，采用三种Redis存储结构来缓存数据：TraceData:{TraceId}:{SpanId}、Relationship:{TraceId}、Upstream:{TraceId}:{ParentSpanId}，这三种Key中第一个单词表示数据的含义，花括号内表示该含义对应特性的数据。
构建多线程模型优化Redis，以实现高性能的数据缓存，多线程模型包括一个主线程和一组Worker线程，主线程用于监听一个特定的端口Worker线程用于处理连接的读和写事件，为每个Worker线程设计一个缓存队列，缓存队列在主线程和Worker线程之间共享，并通过文件描述符（file descriptor, fd）进行主线程和Worker线程之间的对应连接。
为每个Worker线程创建一个Socket pair，支持Worker线程和主线程之间的双向通信。当主线程收到一个新的连接请求时，通知Worker线程在缓存队列中获取文件描述符。
为了支持多线程模型，我们引入了分段读/写的锁机制，以确保可靠的并发数据访问。分段锁锁允许多个线程读，但只有一个线程同时写。我们实现分段锁以减少竞争:使用RedisDB数据存储结构创建多个数据库对象，并为每个对象实现分段锁。分段锁允许同时访问多个工作线程的不同对象，从而在一定程度上减少了锁竞争。在接收到客户端连接请求后，Worker线程的处理被锁定，以确保数据一致性。当Worker线程执行用户请求时，只有在“执行命令”过程中被锁定，以防止多个Worker线程同时操作同一个数据库。
我们利用乐观锁定来确保提交操作时的数据完整性。在Redis数据库中，设置Watched_keys结构，用于存储所有被监视的Key和对应的客户端对象的链表。在单线程中，Watch机制简化了事务隔离，当事务开始执行时，事务不能被其他客户端中断，但是，在多线程模型中，多个工作线程可能在执行事务时并发地访问Watched_keys，因此，锁定整个Watched_keys，以确保多线程的安全并发访问。
分段锁定机制保证了多个客户端对数据库的并发访问。然而，数据预聚合涉及两个命令，而提出的分段锁定只支持单个命令。此外，在多线程模型中，原有的Redis事务机制无法保证事务隔离。因此，我们提出了基于Version的乐观锁机制来支持多个命令并确保事务隔离。则需要修改Redis数据库中的数据结构，添加Version字段，服务器获取客户端的Key及其对应的Version号，并通过CAS (CompareAndSet)机制，确保当Version值相等时才更新操作。
本发明的优势和有益效果在于：
本申请利用ZeroMQ实现高效的数据传输；引入HAProxy，为数据接收节点提供负载均衡能力；将数据接收和处理分开，采用Kafka集群作为中间层，用于处理数据接收与处理之间的速度不匹配；优化Redis缓存，用于分布式应用中实时分析和存储微服务的调用拓扑；采用基于时间窗口的数据预聚合压缩数据存储，提高数据查询效率；为了支持多线程模型，我们引入了分段读/写的锁机制，以确保可靠的并发数据访问；通过基于Version乐观锁机制优化多线程模型，来确保提交操作时的数据完整性。
附图说明
图1是本发明中数据分析引擎架构图。
图2是本发明中负载均衡器工作原理图。
图3是本发明中Redis优化的多线程模型图。
图4是本发明中Watched_keys数据结构图。
图5是本发明的实验中目标应用的体系结构图。
图6是本发明的实验中用户请求的服务跟踪示意图。
具体实施方式
以下结合附图对本发明的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本发明，并不用于限制本发明。
一种分布式跟踪***的实时数据分析引擎，包括数据采集、数据接收、数据处理和数据分析模块，为了支持实时数据分析，提出了一种将数据接收模块与数据处理模块分离的新架构，使用Kafka作为数据接收模块和数据处理模块之间的中间层来处理数据接收和处理之间的速度不匹配，数据接收模块负责接收和存储数据到Kafka，数据处理模块从Kafka获取数据进行进一步的操作，如图1所示，主要分成以下几个部分进行：
1、数据接收：
数据接收模块与数据采集模块通信，接收来自数据采集节点的数据。在数据采集模块和数据接收模块之间，我们使用消息传输队列（ZeroMQ）。它的无锁队列和数据的零拷贝机制可以保证数据的快速传输。
消息传输机制：ZeroMQ支持多种消息传输模式。我们使用推/拉模式。每个数据采集节点都是推/拉（Push/Pull）模式下的一个Worker。生成的每个消息都被推到数据接收节点的消息队列中。这些操作可以通过ZeroMQ API接口执行。这种推/拉模式可以有效的防止数据收集节点和数据接收节点之间的启动顺序不一致而导致数据丢失。
数据接收模块接收到数据后，将数据放入Kafka中，等待接收到的数据被处理模块处理。接收数据的格式通过一些定义的字段进行表示：TraceId、SpanId、ParentSpanId、AgentId、StartTime、EndTime、Interval、URL。
为了在数据接收模块中实现高可用性和可伸缩性，引入负载均衡器（HAProxy）来平衡多个数据接收节点之间的流量，保证单个节点在发生故障时不丢失数据。为了防止负载均衡器出现单点故障，通过配置Keepalived来增加备用负载均衡器节点的数量，如图2所示，当负载超过数据接收模块的当前吞吐量时，可以通过负载均衡器中的配置，扩展数据接收服务节点。
使用Kafka作为数据接收节点和数据处理节点之间的消息队列缓存，数据接收节点接收到消息后，只需按一定的规则将数据放入Kafka，Kafka是一个分布式消息传递中间件，支持数据的同步和异步传输方式。为了保证数据接收的效率，通常数据接收节点选择异步传输方式。Kafka以集群模式部署，以负载平衡消息，避免了单点故障等问题。在Kafka中，每个消息被封装到一个ProducerRecord结构中，ProducerRecord结构包括主题Topic、分区Parition、和Key、Value和Timestramp字段，其中Topic、Parition字段决定了消息将被存储到何处，Key用于计算分区值，使用唯一标识符TraceId标识Key。
2、数据处理
数据处理模块从Kafka集群获取消息，进行数据预聚合，并使用Elasticsearch（ES）实现数据持久化。存储采集到的数据给数据存储带来了很大的压力，对如此大量的数据进行聚合查询可能会遇到一些操作效率低下的问题（例如调用拓扑可视化和数据查询）。为了解决这些问题，提出了基于时间窗口的数据预聚合。
数据预聚合的中间结果存储在Redis缓存中，以便进行进一步的数据分析。数据预聚合的过程包括以下几个步骤：1）将新数据添加到聚合的结果中，获取Key对应的哈希结构，比较数据字段得到一个新结果，并将结果写回Redis；2）及时提取数据汇总结果。进一步考虑多线程并发访问一个Key的情况。当多个线程运行回写命令回写数据时，通过运行访问命令访问的数据将被覆盖。为了确保命令的执行不被中断，我们利用了Redis事务。
3、数据分析
数据分析模块旨在还原分布式应用程序中微服务的调用拓扑。分布式跟踪***采集的数据通常是复杂、无序的。传统的数据分析引擎直接将数据存储在HDFS中，经过MapReduce计算后将分析结果恢复到HDFS中。分析过程处于脱机状态，因此无法实时获取调用拓扑。使用Redis缓存，数据分析模块可以直接查询上下游节点的数据，然后，数据分析模块分析数据关联并还原微服务的调用拓扑。对于数据分析，分布式应用中数据到达顺序的三种情况包括：1）应用生成的数据由终端用户访问，没有上游服务调用节点；2）上游服务调用节点的数据先到达；3）被调用节点的数据先到达。
通过使用数据字段分析数据关联来恢复微服务的调用拓扑：TraceId、SpanId、ParentSpanId、AgentId、StartTime、EndTime、Interval、URL字段。采用三种Redis存储结构来缓存数据，TraceData:{TraceId}:{SpanId}、Relationship:{TraceId}、Upstream:{TraceId}:{ParentSpanId}，这三种Key中第一个单词表示数据的含义，花括号内表示该含义对应特性的数据。
4、REDIS优化数据缓存
优化Redis以实现高性能的数据缓存。Redis使用单线程模型。在单线程模型中，如果存在多个Redis实例，部署会很困难。此外，有些命令不能有效地实现。因此，为Redis提出了一个多线程模型。
多线程模型包含两种类型的线程，一个主线程和多个Worker线程，如图3所示。主线程监听一个特定的端口。一旦发出新的连接请求后，主线程调用命令来接收请求，并获得连接的文件描述符（file descriptor，fd）。然后，主线程将其传递给Worker线程。Worker线程处理连接的读和写事件。在原始的单线程模型中，一个主线程获得所有的文件描述符，并使用遍历方法逐个处理它们。相反，在多线程模型中，主线程只负责接收新的连接请求，并将连接的文件描述符传递给Worker线程。
如果存在大量并发请求，并且所有Worker线程都很忙，那么主线程将等待，直到有一个Worker线程可用。这将导致主线程阻塞；无法处理后续的新连接请求。为了解决这个问题，我们为每个Worker线程设计了一个缓存队列。缓存队列在主线程和Worker线程之间共享。主线程将最新连接的文件描述符推入队列，并通知Worker线程。然后Worker线程将元素从队列中取出，并向事件处理程序注册文件描述符。一旦Worker线程获得文件描述符，一个新的事件就会发生，并由事件处理程序处理。
为了实现线程的统一通信机制，我们为每个Worker线程创建一个Socket pair，以支持Worker线程和主线程之间的双向通信。当主线程收到一个新的连接请求时，它通知Worker线程在缓存队列中获取文件描述符。
为了支持多线程模型，我们引入了分段读/写的锁机制，以确保多个客户端对数据库并发访问的可靠性。该机制允许多个线程读，但只有一个线程同时写。例如一个线程访问了，其他线程就需要等待该线程处理结束才能继续。我们实现分段锁以减少竞争：使用RedisDB数据存储结构创建多个数据库对象，并为每个对象实现分段锁。分段锁允许同时访问多个Worker线程的不同对象，从而在一定程度上减少了锁竞争。
在接收到用户请求后，Worker线程的处理需要被锁定，以确保数据一致性。当Worker线程执行用户请求时，它将执行以下步骤：1）接收数据；2）解析命令；3）处理命令；4）调用命令；5）执行命令；6）回写结果。在执行客户端请求的整个过程中，只有执行命令的过程（即第5步）被锁定，以防止多个Worker线程同时操作同一个数据库。
我们利用乐观锁定来确保提交操作时的数据完整性。具体来说，在Redis数据库中，我们保持了一个称为watched_keys的结构，如图4所示。该结构存储所有被监视的Key和相应的客户端链表。在单个线程中，Watch机制简化了事务隔离，当事务开始执行时，事务不能被其他客户端中断。但是，在多线程模型中，多个工作线程可能在执行事务时并发地访问watched_keys。因此，锁定了整个watched_keys，以确保多线程的安全并发访问。
分段锁机制保证了多个客户端对数据库的并发访问。然而，数据预聚合涉及两个命令，而提出的分段锁只支持一个命令。此外，在多线程模型中，原有的Redis事务机制无法保证事务隔离。因此，提出了基于Version的乐观锁机制来支持多个命令并确保事务隔离。
乐观锁需要增加Version号，就需要修改Redis中原始的数据结构，并添加一个Version字段。为了实现基于Version号的CAS （CompareAndSet）机制：1）为get命令提供Version号；2）将Version号和Key传递给服务器，用于Set和Delete命令。在服务器解析并执行命令之后，CAS原子操作（比较匹配的操作）确定Version号是否一致，即通过CAS原子操作比较客户端的Version号及服务器中提取的当前Version号。确保Version号一致以进行数据更新。从而优化多线程模型，确保数据的一致性。
通过实验评估数据分析引擎的延迟、处理能力和有效性。将数据分析引擎部署在多个服务器上，包括1个数据接收节点、4个数据处理节点、Kafka集群 (2个Kafka实例，分区数设为4)、Redis集群和ES集群。
1、延时性
低延迟是实时数据分析的一个重要要求。采用数据接收到数据分析完成之间的时间间隔来表示实时数据分析中的延迟。大多数延迟来自数据分析。为了获得数据分析的持续时间，通过为每个数据片段添加一个IndexTime字段来记录每个ES数据***的时间戳。每一段数据在生成时还保留一个Timestramp。我们通过这两个Timestramp之间的差异来定义数据段的数据分析持续时间。随着服务调用数量的增加，延迟会逐渐增加。当并发数据的数量持续增加时，延迟就会变得很明显。实验显示90%的数据处理时间在1分钟内。
2、处理能力
通过比较Redis优化前后的处理能力，来评估Redis优化如何改善数据分析引擎的处理能力。首先，以模拟的方式将实验数据发送到实时数据分析引擎。通过修改一些数据字段（例如一个请求的TraceId），可以检查Kafka中相应的Topic中是否发生了消息积累（message accumulation）。当消息积累发生时，开始评估数据处理节点的处理能力。
为了度量数据处理节点在一分钟内处理的数据块的数量，在数据处理节点中添加一个计数器，并将数据块的数量附加到日志文件中。实验分为两轮，一轮是Redis优化前的处理能力评估，另一轮是Redis优化后的处理能力评估。设每轮数据处理节点数为1、2、3、4个。
3、有效性
为了评估数据分析引擎的有效性，我们检查该引擎是否能够在分布式应用程序中还原微服务的调用拓扑。为一个分布式应用（购物***）部署了数据分析引擎，其架构如图5所示。目标应用程序由多个微服务组成：登录管理、用户管理、订单管理和地址管理。微服务相互调用以实现应用程序的功能。
我们使用分布式跟踪***从节点A、B、C、D、E收集到的数据，如图6所示。这些节点分别代表web前端、登录管理、用户管理、订单管理和地址管理。检查由分布式跟踪***生成的数据，以查看服务调用是否保留。总共设计了六组实验，其数据发送顺序考虑了之前描述的三种情况。实验结果如表1所示。将对每个组执行几次，直到可以恢复所有节点之间的调用拓扑。对于所有的实验，数据分析引擎有效地捕获了调用拓扑。
| 组别 | 序列 | 是否还原所有调用拓扑 |
| 1 | A，B，C，D，E | 是 |
| 2 | A，D，E，B，C | 是 |
| 3 | A，C，D，E，B | 是 |
| 4 | B，A，C，E，D | 是 |
| 5 | B，E，C，D，A | 是 |
| 6 | B，D，E，A，C | 是 |
表1数据分析的有效性
以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的范围。
Claims (10)
1.一种分布式跟踪***的实时数据分析引擎，包括数据处理模块及与数据处理模块连接的数据采集模块和数据分析模块，其特征在于所述的数据采集模块和数据处理模块通过数据接收模块连接，数据接收模块和数据处理模块之间采用Kafka集群作为中间层，数据采集模块包括一组数据采集节点，数据接收模块包括一组数据接收节点，所述Kafka与数据接收模块中的数据接收节点之间采用异步传输方式，使用来自Kafka集群的服务调用数据来统计特定时间间隔内每个URL访问的响应时间，数据处理模块采用基于时间窗口的数据预聚合，通过比较响应时间对应的字段，进行数据聚合，并将新数据添加到聚合的结果中，数据预聚合的结果存储在Redis缓存中，提取数据汇总结果并存储，同时删除Redis缓存中的数据。
2.如权利要求1所述的一种分布式跟踪***的实时数据分析引擎，其特征在于所述Kafka中的消息被封装到一个ProducerRecord结构中，所述ProducerRecord结构包括Topic、Parition、Key、Value和Timestramp字段，其中Topic、Parition字段用于决定消息将被存储的位置，Key用于计算分区值，使用唯一标识符TraceId标识Key。
3.如权利要求1所述的一种分布式跟踪***的实时数据分析引擎，其特征在于数据采集节点与数据接收节点之间使用推/拉模式的ZeroMQ消息传输机制，每个数据采集节点生成的消息被推到消息传输队列中，数据接收节点从消息队列中接收消息。
4.如权利要求1所述的一种分布式跟踪***的实时数据分析引擎，其特征在于数据采集节点和数据接收节点之间，使用一组HAProxy负载均衡器，负载均衡器配置Keepalived增加备用负载均衡器节点的数量。
5.如权利要求1所述的一种分布式跟踪***的实时数据分析引擎，其特征在于多线程并发访问时，服务器收到客户端的打开事务状态命令时，服务器设置一个标志用于指示事务状态。
6.如权利要求1所述的一种分布式跟踪***的实时数据分析引擎，其特征在于所述数据分析模块采用Redis缓存，直接查询上下游节点的数据，通过使用数据字段分析数据关联来还原微服务的调用拓扑，数据字段包括：AgentId、TraceId、SpanId、ParentSpanId、URL和Interval，采用三种Redis存储结构来缓存数据，TraceData:{TraceId}:{SpanId}、Relationship:{TraceId}、Upstream:{TraceId}:{ParentSpanId}，这三种Key中第一个单词表示数据的含义，花括号内表示该含义对应特性的数据。
7.如权利要求1-6所述的一种分布式跟踪***的实时数据分析引擎，其特征在于构建多线程模型优化Redis，多线程模型包括一个主线程和一组Worker线程，主线程用于监听一个特定的端口，Worker线程用于处理连接的读和写事件，为每个Worker线程设计一个缓存队列，缓存队列在主线程和Worker线程之间共享，在这个过程中通过文件描述符用于主线程worker线程之间的连接对应。
8.如权利要求7所述的一种分布式跟踪***的实时数据分析引擎，其特征在于为每个Worker线程创建一个Socket pair，以支持Worker线程和主线程之间的双向通信。
9.如权利要求7所述的一种分布式跟踪***的实时数据分析引擎，其特征在于采用分段锁读/写锁定机制，允许多个线程读，但只有一个线程同时写，我们实现分段锁以减少竞争：使用RedisDB数据存储结构创建多个数据库对象，并为每个对象实现锁机制，在接收到用户连接请求后，Worker线程的处理被锁定，当Worker线程执行用户请求时，只有在执行命令过程中被锁定。
10.如权利要求7所述的一种分布式跟踪***的实时数据分析引擎，其特征在于采用基于Version的乐观锁机制来确保提交操作时的数据完整性,在Redis数据库中，设置Watched_keys结构，用于存储所有被监视的Key和对应的客户端对象的链表，修改Redis数据库中的数据结构，添加Version字段，服务器获取客户端的Key及其对应的Version号，从Redis数据库中提取Key及其对应的当前Version号传递给服务器，同时锁住数据库的写操作，通过CAS原子操作比较客户端的版本号及数据库中提取的当前版本号是否一致，如果是，则将当前Version号加1并保存到数据库相应位置，否则将返回失败，解锁数据库的写操作。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011058075.7A CN112099977A (zh) | 2020-09-30 | 2020-09-30 | 一种分布式跟踪***的实时数据分析引擎 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011058075.7A CN112099977A (zh) | 2020-09-30 | 2020-09-30 | 一种分布式跟踪***的实时数据分析引擎 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112099977A true CN112099977A (zh) | 2020-12-18 |
Family
ID=73782496
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011058075.7A Pending CN112099977A (zh) | 2020-09-30 | 2020-09-30 | 一种分布式跟踪***的实时数据分析引擎 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112099977A (zh) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112685335A (zh) * | 2020-12-28 | 2021-04-20 | 湖南博匠信息科技有限公司 | 数据存储*** |
| CN113177068A (zh) * | 2021-03-15 | 2021-07-27 | 新华三信息安全技术有限公司 | 一种聚合数据查询方法、设备及介质 |
| CN113190418A (zh) * | 2021-07-01 | 2021-07-30 | 奇安信科技集团股份有限公司 | 日志接收方法、装置、电子设备及存储介质 |
| CN113268363A (zh) * | 2021-06-16 | 2021-08-17 | 中移（杭州）信息技术有限公司 | 基于全局能力的调用追踪方法、装置、服务器及存储介质 |
| CN113284573A (zh) * | 2021-06-02 | 2021-08-20 | 山东健康医疗大数据有限公司 | 一种文档数据库检索方法与装置 |
| CN113590560A (zh) * | 2021-06-29 | 2021-11-02 | 济南浪潮数据技术有限公司 | 一种分布式***的缓存优化方法、***、设备和存储介质 |
| CN113949624A (zh) * | 2021-09-17 | 2022-01-18 | 远景智能国际私人投资有限公司 | 链路采样数的分配方法、装置、设备及介质 |
| CN116361016A (zh) * | 2023-06-01 | 2023-06-30 | 天翼云科技有限公司 | 一种网络控制器消息处理方法、*** |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105224445A (zh) * | 2015-10-28 | 2016-01-06 | 北京汇商融通信息技术有限公司 | 分布式跟踪*** |
| CN106487596A (zh) * | 2016-10-26 | 2017-03-08 | 宜人恒业科技发展（北京）有限公司 | 分布式服务跟踪实现方法 |
-
2020
- 2020-09-30 CN CN202011058075.7A patent/CN112099977A/zh active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105224445A (zh) * | 2015-10-28 | 2016-01-06 | 北京汇商融通信息技术有限公司 | 分布式跟踪*** |
| CN106487596A (zh) * | 2016-10-26 | 2017-03-08 | 宜人恒业科技发展（北京）有限公司 | 分布式服务跟踪实现方法 |
Non-Patent Citations (1)
| Title |
|---|
| 汪灿丰: "分布式跟踪***中数据分析引擎的设计与实现", 《中国优秀硕士学位论文全文数据库》, no. 01, pages 138 - 2164 * |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112685335A (zh) * | 2020-12-28 | 2021-04-20 | 湖南博匠信息科技有限公司 | 数据存储*** |
| CN112685335B (zh) * | 2020-12-28 | 2022-07-15 | 湖南博匠信息科技有限公司 | 数据存储*** |
| CN113177068A (zh) * | 2021-03-15 | 2021-07-27 | 新华三信息安全技术有限公司 | 一种聚合数据查询方法、设备及介质 |
| CN113284573A (zh) * | 2021-06-02 | 2021-08-20 | 山东健康医疗大数据有限公司 | 一种文档数据库检索方法与装置 |
| CN113268363A (zh) * | 2021-06-16 | 2021-08-17 | 中移（杭州）信息技术有限公司 | 基于全局能力的调用追踪方法、装置、服务器及存储介质 |
| CN113268363B (zh) * | 2021-06-16 | 2024-04-09 | 中移（杭州）信息技术有限公司 | 基于全局能力的调用追踪方法、装置、服务器及存储介质 |
| CN113590560A (zh) * | 2021-06-29 | 2021-11-02 | 济南浪潮数据技术有限公司 | 一种分布式***的缓存优化方法、***、设备和存储介质 |
| CN113190418A (zh) * | 2021-07-01 | 2021-07-30 | 奇安信科技集团股份有限公司 | 日志接收方法、装置、电子设备及存储介质 |
| CN113949624A (zh) * | 2021-09-17 | 2022-01-18 | 远景智能国际私人投资有限公司 | 链路采样数的分配方法、装置、设备及介质 |
| CN113949624B (zh) * | 2021-09-17 | 2023-07-21 | 远景智能国际私人投资有限公司 | 链路采样数的分配方法、装置、设备及介质 |
| CN116361016A (zh) * | 2023-06-01 | 2023-06-30 | 天翼云科技有限公司 | 一种网络控制器消息处理方法、*** |
| CN116361016B (zh) * | 2023-06-01 | 2023-10-13 | 天翼云科技有限公司 | 一种网络控制器消息处理方法、*** |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112099977A (zh) | 一种分布式跟踪***的实时数据分析引擎 | |
| CN107018042B (zh) | 用于在线服务***的追踪方法及追踪*** | |
| CN111309409B (zh) | 一种api服务调用实时统计方法 | |
| CN102831156B (zh) | 一种云计算平台上的分布式事务处理方法 | |
| CN111723160A (zh) | 一种多源异构增量数据同步方法及*** | |
| US7801997B2 (en) | Asynchronous interconnect protocol for a clustered DBMS | |
| US20060059228A1 (en) | Capturing and re-creating the state of a queue when migrating a session | |
| Yongguo et al. | Message-oriented middleware: A review | |
| CN111125260A (zh) | 一种基于SQL Server的数据同步方法及*** | |
| CN113422842B (zh) | 一种考虑网络负载的分布式电力用电信息数据采集*** | |
| WO2021036684A1 (zh) | 分布式数据同步方法、装置、设备及可读存储介质 | |
| EP3172682B1 (en) | Distributing and processing streams over one or more networks for on-the-fly schema evolution | |
| CN109388481A (zh) | 一种事务信息的传输方法、***、装置、计算设备和介质 | |
| Gao et al. | Lazy update propagation for data replication in cloud computing | |
| CN112597251A (zh) | 数据库集群日志同步方法、装置、服务器及存储介质 | |
| CN109639773A (zh) | 一种动态构建的分布式数据集群控制***及其方法 | |
| CN112084206A (zh) | 数据库的事务请求处理方法、相关设备及存储介质 | |
| WO2024051454A1 (zh) | 处理事务日志的方法及装置 | |
| CN113076304A (zh) | 一种分布式版本管理方法、装置和*** | |
| CN110515938B (zh) | 基于kafka消息总线的数据汇聚存储方法、设备和存储介质 | |
| CN115022402B (zh) | 一种基于一栈式集成技术的agent采集方法及*** | |
| CN116340111A (zh) | 一种Linux套接字监听事件监控方法及装置 | |
| Jiang et al. | Non-blocking raft for high throughput iot data | |
| CN114500289B (zh) | 控制平面恢复方法、装置、控制节点及存储介质 | |
| CN114500443B (zh) | 消息推送方法、装置、***、电子设备和存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |