<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[吃透Java]]></title><description><![CDATA[关注移动互联网]]></description><link>https://blog.youkuaiyun.com/u013277209</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; u013277209]]></copyright><item><title><![CDATA[吃透Redis（十一）：Redis原子性的保证]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/128924891</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/128924891</guid><author>u013277209</author><pubDate>Tue, 07 Feb 2023 20:05:57 +0800</pubDate><description><![CDATA[Redis server 一旦和一个客户端建立连接后，就会在事件驱动框架中注册可读事件，这就对应了客户端的命令请求。而对于整个命令处理的过程来说，我认为主要可以分成四个阶段]]></description><category></category></item><item><title><![CDATA[吃透Redis（十）：Redis网络框架]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/128861093</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/128861093</guid><author>u013277209</author><pubDate>Fri, 03 Feb 2023 09:42:49 +0800</pubDate><description><![CDATA[很多人认为 Redis 是单线程，这个描述是不准确的。准确来说 Redis 只有在处理「客户端请求」时，是单线程的。但整个 Redis Server 并不是单线程的，还有后台线程在辅助处理一些工作。Redis 还启动了 3 个线程来执行文件关闭、AOF 同步写和惰性删除等操作。]]></description><category></category></item><item><title><![CDATA[吃透Redis（九）：缓存淘汰篇-LFU算法]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/126754778</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/126754778</guid><author>u013277209</author><pubDate>Wed, 07 Sep 2022 22:24:32 +0800</pubDate><description><![CDATA[Redis 在 4.0 版本后，还引入了 LFU 算法，也就是最不频繁使用（Least Frequently Used，LFU）算法。LFU 算法在进行数据淘汰时，会把最不频繁访问的数据淘汰掉。而 LRU 算法是把最近最少使用的数据淘汰掉，看起来也是淘汰不频繁访问的数据。那么，LFU 算法和 LRU 算法的区别到底有哪些呢？我们在实际场景中，需要使用 LFU 算法吗？]]></description><category></category></item><item><title><![CDATA[吃透Redis（八）：缓存淘汰篇-LRU算法]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/126370384</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/126370384</guid><author>u013277209</author><pubDate>Tue, 16 Aug 2022 17:43:22 +0800</pubDate><description><![CDATA[近似 LRU 算法并没有使用耗时耗空间的链表，而是使用了固定大小的待淘汰数据集合，每次随机选择一些 key 加入待淘汰数据集合中。最后，再按照待淘汰集合中 key 的空闲时间长度，删除空闲时间最长的 key。这样一来，Redis 就近似实现了 LRU 算法的效果了...]]></description><category></category></item><item><title><![CDATA[吃透Redis（七）：网络框架篇-redis 6.0 IO多线程原子性保证]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/126274656</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/126274656</guid><author>u013277209</author><pubDate>Wed, 10 Aug 2022 21:31:03 +0800</pubDate><description><![CDATA[Redis的主线程处理客户端连接操作Redis的IO线程处理客户端的读、写操作Redis IO线程处理时，Redis主线程处理部分连接完毕后需要等待IO线程处理读写完成。]]></description><category></category></item><item><title><![CDATA[吃透Redis（六）：网络框架篇-redis框架源码]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/126217123</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/126217123</guid><author>u013277209</author><pubDate>Sun, 07 Aug 2022 21:34:25 +0800</pubDate><description><![CDATA[很多人认为 Redis 是单线程，这个描述是不准确的。准确来说 Redis 只有在处理「客户端请求」时，是单线程的。但整个 Redis Server 并不是单线程的，还有后台线程在辅助处理一些工作。Redis 还启动了 3 个线程来执行文件关闭、AOF 同步写和惰性删除等操作。...]]></description><category></category></item><item><title><![CDATA[吃透Redis（五）：网络框架篇-reactor模型]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/126200112</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/126200112</guid><author>u013277209</author><pubDate>Sat, 06 Aug 2022 20:08:50 +0800</pubDate><description><![CDATA[Redis 是由 C 语言实现的，它采用的正是「单 Reactor 单进程」的方案，因为 Redis 业务处理主要是在内存中完成，操作的速度是很快的，性能瓶颈不在 CPU 上，所以 Redis 对于命令的处理是单进程的方案。......]]></description><category></category></item><item><title><![CDATA[吃透Redis（四）：网络框架篇-多路复用器]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/126105731</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/126105731</guid><author>u013277209</author><pubDate>Mon, 01 Aug 2022 17:48:02 +0800</pubDate><description><![CDATA[主要介绍了Redis网络通信依赖的操作系统底层机制，也就是IO多路复用机制。由于Redis是单线程程序，如果使用基本的Socket编程模型的话，只能对一个监听套接字或一个已连接套接字进行监听。而当Redis实例面临很多并发的客户端时，这种处理方式的效率就会很低。所以，和基本的Socket通信相比，使用IO多路复用机制，就可以一次性获得就绪的多个套接字，从而避免了逐个检测套接字的开销。单线程服务器模型，面临的最大的问题就是，一个线程如何处理多个客户端请求？https。...]]></description><category></category></item><item><title><![CDATA[吃透Redis（三）：数据结构篇-skiplist、quicklist、listpack]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/125998869</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/125998869</guid><author>u013277209</author><pubDate>Wed, 27 Jul 2022 11:01:48 +0800</pubDate><description><![CDATA[跳表是一个多层的有序链表，在跳表中进行查询操作时，查询代码可以从最高层开始查询。层数越高，结点数越少，同时高层结点的跨度会比较大。因此，在高层查询结点时，查询一个结点可能就已经查到了链表的中间位置了。这样一来，跳表就会先查高层，如果高层直接查到了等于待查元素的结点，那么就可以直接返回。如果查到第一个大于待查元素的结点后，就转向下一层查询。下层上的结点数多于上层，所以这样可以在更多的结点中进一步查找待查元素是否存在。Redis的ZSet为什么用skiplist而不用平衡二叉树实现？https。......]]></description><category></category></item><item><title><![CDATA[吃透Redis（二）：数据结构篇-内存优化的数据结构设计]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/125965385</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/125965385</guid><author>u013277209</author><pubDate>Sun, 24 Jul 2022 22:35:43 +0800</pubDate><description><![CDATA[降低内存开销，对于Redis这样的内存数据库来说非常重要，Redis用于优化内存使用效率的两种方法内存优化的数据结构设计和节省内存的共享数据访问。]]></description><category></category></item><item><title><![CDATA[吃透Redis（一）：数据结构篇-全局Hash表]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/125805731</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/125805731</guid><author>u013277209</author><pubDate>Fri, 15 Jul 2022 15:47:28 +0800</pubDate><description><![CDATA[通过源码分析Redis的全局Hash表，dictEntry源码，RedisObject源码，SDS、Hash表扩容、渐进式reHash等原理]]></description><category></category></item><item><title><![CDATA[吃透MySQL（十四）：主从延时问题]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/125593653</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/125593653</guid><author>u013277209</author><pubDate>Mon, 04 Jul 2022 09:48:23 +0800</pubDate><description><![CDATA[mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高，slave的sql thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随机的，不是顺序，所以成本要高很多，另一方面，由于sql thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL thread所能处理的速度，或者当slave中有大型query语句产生了锁等待，那么延时就产生了。所谓的主备延迟就是同一个事务]]></description><category></category></item><item><title><![CDATA[吃透Kafka七：Producer NIO 网络模型]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/123600650</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/123600650</guid><author>u013277209</author><pubDate>Sat, 19 Mar 2022 19:49:49 +0800</pubDate><description><![CDATA[主要讲述以下两个问题：

