<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[u010899985的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/u010899985</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; u010899985]]></copyright><item><title><![CDATA[Milvus数据一致性介绍及选择方法]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/135163254</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/135163254</guid><author>u010899985</author><pubDate>Sat, 23 Dec 2023 00:17:58 +0800</pubDate><description><![CDATA[来保障读链路的一致性，如下图所示，在往消息队列插入数据时， Milvus 不光会为这些插入记录打上时间戳，还会不间断地插入同步时间戳，以图中同步时间戳 syncTs1 为例，当下游消费者（比如QueryNodes）看到 syncTs1，那么意味着 syncTs1 以前的 数据已经全部被消费了，换句话说，比 syncTs1 时间戳还小的插入记录不会再出现在消息队列中。反之，如果用户希望尽快得到搜索结果，对可用性有较高的要求，对查询精度有较高的 容忍程度，那么 GuaranteeTs 可以不必特别大。]]></description><category></category></item><item><title><![CDATA[Milvus向量数据库基础用法及注意细节]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/135155871</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/135155871</guid><author>u010899985</author><pubDate>Fri, 22 Dec 2023 16:51:24 +0800</pubDate><description><![CDATA[现有一查询向量S、过滤条件E1和过滤条件E2（E1、E2均为列表），集合需要返回S与V相似度最高，且B包含于E1、C包含于E2的字符名称A。假设E1 = [1,2,3]，E2 = [4,5,6]，则对于同一条向量，需要做3 x 3 = 9次过滤。1、假设集合中有一字段A的数据类型为整型或浮点型，则可以。2、假设集合中有一字段A为任意数据类型，则可以。5、假设集合中有一字段A为json类型，则可以。3、假设集合中有一字段A为字符类型，则可以。4、假设集合中有一字段A为字符类型，则可以。数据量最小为1024。]]></description><category></category></item><item><title><![CDATA[时间序列预测模型介绍及使用经验总结]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/135147732</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/135147732</guid><author>u010899985</author><pubDate>Fri, 22 Dec 2023 11:08:57 +0800</pubDate><description><![CDATA[时间序列预测模型，常用的机器学习模型主要包括以下3类：ARIMA，Prophet，LGB。①优点简单易行，可解释性强；数据量要求低；计算速度较快，可以对每个站在线拟合推理；②缺点仅支持单变量；准确率低；③适用场景：基于统计学方法，项目初期冷启动①优点简单易行，可解释性强；数据量要求低；加入先验知识（节假日）；计算速度更快，可以对每个站在线拟合推理；②缺点仅支持单变量；无法特征工程；准确率较低；③适用场景：项目初期迭代①优点准确率较高；简单易行，可解释性强；]]></description><category></category></item><item><title><![CDATA[大语言模型的三种主要架构 Decoder-Only、Encoder-Only、Encoder-Decoder]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/135144595</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/135144595</guid><author>u010899985</author><pubDate>Fri, 22 Dec 2023 09:09:41 +0800</pubDate><description><![CDATA[f基于 Transformer 模型以非灰色显示：decoder-only 模型在蓝色分支，encoder-only 模型在粉色分支，encoder-decoder 模型在绿色分支。模型在时间线上的垂直位置表示它们的发布日期。开源模型由实心方块表示，而闭源模型由空心方块表示。右下角的堆积条形图显示了各公司和机构的模型数量。从时间轴上，我们可以看到：2021年前，当 OpenAI 决定在，他们实际上是在逆流而上。]]></description><category></category></item><item><title><![CDATA[RLHF介绍及实践测试]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/135135706</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/135135706</guid><author>u010899985</author><pubDate>Thu, 21 Dec 2023 17:18:25 +0800</pubDate><description><![CDATA[RLHF（Reinforcement Learning Hyperparameter Optimization Framework）是一种用于强化学习模型的超参数优化框架。使用generate_prompt_dataset.py对目标数据生成prompt数据（instructions）修改critic.load_state_dict(state_dict, strict=False)可解决；与lora微调的区别是：RLHF多了。：执行监督训练shell脚本。：执行奖励函数训练脚本。：执行LM微调训练脚本。]]></description><category></category></item><item><title><![CDATA[基于DeepSpeed对 llama2-7b的LORA精调]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/135133260</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/135133260</guid><author>u010899985</author><pubDate>Thu, 21 Dec 2023 16:22:41 +0800</pubDate><description><![CDATA[在调参实验中，我们先对ZeRO相关的所有参数做了一次实验，单次实验只改变一个实验参数，最后锁定了与zero_stage=3相关的三个参数以及参数reduce_bucket_size，针对这些参数进行了一系列调参实验。从表格中我们可以看到，对于llama2-7b模型，除zero_stage为0以外，单机单卡对该模型进行LORA精调支持的最大长度都为256，zero_stage为1或2时，单机双卡和双机四卡对llama2-7b模型进行LORA精调的最大长度都为512。较小的值使用较少的内存，但执行更多的通信。]]></description><category></category></item><item><title><![CDATA[Megatron模型并行研究]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/135132805</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/135132805</guid><author>u010899985</author><pubDate>Thu, 21 Dec 2023 15:58:24 +0800</pubDate><description><![CDATA[在终端输入如下命令，其中output-prefix是数据预处理生成文件的前缀，在本文的例子中，数据预处理后生成的文件被命名为my-gpt2_text_document.bin和my-gpt2_text_document.idx。多机并行是在单机并行的基础上进行的，因此要运行多机并行的脚本文件，请先参考Megatron-LM模型并行研究的第2小节中的a，完成其中的操作，再配置接下来的部分。两个节点中运行脚本的唯一不同：A服务器作为主节点的NODE_RANK=0，83服务器作为副节点的NODE_RANK=1。]]></description><category></category></item><item><title><![CDATA[Triton + HF + Qwen 推理经验总结]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/135132415</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/135132415</guid><author>u010899985</author><pubDate>Thu, 21 Dec 2023 15:46:47 +0800</pubDate><description><![CDATA[开启use_cache_quantization和use_cache_kerne。2.1. docker部署。]]></description><category></category></item><item><title><![CDATA[vllm 加速推理通义千问Qwen经验总结]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/135132223</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/135132223</guid><author>u010899985</author><pubDate>Thu, 21 Dec 2023 15:31:00 +0800</pubDate><description><![CDATA[curl请求 curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Qwen/Qwen-14B-Chat-Int4-hf", "prompt": "San Francisco is a", "max_tokens": 7, "temperature": 0 }'解决方法：将序列中token按固定长度划分为多个块，并与系统内存进行映射，解决不连续填满问题。]]></description><category></category></item><item><title><![CDATA[Redis 哨兵模式原理]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109231442</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109231442</guid><author>u010899985</author><pubDate>Thu, 22 Oct 2020 22:32:32 +0800</pubDate><description><![CDATA[1）哨兵模式原理

①哨兵如何实现相互监督的功能

哨兵通过发布订阅__sentinel__:hello channel来实现这个功能。每个哨兵每隔2s会向自己监控的所有主从Redis节点发送hello message，包括自己的IP、端口、运行ID、自己监控的Master节点IP、Master节点端口。
	所有主从Redis节点也会反馈这样的信息
②哨兵如何故障检测

基于多数投票原则

第一：某个哨兵节点判定master节点故障，他会投出一票S_DOWN(主观下线)

第二：当有足够多的sentinel]]></description><category></category></item><item><title><![CDATA[分布式锁有三种实现方式]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109229874</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109229874</guid><author>u010899985</author><pubDate>Thu, 22 Oct 2020 20:44:09 +0800</pubDate><description><![CDATA[分布式锁有三种实现方式：

1. 数据库乐观锁；

利用数据版本 Version 记录机制实现：



2. 基于Redis的分布式锁；

 SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。缓存过期时，通过  SetNX 获取锁，如果成功了，那么更新缓存，删除锁，需要注意的是：

如果请求执行因为某些原因意外退出了，导致创建了锁但是没有删除锁，那么这个锁将一直存在，以至于以后缓存再也得不到更新。于是乎我们需要给锁加一个过期时间以防...]]></description><category></category></item><item><title><![CDATA[Redis 缓存穿透+缓存击穿+缓存雪崩]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109229069</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109229069</guid><author>u010899985</author><pubDate>Thu, 22 Oct 2020 20:25:04 +0800</pubDate><description><![CDATA[Redis 缓存穿透+缓存击穿+缓存雪崩

1.缓存穿透：

缓存穿透是指读的请求在缓存redis中没有命中，需要从mysql数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。



 1.2解决办法：


	缓存空对象
	
当存储层不命中后，即使数据库返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，依次保护了后端数据源。

                     ...]]></description><category></category></item><item><title><![CDATA[缓存与数据库数据不一致 解决方法]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109226666</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109226666</guid><author>u010899985</author><pubDate>Thu, 22 Oct 2020 17:41:23 +0800</pubDate><description><![CDATA[Redis缓存与数据库数据一致性

不管是先写数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况：

1.如果删除了缓存，还没有来得及写数据库，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。
	2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。
1.第一种方案：延时双删策略+缓存超时设置

在写库前后都进行删除缓存操作（redis.del(key)），并且设定合理的缓存过期时间。具体的步骤就是：.]]></description><category></category></item><item><title><![CDATA[Redis 淘汰删除策略]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109216774</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109216774</guid><author>u010899985</author><pubDate>Thu, 22 Oct 2020 11:25:14 +0800</pubDate><description><![CDATA[Redis 淘汰删除策略

目前，Redis采用的是惰性删除+定期删除的方案

1. 定时删除

在设置键过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时，立即执行对键的删除操作；

 1.1 定时删除优劣

定时删除操作对于内存来说是友好的，内存不需要操作，而是通过使用定时器，可以保证尽快的将过期键删除；
	对于CPU来说不是友好的，如果过期键比较多的话，起的定时器也会比较多，删除的这个操作会占用到CPU的资源；
2. 惰性删除

当key被操作时(如get,set)时，Redis 会被动..]]></description><category></category></item><item><title><![CDATA[MySQL 主从同步机制 undo log redo log和bin log的区别]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109195477</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109195477</guid><author>u010899985</author><pubDate>Wed, 21 Oct 2020 11:05:16 +0800</pubDate><description><![CDATA[1. 二进制日志 bin log

  1.1 bin log的功能

  MySQL为了兼容其它非事务引擎的复制，在server层面引入了 binlog, 它可以记录所有引擎中的修改操作。

binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。
	binlog不会记录SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改，但可以通过查询通用日志来查看MySQL执行过的所有语句。...]]></description><category></category></item><item><title><![CDATA[消息队列消息丢失的原因及解决办法 RabbitMQ 和 Kafka]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109150280</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109150280</guid><author>u010899985</author><pubDate>Mon, 19 Oct 2020 09:52:26 +0800</pubDate><description><![CDATA[1. MQ一条消息的生产和消费过程

 消息的丢失可能发生在Producer、Broker、Consumer 的任一阶段；



2. RabbitMQ

  2.1 生产者丢失数据原因

   生产者将数据发送到 RabbitMQ 的时候，消息可能因为网络等问题在传入过程中给搞丢了。

  2.1.1生产者端解决方法

开启 RabbitMQ 事务
     使用用 RabbitMQ 提供的事务功能，就是生产者发送数据之前开启 RabbitMQ 事务channel.tx...]]></description><category></category></item><item><title><![CDATA[消息队列消息持续积压 与 消息队列满解决方法]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109142045</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109142045</guid><author>u010899985</author><pubDate>Sun, 18 Oct 2020 11:08:19 +0800</pubDate><description><![CDATA[1. 消息队列消息持续积压 与消息队列满出现原因

系统的某个部分出现了性能问题，来不及处理上游发送的消息，才会导致消息积压

消息队列消息持续积压 与消息队列满出现原因 可以从生产者端与消费者端两个方面去思考，要么是发送变快，要么是消费变慢：

Producer 端单位时间发送的消息增多，Consumer 端短时间内来不及消费；
	Producer 端单位时间发送的消息正常，Consumer 端因消费线程低效不能及时消费
2. 如何优化MQ性能避免消息积压

   消息队列的性能优化，需要优化...]]></description><category></category></item><item><title><![CDATA[Kafka 心跳机制 重复消费]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109139983</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109139983</guid><author>u010899985</author><pubDate>Sun, 18 Oct 2020 00:03:03 +0800</pubDate><description><![CDATA[kafka 心跳机制

Kafka是通过心跳机制来控制消费超时，心跳机制对于消费者客户端来说是无感的，它是一个异步线程，当我们启动一个消费者实例时，心跳线程就开始工作了。心跳超时会导致消息重复消费。

在org.apache.kafka.clients.consumer.internals.AbstractCoordinator中会启动一个HeartbeatThread线程来定时发送心跳和检测消费者的状态。每个消费者都有个org.apache.kafka.clients.consumer.internals]]></description><category></category></item><item><title><![CDATA[Kafka消费者负载均衡策略 消费者再平衡 consumer rebalance 心跳机制]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109138020</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109138020</guid><author>u010899985</author><pubDate>Sat, 17 Oct 2020 21:38:30 +0800</pubDate><description><![CDATA[消费者负载均衡策略

一、消费者平衡过程（consumer rebalance）

 1. 消费者平衡过程

   消费者平衡过程是指 消费者重新加入消费组，并且重新分配分区Partition给消费者的过程。

 2. 会引起消费者平衡的情况

新的消费者加入消费组
	某个消费者从消费组中退出（异常或正常）
	增加订阅主题的分区（kafka的分区数，可以动态的增加，但不能减少）
	某台broker宕机，新的协调器ZK当选
	某个消费者在心跳会话时间内没有发送心跳请求（配置参数：...]]></description><category></category></item><item><title><![CDATA[kafka 如何解决消息队列重复消费]]></title><link>https://blog.youkuaiyun.com/u010899985/article/details/109137763</link><guid>https://blog.youkuaiyun.com/u010899985/article/details/109137763</guid><author>u010899985</author><pubDate>Sat, 17 Oct 2020 20:47:19 +0800</pubDate><description><![CDATA[1、消息重复消费场景

kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，代表他的序号，然后consumer消费了数据之后，每隔一段时间，会把自己消费过的消息的offset提交一下，代表已经消费过了，下次消费时，会继续从上次消费到的最后一次offset来继续消费。但是凡事总有意外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启了，如果碰到点着急的，直接kill进程了，再重启。这会导致consumer有些消息处理了，但是没来得及提交offset。重启之后，少数消]]></description><category></category></item></channel></rss>