Palette

发表于2025-11-18|AI|AI

FastGPT 是一个基于 LLM 大语言模型的知识库问答系统，提供开箱即用的数据处理、模型调用等能力。同时可以通过 Flow 可视化进行工作流编排，从而实现复杂的问答场景！官方文档如下所示： https://doc.tryfastgpt.ai/docs/intro/ FastGPT的能力如下： 1. 专属 AI 客服（很多公司目前都在用）通过导入文档或已有问答对进行训练，让 AI 模型能根据你的文档以交互式对话方式回答问题。 2. 简单易用的可视化界面 FastGPT 采用直观的可视化界面设计，为各种应用场景提供了丰富实用的功能。通过简洁易懂的操作步骤，可以轻松完成 AI 客服的创建和训练流程。 3. 自动数据预处理提供手动输入、直接分段、LLM。自动处理和 CSV 等多种数据导入途径，其中“直接分段”支持通过 PDF、WORD、Markdown 和 CSV 文档内容作为上下文。FastGPT 会自动对文本数据进行预处理、向量化和 QA 分割，节省手动训练时间，提升效能。 4. 工作流编排基于 Flow 模块的工作流编排，可以帮助你设计更加复杂的问答流程。例如查询数据 ...

玩转AI应用1：AI实现代码评审

发表于2025-11-01|AI|AI

介绍 AI 实现自动 code review 的技术方案

一步一步手写分布式锁

发表于2025-10-28|场景|Redis•Redisson

背景记一次惨痛的教训：一次节日临近，产品经理兴致勃勃地组织团队研发抢红包活动。小目标定下来之后，研发团队加班赶进度，终于软件成功上线。不幸的是，后来发现有人疯狂刷接口，一笔红包提现N次，累计被盗走好几万资金。参与研发的同事被老板叫到办公室骂了个狗血喷头，还被罚了款。故事结尾，CTO让我来解决这个并发安全问题。故事从这里开始… 什么是分布式锁？线程锁和进程锁仅能满足在单机jvm或者同一个操作系统下，才能有效，跨jvm无法满足。因此就产生了分布式锁，其目的可以概括为：控制多个分布式节点的线程对同一项资源的互斥访问。一个完善的分布式锁需要实现哪些目标？分布式环境下的互斥功能锁在事务的外围防止死锁的发生锁等待锁重入锁续约使用方便手写分布式锁——基础版该版本的加锁和业务逻辑代码混在一起，按照加锁->业务逻辑->解锁的顺序执行。基于lua脚本和setnx命令实现，保证加锁过程的原子性。核心代码： 123456lock(key, value, seconds);try { //do business} finally { ...

缓存最终一致性与强一致性实战

发表于2025-10-21|场景|缓存•场景

最终一致性分布式缓存场景场景描述经过几年演进，携程金融形成了自顶向下的多层次系统架构，如业务层、平台层、基础服务层等，其中用户信息、产品信息、订单信息等基础数据由基础平台等底层系统产生，服务于所有的金融系统，对这部分基础数据我们引入了统一的缓存服务（系统名utag），缓存数据有三大特点：全量、准实时、永久有效，在数据实时性要求不高的场景下，业务系统可直接调用统一的缓存查询接口。我们的典型使用场景有：风控流程、APP入口信息提示等，而对数据一致性要求高的场景依然需要走实时的业务接口查询。引入缓存前后系统架构对比如下：统一缓存服务的构建给部门的整体系统架构带来了一些优势：对业务系统：响应速度提升：相比直接调用底层高流量的基础服务，调用缓存服务接口的系统响应时间大大减少（缓存查询接口P98为10毫秒）。统一接口，降低接入成本：一部分业务场景下可以直接调用统一缓存服务查询接口，而不用再对接底层的多个子系统，极大地降低了各个业务线的接入成本。统一缓存，省去各个服务单独维护缓存的成本。对基础服务：服务压力降低：基础平台的系统本身就属于高流量系统，可减少一大部分的查询流量，降 ...

RocketMQ消息模型提升AI通信效率

发表于2025-10-17|RocketMQ|AI•RocketMQ

Apache RocketMQ 顺应AIGC浪潮，针对长时会话、稀缺算力调度及AI Agent协作等挑战，推出专为AI时代打造的消息引擎。

APISIX的使用

发表于2025-10-17|安全|APISIX

APISIX的主要概念Apache APISIX是一个动态、实时、高性能的API网关，提供丰富的流量管理特性，例如负载均衡、动态路由、灰度发布、服务熔断、身份认证等。支持多种环境部署，并提供大量插件实现不同业务场景需求，且支持编写自定义插件，提供dashboard供用户通过页面管理apisix。 APISIX网关的数据面和控制面分离，和传统网关相比，它具有负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能，并且它的动态路由和插件热加载非常适合管理微服务; APISIX有完整的生态系统，能支持多种协议（http,tcp,udp,mqtt,grpc，…），丰富的插件（身份认证，安全，流控，监控，日志,…); 1.我们为何选择它？1).开源社区活跃，国内参与度高;2).高可用集群，功能强大，成熟的生态圈;3).丰富的插件，支持热加载，可随时插拔，修改;4).最主要的是我司的业务场景90%以上都能满足; 我们是如何部署的? 1.外置etcd集群存储apisix元数据，保证数据不丢失和高可用;2.通过k8s-configmap管理dashboard+apisi ...

