- 博客(2747)
- 收藏
- 关注
RSS订阅
原创 【置顶】【人工智能】常用的Prompt Engineering 提示词工程最佳实践汇总集合
摘要：本文提供两类实用Prompt模板：(1) 开发工程师常用：通过Java实体类自动生成Mock接口JSON数据示例；(2) 内容创作者专用：包含公众号文章创作标准模板，要求标题新颖、内容深度与通俗性兼顾，并设计互动性结尾。两个模板均采用结构化指令格式，适用于不同场景的自动化内容生成需求。（149字）
2025-06-30 17:11:29
694
原创 【人工智能】AI大模型&智能体领域100个名词术语含义，每一个附详细的讲解链接
现在大模型吸引了越来越多人的关注，好几次在大街上走听见路人谈论大模型。大模型领域有很多专业词汇，比如什么AGI、AIGC、多模态、Token、RAG、COT、SFT、LORA等等，对非这个行业从业者来说，初次见到通常不明所以。最近花了几天时间整理了AI大模型相关领域100多个专业名词及其解释，涵盖基础概念、机器学习&深度学习、NLP、多模态、智能体、框架&工具等多个类别。
2025-03-03 09:44:03
532
原创 【20250604】【项目实战】【亲测可用】使用国内镜像源（如华为云、阿里云、腾讯云等）提供的Docker镜像加速服务，解决Docker被墙的问题
以下是配置使用国内镜像源（如华为云、阿里云、腾讯云等提供的Docker镜像加速服务）的步骤：为了加快Docker镜像的下载速度，可以配置使用国内云服务商提供的Docker镜像加速服务。通过以下步骤，你可以轻松地在自己的系统中配置并使用国内镜像源来加速Docker镜像的下载过程。如果一切配置正确，你应该能够体验到更快的镜像下载速度，并看到成功拉取镜像的消息。这不仅能测试镜像加速是否生效，还能检查Docker的基本功能是否正常工作。为你从阿里云、华为云、腾讯云等获取的具体镜像加速地址。
2025-02-05 10:35:43
1623
7
原创 【20250604】【项目实战】【亲测可用】Get https://registry-1.docker.io/v2/: net/http: request canceled
【异常】Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection。
2024-11-21 12:23:14
17358
1
原创 【2025】docker pull hello-world提示Error response from daemon: Get “https://registry-1.docker.io/v2/“解决
在使用 Docker 时，如果你需要通过 HTTP 或 HTTPS 代理服务器来访问互联网（例如，在企业网络中），你可以为 Docker 配置环境变量以设置代理。对于 Docker 版本 26.1.4 或其他版本，配置代理的方法是相似的。这个文件允许你为 Docker 守护进程指定各种配置选项，包括 HTTP 和 HTTPS 代理设置。查看更详细的错误信息，并确保代理服务器的地址和端口是正确的，并且可以从你的机器访问。你还可以直接在 Docker 的守护进程配置文件中设置代理。并加入类似上面的内容。
2024-11-01 13:20:22
4570
1
原创 【异常】docker-compose up -d提示执行ERROR: Get https://registry-1.docker.io/v2/: net/http: request canceled
命令启动 Milvus 服务时，遇到了网络错误 “read: connection reset by peer”，这通常意味着 Docker 在尝试从 Docker Hub 拉取镜像时连接被重置。这个问题可能是由于多种原因引起的，比如网络不稳定、防火墙或代理设置问题等。如果你在中国大陆，Docker Hub 的访问速度可能会比较慢或者不稳定。你可以考虑更换为国内的镜像加速器，例如阿里云、腾讯云或 DaoCloud 提供的镜像加速服务。使用ctrl+c推出vi，然后输入以下内容保存。
2024-10-21 21:26:31
4403
3
原创 【异常】Found Banned Dependency: commons-logging:commons-logging:jar:1.1.1 Use ‘mvn dependency
通过这些步骤，你可以移除被禁止的commons-logging依赖，同时确保使用logback作为日志组件，从而解决这个Enforcer插件的错误。这个错误提示表明你的Maven项目中使用了被禁止的依赖项。，而项目规则要求必须使用logback作为日志组件。
2025-07-25 00:31:53
13
原创 【异常】com.yomahub:liteflow-spring-boot-starter:jar must be a valid version but is ‘${liteflow.version}
二、报错说明这个错误提示表明在你的Maven项目中存在版本号配置问题：错误信息 说明Maven无法解析 这个变量。解决方法有两种：选择其中一种方法修改pom.xml后，重新执行Maven构建命令即可。2. 直接指定具体的版本号，而不是使用变量：你可以在 Maven中央仓库 查找适合你项目的最新或兼容版本。
2025-07-25 00:31:42
13
原创 【项目实战】接口幂等性 之 定义、核心原则与典型场景
在微服务架构中，接口幂等性指重复请求（同一请求多次发送）不会对系统产生未预期的副作用，即多次执行与一次执行的业务结果一致（允许返回结果不同，如第一次成功、第二次返回“已处理”）。其核心聚焦于状态变更和数据写入操作（读操作天然幂等，无需额外处理），因读操作仅查询数据，重复执行不会改变系统状态。
2025-07-25 00:31:23
12
原创 【项目实战】接口幂等性 之 防重提交（前端控制+后端拦截）
前端控制：通过禁用按钮、跳转页面等方式减少用户误操作，提升体验，但无法完全防重（可被绕过）；后端拦截：通过Token、唯一ID、锁机制等确保数据唯一性，是防重提交的核心保障；最佳实践：前端控制+后端拦截结合，既提升用户体验，又保证系统数据安全。
2025-07-25 00:30:41
9
原创 【项目实战】接口幂等性 之 幂等Token令牌机制（Token+Redis唯一标识法）
在分布式系统中，接口的幂等性是保障系统可靠性的关键（幂等性指多次执行同一操作，结果与一次执行一致）。是最常用的幂等性保障方案之一，通过“唯一请求令牌”确保同一请求仅被处理一次。基于Token+Redis的唯一标识法，通过“唯一Token+Redis原子操作”实现了高效的幂等性保障，平衡了通用性、可靠性和实现复杂度，是分布式系统中解决重复请求问题的首选方案之一。核心是抓住“Token唯一性”“Redis原子校验”“一次有效”三个关键点，同时合理处理过期时间和高可用问题。
2025-07-25 00:30:28
12
原创 【项目实战】接口幂等性 之 HTTP幂等性与API设计：从概念到实践
多次执行相同的请求，对服务器资源产生的副作用与一次执行的副作用完全相同。这里的“副作用”指对服务器资源的修改（如创建、更新、删除）；只读操作（如查询）无副作用，天然满足幂等性；注意：幂等性不要求“返回结果完全相同”（可能因其他请求修改资源导致结果变化），只要求“副作用相同”。
2025-07-25 00:30:15
8
原创 【项目实战】并发编程 之 悲观锁：强一致性场景下的并发控制方案
在并发编程中，数据一致性是核心挑战之一。悲观锁作为应对并发冲突的经典机制，其设计理念源于“悲观假设”——，因此在操作数据前主动加锁，阻止其他请求对数据的同时修改，从而确保数据强一致性。悲观锁是“以性能换一致性”的方案，通过提前加锁阻止并发冲突，适合强一致性要求极高（如资金交易）、并发量较低的场景。使用时需关注锁粒度、事务范围和死锁风险，平衡一致性与性能。与乐观锁（通过版本号实现，冲突后重试）相比，悲观锁无需处理重试逻辑，但并发性能更差，需根据业务场景选择。
2025-07-25 00:29:55
8
原创 【项目实战】CAS（Compare and Swap，比较并交换）是一种乐观锁机制，它通过比较数据的当前值与预期的旧值，只有当两者相等时才执行更新操作，从而实现并发控制。
CAS（Compare and Swap，比较并交换）是一种乐观锁机制，它通过比较数据的当前值与预期的旧值，只有当两者相等时才执行更新操作，从而实现并发控制。
2025-07-25 00:29:40
9
原创 【项目实战】接口幂等性 之 全局唯一请求ID生成方案：原理、实现与实践
在分布式系统中，因网络延迟、客户端重试、服务端超时等问题，重复请求是常见场景。若重复请求触发重复业务逻辑（如重复支付、重复创建订单），可能导致数据不一致。通过为每个请求生成唯一标识，结合存储校验机制，实现“重复请求只处理一次”，是保障系统幂等性的核心方案之一。全局唯一请求ID方案通过“唯一标识+存在性校验+超时机制”，解决了分布式系统中重复请求的问题，是保障数据一致性的基础方案。
2025-07-25 00:29:23
8
原创 【项目实战】接口幂等性 之 分布式系统中异常处理、重试、监控与补偿机制的协同设计
在分布式系统中，网络抖动、服务宕机、资源竞争等问题不可避免，需通过的协同设计，保障系统稳定性与数据一致性。以下从核心机制、协同逻辑及实践示例展开说明。
2025-07-25 00:29:06
12
原创 【项目实战】接口幂等性 之 业务流转控制：状态机设计与乐观锁机制详解
摘要： 状态机设计与乐观锁是解决业务系统幂等性与并发控制的核心方案。状态机通过定义业务状态流转规则（如订单状态迁移），天然保证幂等性，适用于强顺序性场景（如支付流程）；乐观锁通过版本号校验实现无锁并发控制，适合读多写少场景（如库存扣减）。两者结合可兼顾业务规则严谨性与更新原子性。状态机优势在于语义清晰，但实现复杂；乐观锁性能更高，但需处理冲突重试。技术选型需根据业务特性（如状态明确性、并发量）权衡，复杂场景推荐组合使用。
2025-07-25 00:28:44
10
原创 【项目实战】接口幂等性 之 数据库唯一机制与防重表机制：保证数据唯一性与幂等性的核心方案
维度数据库唯一索引防重表（幂等表）核心逻辑基于业务字段唯一约束，拦截重复插入基于请求ID记录，拦截重复请求适用操作主要适用于创建操作支持创建、更新、删除等全操作与业务耦合度高（依赖业务表字段）低（独立表，与业务解耦）性能损耗低（仅索引开销）高（额外写入防重表）典型场景订单创建、支付记录（有天然唯一标识）复杂业务流程、需返回历史结果的请求。
2025-07-25 00:28:29
8
原创 【项目实战】接口幂等性 之 分布式锁（全局互斥）
分布式锁是一种在分布式系统中实现跨服务、跨节点资源互斥访问的机制，主要用于保证高并发场景下操作的顺序性和一致性，通常作为幂等控制的补充手段（慎用）。分布式锁是分布式系统中解决并发冲突的重要手段，但需注意其实现复杂度和潜在风险，通常需结合业务场景谨慎使用，并配合其他幂等机制确保系统可靠性。
2025-07-25 00:28:15
8
原创 【项目实战】接口幂等性 之 消息队列幂等消费与消息去重详解
在微服务架构中，消息队列（MQ）是解耦服务、异步通信的核心组件。但由于网络波动、重试机制、中间件故障等原因，消息可能被重复投递，导致消费者重复处理，引发数据不一致（如重复下单、重复扣款）。因此，和是MQ场景中必须解决的核心问题。消息队列的幂等消费核心是“识别重复→避免重复处理”，推荐优先使用的方式，结合业务逻辑的幂等性（如状态机、乐观锁），同时配合幂等生产者从源头减少重复消息。需根据业务场景选择存储（Redis/数据库），并做好过期清理，确保系统高效且可靠。
2025-07-25 00:28:01
7
原创 【项目实战】分布式日志系统 之 高性能/实时性与成本优化策略（以日志系统为例）
日志系统的高性能与成本优化是“平衡艺术”：写入侧通过异步、批量、零拷贝提升吞吐；查询侧通过预计算、索引、缓存降低延迟；存储与网络侧通过分层、压缩、生命周期管理控制成本，最终实现“高吞吐不阻塞业务、低延迟满足分析、低成本支撑规模”的目标。
2025-07-24 00:06:16
19
原创 【项目实战】分布式日志系统 之 日志传输与序列化协议全解析
在日志数据的采集、传输和处理过程中，传输协议和序列化协议的选择直接影响效率、可靠性和兼容性。日志传输的核心是“按需匹配”——根据数据量、实时性、兼容性、成本等因素，组合传输协议和序列化协议，实现高效、可靠的日志流转。以下从和。
2025-07-24 00:04:59
17
原创 【项目实战】数据压缩与编码优化：核心策略与实践指南
数据压缩与编码优化通过“算法选型+场景适配”，可有效降低带宽、存储、I/O等核心资源开销。其中，日志等文本类数据的压缩价值尤为突出（5-10倍压缩率），而LZ4、ZSTD等高效算法的应用，进一步实现了“低损耗”与“高收益”的平衡，是系统性能优化的重要手段。
2025-07-24 00:04:03
15
原创 【项目实战】分布式日志系统 之 数据可靠性保障机制详解
日志数据的可靠性是系统稳定运行的核心诉求，核心目标是通过技术手段确保数据。实现高可靠性的基础是采用主从复制或多副本机制，在此基础上，需从采集、传输、存储三个核心环节构建全链路保障体系。日志数据的可靠性保障是“采集-传输-存储”全链路的协同结果：采集端通过本地缓存、非阻塞设计确保数据不丢失且不影响业务；传输端通过队列缓冲、重试机制应对网络和节点故障；存储端通过分级存储、备份、分布式架构实现数据长期可用与成本平衡。结合主从复制、多副本等基础机制，可构建高可靠的日志数据系统。
2025-07-24 00:03:48
10
原创 【项目实战】分布式日志系统 之 Exactly-once 语义：确保数据处理的精确性
在分布式系统的数据传输与处理中，是一种核心可靠性保障，其目标是确保数据“仅被处理一次”——既不重复（避免多次处理），也不遗漏（避免未处理）。与，二者共同保障数据处理的精确性。Exactly-once 语义是分布式系统中数据可靠性的高级目标，其核心通过“幂等设计”（解决重复问题）和“分布式事务”（解决原子性问题）实现。在实际应用中，常结合 At-Least-Once 语义与幂等性，或通过事务 API 与唯一 ID 去重的组合，平衡可靠性与系统性能。
2025-07-24 00:03:38
10
原创 【项目实战】分布式日志系统 之 一致性：强一致与最终一致如何选
在分布式系统中，一致性模型是保障数据可靠性与可用性的核心设计原则，其中与是两大核心方向，实际应用中需结合业务需求进行权衡。一致性模型的选择无绝对优劣，需结合业务场景，通过协议（如Raft/Paxos）、策略（如Quorum Write、分片复制）平衡数据可靠性与系统性能。
2025-07-24 00:03:26
11
原创 【项目实战】分布式日志系统 之 顺序性保障：从局部有序到全局排序
在分布式系统中，日志的顺序性保障是实现时序可追溯、数据一致性的核心需求。尤其是在多节点、高并发场景下，如何确保“谁先发生、谁后发生”的时序关系，需要结合与共同实现。两者结合，可在高并发、分布式场景下，为日志的时序追溯、问题排查、数据一致性验证提供坚实支撑。
2025-07-24 00:03:12
10
原创 【项目实战】分布式日志系统 之 数据一致性保障机制
在分布式系统中（如微服务、多节点存储集群），数据一致性指多节点间数据的"准确性"和"协调性"——避免出现数据重复、丢失、顺序错乱或状态冲突。由于网络延迟、节点故障等问题，分布式一致性需通过专门的机制设计实现，核心目标是在"可用性"和"一致性"之间找到符合业务需求的平衡点。
2025-07-24 00:03:01
7
原创 【项目实战】分布式日志系统 之 高可用性（High Availability）核心体系详解
从架构层面消除单点故障，通过集群化部署确保无核心依赖；通过多副本与分片实现数据与服务冗余，容忍部分节点失效；建立“检测-转移-隔离-恢复”的全流程容错机制，快速应对故障；跨地域部署与数据复制，抵御地域级灾难，最终实现“系统持续服务、数据零丢失”的目标。
2025-07-24 00:02:48
27
原创 【项目实战】分布式日志系统 之 无单点故障（SPOF Elimination）架构详解
组件类型示例工具部署要求核心目标采集组件多Agent/多实例集群避免数据采集中断消息队列（传输）分布式集群（多Broker+多副本）保障数据传输连续性存储节点多节点集群（分片+副本）避免数据丢失或无法访问协调服务3+节点高可用集群避免协调服务自身成为单点查询服务Elasticsearch查询节点多实例集群+负载均衡保障查询请求正常响应负载均衡器高可用部署（如双机热备）避免流量入口单点故障。
2025-07-24 00:02:34
11
原创 【项目实战】冗余设计与副本机制是分布式系统实现高可用性、容错性和性能扩展的核心技术。
冗余设计与副本机制是分布式系统实现高可用性、容错性和性能扩展的核心技术。冗余设计与副本机制是分布式系统的基石，其核心目标是在可用性、性能和成本之间找到平衡。Kafka和Elasticsearch通过动态副本管理、故障域隔离和参数调优，为不同场景提供了可靠的解决方案。实际应用中，需结合业务需求（如金融场景的强一致性、日志分析的高吞吐量）选择合适的复制策略，并通过持续监控和容灾演练确保系统稳定性。
2025-07-24 00:02:20
11
原创 【项目实战】分布式日志系统架构演进：从单体到平台化的核心路径
业务规模：从单体到分布式，日志量从MB→TB级，驱动“集中化”。运维效率：从手动跨机查询到一键检索，驱动“平台化”。性能要求：从无感知到“零影响业务”，驱动“异步化”“解耦化”。功能需求：从简单存储到监控分析，驱动“工具链集成”。未来，日志架构将向“智能化”演进，结合AI实现日志异常检测（如通过机器学习识别异常日志模式）、自动根因分析，进一步降低运维成本。
2025-07-24 00:02:05
14
原创 【项目实战】分布式日志系统：设计核心与高可用实战
高可用分布式日志系统的核心目标（可靠采集、安全传输、持久存储、高效查询、故障自愈）是“结果导向”的需求落地，而高可用性、可扩展性、安全性等要素是“过程保障”的支撑条件。高可用性是故障自愈的基础（无高可用设计，故障后无法自动恢复）；可扩展性是应对数据增长的前提（无水平扩展能力，数据量激增会击穿存储与查询链路）；数据高可靠性是可靠采集、持久存储的核心（丢数据会直接导致日志失去价值）。
2025-07-24 00:01:50
7
原创 【项目实战】分区/分片（Partitioning/Sharding）是分布式系统中实现水平扩展的核心技术，通过将数据拆分并分散到多个节点，解决单节点的性能和容量瓶颈，提升系统的并行处理能力和容错性。
分区与分片是分布式系统实现水平扩展的关键技术，通过数据拆分提升并行处理能力和容错性。分区（如Kafka）将数据分散到多个节点实现高吞吐和容错，支持动态调整但需平衡性能。分片采用哈希、范围等策略分散数据，通过负载均衡和动态扩容（如Elasticsearch、MongoDB）解决单节点瓶颈，推荐单分片容量控制在30-50GB。两者均需根据业务场景选择合适策略，并配合监控机制确保系统高效稳定。
2025-07-24 00:01:31
10
原创 【项目实战】分布式日志系统 之 可扩展性（Scalability）核心体系详解
可扩展性（Scalability）是日志系统应对数据量增长的核心能力，核心目标是实现“按需扩容”——当日志量从GB级、TB级飙升至PB级甚至EB级时，系统能通过平滑扩展满足容量与性能需求。日志系统的可扩展性设计需以“无状态化”为基础，通过“水平扩展+分区/分片”实现容量与性能的线性提升，结合“弹性伸缩”实现资源按需分配，最终通过“协议兼容”保障扩展的平滑性。核心目标是：支持从TB级到PB级、EB级数据的存储与处理，并能在业务增长时“无缝扩容”。
2025-07-24 00:01:06
11
原创 【项目实战】混合存储（分级存储）：冷热数据分离与分层策略详解
在数据量爆炸的当下，单一存储介质难以平衡“高性能访问”与“低成本存储”的需求。混合存储（分级存储）通过**冷热数据分离**，基于数据的访问频率、生命周期和业务价值，将数据分配到不同性能、不同成本的存储介质中，实现“热数据高效访问、冷数据低成本留存”的目标。混合存储的冷热数据分离，本质是“让合适的数据待在合适的地方”：热数据靠高性能介质保障业务效率，冷/归档数据靠低成本存储控制成本，通过生命周期管理实现动态平衡，最终在性能、成本与合规性之间找到最优解。
2025-07-23 23:50:39
13
原创 【项目实战】智能告警机制：保障系统稳定运行的关键防线
智能告警机制是保障系统稳定运行的重要工具。它通过多级阈值设置（预警/告警/紧急阈值）、多维度告警（异常检测、趋势分析）和自定义告警脚本实现精准监控。告警信息可通过短信、邮件、企业微信等多渠道推送，并基于严重程度（P0-P3）进行分级处理。采用Prometheus+Alertmanager架构的告警系统能有效提升运维效率，及时发现和预警系统问题，确保业务连续性。企业应根据实际需求合理配置告警机制，充分发挥其在系统运维中的保障作用。
2025-07-23 23:49:42
21
原创 【项目实战】全链路监控体系构建指南
全链路监控是保障系统稳定性的核心手段，需结合业务场景动态调整指标阈值与监控粒度，实现“可观测、可预警、可定位”的目标。
2025-07-23 23:48:36
18
原创 【项目实战】分布式日志系统 之 日志采集（Log Collection/Ingestion）：系统日志链路的“入口防线”
日志采集层作为系统入口，需满足以下核心要求：日志采集的核心载体是轻量级采集代理（Agent），其作用是部署在日志产生节点（如服务器、容器、虚拟机），本地读取日志并转发至中心化收集器（如Kafka、日志服务器）。核心特性：为适配不同数据源的特性，日志采集需支持自定义采集规则，常见方式包括：日志采集需支持多样化的数据源，确保无死角覆盖，具体包括：应用程序日志基础设施日志异构环境日志采集代理的部署需与环境架构匹配，常见方式包括：不同场景下需选择适配的采集工具，以下是主流技术栈的特点及适用场景：在Kubernete
2025-07-23 23:47:37
12
GifCam 是一款专注于屏幕录制并生成 GIF 动画的免费工具，GifCam 凭借其轻便、高效的特点，成为动态图制作的实用工具，尤其适合对文件体积和操作便捷性有较高需求的用户
2025-05-06
MQTTBox 是一款功能强大的跨平台 MQTT 客户端工具，主要用于测试和调试 MQTT 协议通信
2025-05-06
Hiddify-Next，一款强大的资源隐藏与保护工具，解决你常见的烦恼
2025-04-21
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人