Producer 的大概网络模型，与 Java NIO 模型之间关系；
Producer 整体流程及其整体流程详解。

Producer 的网络模型
KafkaProducer 通过 Sender 进行相应的 IO 操作，而 Sender 又调用 NetworkClient 来进行 IO 操作，NetworkClient 底层是对 Java NIO 进行相应的封装，其网络模型如下图所示

从图中可以看出，Sender 为最上层的接口，即调用层，Sender 调用 NetworkCl]]></description><category></category></item><item><title><![CDATA[吃透Kafka六：topic 创建过程]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/123512753</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/123512753</guid><author>u013277209</author><pubDate>Tue, 15 Mar 2022 21:51:04 +0800</pubDate><description><![CDATA[本文主要讲述一个 topic 的创建过程，从 topic 是如何创建到 topic 真正创建成功的中间详细过程，文章主要内容可以分为以下几个部分：
1，topic 是如何创建的？

命令行创建；
Producer 发送数据时，自动创建；

2，topic创建时，replicas 是如何分配的？

指定 replicas 的分配；
自动 replicas 分配；

3，replicas 更新到 zk 后，底层如何创建一个 topic？

创建 Partition 对象及状态更新；
创建 Partition 的]]></description><category></category></item><item><title><![CDATA[吃透Kafka五：Producer Metadata 更新机制]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/123411790</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/123411790</guid><author>u013277209</author><pubDate>Thu, 10 Mar 2022 21:31:05 +0800</pubDate><description><![CDATA[在上一篇文章中，已经介绍了 Producer 的发送模型，Producer dosend() 方法中的第一步，就是获取相关的 topic 的 metadata，但在上篇中并没有深入展开，因为这部分的内容比较多，所以本文单独一篇文章进行介绍，本文主要来讲述以下三个问题：

metadata 内容是什么。
Producer 更新 metadata 的流程。
Producer 在什么情况下会去更新 metadata。

Metadata 内容
Metadata 信息的内容可以通过源码看明白：
// 这个类被 cl]]></description><category></category></item><item><title><![CDATA[吃透Netty一：普通IO]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/122030429</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/122030429</guid><author>u013277209</author><pubDate>Sun, 19 Dec 2021 21:30:03 +0800</pubDate><description><![CDATA[这里以文件输入输出流：FileInputStream、FileOutputStream来进行解释。由继承关系得知，这两个输入输出类继承自InputStream和OutputStream这两个基础的输入、输出的抽象类，这时我们可以看到当我们需要读写文件的时候，就需要创建两个流对象。原理图如下：

由图中可以知道，OS提供了API的接口给用户程序调用，这时我们可以将API接口和OS，比喻成C/S，也即应用程序就是浏览器端或者桌面端程序，OS和API等价于服务器，也即Controller接口。
public cl]]></description><category></category></item><item><title><![CDATA[吃透Kafka四：kafka producer源码详细分析]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/121803030</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/121803030</guid><author>u013277209</author><pubDate>Wed, 08 Dec 2021 22:43:52 +0800</pubDate><description><![CDATA[一，kafka producer基本使用
kafka生产则代码如下：
	public static void main(String[] args) throws ExecutionException, InterruptedException {

        Properties conf = new Properties();
        conf.setProperty(ProducerConfig.ACKS_CONFIG, "0");
        conf.setProperty(Pr]]></description><category></category></item><item><title><![CDATA[吃透Kafka三：详细分析生产和消费对消息的保障]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/121702583</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/121702583</guid><author>u013277209</author><pubDate>Fri, 03 Dec 2021 16:58:21 +0800</pubDate><description><![CDATA[一，kafka消息传递的三种语义

At most once：最多一次，消息可能会丢失，但不会重复。
At least once：最少一次，消息不会丢失，可能会重复。
Exactly once：只且一次，消息不丢失不重复，只且消费一次。

我们使用kafka肯定是希望Exactly once，要保证Exactly once效率上面需要做出一定的牺牲，那么是要Exactly once还是效率就要结合具体业务来分析了。但是整体的消息投递语义需要 Producer 端和 Consumer 端两者来保证。
二，Pr]]></description><category></category></item><item><title><![CDATA[吃透HTTP一：Http请求HttpUrlConnection，HttpClient、OKHttp详细介绍]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/121682788</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/121682788</guid><author>u013277209</author><pubDate>Thu, 02 Dec 2021 17:52:42 +0800</pubDate><description><![CDATA[一，HTTP概述
HTTP协议是无状态的协议，即每一次请求都是互相独立的。因此它的最初实现是，每一个http请求都会打开一个tcp socket连接，当交互完毕后会关闭这个连接。
HTTP协议是全双工的协议，所以建立连接与断开连接是要经过三次握手与四次挥手的。显然在这种设计中，每次发送Http请求都会消耗很多的额外资源，即连接的建立与销毁。
于是，HTTP协议的也进行了发展，通过持久连接的方法来进行socket连接复用。
HTTP/1.0+的Keep-Alive
使用HTTP/1.0的客户端在首部中加上"C]]></description><category></category></item><item><title><![CDATA[吃透Kafka二：kafka高性能之顺序IO、页缓存、零拷贝]]></title><link>https://blog.youkuaiyun.com/u013277209/article/details/121353239</link><guid>https://blog.youkuaiyun.com/u013277209/article/details/121353239</guid><author>u013277209</author><pubDate>Tue, 16 Nov 2021 12:38:27 +0800</pubDate><description><![CDATA[大家都知道Kafka是将数据存储于磁盘的，而磁盘读写性能往往很差，但Kafka官方测试其数据读写速率能达到600M/s，那么为什么Kafka性能会这么高/为什么这么快呢？
首先producer往broker发送消息时，采用batch的方式即批量而非一条一条的发送，这种方式可以有效降低网络IO的请求次数，提升性能。此外这些批次消息会"暂存"在缓冲池中，避免频繁的GC问题。批量发送的消息可以进行压缩并且传输的时候可以进行高效的序列化，从而减少数据大小。
Kafka除了在producer发送消息方面做了很多优化，]]></description><category></category></item></channel></rss>