MAT案例整理

发表于2025-09-24|JVM|JVM•MAT

开启Dump文件自动转储一般来说，线上运行的系统都会加上下面的 JVM 参数，以便如果线上出现 OOM 问题的时候，自动将事故现场保留下来。 12# 当程序出现OutofMemory时，将会在相应的目录下生成一份dump文件，如果不指定选项HeapDumpPath则在当前目录下生成dump文件-XX:+HeapDumpOnOutOfMemoryError -XX:ErrorFile=/logs/oom_dump/xxx.log -XX:HeapDumpPath=/logs/oom_dump/xxx.hprof 但是有某种情况下，pod会被k8s的某种保护机制下自动kill掉，那么dump文件没办法保存下来。此时也可以联系运维给这个服务加上EFS （Amazon 文件系统）等待下次出现能抓住这个问题。 EFS 是 Amazon 提供的完全托管的弹性网络文件系统，主要用于在 AWS 上运行的多台 EC2 实例之间共享存储。它可以实现多个容器等实例同时挂载同一个 EFS 文件系统。如果程序出现 OOM 之后，就是有代码存在内存泄漏的风险，这个时候即使能对外提供服务，其实也是有风险的， ...

发表于2025-09-22|AI|AI

发表于2025-09-12|场景|场景

发表于2025-09-08|JUC|JUC

可见性、原子性和有序性问题：并发编程Bug的源头可见性在单核时代，所有的线程都是在一颗CPU上执行，CPU缓存与内存的数据一致性容易解决。一个线程对共享变量的修改，另外一个线程能够立刻看到，我们称为可见性。多核时代，每颗CPU都有自己的缓存，这时CPU缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的CPU上执行时，这些线程操作的是不同的CPU缓存。每执行一次add10K()方法，都会循环10000次count+=1操作。在calc()方法中我们创建了两个线程，每个线程调用一次add10K()方法，循环10000次count+=1操作如果改为循环1亿次，你会发现效果更明显，最终count的值接近1亿，而不是2亿。如果循环10000次，count的值接近20000，原因是两个线程不是同时启动的，有一个时差。原子性操作系统允许某个进程执行一小段时间，例如50毫秒，过了50毫秒操作系统就会重新选择一个进程来执行（我们称为“任务切换”），这个50毫秒称为“时间片”。在一个时间片内，如果一个进程进行一个IO操作，例如读个文件，这个时候该进程可以把自 ...

uhr考勤

发表于2025-07-14|场景|业务

1自动生成年假1.1基本业务场景假期类型为定额类且规则是自动生成的需要定时任务自动生成假期，根据基准值和生成条件来确定年假生成的额度。基准值：福利工龄日期、社会工龄日期!!#ff0000 生成条件!!：福利工龄日期满N个月、社会工龄日期满N个月是否预支年假：是、否。即是生成已工作年份年假和未来为工作时间的年假（预支，员工刚入职生成今年一年的年假）基准值单位：月、自然年例如：基准值以月为单位：基准值单位选择为“月”，非预支类型年假，若起始日期为2022年10月1日，则2023年10月1日基准值满12个月示例：若年假计算规则：以“福利工龄”为基准值+“福利工龄”为基础条件+“自然年”为计算周期+取整方式为“向下取整”+额度单位为“天”+基准值单位为“月”：小王于2015年7月12日首次参加工作，于2022年2月10日加入公司，公司规定：福利工龄满12个月（2023年2月10日）后给予年假，年假阶梯是福利工龄12个月60个月给予5天，60个月120个月给予7天。小王于2022年5月10日，入职满12个月，此时生成年假。计算规则为：（20221231-20220211）/ ...

kubernetes

发表于2025-07-09|k8s|k8s

基本概念虽然容器技术开启了云原生时代，但它也只走出了一小步，再继续前进就无能为力了，因为这已经不再是隔离一两个进程的普通问题，而是要隔离数不清的进程，还有它们之间互相通信、互相协作的超级问题，困难程度可以说是指数级别的上升。这些容器之上的管理、调度工作，就是这些年最流行的词汇：“容器编排”（Container Orchestration）。面对单机上的几个容器，“人肉”编排调度还可以应付，但如果规模上到几百台服务器、成千上万的容器，处理它们之间的复杂联系就必须要依靠计算机了，而目前计算机用来调度管理的“事实标准”，就是：Kubernetes。 Kubernetes就是一个生产级别的容器编排平台和集群管理系统，不仅能够创建、调度容器，还能够监控、管理服务器。基本架构 Kubernetes采用了现今流行的“控制面/数据面”（Control Plane / Data Plane）架构，集群里的计算机被称为“节点”（Node），可以是实机也可以是虚机，少量的节点用作控制面来执行集群的管理维护工作，其他的大部分节点都被划归数据面，用来跑业务应用。控制面的节点在Kube ...