<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[duagh7的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/duagh7</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; duagh7]]></copyright><item><title><![CDATA[kafka consumer客户端消费逻辑解析]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/140022563</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/140022563</guid><author>duagh7</author><pubDate>Fri, 28 Jun 2024 00:37:11 +0800</pubDate><description><![CDATA[(2-1-1) ack策略-立即提交：说明在配置了手动提交-立即提交的ack策略时，提交动作是每次消息拉取前，将worker线程已处理完的消息挨个put进本地metadata一个map里，map是partition和offset的映射。需要提交的消息(ConsumerRecord)会维护在一个linkedBlockingQueue本地队列（且称之为worker队列）中，这里会不断while循环尝试从队列里获取消息，如果队列里还有消息，对这个消息进行处理。1、自动提交：拉取消息后立即提交。]]></description><category></category></item><item><title><![CDATA[由“cpu使用率”如何计算开始的基础知识学习过程]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/135865570</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/135865570</guid><author>duagh7</author><pubDate>Fri, 26 Jan 2024 15:57:09 +0800</pubDate><description><![CDATA[线程名是dubbo提供者，看堆栈是在从线程池获取task的时候没获取到于是处于waiting状态阻塞了，要等待被其他线程显式的唤醒。看来dubbo线程池还蛮大的，线程id都到142了，虽然此时都在waiting状态没有任务在被处理，但如果请求量上来了可能会频繁切换上下文，造成cpu开销增大。把jstack快照dump下来，top信息一起被dump了，这个时候300+个线程都处于sleeping状态，没有任何线程在running。废话不多说，直接找cpu占用率最高的线程。线上CPU飚高了，原因是什么？]]></description><category></category></item><item><title><![CDATA[项目管理经验总结]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/135776161</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/135776161</guid><author>duagh7</author><pubDate>Tue, 23 Jan 2024 17:01:48 +0800</pubDate><description><![CDATA[需求优先级管理

需求阶段

确保需求无漏洞、无歧义。
确保开发/测试对需求理解到位。
管理手段：

需求评审


流程沉淀：

产品将需求文档在评审前1天发出，研发侧有时间去看
再小的需求都必须有文字记录，比如用1句话在tapd进行描述




开发阶段

开发质量保证
按时完成

进度管理手段：早会、进步同步文档、项目群每日个人总结
进度管理
协同较多、跨域项目建议使用会议形式，有利于问题解决。
协同较少、小型项目建议使用定期


按量完成


联调阶段

前后端一致


测试阶段


]]></description><category></category></item><item><title><![CDATA[项目结构总结]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/135744460</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/135744460</guid><author>duagh7</author><pubDate>Mon, 22 Jan 2024 11:43:05 +0800</pubDate><description><![CDATA[1、防腐层，是为了在外部变化时，保持防腐边界内代码的不变。从而避免变化域内外的代码耦合度增高，引发频繁变更导致的边界内代码腐烂。]]></description><category></category></item><item><title><![CDATA[高可用初探]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/134993814</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/134993814</guid><author>duagh7</author><pubDate>Mon, 18 Dec 2023 10:09:34 +0800</pubDate><description><![CDATA[VRRP路由器是指运行VRRP的路由器，是物理实体；处于同一个VRRP组中的路由器具有两种互斥的角色：主控路由器和备份路由器，一个VRRP组中有且只有一台处于主控角色的路由器，可以有一个或者多个处于备份角色的路由器VRRP协议从路由器组中选出一台作为主控路由器，负责ARP解析和转发IP数据包，组中的其他路由器作为备份的角色并处于待命状态，当由于某种原因主控路由器发生故障时，其中的一台备份路由器能在瞬间的时延后升级为主控路由器，由于此切换非常迅速而且不用改变IP地址和MAC地址，故对终端使用者系统是透明的。]]></description><category></category></item><item><title><![CDATA[【参数汇总】mysql服务端/客户端常见优化参数]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/134954114</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/134954114</guid><author>duagh7</author><pubDate>Wed, 13 Dec 2023 10:28:48 +0800</pubDate><description><![CDATA[一般地，mysql 5.7、8.0 下 INNODB_BUFFER_POOL_INSTANCES 默认为1（单实例），若 mysql 存在高并发和高负载访问，设置为1则会造成大量线程对 BUFFER_POOL 的单实例互斥锁竞争，这样会存在一定量的性能问题， 该参数可以设置为服务器 CPU 核心数，这样可在一定程度上提供并发性能。innodb_log_file_size 值越大，在缓冲池中需要检查点刷新的行为就越少，因此也越节约磁盘I/O，但更大的日志文件也意味着在崩溃时恢复得更慢。]]></description><category></category></item><item><title><![CDATA[业务设计原则]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/134879432</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/134879432</guid><author>duagh7</author><pubDate>Fri, 08 Dec 2023 16:45:48 +0800</pubDate><description><![CDATA[不同业务的流程，流程节点代码可重用，方便不同需求复用。]]></description><category></category></item><item><title><![CDATA[springboot参数汇总]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/134706649</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/134706649</guid><author>duagh7</author><pubDate>Thu, 30 Nov 2023 10:42:00 +0800</pubDate><description><![CDATA[（默认值： false）spring.groovy.template.expose-spring-macro-helpers 是否发布供 Spring 宏程序库使用的 RequestContext ，并将其命名为 springMacro- RequestContext。spring.velocity.expose-spring-macro-helpers 是否发布供 Spring 宏程序库使用的 RequestContext ，并将其名命为 springMacro- RequestContext。]]></description><category></category></item><item><title><![CDATA[服务器运行情况及线上排查问题常用命令]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/134662633</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/134662633</guid><author>duagh7</author><pubDate>Tue, 28 Nov 2023 11:12:15 +0800</pubDate><description><![CDATA[三个数字分别代表了1分钟，5分钟，15分钟的统计值，这个数值的确能反应服务器的负载情况。但是，这个数值高了也并不能直接代表这台机器的性能有问题，可能是因为正在进行CPU密集型的计算，也有可能是因为I/O问题导致运行队列堵了。内存信息和swap信息，所有程序的运行都是在内存中进行的，所以内存的性能对与服务器来说非常重要。Swap分区是由硬盘提供的交换区，当物理内存不够用的时候，操作系统才会把暂时不用的数据放到Swap中。RES    进程使用的、未被换出的物理内存大小，单位kb。以下是几个需要注意的参数。]]></description><category></category></item><item><title><![CDATA[副本读最终一致性探究及其解决方案]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/134581825</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/134581825</guid><author>duagh7</author><pubDate>Thu, 23 Nov 2023 17:11:58 +0800</pubDate><description><![CDATA[其实，在读取请求中表现出一模一样的样子也是很难的，基本上业务系统只要求在所有数据大部分时间内表现出副本读一致性，而少部分数据是可以在少部分时间内读不一致的，但这个读不一致必须是可随着时间推移无操作自然恢复。副本读一致性则是不要求任何时刻它们真的一模一样，而是在读取请求中表现出一模一样的样子。其常见的场景如下：缓存和db之间的副本读一致性，es和mysql之间的副本读一致性，主库和从库的副本读一致性。下面让我们以redis和mysql之间的同步为例，来挨个探讨副本读一致性的解决方案。]]></description><category></category></item><item><title><![CDATA[mysql使用规范【转载】]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/134554797</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/134554797</guid><author>duagh7</author><pubDate>Wed, 22 Nov 2023 15:38:50 +0800</pubDate><description><![CDATA[update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘最后修改时间’,在修改表结构时，如果有缩短字段长度，且存在大于新的长度的表记录时，会导致修改失败并回滚，且回滚的时间比较长，整个过程是锁表操作，从而影响正常业务。注1：无法确认时，条件值允许统一加上单引号，因为MySQL会优先转换为数值，比如 where id=‘123’ 只会隐式转换’123’为123。]]></description><category></category></item><item><title><![CDATA[常见的幂等性保障方案]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/134530580</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/134530580</guid><author>duagh7</author><pubDate>Tue, 21 Nov 2023 14:55:11 +0800</pubDate><description><![CDATA[在实际的写入请求之前，先插入幂等表，幂等表插入成功则可以继续执行，若插入失败则表明已做过相应操作，执行失败时应回滚幂等表。当多次执行相同的操作时，如果没有幂等性，会产生不可预料的结果。例如在数据库中插入一条记录时，如果没有使用幂等性，可能会导致多条相同的记录被插入。上面的代码中，使用了VALUES子句来获取插入时的值，使得更新操作与插入操作一样。数据幂等性是指相同的操作在不同时间执行多次所产生的结果是一样的，它是保证操作的可靠性和正确性的重要标准。该方法能够保障数据库插入操作时的幂等性。]]></description><category></category></item><item><title><![CDATA[服务发布规范]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/132033176</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/132033176</guid><author>duagh7</author><pubDate>Tue, 01 Aug 2023 00:16:38 +0800</pubDate><description><![CDATA[服务发布是一次对线上环境的一次震荡，且前后端分离架构、微服务架构扩充了能够利用的服务器资源，却给服务发布带来很多衍生问题。ps：每次点写文章就要弹出新手指南、教我一次怎么发布，还必须手动点关闭。这交互和校验逻辑怎么设计的啊。1.配置维护：配置应当是原则上各环境一致，允许出现根据环境配置不同的情况，但是必须在发布灰度环境前有检查卡点。提供给前端的api，不可删除字段，新增字段不可为必填。1.已暴露给外部的api，必须兼容旧api。一、checklist。]]></description><category></category></item><item><title><![CDATA[微服务与sop工程结构的优缺点分析]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/132032907</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/132032907</guid><author>duagh7</author><pubDate>Mon, 31 Jul 2023 23:45:34 +0800</pubDate><description><![CDATA[2.从前者引出的，是微服务独立却完整，因此会有许多重复代码。大部分是service+repository构成一个微服务，微服务间不互相依赖，通过middle来复用代码，使用消息队列通信。sop的controller、service和repository是独立的，且controller还会根据业务领域划分。1.微服务的service是相对完整、独立可运行的单元，sop更强调层、间、互相协作的概念。]]></description><category></category></item><item><title><![CDATA[降级场景（待整理）]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/132026517</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/132026517</guid><author>duagh7</author><pubDate>Mon, 31 Jul 2023 17:12:32 +0800</pubDate><description><![CDATA[降级可以分为前端或者后端降级。]]></description><category></category></item><item><title><![CDATA[canal之作为万能数据触发流]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/131907510</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/131907510</guid><author>duagh7</author><pubDate>Tue, 25 Jul 2023 00:14:30 +0800</pubDate><description><![CDATA[canal数据变更之后再触发写日志，真正的解藕且数据已经执行成功才会收到通知，canal发到kafka的stream，用消息做了最终一致性。canal的思想是以数据变更为触发点，实现异步操作。它是高一致性的异步。它是无侵入性的后置流程处理。后续学习canal基础知识之后再填坑。以前日志需要做切面，还需要考虑写入失败的问题。有了canal就什么都想往里面扔。]]></description><category></category></item><item><title><![CDATA[kafka topic迁移方案及过程记录（待整理）]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/131907334</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/131907334</guid><author>duagh7</author><pubDate>Tue, 25 Jul 2023 00:02:27 +0800</pubDate><description><![CDATA[kafka的topic如果一开始没有做合理拆分，在业务不断膨胀的情况下，容易产生消息堆积，问题难以定位排查。二、新增发送者、从原topic拆出部分消息作为新topic、consumer group不变。三、新增发送者、从原topic拆出部分消息作为新topic、新增consumer group。四、新增发送者、从原topic拆出部分消息作为新topic、旧topic消息不变。一、发送者不变、topic不变、新增consumer group。五、新增发送者、旧发送者下线、新增topic。]]></description><category></category></item><item><title><![CDATA[表冷热改造方案及过程记录]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/131907151</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/131907151</guid><author>duagh7</author><pubDate>Mon, 24 Jul 2023 23:49:36 +0800</pubDate><description><![CDATA[冷热分离的目的在于提升热数据的性能，给冷数据分配较少的资源从而节约资源。热数据的范围越小，冷热改造的意义就越大。同时，需要确保冷数据足够冷，应该是终态数据（无改动），且访问频率低、性能要求低。




阶段
改造点
序号




冷表创建
创建冷表，结构与热表一致
1


冷热双查改造
单条查询改为先查热表，查不到则访问冷表，同时加冷表读开关，平时开关是关闭状态，业务特殊需求时才需要开启
2


冷热双查改造
多条查询改为同时查冷热表并聚合返回，分页先查热再拼凑冷表数据
3


冷表写入改造
定时任务每天将]]></description><category></category></item><item><title><![CDATA[后端服务迁移方案及过程记录]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/131906101</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/131906101</guid><author>duagh7</author><pubDate>Mon, 24 Jul 2023 23:15:07 +0800</pubDate><description><![CDATA[阶段
时序
动作




双写+数据对比
1
新rdb集群上线


双写+数据对比
2
新服务上线，无流量


双写+数据对比
2
后台处理程序，新服务上线一份新的


双写+数据对比
2
消费二方mq，新服务使用新的消费组消费原有消息


双写+数据对比
3
新旧服务比较转发服务comparator上线，定时拉取新旧库数据对比是否一致，并打印对比日志


双写+数据对比
4
旧服务改造上线


双写+数据对比
4
旧服务http读、写请求转发comparator，再转发到新服务


双写+数据对比]]></description><category></category></item><item><title><![CDATA[后台项目的类别配置化及通用化设计]]></title><link>https://blog.youkuaiyun.com/duagh7/article/details/131893198</link><guid>https://blog.youkuaiyun.com/duagh7/article/details/131893198</guid><author>duagh7</author><pubDate>Mon, 24 Jul 2023 12:36:16 +0800</pubDate><description><![CDATA[不好的地方是由于场景类别对应的语义是动态的，保存在数据库里，前端操作框只能强绑定场景code，导致前端出现魔数和表意模糊等问题。通用化除了减少重复性工作外，往往还意味着功能升级，在原有共同基础功能的基础上，迭代出更强大的能力。比如权限，层级，排序等。其次是性能问题，每次用户查询类别或者代码根据类别走不同逻辑的判断，都需要一次dsl。3后端统一接口根据场景及权限筛选类别，查询类别表返回。4前后端详情及保存，使用类别编码交互，查询类别表。具体产品场景的类别通用化，统一管理，统一开发护。]]></description><category></category></item></channel></rss>