CN114546817A - 一种信息处理方法、装置、存储介质及计算机程序产品 - Google Patents

一种信息处理方法、装置、存储介质及计算机程序产品 Download PDF

Info

Publication number
CN114546817A
CN114546817A CN202011337118.5A CN202011337118A CN114546817A CN 114546817 A CN114546817 A CN 114546817A CN 202011337118 A CN202011337118 A CN 202011337118A CN 114546817 A CN114546817 A CN 114546817A
Authority
CN
China
Prior art keywords
command
server
client
service
service request
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
Application number
CN202011337118.5A
Other languages
English (en)
Inventor
温志豪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202011337118.5A priority Critical patent/CN114546817A/zh
Publication of CN114546817A publication Critical patent/CN114546817A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/062—Securing storage systems
    • G06F3/0623—Securing storage systems in relation to content
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0656—Data buffering arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • 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/544—Buffers; Shared memory; Pipes
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请涉及一种信息处理方法、装置、存储介质及计算机程序产品，其中，该方法应用于分布式缓存系统的客户端，该方法包括：在客户端向服务端发起服务请求时，客户端向所述服务端发送封装后的第一命令、第二命令及第三命令，其中，第一命令用于指示服务端开启针对客户端与服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应；第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息；接收服务端发送的服务响应及跟踪信息。这样，随时跟踪服务端内部各阶段的时延信息，提高了分布式缓存系统的问题定位定界能力。

Description

