CN120301945A - 一种港口平台的缓存信息处理方法、设备及介质 - Google Patents
一种港口平台的缓存信息处理方法、设备及介质 Download PDFInfo
- Publication number
- CN120301945A CN120301945A CN202510779361.9A CN202510779361A CN120301945A CN 120301945 A CN120301945 A CN 120301945A CN 202510779361 A CN202510779361 A CN 202510779361A CN 120301945 A CN120301945 A CN 120301945A
- Authority
- CN
- China
- Prior art keywords
- cache
- message
- data
- request
- business
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/215—Flow control; Congestion control using token-bucket
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/105—Multiple levels of security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种港口平台的缓存信息处理方法、设备及介质,属于港口分布式信息处理技术领域,接收更新请求,对请求进行鉴权与限流处理;获取缓存键前缀及数据结构类型,基于消费回写事件将缓存键路由至分片节点,在分布式缓存服务中执行写入操作并设置生存时间及多副本同步;将消息体投递至消息中间件并获取投递确认;按照配置的并发度从队列拉取消息,对消息的幂等标识进行去重校验,在校验消息版本高于数据库当前版本后执行数据持久化操作;在全链路各模块植入指标采集点,对请求延迟、缓存命中率、消息堆积深度指标进行可视化展示。实现对系统资源的合理分配和优化;保障了数据的一致性和完整性,同时提高了消息传递的可靠性。
Description
技术领域
本发明属于港口分布式信息处理技术领域,具体涉及一种港口平台的缓存信息处理方法、设备及介质。
背景技术
目前,港口一体化平台已逐步成为整合船舶调度、码头作业、设备监控和物流跟踪等关键环节的数据中枢。该平台需处理海量实时业务请求,既要保证各子系统之间的数据高效交换,又要满足秒级响应和高并发访问的要求。
为满足港口需求,业界通常采用分布式缓存来加速热点数据访问,并辅以异步消息队列实现模块间的松耦合通信。在缓存方面,以Redis为代表的内存存储数据结构服务器因其优异的读写性能、丰富的数据类型支持字符串、列表、哈希、有序集合等,以及集群分片和高可用保障,被广泛用于热点数据加速和分布式锁等场景。
港口一体化平台数据处理方式,数据读写操作可能都集中在数据库,导致响应速度慢,无法满足高并发场景下快速响应的需求。同时,对于热点数据的处理能力不足,大量对热点数据的请求会造成存储系统负载过高,进一步降低系统性能。在分布式环境中,数据在多个节点存储和传输,容易出现数据不一致的情况。消息重复处理、数据版本混乱等问题,会导致数据库中数据错误或不完整。当系统出现异常时,无法快速定位问题根源,排查和修复故障耗时较长,影响系统的正常运行和用户体验。
发明内容
本发明提供一种港口平台的缓存信息处理方法,方法实现了对系统资源的合理分配和优化;保障了数据的一致性和完整性,同时提高了消息传递的可靠性。
方法包括:
S101:接收包含订单标识、目标状态和用户凭证的更新请求,对请求进行鉴权与限流处理,并为通过限流的请求生成链路标识和初始化请求上下文;
S102:解析链路标识和请求体,获取缓存键前缀及数据结构类型,在本地内存缓存中执行写入操作并设置短期生存时间,写入成功后返回响应,同时发布消费回写事件,并标记需要同步至分布式缓存;
S103:基于消费回写事件将缓存键路由至分片节点,在分布式缓存服务中执行写入操作并设置生存时间及多副本同步;
S104:根据缓存写入结果构建包含订单标识、状态变更、版本号、幂等标识及时间戳的消息体,依据消息分区键、业务优先级和队列堆积状况选择消息交换类型和目标队列,将消息体投递至消息中间件并获取投递确认;
S105:按照配置的并发度从队列拉取消息,对消息的幂等标识进行去重校验,在校验消息版本高于数据库当前版本后执行数据持久化操作;
S106:在全链路各模块植入指标采集点,对请求延迟、缓存命中率、消息堆积深度指标进行可视化展示。
进一步需要说明的是,步骤S101具体包括:
在接收包含订单标识、目标状态和用户凭证的更新请求时,基于请求来源的业务属性和用户角色,调整鉴权验证策略;
在限流处理阶段,实时采集网关运行状态,通过规则引擎计算令牌桶算法的令牌生成速率和桶容量;
当触发限流时,对核心业务请求进入排队等待队列并分配优先级标记;
在生成链路标识时,将请求的业务类型、用户角色及访问路径编码至TraceID的前缀中,形成结构化的标识格式;
在初始化请求上下文时,将TraceID及关键元数据透传至后端SDK和监控系统;当链路中某环节发生异常时,TraceID携带异常信息回溯至请求源头。
进一步需要说明的是,步骤S102具体包括:
基于实时业务负载调整缓存键的短期生存时间;
根据缓存键的前缀及数据结构类型,结合分布式缓存节点的负载状态,预判缓存键在分布式缓存中的目标分片节点,并在本地缓存中标记目标分片信息;
为本地缓存中的每个缓存键生成缓存映射表,记录其在本地缓存和分布式缓存中的存储位置及版本号;
根据缓存键的业务重要性或数据更新频率,为消费回写事件分配优先级标签;
步骤S102还基于当前缓存键的访问频率及历史趋势,预测未来可能成为热点的缓存键,并提前在分布式缓存中预留存储空间;
对预测的热点数据,将相关缓存键全量加载至分布式缓存节点,并通过流量镜像技术验证加载效果。
进一步需要说明的是,步骤S103具体包括:
在路由缓存键至分片节点时,基于分布式缓存节点的当前负载状态,调整缓存键的路由规则,并在写入多副本时,为每个副本分配独立的版本号,在写入完成后通过分布式事务框架验证副本间版本一致性;
基于历史访问日志及当前访问频率,预测未来一段时间内成为热点的缓存键集合。
进一步需要说明的是,方法还基于步骤S101传递的拓扑路由标签及业务类型,其中,核心业务数据采用跨区域多活分片,同步写入主备区域节点;普通业务采用本地域一致性哈希分片,在步骤S106监测到目标区域延迟超阈值时,将分片流量切换至低延迟区域;
步骤S103还基于单节点写入失败率超第一预设阈值时,启用同区域备用节点重试;同区域整体失败率超第二预设时,触发跨层联动:向步骤S102发送指令延长本地缓存生存周期;将请求导向步骤S105关联的数据库只读副本,返回静态化数据;并标记失败区域为脆弱区,暂停非核心业务写入;
根据步骤S106植入的节点装置,规避高负载节点分片;对连续失效的数据执行生成加密快照存储至冷备存储池,再强制启用多区域同步写入;并向S101反馈信用扣减信号限制来源请求。
进一步需要说明的是,步骤S104具体包括:
在构建消息体时,根据订单标识关联的业务实体类型生成消息路由特征向量,将特征向量与预设的路由规则库进行匹配,调整消息的Exchange类型和目标Queue优先级;
对包含状态变更历史的消息体进行分层压缩:采用字典编码压缩常用字段值,压缩后的消息体通过独立通道投递至消息中间件;
建立消息投递的跨中间件容灾通道,当主消息中间件出现故障时,将消息切换至备用中间件的对应Topic,并根据备用中间件的协议特性调整消息格式;
在本地Retry队列中增加消息老化时间戳字段,对超过预设老化时间仍未成功投递的消息,触发业务补偿逻辑:根据消息中的幂等标识查询数据库,若对应业务操作已完成则标记消息为已处理并丢弃。
进一步需要说明的是,步骤S105具体包括:
在消息拉取阶段,根据港口作业高峰时段提升消费者实例的并发消费数量,非高峰时段恢复默认值,以匹配业务流量波动;
在幂等校验环节,比对消息中的状态变更路径与数据库中记录的前序状态是否一致;
在数据持久化前,对消息中的版本号与数据库当前版本号进行差值校验,若差值超过预设阈值,则判定为过时消息并跳过处理;
当消息写入补偿队列时,关联该消息对应的缓存键与链路标识,生成包含操作时间、失败次数、数据库锁状态的诊断数据包,供补偿任务在重试时优先获取锁状态信息。
进一步需要说明的是,方法中,基于S106下发的实时消息堆积深度及消费者处理延迟指标,堆积深度超阈值时线性增加并发度,延迟超阈值时启用批量预取模式;为高信用核心业务分配独立消费通道,隔离非核心业务流量冲击;
核心业务状态变更定义校验版本号连续性;非核心业务设定为跳过中间版本;当检测到版本号断层时,查询步骤S103分布式缓存获取最新数据补全版本链;
方法在解析消息中嵌入的拓扑路由标签时,路由至同区域数据库副本;若目标副本不可用,依据定义的区域健康拓扑图切换至最近低延迟副本;处理结果回传至S106,关联全链路标识更新追踪状态;
方法还采集步骤S102本地缓存命中率、步骤S103分布式缓存写入延迟、步骤S104消息投递成功率、步骤S105消费者处理延迟的实时数据,并基于(命中率×20%)+(1/延迟×30%)+(成功率×30%)+(1/延迟×20%)计算业务健康度综合评分;当评分低于安全阈值时触发全局预警。
根据本申请的另一个实施例,提供了一种电子设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述程序时实现所述港口平台的缓存信息处理方法的步骤。
根据本申请的又一个实施例,还提供了一种存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现所述港口平台的缓存信息处理方法的步骤。
从以上技术方案可以看出,本发明具有以下优点:
本发明提供的港口平台的缓存信息处理方法能够验证用户身份和权限,防止非法用户访问系统资源,保障系统安全性;限流处理可避免因流量过大导致系统负载过高甚至崩溃,保证系统稳定运行。将数据先写入本地内存缓存并设置短期生存时间,利用本地内存缓存访问速度快的特点,能快速响应请求,减少用户等待时间。
本发明基于消费回写事件将缓存键路由至分片节点,合理分配数据存储,提高分布式缓存的使用效率。设置生存时间及多副本同步,增强了数据的可用性和持久性。对热点数据进行全量加载,可减少热点数据访问时的延迟,提高系统整体性能。
本发明根据缓存写入结果构建包含多种关键信息的消息体,确保消息携带完整业务信息;依据多种条件选择消息交换类型和目标队列,实现消息的智能投递,提高消息处理效率。对消息幂等标识进行去重校验,防止重复处理相同消息导致数据不一致;校验消息版本后执行持久化操作,确保数据库中数据为最新有效数据,保证数据一致性;在全链路植入指标采集点并可视化展示,方便运维人员实时监控系统运行状态;关键指标超阈值时自动调整资源配置,使系统能够根据负载情况优化资源利用。
附图说明
为了更清楚地说明本发明的技术方案,下面将对描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为港口平台的缓存信息处理系统架构示意图;
图2为港口平台的缓存信息处理方法流程图;
图3为电子设备示意图。
具体实施方式
本发明提供的港口平台的缓存信息处理方法将分布式缓存与消息队列在港口一体化平台中进行深度集成与优化的方法。通过统一接入层、异步双写一致性保障、多级缓存预热、消息优先级路由及化弹性伸缩等技术手段,实现低延迟、高吞吐且可平滑应对突发流量的缓存。
如图1是实现本方法的整体系统架构,分别为请求接入层、中间件协同层、后端持久化层与统一监控控制层。
具体来讲,请求接入层包括网关与嵌入式SDK,作为所有客户端请求进入系统的统一入口。网关具备统一认证、限流、降级、日志打标等功能,而SDK则集成于具体业务微服务中,提供本地缓存与消息封装的标准接口。
中间件协同层由分布式缓存子系统与消息队列子系统构成,是本发明的核心创新区。分布式缓存支持本地+远程两级缓存结构,具备高性能数据读写能力;消息队列子系统则支撑系统内部的异步通信、事件驱动与削峰填谷处理。
后端持久化层包括数据库与文件存储系统,用于完成关键业务数据的最终落地与一致性保障。该层通过异步处理机制与幂等判断,确保在系统高并发情况下保持数据正确性。
统一监控控制层负责全链路数据流的监控与治理,支持对缓存命中率、消息堆积情况、服务响应延迟、异常告警等信息进行实时分析,同时与容器平台配合实现伸缩与策略调整。
系统架构设计可以将缓存与消息作为协同中间件能力,而非孤立组件,形成一个可感知系统运行状态并自我调节的智能中台,极大提升了整体系统的韧性与资源利用率。
以下将详细描述本申请涉及的港口平台的缓存信息处理方法,为了说明而不是为了限定,提出了诸如特定系统结构、技术之类的具体细节,以便透彻理解本申请实施例。然而,本领域技术人员应当清楚,在没有这些具体细节的其它实施例中也可以实现本申请。
应当理解的是,当在本申请说明书中使用时,术语包括指示所描述特征、整体、步骤、操作、元素和/或组件的存在,但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。术语包括、包含、具有及它们的变形都意味着包括但不限于,除非是以其他方式另外特别强调。
在本申请中描述的一个实施例或一些实施例等语句意味着在本申请的一个或多个实施例中包括该实施例描述的特定特征、结构或特点。由此,在本申请中的不同之处出现的在一个实施例中、在一些实施例中、在其他一些实施例中、在另外一些实施例中等语句不是必然都参考相同的实施例,而是意味着一个或多个但不是所有的实施例,除非是以其他方式另外特别强调。
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
请参阅图2所示是一具体实施例中港口平台的缓存信息处理方法的流程图,方法包括:
步骤S101:接收包含订单标识、目标状态和用户凭证的更新请求,对请求进行鉴权与限流处理,并为通过限流的请求生成链路标识和初始化请求上下文。
在一些实施例中,系统接收包含订单标识、目标状态和用户凭证的更新请求后,首先进行鉴权处理,验证用户凭证的合法性,包括令牌有效性、权限检查等。同时进行限流处理,防止恶意请求或过大流量对系统造成冲击。对于通过限流的请求,生成唯一的链路标识,用于全链路追踪,并初始化请求上下文,存储请求相关的元数据。确保系统安全性,防止未授权访问。
在一些具体的实施例中,船舶调度系统或运营平台通过HTTP/GRPC接口发送带有订单ID、目标状态和用户凭证的更新请求。
请求格式示例:
{"orderId":12345,"newStatus":"LOADED","authToken":"xxx"}。
网关校验authToken的合法性,并根据用户所属角色、IP地址、接口级别分别执行令牌桶限流。若限流触发,则对非核心业务返回预定义降级响应,核心业务则进入排队等待。成功通过限流的请求,网关生成唯一的TraceID和RequestID,用于后续全链路跟踪与日志聚合。请求元数据被下发至后端SDK和监控系统。请求元数据可以为用户信息、请求来源、业务类型。
步骤S102:解析链路标识和请求体,获取缓存键前缀及数据结构类型,在本地内存缓存中执行写入操作并设置短期生存时间,写入成功后返回响应,同时发布消费回写事件,并标记需要同步至分布式缓存。
在一些实施例中,在全链路各模块植入指标采集点,收集请求延迟、缓存命中率、消息堆积深度等指标。对这些指标进行可视化展示,便于运维人员监控系统运行状态。当关键指标持续超过预设阈值时,调整系统资源配置,如增加服务器实例或调整缓存大小。对指标异常和服务异常进行实时告警,并支持通过链路标识进行问题定位,快速排查故障原因。
在一些具体的实施例中,SDK解析TraceID和请求体,从本地配置获取缓存Key的前缀以及数据结构类型。SDK在本地内存缓存中执行写入操作,并为该条目设置短期TTL,可以设置为5秒,10秒,以用于后续短时重复请求的高速响应。写入成功后立即返回给网关缓存已更新响应,减少延迟感知。本地写入后,SDK在内部发布回写事件到回写队列,标记该条目需要同步至L2分布式缓存。同时上报本地缓存命中率和写入延迟指标。
作为本申请的步骤S102的一种实现方式,步骤S102具体包括:
基于实时业务负载调整缓存键的短期生存时间;根据缓存键的前缀及数据结构类型,结合分布式缓存节点的负载状态,预判缓存键在分布式缓存中的目标分片节点,并在本地缓存中标记目标分片信息;为本地缓存中的每个缓存键生成缓存映射表,记录其在本地缓存和分布式缓存中的存储位置及版本号;根据缓存键的业务重要性或数据更新频率,为消费回写事件分配优先级标签。
步骤S102还基于当前缓存键的访问频率及历史趋势,预测未来可能成为热点的缓存键,并提前在分布式缓存中预留存储空间;对预测的热点数据,将相关缓存键全量加载至分布式缓存节点,并通过流量镜像技术验证加载效果。
可以看出,通过调整TTL,系统能够在不同业务负载下智能平衡数据freshness和缓存命中率,提升整体性能。预判分片节点并标记分片信息,减少了数据在分布式缓存中的迁移和查找开销,加速数据访问。缓存映射表的存在使得数据在本地和分布式缓存间的同步和版本控制更加精准高效。流量镜像验证保证了预加载策略的正确性,降低了因预判失误导致的风险。
步骤S103:基于消费回写事件将缓存键路由至分片节点,在分布式缓存服务中执行写入操作并设置生存时间及多副本同步;当出现缓存失效或写入失败时执行备选节点重试或开启临时降级策略,基于访问频率对热点数据进行全量加载。
在一些实施例中,基于消费回写事件将缓存键路由至分片节点,根据分片规则确定数据应存储的节点。在分布式缓存服务中执行写入操作,设置生存时间及多副本同步,确保数据的可用性和持久性。当出现缓存失效或写入失败时,执行备选节点重试,若仍失败则开启临时降级策略,如返回默认值或降级服务。基于访问频率对热点数据进行全量加载,提高热点数据的访问性能。
这里的分片规则基于一致性哈希或范围分片等算法,将缓存键映射到具体节点。分布式缓存使用如RedisCluster等集群模式,支持多副本同步。缓存失效检测通过定期轮询或事件通知机制。提高缓存可用性和可靠性,多副本同步确保数据不丢失。
作为步骤S103的一种实现方式,具体包括:在路由缓存键至分片节点时,基于分布式缓存节点的当前负载状态,调整缓存键的路由规则,并在写入多副本时,为每个副本分配独立的版本号,在写入完成后通过分布式事务框架验证副本间版本一致性;基于历史访问日志及当前访问频率,预测未来一段时间内成为热点的缓存键集合。
在将缓存键路由至分片节点时,系统会实时收集分布式缓存集群中各节点的负载状态,包括CPU使用率、内存占用、网络I/O等指标。基于这些指标调整缓存键的路由规则,例如将新的缓存键优先路由至负载较低的节点,避免流量过度集中。在写入多副本时,为每个副本分配独立的版本号,版本号包含时间戳和序列号信息。写入完成后,通过分布式事务框架如Seata或TCC模式,验证所有副本间的版本一致性,确保数据在各副本间的同步性。系统会分析历史访问日志,提取缓存键的访问模式、频率变化趋势等信息。结合当前的访问频率数据,运用时间序列分析、机器学习算法如LRU改进算法或基于热度预测模型,预测未来一段时间内可能成为热点的缓存键集合。实现了分布式缓存集群的负载均衡,避免了部分节点过载导致的性能瓶颈,提升了整个缓存系统的吞吐量和稳定性。多副本独立版本号及一致性验证机制,确保了数据在各副本间的强一致性,提高了数据可靠性。
本申请的步骤S103示例的讲,回写事件由缓存协调模块消费,根据一致性哈希算法将Key路由至对应分片节点。分布式缓存服务对写入操作设置足够的TTL并进行多副本同步。若L2写入过程中发生短暂故障或节点宕机,模块触发备选节点重试机制。当监测到大规模缓存失效或写入失败率超过阈值时,缓存协调模块会开启临时降级策略,将读写请求直接导向后端数据库或返回静态内容。
本实施例基于访问频率监控,当某个Key的访问量超过预热阈值,分布式缓存子系统会主动将该Key的数据全量加载到所有缓存节点,防止集中访问时的并发压力。
步骤S104:根据缓存写入结果构建包含订单标识、状态变更、版本号、幂等标识及时间戳的消息体,依据消息分区键、业务优先级和队列堆积状况选择消息交换类型和目标队列,将消息体投递至消息中间件并获取投递确认;若投递失败则缓存至本地重试队列并执行定时重试。
在一些实施例中,根据缓存写入结果构建包含订单标识、状态变更、版本号、幂等标识及时间戳的消息体。依据消息分区键、业务优先级和队列堆积状况选择消息交换类型和目标队列,将消息体投递至消息中间件并获取投递确认。若投递失败则缓存至本地重试队列并执行定时重试,确保消息最终投递成功。实现系统解耦,不同模块通过消息中间件异步通信。
在一些具体的实施例中,业务消息构建与路由基于下述几个方面来实现:
(1)消息内容组装
SDK根据缓存写入结果,构建消息体,包含:订单ID、更新前后状态、操作版本号、幂等标识UUID及时间戳。
例如:
{
"orderId":12345,
"oldStatus":"LOADING",
"newStatus":"LOADED",
"version":42,
"idempotentKey":"uuid-xyz-123"
}
(2)路由决策
路由模块依据消息内容中的分区键、业务优先级以及当前队列堆积状况,选择合适的Exchange类型和目标Queue。业务优先级可以分为核心业务和非核心业务。
系统支持路由规则下发:在高优先级业务爆发时,可临时将部分非关键消息重定向至备用Queue,缓解主通道压力。
(3)消息投递与确认
消息经由RabbitMQ/KafkaSDK,投递至中间件,获取Broker端投递确认。
若消息投递失败,SDK将消息缓存至本地Retry队列,并执行定时重试;重试多次仍失败则进入死信队列,并生成告警。
步骤S105:按照配置的并发度从队列拉取消息,对消息的幂等标识进行去重校验,在校验消息版本高于数据库当前版本后执行数据持久化操作;若操作失败则将消息写入补偿队列并记录错误日志。
在一些实施例中,按照配置的并发度从队列拉取消息,对消息的幂等标识进行去重校验,防止重复处理。在校验消息版本高于数据库当前版本后执行数据持久化操作,确保数据的一致性。若操作失败则将消息写入补偿队列并记录错误日志,便于后续排查和处理。保证数据处理的幂等性,避免重复处理导致的数据不一致。确保数据最终一致性,通过版本校验保证最新数据被持久化。
在一些具体的实施例中,步骤S105的异步消费与数据落地具体方式为:
(1)消费者拉取与并发控制
消费者实例根据配置的并发度从Queue拉取消息。消费前,消费者对消息的idempotentKey进行去重校验,避免同一消息重复处理。
(2)业务处理与持久化
确认消息幂等性后,消费者执行数据版本校验:仅当消息版本高于数据库中当前版本时,才执行状态更新;否则跳过。持久化操作通过数据库事务保障原子性,并更新业务表的状态字段与版本号。
(3)补偿与错误处理
若数据库操作或事务提交失败,消费者将该消息写入补偿队列,并记录错误日志。补偿任务定期扫描补偿队列,依据日志与报警信息,尝试重试或发起人工干预流程。
作为步骤S105来讲还涉及在消息拉取阶段,根据港口作业高峰时段提升消费者实例的并发消费数量,非高峰时段恢复默认值,以匹配业务流量波动;在幂等校验环节,比对消息中的状态变更路径与数据库中记录的前序状态是否一致;在数据持久化前,对消息中的版本号与数据库当前版本号进行差值校验,若差值超过预设阈值,则判定为过时消息并跳过处理;当消息写入补偿队列时,关联该消息对应的缓存键与链路标识,生成包含操作时间、失败次数、数据库锁状态的诊断数据包,供补偿任务在重试时优先获取锁状态信息。
可以看出,在消息拉取阶段,系统会根据预设的港口作业高峰时段调整消费者实例的并发消费数量。通过监控系统获取当前业务流量数据,与历史高峰时段数据比对,在高峰时段增加消费者实例或提高单个实例的并发线程数,加速消息处理;非高峰时段则恢复默认配置,避免资源浪费。
在幂等校验环节,系统不仅校验消息的幂等标识,还会比对消息中携带的状态变更路径与数据库中记录的前序状态。例如,订单状态从"已创建"只能变更为"已支付",若消息中状态变更路径为"已创建->已完成",则判定为非法变更并拒绝处理。在数据持久化前,系统会提取消息中的版本号与数据库当前记录的版本号进行差值校验。若差值超过预设阈值,则认为该消息是过时消息,可能由于网络延迟等原因导致处理顺序滞后,此时系统会跳过该消息处理,避免旧数据覆盖新数据。当消息写入补偿队列时,系统会将该消息对应的缓存键、链路标识进行关联存储,并生成包含操作时间、失败次数、数据库锁状态等信息的诊断数据包。
补偿任务在重试时,可优先获取锁状态信息,判断是否由于数据库锁冲突导致失败,从而采取相应的重试策略,如延迟重试或优先获取锁。
步骤S106:在全链路各模块植入指标采集点,对请求延迟、缓存命中率、消息堆积深度指标进行可视化展示。当关键指标持续超过预设阈值时调整系统资源配置,对指标异常和服务异常进行实时告警并支持通过链路标识进行问题定位。
在一些实施例中,在全链路各模块植入指标采集点,收集请求延迟、缓存命中率、消息堆积深度等指标。对这些指标进行可视化展示,便于运维人员监控系统运行状态。当关键指标持续超过预设阈值时,调整系统资源配置,如增加服务器实例或调整缓存大小。对指标异常和服务异常进行实时告警,并支持通过链路标识进行问题定位,快速排查故障原因。实现系统可观测性,通过指标可视化及时发现系统异常。提高系统弹性,调整资源配置应对流量变化。快速定位和解决问题,链路追踪支持全链路问题排查。
在一些具体的实施例中,步骤S106还可以实现监控预警与弹性治理处理进程。
具体可以基于全链路在网关、SDK、缓存协调模块和消费者端均植入Prometheus埋点,采集:请求延迟、缓存命中率、消息堆积深度、消费者处理速率、失败率等。数据通过可视化平台展示,并支持自定义看板。
当某项关键指标,如消息堆积深度>5000、消费者延迟>200ms、L2写延迟>50ms持续超过预设阈值时,系统调用容器编排平台接口,增加缓存节点或消费者实例。弹性扩缩容行为会写入审计日志,以便追踪容量调整历史。
本实施例针对指标突增或服务异常时,监控系统通过邮件、SMS、钉钉等渠道实时告警。运维人员可在告警详情中查看TraceID,快速定位出问题的具体请求链路,结合链路追踪面板进行诊断与修复。
在本发明的一种实施例中,基于步骤S101,以下将给出一种可能的实施例对其具体的实施方案进行非限制性阐述。
步骤S101具体包括:在接收包含订单标识、目标状态和用户凭证的更新请求时,基于请求来源的业务属性和用户角色,调整鉴权验证策略;在限流处理阶段,实时采集网关数据处理量及接口响应时间,通过规则引擎计算令牌桶算法的令牌生成速率和桶容量;例如,在系统负载较高时降低令牌生成速率以保护后端服务,在负载较低时提高速率以提升吞吐量。
当触发限流时,对核心业务请求进入排队等待队列并分配优先级标记;在生成链路标识时,将请求的业务类型、用户角色及访问路径编码至TraceID的前缀中,形成结构化的标识格式。该标识用于后续日志聚合时的快速分类与异常溯源。在初始化请求上下文时,将TraceID及用户ID、请求来源IP,并透传至后端SDK和监控系统;当链路中某环节发生异常时,TraceID携带异常信息回溯至请求源头。
这样,使系统安全性与灵活性兼备,既能保护核心业务,又能提供差异化服务体验。有效平衡系统稳定性与吞吐量,避免因过载导致服务崩溃。核心业务请求优先排队,确保关键业务不受限流影响,提升用户体验。通过TraceID可快速关联全链路日志,减少故障排查时间。
在本发明的一种实施例中,基于步骤S104,以下将给出一种可能的实施例对其具体的实施方案进行非限制性阐述。
步骤S104具体包括:
在构建消息体时,根据订单标识关联的业务实体类型生成消息路由特征向量,将特征向量与预设的路由规则库进行匹配,调整消息的Exchange类型和目标Queue优先级。
对包含状态变更历史的消息体进行分层压缩:采用字典编码压缩常用字段值,压缩后的消息体通过独立通道投递至消息中间件。
建立消息投递的跨中间件容灾通道,当主消息中间件出现故障时,将消息切换至备用中间件的对应Topic,并根据备用中间件的协议特性调整消息格式;
在本地Retry队列中增加消息老化时间戳字段,对超过预设老化时间仍未成功投递的消息,触发业务补偿逻辑:根据消息中的幂等标识查询数据库,若对应业务操作已完成则标记消息为已处理并丢弃。
需要说明的是,特征向量生成基于业务实体的元数据模型,系统从订单标识解析关联实体类型,提取属性值映射到特征空间。路由规则库使用决策树算法,将特征向量输入后输出匹配的Exchange类型和Queue优先级。分层压缩采用两级处理,第一级字典编码建立常用值与短码的映射表,第二级使用GZIP算法进一步压缩。独立通道通过Netty等框架建立专用连接,实现消息的快速投递。跨中间件容灾基于健康检查机制,系统定期向主中间件发送心跳包,若连续失败超过阈值则触发切换。消息格式转换通过适配器模式实现,针对不同中间件协议提供序列化/反序列化器。老化消息处理通过Redis的SortedSet实现,将消息ID作为成员,老化时间作为分数。定时任务扫描过期成员,调用补偿服务。分层压缩策略有效减少消息体积,独立通道避免网络拥塞,提高消息传输效率。跨中间件容灾通道增强了系统韧性,确保在中间件故障时消息不丢失,提升可用性。同时通过业务补偿逻辑保证数据最终一致性。
进一步的,作为上述港口平台的缓存信息处理方法实施例的一种具体实施方式的细化和扩展,方法还基于步骤S101传递的拓扑路由标签及业务类型,其中,核心业务数据采用跨区域多活分片,同步写入主备区域节点;普通业务采用本地域一致性哈希分片,在步骤S106监测到目标区域延迟超阈值时,将分片流量切换至低延迟区域。
步骤S103还基于单节点写入失败率超第一预设阈值时,启用同区域备用节点重试;同区域整体失败率超第二预设时,触发跨层联动:向步骤S102发送指令延长本地缓存生存周期;将请求导向步骤S105关联的数据库只读副本,返回静态化数据;并标记失败区域为脆弱区,暂停非核心业务写入。
根据步骤S106植入的节点装置,规避高负载节点分片;对连续失效的数据执行生成加密快照存储至冷备存储池,再强制启用多区域同步写入;并向S101反馈信用扣减信号限制来源请求。
本实施例基于S101传递的拓扑路由标签及业务类型,对核心业务数据采用跨区域多活分片策略,数据同时写入主备区域节点,确保强一致性。
当S106监测到目标区域延迟超阈值时,系统将分片流量切换至低延迟区域,保证服务质量。在S103中,当单节点写入失败率超过第一预设阈值时,系统启用同区域备用节点重试,尝试将请求发送至同区域的其他可用节点。若同区域整体失败率超过第二预设阈值,触发跨层联动机制:向S102发送指令延长本地缓存生存周期,减少对分布式缓存的依赖;将请求导向S105关联的数据库只读副本,返回静态化数据;同时标记失败区域为脆弱区,暂停非核心业务写入,保障核心业务。系统根据S106下发的节点负载信息,规避高负载节点分片,将流量导向低负载节点。对连续失效的数据,生成加密快照存储至冷备存储池,确保数据安全性。同时强制启用多区域同步写入,增强数据可靠性。系统还会向S101反馈信用扣减信号,限制来源请求的访问频率,防止恶意或异常请求进一步影响系统。
进一步的,作为上述港口平台的缓存信息处理方法的一种实施例具体实施方式包括如下步骤:
方法中,基于S106下发的实时消息堆积深度及消费者处理延迟指标,堆积深度超阈值时线性增加并发度,延迟超阈值时启用批量预取模式;为高信用核心业务分配独立消费通道,隔离非核心业务流量冲击。
核心业务状态变更定义校验版本号连续性;非核心业务设定为跳过中间版本;当检测到版本号断层时,查询步骤S103分布式缓存获取最新数据补全版本链。
方法在解析消息中嵌入的拓扑路由标签时,路由至同区域数据库副本;若目标副本不可用,依据定义的区域健康拓扑图切换至最近低延迟副本;处理结果回传至S106,关联全链路标识更新追踪状态。
方法还采集步骤S102本地缓存命中率、步骤S103分布式缓存写入延迟、步骤S104消息投递成功率、步骤S105消费者处理延迟的实时数据,并基于(命中率×20%)+(1/延迟×30%)+(成功率×30%)+(1/延迟×20%)计算业务健康度综合评分。
命中率×20%中的命中率基于步骤S102来获取。(1/延迟×30%)中的延迟基于步骤S103来获取。(成功率×30%)中的命中率基于步骤S104来获取。(1/延迟×20%)中的命中率基于步骤S105来获取。
当评分低于安全阈值时触发全局预警。业务健康度综合评分提供了系统整体运行状态的量化指标,使预警和降级策略更科学。
示例性的讲,比如业务健康度综合评分小于某一分数,可以触发S101限流升级以及S103降级写入。业务健康度综合评分小于更低一个分数,则启动全局熔断。
在一些具体的实施例中,当堆积深度超过预设阈值时,线性增加消费者并发度;当处理延迟超过阈值时,启用批量预取模式,一次拉取多条消息减少网络开销。对于核心业务的状态变更,系统严格校验版本号连续性。
当检测到版本号断层,系统查询S103的分布式缓存获取最新数据,补全版本链后再执行持久化操作。系统解析消息中嵌入的拓扑路由标签,优先将请求路由至同区域的数据库副本。若目标副本不可用,依据预定义的区域健康拓扑图,切换至最近的低延迟副本。处理结果回传至S106,更新全链路追踪状态,实现请求闭环监控。
应理解,上述实施例中各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
如图3所示,本申请还提供一种电子设备,包括显示模块103、存储器102、处理器101及存储在所述存储器上并可在所述处理器101上运行的计算机程序,所述处理器101执行所述程序时实现港口平台的缓存信息处理方法的步骤。
在本发明实施例中,电子设备包括但不限于膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本申请实施例的实现。
本申请实施例中,处理器101可以通过使用特定用途集成电路、可编程逻辑装置、现场可编程门阵列、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施,在一些情况下,这样的实施方式可以在控制器中实施。对于软件实施,诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施,软件代码可以存储在存储器中并且由控制器执行。
显示模块103用于显示由用户输入的信息或提供给用户的信息。显示模块103可包括显示面板,可以采用液晶显示器、有机发光二极管等形式来配置显示面板。
存储器102可用于存储软件程序以及各种数据。存储器102可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
本申请还提供一种存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现所述港口平台的缓存信息处理方法的步骤。
存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
在存储介质中,可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了可读程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质,该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (10)
1.一种港口平台的缓存信息处理方法,其特征在于,方法包括:
S101:接收包含订单标识、目标状态和用户凭证的更新请求,对请求进行鉴权与限流处理,并为通过限流的请求生成链路标识和初始化请求上下文;
S102:解析链路标识和请求体,获取缓存键前缀及数据结构类型,在本地内存缓存中执行写入操作并设置短期生存时间,写入成功后返回响应,同时发布消费回写事件,并标记需要同步至分布式缓存;
S103:基于消费回写事件将缓存键路由至分片节点,在分布式缓存服务中执行写入操作并设置生存时间及多副本同步;
S104:根据缓存写入结果构建包含订单标识、状态变更、版本号、幂等标识及时间戳的消息体,依据消息分区键、业务优先级和队列堆积状况选择消息交换类型和目标队列,将消息体投递至消息中间件并获取投递确认;
S105:按照配置的并发度从队列拉取消息,对消息的幂等标识进行去重校验,在校验消息版本高于数据库当前版本后执行数据持久化操作;
S106:在全链路各模块植入指标采集点,对请求延迟、缓存命中率、消息堆积深度指标进行可视化展示。
2.根据权利要求1所述的港口平台的缓存信息处理方法,其特征在于,步骤S101具体包括:
在接收包含订单标识、目标状态和用户凭证的更新请求时,基于请求来源的业务属性和用户角色,调整鉴权验证策略;
在限流处理阶段,实时采集网关运行状态,通过规则引擎计算令牌桶算法的令牌生成速率和桶容量;
当触发限流时,对核心业务请求进入排队等待队列并分配优先级标记;
在生成链路标识时,将请求的业务类型、用户角色及访问路径编码至TraceID的前缀中,形成结构化的标识格式;
在初始化请求上下文时,将TraceID及关键元数据透传至后端SDK和监控系统;当链路中某环节发生异常时,TraceID携带异常信息回溯至请求源头。
3.根据权利要求1所述的港口平台的缓存信息处理方法,其特征在于,步骤S102具体包括:
基于实时业务负载调整缓存键的短期生存时间;
根据缓存键的前缀及数据结构类型,结合分布式缓存节点的负载状态,预判缓存键在分布式缓存中的目标分片节点,并在本地缓存中标记目标分片信息;
为本地缓存中的每个缓存键生成缓存映射表,记录其在本地缓存和分布式缓存中的存储位置及版本号;
根据缓存键的业务重要性或数据更新频率,为消费回写事件分配优先级标签;
步骤S102还基于当前缓存键的访问频率及历史趋势,预测未来可能成为热点的缓存键,并提前在分布式缓存中预留存储空间;
对预测的热点数据,将相关缓存键全量加载至分布式缓存节点,并通过流量镜像技术验证加载效果。
4.根据权利要求1所述的港口平台的缓存信息处理方法,其特征在于,步骤S103具体包括:
在路由缓存键至分片节点时,基于分布式缓存节点的当前负载状态,调整缓存键的路由规则,并在写入多副本时,为每个副本分配独立的版本号,在写入完成后通过分布式事务框架验证副本间版本一致性;
基于历史访问日志及当前访问频率,预测未来一段时间内成为热点的缓存键集合。
5.根据权利要求1所述的港口平台的缓存信息处理方法,其特征在于,方法还基于步骤S101传递的拓扑路由标签及业务类型,其中,核心业务数据采用跨区域多活分片,同步写入主备区域节点;普通业务采用本地域一致性哈希分片,在步骤S106监测到目标区域延迟超阈值时,将分片流量切换至低延迟区域;
步骤S103还基于单节点写入失败率超第一预设阈值时,启用同区域备用节点重试;同区域整体失败率超第二预设时,触发跨层联动:向步骤S102发送指令延长本地缓存生存周期;将请求导向步骤S105关联的数据库只读副本,返回静态化数据;并标记失败区域为脆弱区,暂停非核心业务写入;
根据步骤S106植入的节点装置,规避高负载节点分片;对连续失效的数据执行生成加密快照存储至冷备存储池,再强制启用多区域同步写入;并向S101反馈信用扣减信号限制来源请求。
6.根据权利要求1所述的港口平台的缓存信息处理方法,其特征在于,步骤S104具体包括:
在构建消息体时,根据订单标识关联的业务实体类型生成消息路由特征向量,将特征向量与预设的路由规则库进行匹配,调整消息的Exchange类型和目标Queue优先级;
对包含状态变更历史的消息体进行分层压缩:采用字典编码压缩常用字段值,压缩后的消息体通过独立通道投递至消息中间件;
建立消息投递的跨中间件容灾通道,当主消息中间件出现故障时,将消息切换至备用中间件的对应Topic,并根据备用中间件的协议特性调整消息格式;
在本地Retry队列中增加消息老化时间戳字段,对超过预设老化时间仍未成功投递的消息,触发业务补偿逻辑:根据消息中的幂等标识查询数据库,若对应业务操作已完成则标记消息为已处理并丢弃。
7.根据权利要求1所述的港口平台的缓存信息处理方法,其特征在于,步骤S105具体包括:
在消息拉取阶段,根据港口作业高峰时段提升消费者实例的并发消费数量,非高峰时段恢复默认值,以匹配业务流量波动;
在幂等校验环节,比对消息中的状态变更路径与数据库中记录的前序状态是否一致;
在数据持久化前,对消息中的版本号与数据库当前版本号进行差值校验,若差值超过预设阈值,则判定为过时消息并跳过处理;
当消息写入补偿队列时,关联该消息对应的缓存键与链路标识,生成包含操作时间、失败次数、数据库锁状态的诊断数据包,供补偿任务在重试时优先获取锁状态信息。
8.根据权利要求1所述的港口平台的缓存信息处理方法,其特征在于,方法中,基于S106下发的实时消息堆积深度及消费者处理延迟指标,堆积深度超阈值时线性增加并发度,延迟超阈值时启用批量预取模式;为高信用核心业务分配独立消费通道,隔离非核心业务流量冲击;
核心业务状态变更定义校验版本号连续性;非核心业务设定为跳过中间版本;当检测到版本号断层时,查询步骤S103分布式缓存获取最新数据补全版本链;
方法在解析消息中嵌入的拓扑路由标签时,路由至同区域数据库副本;若目标副本不可用,依据定义的区域健康拓扑图切换至最近低延迟副本;处理结果回传至S106,关联全链路标识更新追踪状态;
方法还采集步骤S102本地缓存命中率、步骤S103分布式缓存写入延迟、步骤S104消息投递成功率、步骤S105消费者处理延迟的实时数据,并基于(命中率×20%)+(1/延迟×30%)+(成功率×30%)+(1/延迟×20%)计算业务健康度综合评分;当评分低于安全阈值时触发全局预警。
9.一种电子设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时实现如权利要求1至8任一项所述港口平台的缓存信息处理方法的步骤。
10.一种存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1至8任一项所述港口平台的缓存信息处理方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202510779361.9A CN120301945B (zh) | 2025-06-12 | 2025-06-12 | 一种港口平台的缓存信息处理方法、设备及介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202510779361.9A CN120301945B (zh) | 2025-06-12 | 2025-06-12 | 一种港口平台的缓存信息处理方法、设备及介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN120301945A true CN120301945A (zh) | 2025-07-11 |
| CN120301945B CN120301945B (zh) | 2025-09-26 |
Family
ID=96283456
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202510779361.9A Active CN120301945B (zh) | 2025-06-12 | 2025-06-12 | 一种港口平台的缓存信息处理方法、设备及介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN120301945B (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN120583104A (zh) * | 2025-08-01 | 2025-09-02 | 广东省城乡规划设计研究院科技集团股份有限公司 | 高鲁棒性的数据实时同步方法、系统、存储介质及电子设备 |
| CN120687442A (zh) * | 2025-08-25 | 2025-09-23 | 天津南大通用数据技术股份有限公司 | 数据库限流方法、装置、设备、介质 |
| CN120803623A (zh) * | 2025-09-12 | 2025-10-17 | 奇秦科技(北京)股份有限公司 | 一种基于Flink的智能数据流处理系统及其实现方法 |
| CN121255499A (zh) * | 2025-12-03 | 2026-01-02 | 北京布洛克快链科技有限公司 | 基于mq消息触发的数据解耦集中式查询方法及系统 |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2032067A1 (en) * | 1989-12-22 | 1991-06-23 | Douglas E. Jewett | Fault-tolerant computer system with online reintegration and shutdown/restart |
| CN102098344A (zh) * | 2011-02-21 | 2011-06-15 | 中国科学院计算技术研究所 | 一种缓存管理中同步版本方法和装置及其缓存管理系统 |
| CN113781133A (zh) * | 2020-06-22 | 2021-12-10 | 北京沃东天骏信息技术有限公司 | 一种订单数据处理方法和装置 |
| CN116405436A (zh) * | 2023-03-01 | 2023-07-07 | 江苏开放大学(江苏城市职业学院) | 高并发条件下基于消息队列的流量控制系统及消息队列中间件 |
| CN117278640A (zh) * | 2023-09-05 | 2023-12-22 | 北京长河数智科技有限责任公司 | 一种基于数据归集的api接口调用方法及系统 |
| CN117439952A (zh) * | 2023-11-24 | 2024-01-23 | 携程商旅信息服务(上海)有限公司 | 基于Redis的流量控制方法、系统、设备和介质 |
| US20240256563A1 (en) * | 2023-01-30 | 2024-08-01 | Microsoft Technology Licensing, Llc | Mechanism for backfilling records dropped during transfer from distributed node system |
| WO2024178909A1 (zh) * | 2023-03-02 | 2024-09-06 | 王彪 | 基于saas模式的多业务上下游多协议接入平台及方法 |
| CN120123108A (zh) * | 2025-05-14 | 2025-06-10 | 富盛科技股份有限公司 | kafka存算分离的数据处理方法及装置 |
-
2025
- 2025-06-12 CN CN202510779361.9A patent/CN120301945B/zh active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2032067A1 (en) * | 1989-12-22 | 1991-06-23 | Douglas E. Jewett | Fault-tolerant computer system with online reintegration and shutdown/restart |
| CN102098344A (zh) * | 2011-02-21 | 2011-06-15 | 中国科学院计算技术研究所 | 一种缓存管理中同步版本方法和装置及其缓存管理系统 |
| CN113781133A (zh) * | 2020-06-22 | 2021-12-10 | 北京沃东天骏信息技术有限公司 | 一种订单数据处理方法和装置 |
| US20240256563A1 (en) * | 2023-01-30 | 2024-08-01 | Microsoft Technology Licensing, Llc | Mechanism for backfilling records dropped during transfer from distributed node system |
| CN116405436A (zh) * | 2023-03-01 | 2023-07-07 | 江苏开放大学(江苏城市职业学院) | 高并发条件下基于消息队列的流量控制系统及消息队列中间件 |
| WO2024178909A1 (zh) * | 2023-03-02 | 2024-09-06 | 王彪 | 基于saas模式的多业务上下游多协议接入平台及方法 |
| CN117278640A (zh) * | 2023-09-05 | 2023-12-22 | 北京长河数智科技有限责任公司 | 一种基于数据归集的api接口调用方法及系统 |
| CN117439952A (zh) * | 2023-11-24 | 2024-01-23 | 携程商旅信息服务(上海)有限公司 | 基于Redis的流量控制方法、系统、设备和介质 |
| CN120123108A (zh) * | 2025-05-14 | 2025-06-10 | 富盛科技股份有限公司 | kafka存算分离的数据处理方法及装置 |
Non-Patent Citations (2)
| Title |
|---|
| DANNY COHEN; MYRICOM; CRAIG LUND; MERCURY COMPUTERS;: "Proposed Specification for the PacketWay Protocol", IETF, 31 October 1996 (1996-10-31) * |
| 王胜;杨超;崔蔚;黄高攀;张明明;: "基于MongoDB的分布式缓存", 计算机系统应用, no. 04, 15 April 2016 (2016-04-15) * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN120583104A (zh) * | 2025-08-01 | 2025-09-02 | 广东省城乡规划设计研究院科技集团股份有限公司 | 高鲁棒性的数据实时同步方法、系统、存储介质及电子设备 |
| CN120687442A (zh) * | 2025-08-25 | 2025-09-23 | 天津南大通用数据技术股份有限公司 | 数据库限流方法、装置、设备、介质 |
| CN120803623A (zh) * | 2025-09-12 | 2025-10-17 | 奇秦科技(北京)股份有限公司 | 一种基于Flink的智能数据流处理系统及其实现方法 |
| CN121255499A (zh) * | 2025-12-03 | 2026-01-02 | 北京布洛克快链科技有限公司 | 基于mq消息触发的数据解耦集中式查询方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN120301945B (zh) | 2025-09-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN120301945B (zh) | 一种港口平台的缓存信息处理方法、设备及介质 | |
| US10048996B1 (en) | Predicting infrastructure failures in a data center for hosted service mitigation actions | |
| KR101570892B1 (ko) | 로컬 호스팅된 캐시 및 암호 해시 함수를 사용하여 네트워크 트래픽을 감소시키는 방법 및 시스템 | |
| KR101315330B1 (ko) | 대용량 데이터베이스와 인터페이스하기 위한 다 계층소프트웨어 시스템에서 캐쉬 콘텐츠의 일관성을 유지하는시스템 및 방법 | |
| JP5631373B2 (ja) | キャッシュ・エントリの一致性検索のための確率テクニック | |
| CN111159233B (zh) | 分布式缓存方法、系统、计算机设备以及存储介质 | |
| CN108683668B (zh) | 内容分发网络中的资源校验方法、装置、存储介质及设备 | |
| CN106789249B (zh) | 热更新方法、客户端及服务器 | |
| EP2156308A1 (en) | Extensible and programmable multi-tenant service architecture | |
| JP6191159B2 (ja) | サーバ、バックアップシステム、バックアップ方法、および、コンピュータ・プログラム | |
| CN111787055A (zh) | 一种基于Redis且面向事务机制和多数据中心的数据分发方法和系统 | |
| US20250175540A1 (en) | Artificial intelligence log processing and content distribution network optimization | |
| CN113505260B (zh) | 人脸识别方法、装置、计算机可读介质及电子设备 | |
| RU2711348C1 (ru) | Способ и система для обработки запросов в распределенной базе данных | |
| CN120448066A (zh) | 边缘云与分布式存储混合计算任务调度方法及系统 | |
| CN116107801B (zh) | 交易处理方法及相关产品 | |
| CN118245544A (zh) | 一种数据处理方法、装置、电子设备及存储介质 | |
| CN115484039A (zh) | 安全防护方法、装置、计算机可读介质及电子设备 | |
| CN104850795B (zh) | 一种密钥管理系统及变更账户信息的方法 | |
| CN120567817B (zh) | 一种基于即时通讯平台的数据管理方法及系统 | |
| CN121391197A (zh) | 基于微服务网关的多源异构业务系统集成方法及平台 | |
| CN116975158B (zh) | 请求处理方法、装置、计算机设备和存储介质 | |
| Huang et al. | A distributed database consistency method for intelligent connected vehicle cloud control platform | |
| WO2026007577A1 (zh) | 基于多级缓存的缓存更新方法、装置、设备以及介质 | |
| CN112084266A (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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |