CYK's Blog

Cursor一、下载安装下载和安装好像是很傻瓜的，在官网下载了直接安装包点点就ok了，然后在官网注册一下账号并且登录到应用就可以了 官网地址：https://cursor.com/cn 二、配置看起来就是类似vscode的应用，甚至还有一键从vscode导入设置的选项，但是本地电脑没咋用vscode写前端所以没啥可以迁移的 像vscode一样在插件市场安装了一个中文插件将软件汉化，名字是Chinese (Simplified) (简体中文) Language Pack for Visual Studio Code 然后有一个是要配置一下java的开发环境 设置我的JAVA_HOME和MAVEN_HOME，在setting.json中添加了如下内容吗，然后好像是重启就可以辽 { "java.home": "F:/java/jdk/jdk-11.0.23", "java.configuration.maven.userSettings": "F:/maven/apache-maven-3.9.6/ ...

Linux持续写入的日志如何清理如果一个日志正在持续写入，但是它的内容太多了，占用了很大的内存，这时候如果想要清理的话，直接删除是不行的，因为一旦删除这个文件就不存在了，应用 会因为找不到日志文件而报错。 那么可以通过以下方式清空文件内容： > application.log或者cat /dev/null > file_name或者echo "">file_name

RAG是什么RAG 的全称是：Retrieval-Augmented Generation，翻译成中文是：检索增强生成。 说人话就是——让大语言模型（比如 ChatGPT）在生成答案之前，先去找资料（检索）来增强它的知识，再用这些资料来生成更准确的回答。 如何构建一个RAG 前置准备 首先我们需要做数据准备，把你要用的资料收集好，比如：公司内部文档（PDF、Word、Markdown）、FAQ 列表、产品手册等，然后清洗这些数据，比如 去掉无关信息、切分成合理的小段。 然后把每一小段文本用 Embedding 模型转成向量，把这些向量存到向量数据库里，比如 FAISS、Milvus 等。 检索查询 当用户提问时，先用相同的 Embedding 模型把问题也转成向量。然后在向量数据库里用向量相似度搜索，找出最相关的几段资料（比如 Top 5）。这些找到 的内容就是上下文增强材料。 生成回答 紧接着，就可以把用户的问题 + 检索到的资料一起，作为 Prompt 发给大语言模型（LLM）。 这样可以保证模型只在资料范围内生成答案，降低幻觉。