一种信息处理方法、装置、存储介质及计算机程序产品
技术领域
本申请涉及信息技术领域，尤其涉及一种信息处理方法、装置、存储介质及计算机程序产品。
背景技术
随着分布式技术的发展，分布式缓存服务发展迅速，大量业务需要依赖分布式缓存服务。当前现网部署大规模的远程字典服务(redis，Remote Dictionary Server)集群，构建分布式缓存系统；相关技术中，通过跟踪缓存服务的时延信息进行问题定位；然而，仅能跟踪分布式缓存系统的客户端到服务端的时延信息，当现网出现高时延时，无法进行快速精确地问题定位。
发明内容
有鉴于此，提出了一种信息处理方法、装置、存储介质及计算机程序产品。
第一方面，本申请的实施例提供了一种信息处理方法，所述方法应用于分布式缓存系统的客户端，所述分布式缓存系统包括客户端和服务端，所述方法包括：在所述客户端向所述服务端发起服务请求时，所述客户端向所述服务端发送封装后的第一命令、第二命令及第三命令，其中，所述第一命令用于指示所述服务端开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；所述第二命令用于指示所述服务端处理所述服务请求，并发送处理所述服务请求得到的服务响应；所述第三命令用于指示所述服务端关闭消息跟踪功能，并发送所述跟踪信息；接收所述服务端发送的所述服务响应及所述跟踪信息。
基于上述技术方案，客户端向服务端发起服务请求时，发送封装后的第一命令、第二命令及第三命令，其中，第一命令用于指示服务端开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应；第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息；客户端接收服务响应及跟踪信息；这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
根据第一方面，在所述第一方面的第一种可能的实现方式中，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
基于上述技术方案，通过服务请求等候处理的时延、服务请求的处理时延、服务响应等候发送的时延等服务端内部阶段的时延信息，可以扩展调用链的跟踪信息，为问题定位提供更多有效的信息。
根据第一方面，或者第一方面的第一种可能的实现方式，在所述第一方面的第二种可能的实现方式中，所述时延信息，包括：第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
基于上述技术方案，在服务端处理服务请求的过程中，通过记录第一时间点、第二时间点、第三时间点、第四时间点，从而实现随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，为问题定位提供更多有效的信息。
根据第一方面,在所述第一方面的第三种可能的实现方式中，所述客户端向所述服务端发送封装后的第一命令、第二命令及第三命令，包括：所述客户端通过管道的方式，打包发送所述第一命令、所述第二命令及所述第三命令。
基于上述技术方案，客户端可以通过管道的方式，一次性把第一命令、第二命令及第三命令，这三个命令打包发送到服务端，减少客户端与服务端之间的网络传输时间，实现了客户端实时监控服务端的时延信息。
根据第一方面,在所述第一方面的第四种可能的实现方式中，所述方法还包括：解析所述跟踪信息，并将解析后的跟踪信息上报到调用链系统。
基于上述技术方案，客户端通过解析跟踪信息，并将解析后的跟踪信息上报到调用链系统，从而可以将时延信息转储到调用链系统中。这样，时延信息的数量将不再受限，存储的理论上限是调用链系统数据存储的上限，有效解决时延信息存储数量限制问题。
根据第一方面,在所述第一方面的第五种可能的实现方式中，所述分布式缓存系统采用远程字典服务Redis通信协议。
基于上述技术方案，针对大规模Redis集群构建的分布式缓存系统，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
第二方面，本申请的实施例提供了一种信息处理方法，所述方法应用于分布式缓存系统的服务端，所述分布式缓存系统包括客户端和服务端，所述方法包括：接收所述客户端发送的第一命令、第二命令及第三命令；响应于所述第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；响应于所述第二命令，处理所述客户端的服务请求，并发送处理所述服务请求得到的服务响应；响应于所述第三命令，关闭消息跟踪功能，并向所述客户端发送所述跟踪信息。
基于上述技术方案，服务端接收客户端发送的第一命令、第二命令及第三命令；响应于第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；响应于第二命令，处理客户端的服务请求，并发送处理服务请求得到的服务响应；响应于第三命令，关闭消息跟踪功能，并向客户端发送跟踪信息。这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
根据第二方面，在所述第二方面的第一种可能的实现方式中，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
基于上述技术方案，通过服务请求等候处理的时延、服务请求的处理时延、服务响应等候发送的时延等服务端内部阶段的时延信息，可以扩展调用链的跟踪信息，为问题定位提供更多有效的信息。
根据第二方面，或者第二方面的第一种可能的实现方式，在所述第二方面的第二种可能的实现方式中，所述时延信息，包括：第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
基于上述技术方案，在服务端处理服务请求的过程中，通过记录第一时间点、第二时间点、第三时间点、第四时间点，从而实现随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，为问题定位提供更多有效的信息。
根据第二方面，在所述第二方面的第三种可能的实现方式中，所述接收所述客户端发送的第一命令、第二命令及第三命令，包括：通过管道的方式，接收所述客户端打包发送的所述第一命令、所述第二命令及所述第三命令。
基于上述技术方案，服务端可以通过管道的方式，接收客户端一次性打包发送第一命令、第二命令及第三命令，减少客户端与服务端之间的网络传输时间，实现了实时监控服务端的时延信息。
根据第二方面，在所述第二方面的第四种可能的实现方式中，所述响应于所述第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，包括：响应于所述第一命令，在所述客户端与所述服务端的连接上下文中，添加消息跟踪开启标记，并向所述客户端发送消息跟踪开启结果。
基于上述技术方案，在客户端与服务端的连接上下文中添加消息跟踪开启标记，从而使得服务端在执行后续第二命令的过程中时，可以将每个关键点的时延信息记录在连接上下文中。
根据第二方面，在所述第二方面的第五种可能的实现方式中，所述分布式缓存系统采用远程字典服务Redis通信协议。
基于上述技术方案，针对大规模Redis集群构建的分布式缓存系统，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
第三方面，本申请的实施例提供了一种信息处理装置，所述装置应用于分布式缓存系统的客户端，所述分布式缓存系统包括客户端和服务端，所述装置包括：发送模块，用于在所述客户端向所述服务端发起服务请求时，所述客户端向所述服务端发送封装后的第一命令、第二命令及第三命令，其中，所述第一命令用于指示所述服务端开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；所述第二命令用于指示所述服务端处理所述服务请求，并发送处理所述服务请求得到的服务响应；所述第三命令用于指示所述服务端关闭消息跟踪功能，并发送所述跟踪信息；第一接收模块，用于接收所述服务端发送的所述服务响应及所述跟踪信息。
基于上述技术方案，客户端向服务端发起服务请求时，发送封装后的第一命令、第二命令及第三命令，其中，第一命令用于指示服务端开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应；第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息；客户端接收服务响应及跟踪信息；这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
根据第三方面，在所述第三方面的第一种可能的实现方式中，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
基于上述技术方案，通过服务请求等候处理的时延、服务请求的处理时延、服务响应等候发送的时延等服务端内部阶段的时延信息，可以扩展调用链的跟踪信息，为问题定位提供更多有效的信息。
根据第三方面，或者第三方面的第一种可能的实现方式，在所述第三方面的第二种可能的实现方式中，所述时延信息，包括：第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
基于上述技术方案，在服务端处理服务请求的过程中，通过记录第一时间点、第二时间点、第三时间点、第四时间点，从而实现随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，为问题定位提供更多有效的信息。
根据第三方面，在所述第三方面的第三种可能的实现方式中，所述发送模块，还用于：所述客户端通过管道的方式，打包发送所述第一命令、所述第二命令及所述第三命令。
基于上述技术方案，客户端可以通过管道的方式，一次性把第一命令、第二命令及第三命令，这三个命令打包发送到服务端，减少客户端与服务端之间的网络传输时间，实现了客户端实时监控服务端的时延信息。
根据第三方面，在所述第三方面的第四种可能的实现方式中，所述装置还包括上报模块，用于：解析所述跟踪信息，并将解析后的跟踪信息上报到调用链系统。
基于上述技术方案，客户端通过解析跟踪信息，并将解析后的跟踪信息上报到调用链系统，从而可以将时延信息转储到调用链系统中。这样，时延信息的数量将不再受限，存储的理论上限是调用链系统数据存储的上限，有效解决时延信息存储数量限制问题。
根据第三方面，在所述第三方面的第五种可能的实现方式中，所述分布式缓存系统采用远程字典服务Redis通信协议。
基于上述技术方案，针对大规模Redis集群构建的分布式缓存系统，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
第四方面，本申请的实施例提供了一种信息处理装置，，所述装置应用于分布式缓存系统的服务端，所述分布式缓存系统包括客户端和服务端，所述装置包括：第二接收模块，用于接收所述客户端发送的第一命令、第二命令及第三命令；处理模块，用于响应于所述第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；响应于所述第二命令，处理所述客户端的服务请求，并发送处理所述服务请求得到的服务响应；响应于所述第三命令，关闭消息跟踪功能，并向所述客户端发送所述跟踪信息。
基于上述技术方案，服务端接收客户端发送的第一命令、第二命令及第三命令；响应于第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；响应于第二命令，处理客户端的服务请求，并发送处理服务请求得到的服务响应；响应于第三命令，关闭消息跟踪功能，并向客户端发送跟踪信息。这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
根据第四方面，在所述第四方面的第二种可能的实现方式中，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
基于上述技术方案，通过服务请求等候处理的时延、服务请求的处理时延、服务响应等候发送的时延等服务端内部阶段的时延信息，可以扩展调用链的跟踪信息，为问题定位提供更多有效的信息。
根据第四方面，或者第四方面的第一种可能的实现方式，在所述第四方面的第二种可能的实现方式中，所述时延信息，包括：第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
基于上述技术方案，在服务端处理服务请求的过程中，通过记录第一时间点、第二时间点、第三时间点、第四时间点，从而实现随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，为问题定位提供更多有效的信息。
根据第四方面，在所述第四方面的第三种可能的实现方式中，所述第二接收模块，还用于：通过管道的方式，接收所述客户端打包发送的所述第一命令、所述第二命令及所述第三命令。
基于上述技术方案，基于上述技术方案，服务端可以通过管道的方式，接收客户端一次性打包发送第一命令、第二命令及第三命令，减少客户端与服务端之间的网络传输时间，实现了实时监控服务端的时延信息。
根据第四方面，在所述第四方面的第四种可能的实现方式中，所述处理模块，还用于：响应于所述第一命令，在所述客户端与所述服务端的连接上下文中，添加消息跟踪开启标记，并向所述客户端发送消息跟踪开启结果。
基于上述技术方案，在客户端与服务端的连接上下文中添加消息跟踪开启标记，从而使得服务端在执行后续第二命令的过程中时，可以将每个关键点的时延信息记录在连接上下文中。
根据第四方面，在所述第四方面的第五种可能的实现方式中，所述分布式缓存系统采用远程字典服务Redis通信协议。
基于上述技术方案，针对大规模Redis集群构建的分布式缓存系统，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
第五方面，本申请的实施例提供了一种信息处理装置，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令时实现上述第一方面或者第一方面的多种可能的实现方式中的一种或几种的信息处理方法，或者，实现上述第二方面或者第二方面的多种可能的实现方式中的一种或几种的信息处理方法。
基于上述技术方案，客户端向服务端发起服务请求时，发送封装后的第一命令、第二命令及第三命令，其中，第一命令用于指示服务端开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应；第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息；客户端接收服务响应及跟踪信息。或者，服务端接收客户端发送的第一命令、第二命令及第三命令；响应于第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；响应于第二命令，处理客户端的服务请求，并发送处理服务请求得到的服务响应；响应于第三命令，关闭消息跟踪功能，并向客户端发送跟踪信息。这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
第六方面，本申请的实施例提供了一种非易失性计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现上述第一方面或者第一方面的多种可能的实现方式中的一种或几种的信息处理方法，或者，实现上述第二方面或者第二方面的多种可能的实现方式中的一种或几种的信息处理方法。
基于上述技术方案，客户端向服务端发起服务请求时，发送封装后的第一命令、第二命令及第三命令，其中，第一命令用于指示服务端开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应；第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息；客户端接收服务响应及跟踪信息。或者，服务端接收客户端发送的第一命令、第二命令及第三命令；响应于第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；响应于第二命令，处理客户端的服务请求，并发送处理服务请求得到的服务响应；响应于第三命令，关闭消息跟踪功能，并向客户端发送跟踪信息。这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
第七方面，本申请的实施例提供了一种包含指令的计算机程序产品，其特征在于，当其在计算机上运行时，使得计算机执行上述第一方面或者第一方面的多种可能的实现方式中的一种或几种的信息处理方法，或者，执行上述第二方面或者第二方面的多种可能的实现方式中的一种或几种的信息处理方法。
基于上述技术方案，客户端向服务端发起服务请求时，发送封装后的第一命令、第二命令及第三命令，其中，第一命令用于指示服务端开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应；第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息；客户端接收服务响应及跟踪信息。或者，服务端接收客户端发送的第一命令、第二命令及第三命令；响应于第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；响应于第二命令，处理客户端的服务请求，并发送处理服务请求得到的服务响应；响应于第三命令，关闭消息跟踪功能，并向客户端发送跟踪信息。这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
本申请的这些和其他方面在以下(多个)实施例的描述中会更加简明易懂。
附图说明
包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本申请的示例性实施例、特征和方面，并且用于解释本申请的原理。
图1示出根据本申请一实施例的分布式缓存系统的框架图；
图2示出根据本申请一实施例的一种信息处理方法的流程图；
图3示出根据本申请一实施例的客户端向服务端发起服务请求的示意图；
图4示出根据本申请一实施例的一种信息处理方法的应用场景示意图；
图5示出根据本申请一实施例的一种信息处理方法的流程图；
图6示出根据本申请一实施例的服务端跟踪时延信息的示意图；
图7示出根据本申请一实施例的一种信息处理方法的流程图；
图8示出根据本申请一实施例的客户端与服务端信息交互的示意图；
图9示出根据本申请一实施例的相关技术调用链的示意图；
图10示出根据本申请一实施例的扩展调用链的示意图；
图11示出根据本申请一实施例的展示扩展调用链中跟踪信息的示意图；
图12示出根据本申请一实施例的一种信息处理装置的结构图；
图13示出根据本申请一实施例的一种信息处理装置的结构图；
图14示出根据本申请一实施例的一种信息处理装置的结构示意图。
具体实施方式
以下将参考附图详细说明本申请的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。
在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。
另外，为了更好的说明本申请，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本申请同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本申请的主旨。
本申请实施例中技术方案可以应用到兼容Redis通信协议的分布式缓存系统上，图1示出根据本申请一实施例的分布式缓存系统的框架图；如图1所示，分布式缓存系统11可以包括客户端101和服务端102，客户端101和服务端102的数量均可为一个或多个，本申请实施例对此不作限定；其中，分布式缓存系统11可以采用Redis通信协议；即客户端101与服务端102之间通过Redis协议进行通信，服务端102可以为Redis集群，其中，Redis集群是一个使用ANSI C语言编写的开源、支持网络、基于内存、可选持久性的键值对(key-value)存储数据库。
其中，客户端101可以包括业务系统的一个或多个业务节点，业务系统用于处理外部输入的业务，例如，业务可以为购买业务、支付业务、充值业务等等；业务可以按照调用关系依次调用多个服务来实现，例如，服务可以是产品管理、用户管理、订购关系管理、计费管理以及云服务资源管理等等，本申请实施例对此不作限定。业务节点即表示为业务提供相应服务的节点，当业务节点提供相应服务的过程中，需要调用redis集群的缓存服务时，此时业务节点可以作为分布式缓存系统的客户端。作为客户端的业务节点接收到服务请求时，向服务端发送服务请求，从而调用服务端的缓存服务，例如，服务请求为查询相关数据，则向服务端发送查询相关数据的请求，并接收服务端的服务响应，例如查询结果。
示例性地，客户端可以与业务节点一体设置，即客户端可以为集成分布式缓存系统的客户端的业务节点。
其中，服务端102可以包括缓存节点1、缓存节点2…缓存节点n等n个缓存节点，用于提供分布式缓存服务，其中，n为整数，n的具体数值可以根据实际分布式缓存系统中所部署的缓存节点的数量确定，本申请实施例中对此不作限定。示例性地，缓存节点1、缓存节点2…缓存节点n采用Redis数据库形式，该缓存节点1、缓存节点2…缓存节点n即为Redis集群。服务端接收到客户端的服务请求之后，处理该服务请求，得到服务响应，并向客户端发送该服务响应；例如，服务端接收到查询相关数据的请求，则在Redis集群中进行相关数据的查询，得到所查询的相关数据，并向客户端发送查询到的相关数据。
需要说明的是，各缓存节点可以是一个物理节点，还可以是一个虚拟节点。即可以是由一个单独的服务器构成的物理节点，或者一个服务器中的一个虚拟节点，缓存节点还可以是由多个服务器组成的服务器组，本申请实施例中对此不作限定。
在完成一次业务的过程中，把该处理该业务的过程中所涉及的各服务(包括上述缓存服务)之间的调用信息(时间、接口、层次、结果)打点到日志中，然后将所有的打点数据连接为一个树状链条就产生了一个调用链。通过调用链能够跟踪各服务的时延信息，还原业务的执行轨迹和状态，从而可以进行问题(如故障和性能瓶颈)定位。然而，针对当前现网部署的采用Redis通信协议的分布式缓存系统；由于相关技术中，提供的跟踪Redis时延信息的方式存在缺陷，仅能跟踪分布式缓存系统的客户端到服务端的时延信息，当现网出现高时延时，无法进行快速精确地问题定位。
下面对相关技术中存在的上述技术问题进行举例说明：
相关技术中的一种跟踪时延信息的方式中，通过在分布式缓存系统的客户端埋点的方式实现调用链跟踪分布式缓存的时延信息。当外部的业务请求进来的时候，在第一个接收到这个业务请求的服务器的中间件会生成一次分布式调用的唯一标识(Tid，traceID)，这个trace ID会随着处理该业务请求过程中，每一次分布式调用透传到下游的系统当中，所有透传的事件会存储在远程过程调用日志(RPC log，Remote Procedure Call log)文件当中，随后会有一个中心化的处理集群把所有服务器上的日志增量地收集到该集群当中进行处理，处理的逻辑为简单清洗后再倒排索引。只要系统中报错，然后把trace ID作为异常日志当中的关键字打出来，可以看到这次调用在系统里面经历了哪些事情，通过traceID能够得到按时间排列的调用事件序列。
该方式中，只能跟踪单个请求从分布式缓存系统客户端到服务端的时延信息，无法针对分布式缓存系统中间件内部流程进行有效的分析，即无法跟踪分布式缓存系统内部各阶段的时延信息。采用Redis通信协议的分布式缓存系统的时延问题复杂，多种原因都有可能导致响应时间变大，例如，请求过多导致请求队列满场景(Redis每秒查询率(QPS，Queries persecond)达到性能瓶颈、Redis同步(Redis fork)阻塞请求队列)，或者分布式缓存系统内部处理某个大对象导致队列阻塞(Redis慢查询)，但是针对这两种问题该方式对外展现的现象都是分布式缓存系统的服务端时延变大，无法随时跟踪分布式缓存系统的服务端内部各阶段的时延信息，无法进行快速精确地问题定位。
相关技术中的另一种跟踪时延信息的方式中，通过Redis慢查询日志(Redisslowlog)功能，Redis慢查询日志负责记录超过指定执行时间的查询操作。这个执行时间并不包括输入和输出(I/O，Input/Output)操作(例如服务端和客户端之间的通信、发送应答消息等等)，仅仅是执行命令实际需要消耗的时间。Redis的慢查询日志功能用于记录执行时间超过给定时长的命令，可以通过这个功能产生的日志监视和优化查询速度。
该方式中，首先需要在命令的执行前后记录时间戳，然后相减计算出该命令的执行耗时，最后根据分布式缓存系统的服务端配置的超时参数slowlog-log-slower-than进行对比，决定是否记录慢日志，另外在记录慢日志的时候需要根据慢查询日志指定保存条数slowlog_max_len的值判断是否要删除最久的日志信息。即命令执行完以后，需要判断分布式缓存系统的服务端是否配置了超时参数，如果超时参数小于0则直接返回，否则再比较命令执行时间是否超时，如果超时则插入慢日志；最后再比较慢日志的条数是否达到上限，如果达到则进行删除。
该方式中，需要提前设置阈值，达到阈值的索引键(key)才能被记录下来，如果达不到阈值范围内的消息就不会记录下来，同时，只能跟踪客户端到服务端的时延信息，无法随时跟踪分布式缓存系统的服务端内部各阶段的时延信息，无法进行快速精确地问题定位。
相关技术中的另一种跟踪时延信息的方式中，Redis 2.8.13引入了一个新特性，叫做延迟监控(Latency Monitoring)，它可以帮助用户检查和定位可能的延迟问题。延迟监控由下面的几个组件构成：延迟挂钩：这个组件会对延迟敏感的各种代码路径进行采样；时间序列：这个组件会记录由各种事件造成的延迟飙升；报告引擎：这个组件会从时间序列中取出原始数据；分析引擎：这个组件会根据测量方法向用户提供易读的报告和提示信息。
不同的受监控代码路径具有不同的名称，这些名称也被称为事件。例如，command是一个事件，可用于测量执行速度较慢的命令，这些命令可能会导致延迟飙升；而fast-command也是一个事件，可用于监控执行速度较快的命令，这些命令的时间复杂度为O(1)或O(LogN)其中，N表示命令的数据量。其他事件都没有通用性，这些事件可以分别用于监控分布式缓存系统执行的某个非常具体的操作；例如，fork事件只能监控分布式缓存系统调用fork所消耗的时间。
当事件的运行时间超过已配置的延迟阈值时，便会发生延迟飙升。每个受监控的事件都有一个独立的时间序列。时间序列的工作原理如下所示：每次发生延迟飙升时，分布式缓存系统便会将其记录在合适的时间序列中。每个时间序列都是由160个元素组成的。每个元素都是一对值：一个值是发生延迟飙升时的UNIX时间戳，另一个值是事件运行耗费的时间，以毫秒为单位。如果相同事件的多次延迟飙升连续发生，那么它们便会被合并为一次延迟飙升(取最大的延迟时间)。因此，即使某个给定事件连续发生了多次延迟飙升，如果用户将延迟阈值设置得太低，那么至少会有180秒的历史数据是有效的。每个元素都会记录历史最大延迟时间。分布式缓存系统内部的延迟监控子系统，通过不同代码路径注入相关延迟挂钩，提供延迟监控功能。
该方式中，无法跟踪具体命令，命令分类粒度较大，只有command和fast-command两种类型，不能区分具体的子命令；另外需要提前设置延迟阈值，达到延迟阈值的key才能被记录下来，如果达不到阈值范围内的消息就不会记录下来，无法随时跟踪分布式缓存系统的服务端内部各阶段的时延信息，无法进行快速精确地问题定位。
为了解决相关技术中存在的上述技术问题，本申请提供了一种信息处理的技术方案，本申请实施例的信息处理的技术方案可以应用于上述图1中分布式缓存系统的客户端和/或服务端中，从而能够实现随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
图2示出根据本申请一实施例一种信息处理方法的流程图，该方法可以应用于上述图1中的分布式缓存系统的客户端，其中，分布式缓存系统包括客户端和服务端，示例性地，分布式缓存系统采用Redis通信协议；如图2所示，该方法可以包括：
步骤201、在客户端向服务端发起服务请求时，客户端向服务端发送封装后的第一命令、第二命令及第三命令。
该步骤中，服务请求可以为客户端查询服务端中缓存的相关数据的请求，或其他任意类型的服务请求。客户端在接收到外部输入(如其它业务节点)所发送的一条服务请求后，客户端在服务请求的基础上将添加两个自定义命令，从而将该服务请求封装成第一命令(TC-BGN，TRACE BEGIN)、第二命令(MSG，MESSAGE)、第三命令(TC-END，TRACE END)，共三个命令，这三个命令均可采用Redis通信协议，然后客户端向服务端发送这封装后的三个命令。
图3示出根据本申请一实施例客户端向服务端发起服务请求的示意图，如图3所示，客户端101接收到服务请求后，该服务请求作为第二命令302，在此基础上，客户端将添加第一命令301及第三命令303这两个自定义命令，从而得到封装后的第一命令301、第二命令302及第三命令303，然后将封装后的第一命令301、第二命令302、第三命令303发送到服务端102。
其中，第一命令用于指示服务端开启针对客户端与服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息。这样，通过第一命令，从而可以指示服务端随时开启对与该客户端的连接中的服务请求生效的消息跟踪功能。
其中，客户端可向服务端发起连接请求以建立连接，第一命令的消息跟踪功能可仅针对该连接进行跟踪。消息可以是数据的电子实例,通常在两个正在运行的业务流程或应用程序之间进行交换，消息跟踪功能可通过针对服务请求的处理链路中消息的跟踪，得到所需要的跟踪信息，处理链路包括针对服务请求进行处理的过程中的各个处理节点，在本申请实施例中，跟踪信息包括处理链路中的时延信息，例如可以是根据需要指定处理节点之间的时延信息。第一命令可指示所要跟踪的时延信息(例如通过下文举例的第一时间点、第二时间点、第三时间点、第四时间点表示)。第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应。第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息。这样，第一命令指示服务端开启消息跟踪，该消息跟踪针对该客户端与服务端之间的连接，从而能够跟踪该连接上与第一命令打包在一起的第二命令所指示的服务请求的处理链路中的时延信息，并可在得到服务响应后执行第三命令关闭消息跟踪功能，使得消息跟踪只跟踪该连接中服务请求的时延，不会对其他客户端的访问造成影响，例如，当客户端的数量为多个时，每一客户端与服务端为一个连接，使用第一命令指示服务端开启消息跟踪，只跟踪发送该第一命令的客户端与该服务端的单个连接上服务请求的时延，从而有效避免了对其他客户端访问服务端的影响。并且，通过跟踪服务请求的处理链路的时延信息，使得时延信息不限于端到端之间的时延，而是可以跟踪服务请求的处理链路中内部各阶段的时延信息，使得到的时延信息更精确，满足更高的跟踪需求。
示例性地，处理链路的跟踪信息可以包括：服务端处理服务请求的处理链路中的相关信息，例如，接口信息、时延信息等等。其中，时延信息可以包括：服务请求等候处理的时延、服务请求的处理时延、服务响应等候发送的时延中的一种或多种。这样，通过服务请求等候处理的时延、服务请求的处理时延、服务响应等候发送的时延等服务端内部阶段的时延信息，细化了服务端内部的时延信息，将服务端内部处理服务请求的各个阶段的时延信息都能体现出来，从而扩展调用链的跟踪信息，为问题定位提供更多有效的信息。
由于开启了消息跟踪功能，服务端在执行第二命令的过程中，可以随时记录处理链路的时延信息；示例性地，时延信息可以包括：第一时间点、第二时间点、第三时间点、第四时间点；其中，第一时间点表示服务请求进入消息接收队列的时间点；第二时间点表示业务线程开始处理服务请求的时间点；第三时间点表示业务线程将服务响应提交到消息发送队列的时间点；第四时间点表示服务响应从消息发送队列发出的时间点。进一步地，通过第二时间点与第一时间点的差值即可确定服务请求等候处理的时延，通过第三时间点与第二时间点的差值即可确定服务请求的处理时延，或者称为服务请求处理所花费的时间，通过第四时间点与第三时间点的差值即可确定服务响应等候发送的时延。这样，在服务端处理服务请求的过程中，通过记录第一时间点、第二时间点、第三时间点、第四时间点，从而实现随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，为问题定位提供更多有效的信息。
其中，第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息。
当服务端执行第三命令时，关闭服务端内部处理此次服务请求的消息跟踪功能，避免对后续服务端内部处理其他服务请求的影响，同时节约了服务器资源，第三命令与第一命令相配合，实现了消息跟踪功能的随时开启及关闭，且只跟踪单个连接上服务请求的时延信息，有效解决了相关技术中需要提前设置阈值并且需要时延在阈值内的信息才能被跟踪的问题。
在一种可能的实现方式中，客户端可以通过管道(pipeline)的方式，打包发送第一命令、第二命令及第三命令。
考虑到在redis通信协议中支持以管道的方式一次性把多个命令打包发送到服务端。本申请实施例中，客户端可以通过管道的方式，一次性把TRACE BEGIN|MSG|TRACE END三个命令打包发送到服务端，减少客户端与服务端之间的网络传输时间，实现了客户端实时监控服务端的时延信息。
需要说明的是，客户端在向服务端发起服务请求时，可以根据实际需要，选择是否对此处服务请求开启消息跟踪，例如，对于一般服务请求可以选择关闭消息跟踪，在系统出现延迟，需要进行问题定位或对分布式缓存系统能力进行测试阶段时，可以开启消息跟踪；当需要开启针对客户端与服务端的连接的消息跟踪功能时，客户端将一条服务请求转化为三条命令，从而实现了动态开启针对客户端与服务端的连接的消息跟踪功能，方便快捷，同时节省了系统开销。
步骤202、接收服务端发送的服务响应及跟踪信息。
其中，服务响应可以包括查询到的相关数据等，例如，客户端接收到服务端发送所查询到的相关数据后，可以进行下一步地业务流程。
客户端可以获取服务端通过消息跟踪功能所记录的处理链路的跟踪信息，跟踪信息包括处理链路中各阶段的时延信息，从而通过扩展调用链的跟踪信息，为问题定位提供有效的信息。
本申请实施例中，客户端向服务端发起服务请求时，发送封装后的第一命令、第二命令及第三命令，其中，第一命令用于指示服务端开启针对客户端与服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应；第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息；客户端接收服务响应及跟踪信息；这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
进一步地，上述步骤202之后还可以包括：客户端解析跟踪信息，并将解析后的跟踪信息上报到调用链系统。示例性地，客户端接收到服务端返回的跟踪信息之后，可以通过Redis通信协议对该跟踪信息中的时延信息进行解析，然后根据调用链信息的数据结构，将解析后的时延信息上报到调用链系统，例如，可以上报到调用链系统服务进程的部署服务器中。
考虑到在相关技术中，时延信息记录的日志数量有一定的数量限制。例如，上述相关技术中采用Redis慢查询日志功能及延迟监控功能跟踪时延信息的方式中，记录的日志的数量有均有一定的限制。本申请实施例中，客户端通过解析跟踪信息，并将解析后的跟踪信息上报到调用链系统，从而可以将时延信息转储到调用链系统中。这样，时延信息的数量将不再受限，存储的理论上限是调用链系统数据存储的上限，从而有效解决了相关技术中时延信息存储数量限制问题。
图4示出根据本申请一实施例一种信息处理方法的应用场景示意图，如图4所示，其中，调用链系统41可以包括调用节点1、调用节点2…调用节点m等m个调用节点,用于提供调用链管理，其中，m为整数，m的具体数值可以根据实际调用链系统中所部署的调用节点的数量确定，本申请实施例中对此不作限定。客户端101在收到服务端102发送的跟踪信息之后，解析该跟踪信息，从而将解析后的跟踪信息上报到调用链系统41，示例性地，客户端101可以对接收到跟踪信息所包括的时延信息进行解析，并将解析后的时延信息上报到调用节点1。
图5示出根据本申请一实施例一种信息处理方法的流程图，该方法可以应用于上述图1中的分布式缓存系统的服务端，该分布式缓存系统包括客户端和服务端，示例性地，分布式缓存系统采用Redis通信协议；如图5所示，该方法可以包括：
步骤501、服务端接收客户端发送的第一命令、第二命令及第三命令；
该步骤中，服务端接收客户端所发送的封装后的三个命令，即第一命令(TC-BGN，TRACE BEGIN)、第二命令(MSG，MESSAGE)、第三命令(TC-END，TRACE END)，这三个命令采用Redis通信协议。
在一种可能的实现方式中，服务端通过管道的方式，接收客户端打包发送述第一命令、第二命令及第三命令。
考虑到在redis通信协议中支持服务端以管道的方式接收客户端一次性打包发送的多个命令。本申请实施例中，服务端可以通过管道的方式，接收客户端一次性打包发送TRACE BEGIN|MSG|TRACE END三个命令，减少客户端与服务端之间的网络传输时间，实现了实时监控服务端的时延信息。
步骤502、服务端响应于第一命令，开启针对客户端与服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息。
该步骤中，服务端响应于第一命令，从而可以随时开启对任一服务请求生效的消息跟踪功能；同时，服务端执行第一命令指示服务端开启消息跟踪，只跟踪单个连接上命令的时延，不会对其他客户端的访问造成影响，例如，当客户端的数量为多个时，每一客户端与服务端为一个连接，服务端执行第一命令开启消息跟踪，只跟踪发送该第一命令的客户端与该服务端的单个连接上命令的时延，从而有效避免了对其他客户端访问该服务端的影响。
示例性地，处理链路的跟踪信息可以包括：服务端处理服务请求的链路中的相关信息，例如，接口信息、时延信息等等。其中，时延信息可以包括：服务请求等候处理的时延、服务请求的处理时延、服务响应等候发送的时延中的一种或多种。这样，通过服务请求等候处理的时延、服务请求的处理时延、服务响应等候发送的时延等服务端内部阶段的时延信息，可以扩展调用链的跟踪信息，为问题定位提供更多有效的信息。
在一种可能的实现方式中，该步骤可以包括：服务端响应于第一命令，在客户端与服务端的连接上下文中，添加消息跟踪开启标记，并向客户端发送消息跟踪开启结果。
这样，在客户端与服务端的连接上下文中添加消息跟踪开启标记，从而使得服务端在处执行后续第二命令的过程中时，可以仅针对该客户端与该服务端之间的连接进行消息跟踪，不影响其他客户端和服务端之间的访问，并可以将每个关键点(例如上文中的第一时间点、第二时间点、第三时间点和第四时间点)的信息记录在连接上下文中，以便于后续的统计或上报。
步骤503、服务端响应于第二命令，处理客户端的服务请求，并发送处理服务请求得到的服务响应。
由于服务端在执行第一命令时，已经开启针对客户端与服务端的连接的消息跟踪功能，该步骤中，服务端响应于第二命令，在处理客户端的服务请求的过程中，可以同时将每个关键点的信息记录在连接上下文中。示例性地，关键点的信息可以包括：服务请求进入消息接收队列(net-receive-queue)的时间、业务线程开始处理服务请求的时间、业务线程将服务响应提交到消息发送队列(net-send-queue)的时间、服务响应从消息发送队列发出的时间；相应的，时延信息可以包括：第一时间点、第二时间点、第三时间点、第四时间点；其中，第一时间点表示服务请求进入消息接收队列的时间点；第二时间点表示业务线程开始处理服务请求的时间点；第三时间点表示业务线程将服务响应提交到消息发送队列的时间点；第四时间点表示服务响应从消息发送队列发出的时间点。进一步地，通过第二时间点与第一时间点的差值即可确定服务请求等候处理的时延，通过第三时间点与第二时间点的差值即可确定服务请求的处理时延，通过第四时间点与第三时间点的差值即可确定服务响应等候发送的时延。这样，在服务端处理服务请求的过程中，通过将第一时间点、第二时间点、第三时间点、第四时间点记录在连接上下文中，从而实现随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，为问题定位提供更多有效的信息。
示例性地，图6示出根据本申请一实施例服务端跟踪时延信息的示意图，如图6所示，服务端包括两个消息队列：消息接收队列61、消息发送队列62。当服务端接收到第一命令、第二命令(即服务请求)、第三命令时，这三个命令首先进入消息接收队列61(图6中仅示出服务请求进入消息接收队列61)，其中，服务请求等待服务端处理服务请求的业务线程63处理。此时，记录第一个时间点601，即服务请求进入消息接收队列61的时间点；当业务线程63开始处理该服务请求时，记录第二个时间点602；业务线程63对该服务请求行处理，业务线程63处理完服务请求，生成服务响应以后，当业务线程63将服务响应提交到消息发送队列62，记录第三个时间点603；当响应消息从消息发送队列62发送出去时，记录第四个时间点604。
步骤504、服务端响应于第三命令，关闭消息跟踪功能，并向客户端发送跟踪信息。
当服务端执行第三命令时，关闭服务端内部处理此次服务请求的消息跟踪功能，避免对后续服务端内部处理其他服务请求的影响，同时节约了服务器资源，第三命令与第一命令相配合，实现了消息跟踪功能的随时开启及关闭，且可只跟踪单个连接上命令的时延信息。同时，服务端可以将记录在连接上下文中的时延信息进行统计计算，并向客户端发送所跟踪的时延信息。
本申请实施例中，服务端接收客户端发送的第一命令、第二命令及第三命令；响应于第一命令，开启针对客户端与服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；响应于第二命令，处理客户端的服务请求，并发送处理服务请求得到的服务响应；响应于第三命令，关闭消息跟踪功能，并向客户端发送跟踪信息。这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
图7示出根据本申请一实施例一种信息处理方法的流程图，该方法可以应用于上述图1中的分布式缓存系统的客户端和服务端，示例性地，分布式缓存系统采用Redis通信协议；如图7所示，该方法可以包括：
步骤701、在客户端向服务端发起服务请求时，客户端向服务端发送封装后的第一命令、第二命令及第三命令；其中，第一命令用于指示服务端开启针对客户端与服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应；第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息；
该步骤可参照上述图2中步骤201，在此不再赘述。
步骤702、服务端接收客户端发送的第一命令、第二命令及第三命令。
该步骤可参照上述图5中步骤501，在此不再赘述。
步骤703、服务端响应于第一命令，开启针对客户端与服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息。
该步骤可参照上述图5中步骤502，在此不再赘述。
步骤704、服务端响应于第二命令，处理客户端的服务请求，并发送处理服务请求得到的服务响应。
该步骤可参照上述图5中步骤503，在此不再赘述。
步骤705、服务端响应于第三命令，关闭消息跟踪功能，并向客户端发送跟踪信息。
该步骤可参照上述图5中步骤504，在此不再赘述。
步骤706、客户端接收服务端发送的服务响应及跟踪信息。
该步骤可参照上述图2中步骤202，在此不再赘述。
图8示出根据本申请一实施例客户端与服务端信息交互的示意图，如图8所示，客户端与服务端之间执行上述步骤701-706过程中的信息交互。在客户端向服务端发起服务请求时，客户端通过客户端与服务端之间的单个连接，向服务端发送封装后的第一命令、第二命令、第三命令，服务端接收第一命令、第二命令、第三命令，该第一命令、第二命令、第三命令首先进入服务端的消息接收队列，服务端执行第一命令，开启针对客户端与所述服务端的连接的消息跟踪功能，标记该单个连接开启了消息跟踪，以记录服务端内部整个服务请求处理链路的时延信息，并通过消息发送队列将消息跟踪开启结果发送到客户端；服务端执行第二命令，业务线程对消息收发队列中等候的服务请求进行处理，得到服务响应，并通过消息发送队列将服务响应发送到客户端；服务端响应于第三命令，关闭消息跟踪功能，并通过消息发送队列将跟踪信息发送到客户端。从而可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
步骤707、客户端解析跟踪信息，并将解析后的跟踪信息上报到调用链系统。
该步骤可参考上述相关描述，例如图4，在此不再赘述。
步骤708、调用链系统展示跟踪信息。
该步骤中，客户端将跟踪信息上报到调用链系统之后，调用链系统可以通过可视化的页面展示跟踪信息，即可以展示服务端内部各个阶段的时延信息，例如，可以通过根据时延信息及处理业务相关的调用链日志生成服务依赖关系拓扑图，可以直观地观察到故障点或处理整个业务的瓶颈点所在，从而提高问题的定位定界能力。
下面以订单查询这一业务为例，对相关技术中的调用链中跟踪信息与本申请上述实施例中的扩展调用链的跟踪信息进行对比说明。
对于一些商品销售平台(如，网页版商城或手机端应用程序等)，为了提升数据查询性能，一般可以将频繁访问的数据存储在分布式缓存系统中，以便可以从分布式缓存系统中快速查询到相关数据。例如，对于订单查询业务，需要获取订单信息及订单中所涉及的商品信息，以便在销售平台向客户展示；由于不同订单可能涉及同一商品信息，可以将商品信息存储在分布式缓存系统中，而对于订单信息，如交易时间、付款账号等，一般不同的订单信息会存储在数据库(如，ms SQL数据库)中。这样，客户在发起订单查询业务时，业务系统需要调用多个服务，分别从数据库和分布式缓存系统中获取订单信息及商品信息，从而在销售平台向客户展示订单查询结果。
图9示出根据本申请一实施例的相关技术调用链的示意图，图10示出根据本申请一实施例的扩展调用链的示意图，图9中和图10中，调用链标识(Tid，trace ID)，表示一次分布式调用的唯一标识，即在一次分布式调用中处理同一业务的所调用的所有方法的Tid都相同。当前方法标识(sid，span id)，表示调用一个本地或远程方法的唯一标识，即一次调用方法均有唯一的sid。父级方法标识(pid，parent id)，表示调用当前方法的父级方法的唯一标识，pid其实也是一个span id，其值与当前方法的父级方法的span id相同；业务所调用的第一个方法有客户发起，此时没有pid。
如图9所示，以订单查询这一业务为例对相关技术中调用链的跟踪信息进行说明，客户向服务A发起订单查询业务，此时调用第一个方法a1，记作Tid:1,sid:1；该方法执行订单查询业务，需要调用方法a2,记作Tid:1,pid:1,sid:2，及方法a3,记作Tid:1,pid:1,sid:3,方法a2提供相应的服务需要调用分布式缓存服务，此时，执行a2的业务节点即为分布式缓存系统的客户端，向分布式缓存系统的服务端发送查询商品信息的服务请求，服务端处理服务请求，并向a2返回商品信息，a2根据商品信息继续执行服务，并向a1返回相应的服务响应；方法a3提供相应的服务需要调用服务B中的方法b1,记作Tid:1,pid:3,sid:4,方法b1提供相应的服务需要调用服务B中的方法b2,记作Tid:1,pid:4,sid:5,方法b2提供相应的服务需要调用数据库服务，此时，向数据库发送查询订单信息的服务请求，数据库处理服务请求，并向b2返回订单信息，b2根据订单信息继续执行服务，并向b1返回相应的服务响应，b1接收到该服务响应继续执行服务，并向a3返回相应的服务响应，a3接收到该服务响应继续执行服务，并向a1返回相应的服务响应，a1根据接收到的a2和a3的服务响应，进行处理得到订单查询结果，并发送给客户展示该订单查询结果。
如图10所示，以订单查询这一业务为例对本申请上述实施例中扩展调用链的跟踪信息进行说明，客户向服务A发起订单查询业务，此时调用第一个方法a1，记作Tid:1,sid:1；该方法执行订单查询业务，需要调用方法a2,记作Tid:1,pid:1,sid:2及方法a3,记作Tid:1,pid:1,sid:3,方法a2提供相应的服务需要调用分布式缓存服务，此时，执行a2的业务节点即为分布式缓存系统的客户端，向分布式缓存系统的服务端发送查询商品信息的服务请求，服务端处理该服务请求的过程中，同时记录调用的服务端接收阶段的方法c1，记作Tid:1,pid:2,sid:6；记录调用的服务端处理阶段的方法c2，记作Tid:1,pid:6,sid:7；记录调用的服务端发送阶段的方法c3，记作Tid:1,pid:7,sid:8；c3向a2返回商品信息，a2根据商品信息继续执行服务，并向a1返回相应的服务响应；方法a3提供相应的服务需要调用服务B中的方法b1,记作Tid:1,pid:3,sid:4,方法b1提供相应的服务需要调用服务B中的方法b2,记作Tid:1,pid:4,sid:5,方法b2提供相应的服务需要调用数据库服务，此时，向数据库发送查询订单信息的服务请求，数据库处理服务请求，并向b2返回订单信息，b2根据订单信息继续执行服务，并向b1返回相应的服务响应，b1接收到该服务响应继续执行服务，并向a3返回相应的服务响应，a3接收到该服务响应继续执行服务，并向a1返回相应的服务响应，a1根据接收到的a2和a3的服务响应，进行处理得到订单查询结果，并发送给客户展示该订单查询结果。
对比上述图9与如图10可知，在a2调用分布式缓存服务时，图9中只记录了方法a2-Tid:1,pid:1,sid:2，即相关技术中调用链的跟踪信息只包括分布式缓存系统的客户端到服务端的时延信息。而图10中在记录方法a2-Tid:1,pid:1,sid:2的基础上，同时记录了调用的服务端接收阶段的方法c1-Tid:1,pid:2,sid:6；调用的服务端处理阶段的方法c2-Tid:1,pid:6,sid:7；调用的服务端发送阶段的方法c3-Tid:1,pid:7,sid:8。即采用本申请上述实施例中的技术方案，扩展了调用链的跟踪信息，采将分布式缓存系统服务端内部处理服务请求的每个阶段，都用一个span id对应关联起来，从而跟踪服务端内部处理服务请求各个阶段的时延信息，提高了问题定位定界能力。
进一步地，分布式缓存系统的客户端可以接入调用链系统，将所跟踪的各个阶段时延信息统计到调用链系统上，并通过图形化展示出调用关系。
图11示出根据本申请一实施例的展示扩展调用链中跟踪信息的示意图，如图11所示，展示了上述图10中扩展调用链的跟踪信息，通过图11，可以清晰地观察处理订单查询业务过程中的各服务调用关系，及每个服务的耗时占比；以及分布式缓存服务服务端内部各阶段的耗时占比，即服务请求等候处理的时延、服务请求的处理时延、服务响应等候发送的时延，通过观察个服务及各个阶段的状态，可以迅速定位到问题根因，从而有效提高了分布式缓存系统的问题定位定界能力。
图12示出根据本申请一实施例一种信息处理装置的结构图，该装置可以应用于上述图1中的分布式缓存系统的客户端，如图12所示，该信息处理装置12可以包括：发送模块1201，用于在所述客户端向所述服务端发起服务请求时，所述客户端向所述服务端发送封装后的第一命令、第二命令及第三命令，其中，所述第一命令用于指示所述服务端开启针对客户端与所述服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；所述第二命令用于指示所述服务端处理所述服务请求，并发送处理所述服务请求得到的服务响应；所述第三命令用于指示所述服务端关闭消息跟踪功能，并发送所述跟踪信息；第一接收模块1202，用于接收所述服务端发送的所述服务响应及所述跟踪信息。
在一种可能的实现方式中，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
在一种可能的实现方式中，所述时延信息，包括：第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
在一种可能的实现方式中，所述发送模块1201，还用于：所述客户端通过管道的方式，打包发送所述第一命令、所述第二命令及所述第三命令。
在一种可能的实现方式中，所述装置还包括上报模块，用于：解析所述跟踪信息，并将解析后的跟踪信息上报到调用链系统。
在一种可能的实现方式中，所述分布式缓存系统采用远程字典服务Redis通信协议。
本申请实施例中，客户端向服务端发起服务请求时，发送封装后的第一命令、第二命令及第三命令，其中，第一命令用于指示服务端开启针对客户端与服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；第二命令用于指示服务端处理服务请求，并发送处理服务请求得到的服务响应；第三命令用于指示服务端关闭消息跟踪功能，并发送跟踪信息；客户端接收服务响应及跟踪信息；这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
图13示出根据本申请一实施例一种信息处理装置的结构图，该装置可以应用于上述图1中的分布式缓存系统的服务端，如图13所示，该信息处理装置13可以包括：第二接收模块1301，用于接收所述客户端发送的第一命令、第二命令及第三命令；处理模块1302，用于响应于所述第一命令，开启针对客户端与服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；响应于所述第二命令，处理所述客户端的服务请求，并发送处理所述服务请求得到的服务响应；响应于所述第三命令，关闭消息跟踪功能，并向所述客户端发送所述跟踪信息。
在一种可能的实现方式中，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
在一种可能的实现方式中，所述时延信息，包括：第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
在一种可能的实现方式中，所述第二接收模块1301，还用于：通过管道的方式，接收所述客户端打包发送的所述第一命令、所述第二命令及所述第三命令。
在一种可能的实现方式中，所述处理模块1302，还用于：响应于所述第一命令，在所述客户端与所述服务端的连接上下文中，添加消息跟踪开启标记，并向所述客户端发送消息跟踪开启结果。
在一种可能的实现方式中，所述分布式缓存系统采用远程字典服务Redis通信协议。
本申请实施例中，服务端接收客户端发送的第一命令、第二命令及第三命令；响应于第一命令，开启针对客户端与服务端的连接的消息跟踪功能，以记录服务请求的处理链路的跟踪信息，跟踪信息包括处理链路中的时延信息；响应于第二命令，处理客户端的服务请求，并发送处理服务请求得到的服务响应；响应于第三命令，关闭消息跟踪功能，并向客户端发送跟踪信息。这样，可以随时跟踪服务端内部各阶段的时延信息，扩展了服务端内部的跟踪信息，提高了分布式缓存系统的问题定位定界能力，实现了快速精确地问题定位。
上述实施例的各种可能的实现方式或说明参见上文，此处不再赘述。
本申请的实施例提供了一种信息处理装置，包括：处理器以及用于存储处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令时实现上述图2中的方法，或图5中的方法，或图7中的方法。
图14示出根据本申请一实施例的一种信息处理装置的结构图，如图14所示，该信息处理装置可以包括：至少一个处理器1401，通信线路1402，存储器1403以及至少一个通信接口1404。
处理器1401可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
通信线路1402可包括一通路，在上述组件之间传送信息。
通信接口1404，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，RAN，无线局域网(wireless local area networks，WLAN)等。
存储器1403可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compactdisc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过通信线路1402与处理器相连接。存储器也可以和处理器集成在一起。本申请实施例提供的存储器通常可以具有非易失性。其中，存储器1403用于存储执行本申请方案的计算机执行指令，并由处理器1401来控制执行。处理器1401用于执行存储器1403中存储的计算机执行指令，从而实现本申请上述实施例中提供的方法，如上述图2中的方法，或图5中的方法，或图7中的方法。
可选的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。
在具体实现中，作为一种实施例，处理器1401可以包括一个或多个CPU，例如图14中的CPU0和CPU1。
在具体实现中，作为一种实施例，信息处理装置可以包括多个处理器，例如图14中的处理器1401和处理器1407。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
在具体实现中，作为一种实施例，信息处理装置还可以包括输出设备1405和输入设备1406。输出设备1405和处理器1401通信，可以以多种方式来显示信息。例如，输出设备1405可以是液晶显示器(liquid crystal display，LCD)，发光二级管(light emittingdiode，LED)显示设备，阴极射线管(cathode ray tube，CRT)显示设备，或投影仪(projector)等。输入设备1406和处理器1401通信，可以以多种方式接收用户的输入。例如，输入设备1406可以是鼠标、键盘、触摸屏设备或传感设备等。
本申请的实施例提供了一种非易失性计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现上述方法，如上述图2中的方法，或图5中的方法，或图7中的方法。
本申请的实施例提供了一种包含指令的计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在计算机上运行时，所述计算机执行上述方法，如上述图2中的方法，或图5中的方法，或图7中的方法。
计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RandomAccess Memory，RAM)、只读存储器(Read Only Memory，ROM)、可擦式可编程只读存储器(Electrically Programmable Read-Only-Memory，EPROM或闪存)、静态随机存取存储器(Static Random-Access Memory，SRAM)、便携式压缩盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、数字多功能盘(Digital Video Disc，DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。
这里所描述的计算机可读程序指令或代码可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。
用于执行本申请操作的计算机程序指令可以是汇编指令、指令集架构(Instruction Set Architecture，ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(Local Area Network，LAN)或广域网(WideArea Network，WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(Field-ProgrammableGate Array，FPGA)或可编程逻辑阵列(Programmable Logic Array，PLA)，该电子电路可以执行计算机可读程序指令，从而实现本申请的各个方面。
这里参照根据本申请实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。
这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。
也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。
附图中的流程图和框图显示了根据本申请的多个实施例的装置、系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。
也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行相应的功能或动作的硬件(例如电路或ASIC(Application SpecificIntegrated Circuit，专用集成电路))来实现，或者可以用硬件和软件的组合，如固件等来实现。
尽管在此结合各实施例对本发明进行了描述，然而，在实施所要求保护的本发明过程中，本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书，可理解并实现所述公开实施例的其它变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其它单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。
以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (27)

1.一种信息处理方法，其特征在于，所述方法应用于分布式缓存系统的客户端，所述分布式缓存系统包括客户端和服务端，所述方法包括：
在所述客户端向所述服务端发起服务请求时，所述客户端向所述服务端发送封装后的第一命令、第二命令及第三命令，其中，所述第一命令用于指示所述服务端开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；所述第二命令用于指示所述服务端处理所述服务请求，并发送处理所述服务请求得到的服务响应；所述第三命令用于指示所述服务端关闭消息跟踪功能，并发送所述跟踪信息；
接收所述服务端发送的所述服务响应及所述跟踪信息。
2.根据权利要求1所述的方法，其特征在于，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
3.根据权利要求1或2所述的方法，其特征在于，所述时延信息，包括：
第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；
第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；
第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；
第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
4.根据权利要求1所述的方法，其特征在于，所述客户端向所述服务端发送封装后的第一命令、第二命令及第三命令，包括：
所述客户端通过管道的方式，打包发送所述第一命令、所述第二命令及所述第三命令。
5.根据权利要求1所述的方法，其特征在于，所述方法还包括：
解析所述跟踪信息，并将解析后的跟踪信息上报到调用链系统。
6.根据权利要求1所述的方法，其特征在于，所述分布式缓存系统采用远程字典服务Redis通信协议。
7.一种信息处理方法，其特征在于，所述方法应用于分布式缓存系统的服务端，所述分布式缓存系统包括客户端和服务端，所述方法包括：
接收所述客户端发送的第一命令、第二命令及第三命令；
响应于所述第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；
响应于所述第二命令，处理所述客户端的服务请求，并发送处理所述服务请求得到的服务响应；
响应于所述第三命令，关闭消息跟踪功能，并向所述客户端发送所述跟踪信息。
8.根据权利要求7所述的方法，其特征在于，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
9.根据权利要求7或8所述的方法，其特征在于，所述时延信息，包括：
第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；
第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；
第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；
第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
10.根据权利要求7所述的方法，其特征在于，所述接收所述客户端发送的第一命令、第二命令及第三命令，包括：
通过管道的方式，接收所述客户端打包发送的所述第一命令、所述第二命令及所述第三命令。
11.根据权利要求7所述的方法，其特征在于，所述响应于所述第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，包括：
响应于所述第一命令，在所述客户端与所述服务端的连接上下文中，添加消息跟踪开启标记，并向所述客户端发送消息跟踪开启结果。
12.根据权利要求7所述的方法，其特征在于，所述分布式缓存系统采用远程字典服务Redis通信协议。
13.一种信息处理装置，其特征在于，所述装置应用于分布式缓存系统的客户端，所述分布式缓存系统包括客户端和服务端，所述装置包括：
发送模块，用于在所述客户端向所述服务端发起服务请求时，所述客户端向所述服务端发送封装后的第一命令、第二命令及第三命令，其中，所述第一命令用于指示所述服务端开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；所述第二命令用于指示所述服务端处理所述服务请求，并发送处理所述服务请求得到的服务响应；所述第三命令用于指示所述服务端关闭消息跟踪功能，并发送所述跟踪信息；
第一接收模块，用于接收所述服务端发送的所述服务响应及所述跟踪信息。
14.根据权利要求13所述的装置，其特征在于，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
15.根据权利要求13或14所述的装置，其特征在于，所述时延信息，包括：
第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；
第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；
第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；
第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
16.根据权利要求13所述的装置，其特征在于，所述发送模块，还用于：所述客户端通过管道的方式，打包发送所述第一命令、所述第二命令及所述第三命令。
17.根据权利要求13所述的装置，其特征在于，所述装置还包括上报模块，用于：解析所述跟踪信息，并将解析后的跟踪信息上报到调用链系统。
18.根据权利要求13所述的装置，其特征在于，所述分布式缓存系统采用远程字典服务Redis通信协议。
19.一种信息处理装置，其特征在于，所述装置应用于分布式缓存系统的服务端，所述分布式缓存系统包括客户端和服务端，所述装置包括：
第二接收模块，用于接收所述客户端发送的第一命令、第二命令及第三命令；
处理模块，用于响应于所述第一命令，开启针对所述客户端与所述服务端的连接的消息跟踪功能，以记录所述服务请求的处理链路的跟踪信息，所述跟踪信息包括处理链路中的时延信息；响应于所述第二命令，处理所述客户端的服务请求，并发送处理所述服务请求得到的服务响应；响应于所述第三命令，关闭消息跟踪功能，并向所述客户端发送所述跟踪信息。
20.根据权利要求19所述的装置，其特征在于，所述时延信息包括：所述服务请求等候处理的时延、所述服务请求的处理时延、所述服务响应等候发送的时延中的一种或多种。
21.根据权利要求19或20所述的装置，其特征在于，所述时延信息，包括：
第一时间点，所述第一时间点表示所述服务请求进入消息接收队列的时间点；
第二时间点，所述第二时间点表示业务线程开始处理所述服务请求的时间点；
第三时间点，所述第三时间点表示业务线程将所述服务响应提交到消息发送队列的时间点；
第四时间点，所述第四时间点表示所述服务响应从所述消息发送队列发出的时间点。
22.根据权利要求19所述的装置，其特征在于，所述第二接收模块，还用于：通过管道的方式，接收所述客户端打包发送的所述第一命令、所述第二命令及所述第三命令。
23.根据权利要求19所述的装置，其特征在于，所述处理模块，还用于：响应于所述第一命令，在所述客户端与所述服务端的连接上下文中，添加消息跟踪开启标记，并向所述客户端发送消息跟踪开启结果。
24.根据权利要求19所述的装置，其特征在于，所述分布式缓存系统采用远程字典服务Redis通信协议。
25.一种信息处理装置，其特征在于，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令时实现权利要求1-6任意一项所述的方法，或者，实现权利要求7-12任意一项所述的方法。
26.一种非易失性计算机可读存储介质，其上存储有计算机程序指令，其特征在于，所述计算机程序指令被处理器执行时实现权利要求1-6中任意一项所述的方法，或者，实现权利要求7-12任意一项所述的方法。
27.一种包含指令的计算机程序产品，其特征在于，当其在计算机上运行时，使得计算机执行如权利要求1-6中任意一项所述的方法，或者，实现权利要求7-12任意一项所述的方法。
CN202011337118.5A 2020-11-25 2020-11-25 一种信息处理方法、装置、存储介质及计算机程序产品 Pending CN114546817A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011337118.5A CN114546817A (zh) 2020-11-25 2020-11-25 一种信息处理方法、装置、存储介质及计算机程序产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011337118.5A CN114546817A (zh) 2020-11-25 2020-11-25 一种信息处理方法、装置、存储介质及计算机程序产品

Publications (1)

Publication Number Publication Date
CN114546817A true CN114546817A (zh) 2022-05-27

Family

ID=81659142

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011337118.5A Pending CN114546817A (zh) 2020-11-25 2020-11-25 一种信息处理方法、装置、存储介质及计算机程序产品

Country Status (1)

Country Link
CN (1) CN114546817A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115550305A (zh) * 2022-09-28 2022-12-30 深圳市凯迪仕智能科技股份有限公司 设备控制方法及相关装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115550305A (zh) * 2022-09-28 2022-12-30 深圳市凯迪仕智能科技股份有限公司 设备控制方法及相关装置
CN115550305B (zh) * 2022-09-28 2024-03-01 深圳市凯迪仕智能科技股份有限公司 设备控制方法及相关装置

Similar Documents

Publication Publication Date Title
US11314758B2 (en) Storing and querying metrics data using a metric-series index
US10404822B2 (en) Predictive rollup and caching for application performance data
US10452463B2 (en) Predictive analytics on database wait events
US11675682B2 (en) Agent profiler to monitor activities and performance of software agents
US20180219956A1 (en) Dynamic docker pool recycling
US10536505B2 (en) Intelligent data transmission by network device agent
US10528456B2 (en) Determining idle testing periods
CN114490268A (zh) 全链路监控方法、装置、设备、存储介质和程序产品
US11683391B2 (en) Predicting microservices required for incoming requests
CN114546817A (zh) 一种信息处理方法、装置、存储介质及计算机程序产品
US10706108B2 (en) Field name recommendation
US10644971B2 (en) Graph search in structured query language style query
US20180121329A1 (en) Uninstrumented code discovery
CN116097226A (zh) 用于将故障注入分布式系统的装置和方法
EP3665570B1 (en) Correlation across non-logging components
CN112306848A (zh) 微服务系统的架构视图生成方法及装置
CN113326243B (zh) 分析日志数据的方法和装置
Yalavarti Observatory: Fast and Scalable Systems Observability
CN117539719A (zh) 应用运行监测方法、装置、设备及介质
Rank et al. Towards Performance Prediction for Stream Processing Applications.

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