1.?幂幂幂幂???Դ??
2.Kafka Logcleaner源码分析
3.万字长文带你解读Redisson分布式锁的源码
4.lodash源码解析：reject、remove、源码源码repeat、分钟replace、视频result...
?迅雷下载???Դ??
某天，运营反馈称，幂幂幂幂海外消费源码执行一次保存操作后，源码源码后台出现3条数据，分钟我立刻怀疑可能存在代码问题。视频为了确保不会误判，迅雷下载我要求暂停操作，幂幂幂幂保留现场，源码源码以便我进行排查。分钟
查看新增代码，视频发现是迅雷下载同事三歪进行的改动，他将原有的dubbo XML配置方式改为了注解方式。我询问其改动详情，得知他是更改了模块的配置方式。于是，我决定深入研究，找出问题所在。
dubbo配置方式多样，最常见的源码编译apktool为XML配置与注解配置。我已初步推测原因，接下来将进行详细的调试过程。
我使用dubbo版本2.6.2进行调试。首先，针对采用@Reference注解条件下的重试次数配置，我发现调用接口时，会跳转到InvokerInvocationHandler的invoke方法。继续跟踪，最终定位到FailoverClusterInvoker的doInvoke方法。在该方法中，我关注到获取配置的retries值，发现其默认值为null，导致最终计算出的重试次数为3。
采用dubbo:reference标签配置重试次数时，同样在获取属性值后，发现其默认值为0，与注解配置一致，最终计算出的重试次数为1。对比两种配置方式，我总结了以下原因：
在@Reference注解形式下，dubbo会在注入代理对象时，通过自定义驱动器ReferenceAnnotationBeanPostProcessor来注入属性。刀剑江湖源码在标签形式下，虽然也使用了Autowired注解，但dubbo会使用自定义名称空间解析器DubboNamespaceHandler进行解析。
在注解形式下，当配置retries为0时，属性值在注入过程中并未被解析为null，但进入buildReferenceBean时，因nullSafeEquals方法的处理，导致默认值和实际值不一致，最终未保存到map中。而标签形式下，解析器能够正确解析出retries的值为0，避免了后续的问题。
总结发现，采用@Reference注解配置重试次数时，dubbo在注入属性过程中存在逻辑处理上的问题，导致默认值与实际值不一致。此为dubbo的一个逻辑bug。建议在不需要重试时，设置retries为-1，以确保接口的幂等性。需要重试时，vue源码编译设置为1或更大值。
问题解决后，我优化了文件操作，将其改为异步处理，从而缩短了主流程的时间。最终，数据出现3条的状况得以解决。
此问题已得到解决，并在后续dubbo版本2.7.3中修复，确保了在注解配置方式下，nullSafeEquals方法能够正确处理默认值与实际值一致的情况。
Kafka Logcleaner源码分析
Kafka日志保留策略包括按时间/大小和compact两种。Logcleaner遵循compact策略清理日志，只保留最新的消息，当多个消息具有相同key时，只保留最新的一个。
每个日志由两部分组成：clean和dirty。dirty部分可以进一步划分为cleanable和uncleanable。uncleanable部分不允许清理，包括活跃段和未达到compact延迟时间的段。
清理过程由后台线程定期执行，选择最脏的clh队列源码日志进行清理，脏度由dirty部分字节数与总字节数的比例决定。清理前，Logcleaner构建一个key->last_offset映射，包含dirty部分的所有消息。清理后，日志文件过滤掉过期消息，并合并较小的连续段为较大文件。
payload为null的消息被Logcleaner删除，这类消息在topic配置的时间内保留，然后被清理。清理过程需与幂等性和事务性生产者兼容，保留活跃生产者最后一批消息，直到产生新消息或生产者不活跃。只清理提交或终止事物中的消息，未提交事物中的消息不清理。
Logcleaner通过cleanOrSleep方法启动清理，选择最脏日志，调用clean清理并合并段。在清理前计算tombstone的移除时间，确保在clean部分驻留一定时间后移除。清理过程包括构建offset映射，分组段文件并清理合并。
Logcleaner的清理逻辑确保了高效和一致的日志管理，助力Kafka系统稳定运行。
万字长文带你解读Redisson分布式锁的源码
通过深入解读 Redisson 分布式锁的源码，我们了解到其核心功能在于实现加锁、解锁以及设置锁超时这三个基本操作。而分布式锁的实现，离不开对 Redis 发布订阅（pub/sub）机制的利用。订阅者（sub）通过订阅特定频道（channel）来接收发布者（pub）发送的消息，实现不同客户端间的通信。在使用 Redisson 加锁前，需获取 RLock 实例对象，进而调用 lock 或 tryLock 方法来完成加锁过程。
Redisson 中的 RLock 实例初始化时，会配置异步执行器、唯一 ID、等待获取锁的时间等参数。加锁逻辑主要涉及尝试获取锁（tryLock）和直接获取锁（lock）两种方式。tryLock 方法中，通过尝试获取锁并监听锁是否被释放来实现锁的获取和等待逻辑。这通过调用底层命令（整合成 Lua 脚本）与 Redis 进行交互来实现。Redis 的 Hash 结构被用于存储锁的持有情况，hincrby 命令用于在持有锁的线程释放锁时调整计数，确保锁的可重入性。
解锁逻辑相对简单，通过调用 unlock 方法，Redisson 使用特定的 Lua 脚本命令来判断锁是否存在，是否为当前线程持有，并相应地执行删除或调整锁过期时间的操作。
此外，Redisson 支持 RedLock 算法来提供一种更鲁棒的锁实现，通过多个无关联的 Redis 实例（Node）组成的分布式锁来防止单点故障。尽管 RedLock 算法能一定程度上提高系统可靠性，但并不保证强一致性。因此，在业务场景对锁的安全性有较高要求时，可采取业务层幂等处理作为补充。
Redisson 的设计遵循了简化实现与高效性能的原则，通过 Lua 脚本与 Redis 的直接交互来实现分布式锁的原子操作。在源码中，通过巧妙利用并发工具和网络通信机制，实现了分布式锁的高效执行。尽管 Redisson 在注释方面可能稍显不足，但其源码中蕴含的并发与网络通信的最佳实践仍然值得深入学习与研究。
lodash源码解析：reject、remove、repeat、replace、result...
本文解析 lodash 中的 R 开头零散小方法，包括 reject、remove、repeat、replace、result、round。将从变参函数处理、lodash 实现细节、依赖方法 negate、核心方法 random、reject、remove、repeat、replace、result、round，直至原生实现进行深入剖析。
对变参的处理：随机方法 random 的实现思路巧妙，涉及多种情况处理，如参数长度与类型判定。
lodash 实现时对参数处理复杂，采用灵活策略，如依据参数长度与类型进行分类处理。
试验显示，随机方法 random 的 lodash 实现与原始 Math.random 相匹配。
依赖的 lodash 方法 negate：一个接收函数作为参数并返回结果取反的函数。
filter 方法：用于筛选数组元素，返回符合特定条件的元素。
random 方法：对 Math.random 的封装，用于生成指定范围内的随机数。
reject 方法：实现 filter 的相反功能，返回数组中不符合特定条件的元素。
remove 方法：在原数组中删除指定元素，返回删除元素形成的数组。
repeat 方法：采用快速幂算法实现元素重复，提高效率。
result 方法：类似 get 方法，实现简洁高效，尽量减少变量定义。
round 方法：实现带精度的四舍五入，通过 createRound 方法实现，支持不同近似函数。
createRound() 方法：接收参数 floor、ceil、round，返回相应近似函数。
带 e 显示的浮点数处理与不带 e 的处理过程不同，后者通常涉及更直接的数值操作。
原生实现：repeat、replace、round 方法是 ECMAScript 中 String.prototype 的原生实现，可直接使用。
remove 和 result 方法的原生实现需遵循 lodash 类似的思路，以优化性能与代码简洁性。
以 reject 方法为例，其核心逻辑通过创建一个 complement 函数实现，该函数接收一个函数 f 作为参数，返回新的函数执行时返回的结果为 !f(...args)，从而实现功能。