RocketMQ的消息想要确保不丢失，需要生产者、消费者以及Broker的共同努力，缺一不可。 首先在生产者端，消息的发送分为同步、异步两种和单向发送（单向发送不保证成功，不建议使用），在同步发送消息的情况下，消息的发送会同步阻塞等待 Broker 返回结果，在 Broker 确认收到消息之后，生产者才会拿到 SendResult。如果这个过程中发生异常，那么就说明消息发送可能失败了，就需要生产者进行重新发送消息。 try { SendResult sendResult = producer.send(msg); // 同步发送消息，只要不抛异常就是成功。 if (sendResult != null) { //重试逻辑 }}catch (Exception e) { //重试逻辑} 异步发送的时候，会有成功和失败的回调，这还是需要在失败回调中处理重试确保成功 // 异步发送消息, 发送结果通过callback返回给客户端。producer.sendAsync(msg, new S ...

发送端用了单向发送RocketMQ 提供了一种发送方只负责发送消息，不等待服务端返回响应且没有回调函数触发，即只发送请求不等待应答的发送方式，叫做单向发送。 producer.sendOneway(msg); 用了这种发送方式，是非常有可能发送不成功，导致消息丢失 未处理发送失败的情况 如果使用了同步发送或者异步发送，但是没有处理好异常的情况，没有进行合理的重试，那么也会导致消息丢失 同步 try { SendResult sendResult = producer.send(msg); // 同步发送消息，只要不抛异常就是成功。 if (sendResult != null) { //忽略失败 }}catch (Exception e) { //忽略异常} 异步 // 异步发送消息, 发送结果通过callback返回给客户端。producer.sendAsync(msg, new SendCallback() { @Override public void ...

RocketMQ重复消费，指的是同一个消息重复来了多次 Consumer返回给Broker消费失败（常见 不管是因为什么情况了，是真的消费失败了，还是出现了异常了，还是明明消费成功了，但是你错误的返回了失败等等情况，只要你给 RocketMQ 返回的是 RECONSUME_LATER，那么消息就会重投，有重投就会有重复消费。 Consumer消费处理超时了（常见） 不只是返回失败的情况，如果消费方法执行时间过长，RocketMQ 可能判定消费者失联，也一样会重投消息。 那就和上面的情况一样了。 消息发重了（常见） 这种比较常见的，因为有的时候我们调用 MQ 发送消息的时候，因为网络抖动或者异常，我们会把一些实际成功的消息重发一遍，那么就会有两条一模一样的消息，那么对于消费者来说就可能会重复消费了。 广播模式 这不是重复消费，而是 RocketMQ 的广播模式特性，他就是会把一条消息发送给所有的消费者，但是如果大家处理的逻辑都一样， 那么和重复消费的表现是一样的。

和Kafka只支持同一个 Partition 内消息的顺序性一样，RocketMQ 中也提供了基于队列（分区）的顺序消费。即同一个队列内的消息可以做到有序，但是不同队列内的消息是无序的 当我们作为 MQ 的生产者需要发送顺序消息时，需要在 send 方法中，传入一个 MessageQueueSelector。 MessageQueueSelector 中需要实现一个 select 方法，这个方法就是用来定义要把消息发送到哪个 MessageQueue 的，通常可以使用取模法进行路由： SendResult sendResult = producer.send(msg, new MessageQueueSelector() { @Override//mqs：该Topic下所有可选的MessageQueue //msg：待发送的消息 //arg：发送消息时传递的参数 public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) { Integer id = (Inte ...

普通消息，就是很普通，没有什么特别的， 和顺序消息相比的话，就是消息发送到 MQ 后，消费者不保证严格按照发送顺序消费。消息可能会被乱序消费。 顺序消息是指生产者按照顺序发送消息，消费者也必需严格按顺序消费的消息。一般是通过绑定同一个分区来实现的。 顺序消息一般用在对顺序性有严格要求的场景中，比如是涉及到状态流转，尤其是那种状态流转的时间间隔很短的。 比如贷款的还款成功消息和结清消息。交易的确认收货消息和订单完结消息，基本都是同时发生的。如果系统是分别要处理这两个消息，那么可能就需要先处理确认收货，再处理订单完结，否则就会出问题的。 但是大多数情况下，我们用顺序消息的并不多，因为这只对收消息的应用有好处，而对发送消息的应用没有什么好处，反而增加了复杂性（而且还有吞吐量低、维护成本高等缺点）。而要做顺序消息，又需要发送者来做代码改造，所以很多系统都不愿意改，比如交易系统，不可能这么改的。 所以，实际上的大多数场景，并不一定会直接用MQ的顺序消息，而是倾向于消费者自己排序 前置状态判断 作为一个消费支付消息和发货消息的系统，我们可以基于这个 beforeStatus 来判断和我系统中的当前 ...

所谓本地缓存，就是和应用服务器在一起的缓存工具，将需要缓存的数据放到本地缓存中，可以大大的提升访问速度 数据结构 一般来讲，为了提升缓存的效率，通常采用 Key-Value 结构进行数据存储，也就是说，缓存中的数据保存和读取都需要有一个 Key，通过 Key 来读取固定的缓存的 Value 线程安全 本地缓存一定要考虑线程安全的问题，因为大多数情况下本地缓存都是一个全局可访问的变量，那么就会有多个线程同时访问，所以线程安全问题不容忽视 对象上限 因为是本地缓存，而本地内存中的数据是要占用 JVM 的堆内存的，所以内存是有上限要求的，如果无限存储，最终一定会导致 OOM 的问题 清除策略 为了避免 OOM 的问题，一般会考虑在缓存中增加清除策略，通过一定的手段定期的清理掉一些数据，来保证内存占用不会过大，常见清除策略主要有有 LRU（最近最少使用）、FIFO（先进先出）、LFU（最近最不常用）、SOFT（软引用）、WEAK（弱引用）等 过期时间 有了清除策略并不能保证百分百的可以删除数据，极端情况会会使得某些数据一直无法删除。这时候就需要有一种机制，能够保证某些 K-V 一定可以删除。通 ...

客户端与配置中心的数据交互方式其实无非就两种，要么推 ，要么就是拉 推的模式就客户端和服务端建立 TCP 长链接，当服务端数据发生变化，立即通过这个已经建立好的长连接将数据推送到客户端。长链接的优点是实时性，一旦数据变动，客户端立即就能感知到。但是缺点就是服务端需要维护大量的 TCP 连接，这会占用大量的内存和 CPU 资源，同时也容易受到网络抖动等因素的影响。 拉的模式就是客户端轮询，通过不断轮询的方式检查数据是否发生变化，变化的话就把数据拉回来。轮询的优点是实现比较简单，但弊端也显而易见，轮询无法保证数据的实时性，并且轮询方式对服务端还会产生压力。 在 Nacos 1.x 版本中采用的是长轮询，不是长连接，也不是轮询，是长轮询（Long Polling）。 其实就是把长连接和轮询综合了一下，就是说客户端发起轮询，但是不立即返回，而是 hold 一段时间，这段时间保持着一个有效连接，超时或者变化再返回，然后再发起一次轮询。 在 Nacos 2.0 中，采用 gRPC 长连接。 长轮询和长连接 长轮询是一种实现异步消息通信的机制，它通常用于客户端向服务器端请求某个资源时， ...