<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[dream0130__的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/dream0130__</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; dream0130__]]></copyright><item><title><![CDATA[Go 目录规范]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/129914199</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/129914199</guid><author>dream0130__</author><pubDate>Sun, 02 Apr 2023 18:07:24 +0800</pubDate><description><![CDATA[功能明确：一个目录实现的功能应该是明确的，并且在整个项目里具有很高的辨识度，当有新增功能的时候，我们可以清楚的知道应该存放在哪个目录之下。平铺式目录结构就是在项目根目录下存放项目的代码，整个目录就像一层的；- 可预测性：项目规模一定是从小到大，一个好的目录结构应该能够在项目变大时，能够保持之前的目录结构。- 全面性：目录结构应该全面包含研发过程中的所有功能，例如文档、脚本、API实现、功能、测试等。- 可扩展性：每个目录下存放的功能类型是一样的，在项目变大时，这些目录应该存放更多同类功能。]]></description><category></category></item><item><title><![CDATA[README 文档规范]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/129644574</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/129644574</guid><author>dream0130__</author><pubDate>Sat, 18 Mar 2023 22:54:26 +0800</pubDate><description><![CDATA[写一段简短的话描述项目描述该项目的核心功能点描述项目架构图描述该项目依赖的工具包如何构建项目如何运行项目如何使用如何对该项目做贡献]]></description><category></category></item><item><title><![CDATA[垃圾回收(GC)]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/121526670</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/121526670</guid><author>dream0130__</author><pubDate>Wed, 24 Nov 2021 22:51:19 +0800</pubDate><description><![CDATA[一.业内常见的垃圾回收算法
1.引用计数：对每个对象维护一个引用计数，当引用计数为0的时候，回收该对象。

优点：对象可以很快的回收，而不会出现内存耗尽或者达到某个阈值时才回收。
缺点：不能很好处理循环引用，维护引用计数也有一定的代价。

2 标记-清除：从根来遍历所有引用的对象，没有可以访问到的对象就会被回收。

优点：解决引用计数的缺点
缺点：需要STW,会暂时停止程序运行进行回收内存的处理。

3 分代收集：按照对象生命周期的长短分为不同的代空间，生命周期长的放入老年代，而短的放入新生代，不同代有不同]]></description><category></category></item><item><title><![CDATA[分布式理论 - BASE理论学习]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/119151513</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/119151513</guid><author>dream0130__</author><pubDate>Tue, 27 Jul 2021 19:41:01 +0800</pubDate><description><![CDATA[前言

BASE理论是CAP理论中的AP的延伸，是对互联网大规模分布式系统的实践总结，强调可用性。

BASE理论

BASE理论的核心是基本可用(Basically Available),软状态(Soft State)和最终一致性(Eventually Consistent)。软状态为不同节点之间，数据副本存在短暂的不一致性。
基本可用指的是当系统节点出现大规模故障的时候，通过牺牲部分功能的可用性，来保证系统的核心功能可用。
基本可用的本质是一种妥协，通过牺牲部分功能的可用性，来保证核心功能的稳定运行。
]]></description><category></category></item><item><title><![CDATA[CAP理论]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/119115661</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/119115661</guid><author>dream0130__</author><pubDate>Mon, 26 Jul 2021 18:39:15 +0800</pubDate><description><![CDATA[CAP 三指标
CAP理论对于分布式系统的特性做了高度抽象，形成了三个指标：一致性、可用性、分区容错性。
一致性指的是客户端的每次读数据的操作，所有节点返回的数据应该是相同的，不然就读取失败。一致性主要强调的是每个节点间的数据高度一致。
当客户端给节点1发起SET请求，请求成功之后。节点之间会发起通讯，使得节点2的值也编程和节点1的值相同。不管客户端访问哪个节点，读取到的都是同一份数据。

当节点之间发生故障的时候，暂时没有办法将节点之间的数据同步。这个时候，我们需要牺牲数据的一致性，每个节点使用本地数据来]]></description><category></category></item><item><title><![CDATA[HTTP协议的演变]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/115914541</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/115914541</guid><author>dream0130__</author><pubDate>Tue, 20 Apr 2021 18:50:51 +0800</pubDate><description><![CDATA[HTTP/1.1 相比HTTP/1.0 性能上的改进:

使用TCP 长连接的方式去改善了HTTP/1.0 短连接造成的性能开销。
支持管道传输，可以一次性发送多个请求，减少整体的响应时间。

但HTTP/1.1 还有性能瓶颈

只能压缩Body的部分，如果首部信息越多延迟越大
发送冗长的首部，每次发送相同的首部造成的浪费较多。
服务器是按照请求的顺序响应的，如果服务器慢，会导致客户端一直请求不到数据
没有请求优先级
请求只能从客户端开始，服务器只能被动响应。

HTTP/2 相比HTTP/1.1性能改进:]]></description><category></category></item><item><title><![CDATA[https 协议]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/115877422</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/115877422</guid><author>dream0130__</author><pubDate>Tue, 20 Apr 2021 13:24:36 +0800</pubDate><description><![CDATA[https 是什么

简单来说，https是http + ssl, 对http 通讯内容进行加密，使用tls/ssl(理论在传输层实现)加密的HTTP协议
需要理解SSL/TLS的工作原理，我们需要掌握加密算法。涉及到的加密算法有非对称加密和对称加密
对称加密: 通信双方使用相同的密钥进行加密，特点是加密速度快，但缺点是需要保护好密钥，密钥泄漏容易被破解。
非对称加密: 需要生成公钥和私钥 ， 安全性更高，但是计算量较大

https的链接过程

https 主要分为证书验证阶段和内容传输阶段
证书验证阶段]]></description><category></category></item><item><title><![CDATA[接口限流策略]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/115873656</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/115873656</guid><author>dream0130__</author><pubDate>Mon, 19 Apr 2021 21:39:30 +0800</pubDate><description><![CDATA[字节三面的场景题
限流的目的是通过对于并发访问进行限速，一般是达到限制的速率，就会触发相应的限流行为。常见的限流行为如下:

拒绝服务。 把多出来的请求拒绝掉，受到流量暴增的时候，会统计当前的哪个客户端来的请求最多，直接进行拒绝，把带恶意的请求阻挡。
服务降级。关闭一些不太重要的服务，让给更重要的功能。另一种是返回部分数据。
特权请求。我们只把有限的资源分给重要的用户，我们应该把资源尽可能的分给特权用户。
延时队列。利用一个队列来进行缓冲大量的请求，如果队列满，则进行拒绝，一般用于应对短暂的峰刺请求。

限]]></description><category></category></item><item><title><![CDATA[Gnu linker script 脚本手册-笔记]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/115278253</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/115278253</guid><author>dream0130__</author><pubDate>Mon, 29 Mar 2021 23:17:39 +0800</pubDate><description><![CDATA[一.概述

链接过程由链接脚本(lds文件)控制,链接脚本主要用于规定输出文件的内存布局。(可以看做链接过程中的Makefile)
链接器的默认链接脚本,可以通过 ld --verbose 来进行查看，可以通过  -T 选项用于指定自己的链接脚本。

二.简单例子
SECTIONS 
{ 
. = 0x10000; 
.text : { *(.text) } 
. = 0x800000; 
.data : { *(.data) } 
.bss : { *(.bss) } 
}


. = 0x10000 :]]></description><category></category></item><item><title><![CDATA[Redis 缓存异常]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/114764200</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/114764200</guid><author>dream0130__</author><pubDate>Sat, 13 Mar 2021 22:41:37 +0800</pubDate><description><![CDATA[一.Redis 和数据库中的数据不一致的情况是如何发生的?
首先我们需要明确数据一致性的情况

缓存中有数据，但是缓存的数据值需要和数据库中的值相同
缓存中本身没有数据，那么，数据库中的数据就必须是最新值

如果不符合上述情况，那么就出现了数据不一致的情况。
我们可以根据缓存是不是需要处理写请求，我们可以把缓存分为读写缓存和只读缓存
对于读写缓存来说，如果要进行增删改查需要对于缓存中进行，同时还要通过写回方式，同步回数据库中。
对于只读缓存来说，如果有新的数据新增，会直接去写入到数据库之中，而如果有数据删改]]></description><category></category></item><item><title><![CDATA[C++ 在编译阶段可以干什么？ -- 学习笔记]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/114397873</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/114397873</guid><author>dream0130__</author><pubDate>Fri, 05 Mar 2021 16:42:07 +0800</pubDate><description><![CDATA[编译阶段

编译是预处理之后的阶段，输入是通过预处理之后的C++源码，输出是二进制可执行文件。
编译阶段看到的都是 C++语法实体，比如说typedef ,using ,template , struct/class 这些关键字定义的类型，而不是运行阶段的变量。

比如说，让编译器去递归计算斐波那契数列
 template&lt;int N&gt; 
 struct fib // 递归计算斐波那契数列
 { 
 static const int value = fib&lt;N - 1&gt;::value]]></description><category></category></item><item><title><![CDATA[如何提升TCP四次挥手的性能? -- 参数调优]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/114377478</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/114377478</guid><author>dream0130__</author><pubDate>Thu, 04 Mar 2021 21:07:27 +0800</pubDate><description><![CDATA[首先我们来看一下四次挥手的过程

当主动方关闭连接时，会发送 FIN 报文，此时主动方的连接状态由 ESTABLISHED 变为FIN_WAIT1。当被动方收到 FIN 报文后，内核自动回复 ACK 报文，连接状态由ESTABLISHED 变为 CLOSE_WAIT，顾名思义，它在等待进程调用 close 函数关闭连接。
当主动方接收到这个 ACK 报文后，连接状态由 FIN_WAIT1 变为 FIN_WAIT2，主动方的发送通道就关闭了。再来看被动方的发送通道是如何关闭的。当被动方进入 CLOSE_WA.]]></description><category></category></item><item><title><![CDATA[redis 的哨兵机制 - 学习笔记]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/114320092</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/114320092</guid><author>dream0130__</author><pubDate>Wed, 03 Mar 2021 20:19:10 +0800</pubDate><description><![CDATA[在学习过redis 的主从模式之后，我们可以思考一个问题 如果主库发生故障，则没有实例可以去服务客户端的写操作请求，这时候应该如何处理呢?
我们在这个时候，需要考虑这三个问题:

主库真的故障了吗?
如果主库故障，我们应该如何去选择从库作为主库?
我们如何把新的主库信息通知给从库和客户端呢?

Redis 的哨兵机制实现主从库自动切换的关键机制，解决主从复制模式下故障转移的问题。
基本流程
哨兵主要负责的是 监控(防止主库出现故障)，选择主库和通知新主库信息

监控是指哨兵进程在运行的时候，周期性的给所有主]]></description><category></category></item><item><title><![CDATA[Redis - 数据如何保持一致性?]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/114186893</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/114186893</guid><author>dream0130__</author><pubDate>Sat, 27 Feb 2021 19:53:44 +0800</pubDate><description><![CDATA[Redis如何保证服务少中断?

Redis通过增加副本的冗余量，也就是将一份数据同时保存在多个实例上，如果有一个实例出现了故障，其他实例也可以提供服务，不影响业务使用。

Redis 主要提供主从库模式，来保证数据副本的一致性，主从库之间采用的是读写分离的模式。
读操作 ： 主库，从库都可以接收
写操作 ： 首先到主库进行执行，之后通过写操作由主库同步给从库

主从库采用读写分离，所有数据的修改只会在主库上进行，不用协调三个实例。主库有了新的数据后，会同步给从库，这样，主从库的数据就是一致的。
主从库之间]]></description><category></category></item><item><title><![CDATA[MySQL实战45讲  笔记 - MySQL如何保证主从一致？]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/114021380</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/114021380</guid><author>dream0130__</author><pubDate>Wed, 24 Feb 2021 22:20:01 +0800</pubDate><description><![CDATA[GNU ld version 2.27-44.base.1.al7
Supported emulations:
elf_x86_64
elf32_x86_64
elf_i386
elf_iamcu
i386linux
elf_l1om
elf_k1om
using internal linker script:
/* Script for -z combreloc: combine and sort reloc sections /
/ Copyright © 2014-2016 Free Software]]></description><category></category></item><item><title><![CDATA[Redis 渐进式哈希-学习笔记]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/113816163</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/113816163</guid><author>dream0130__</author><pubDate>Mon, 15 Feb 2021 15:18:51 +0800</pubDate><description><![CDATA[Redis 解决哈希冲突的方式


Redis 通过链式哈希的方式来解决哈希冲突。 链式哈希指的是同一个哈希桶中的多个元素用一个链表来保存，它们依次用指针来进行连接。



这里存在一个问题，哈希冲突链上的元素只能通过指针来进行逐一操作。哈希表写入的数据越多，哈希冲突可能也会越多，这会导致某些哈希冲突链过长，进而导致整个链上的元素查找耗时长，效率低。


因此 Redis 会对哈希表做rehash操作，rehash也就是增加哈希桶的数量，减少每个桶中的元素数目，进而减少单个桶中的元素。


Redis 如何]]></description><category></category></item><item><title><![CDATA[mysql 中的  redo log 和undo log - 学习笔记]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/113808572</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/113808572</guid><author>dream0130__</author><pubDate>Sun, 14 Feb 2021 16:49:43 +0800</pubDate><description><![CDATA[Redo log 重做日志


redo log 是为了确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log 进行重做，进而达到事务的持久性这一特性


redo log 物理格式的日志，记录的是物理数据页面的修改信息，其redo log 是顺序写入redo log file 的物理文件中去。


redo log 流转过程



先将原始数据从磁盘中进行读取，修改数据的内存拷贝。


生成一条日志信息写入到 redo log buffer(大小固定]]></description><category></category></item><item><title><![CDATA[mapreduce 论文 - 阅读笔记]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/113514211</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/113514211</guid><author>dream0130__</author><pubDate>Mon, 01 Feb 2021 14:46:18 +0800</pubDate><description><![CDATA[一.概要

MapReduce是一种编程模型，它是一种用于处理和生成大型数据集的实现。用户通过指定一个用来处理键值对(Key/Value)的map函数来生成一个中间键值对集合。然后，再指定一个reduce函数， 它用来合并所有的具有相同中间key的中间value 。

二.编程模型

由用户所编写的Map函数接收输入，并生成一个中间键值对集合。MapReduce这个库会将所有共用一个键的值组合到一起，传递给Reduce函数
Reduce函数接收一个中间键以及该键的值得集合作为输入。它会将这些值合并起来，生成]]></description><category></category></item><item><title><![CDATA[链接-学习笔记]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/113393124</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/113393124</guid><author>dream0130__</author><pubDate>Sat, 30 Jan 2021 00:35:33 +0800</pubDate><description><![CDATA[以下内容均为网络上整理的资料
一.链接是什么?
我们在这里可以去引用csapp 的定义 : 链接（linking）是将各种代码和数据部分收集起来并组合成为一个单一文件的过程，这个文件可被加载（或被拷贝）到存储器并执行。 了解这句话的含义，我们首先需要明白linux 系统上的一般编译过程:

需要强调的是，链接可以执行于编译时（compile time），也就是在源代码被翻译成机器代码时；也可以执行于加载时，也就是在程序被加载器（loader）加载到存储器并执行时；甚至执行于运行时（run time），由应用]]></description><category></category></item><item><title><![CDATA[编译binutil包报错 error: array type has incomplete element type extern const struct relax_type md_relax_t]]></title><link>https://blog.youkuaiyun.com/dream0130__/article/details/113133583</link><guid>https://blog.youkuaiyun.com/dream0130__/article/details/113133583</guid><author>dream0130__</author><pubDate>Mon, 25 Jan 2021 19:24:36 +0800</pubDate><description><![CDATA[编译binutils出错：
…/…/sources/binutils-2.15.91.0.2/gas/config/tc-i386.h:457:32: error: array type has incomplete element type
extern const struct relax_type md_relax_table[];
^
make[3]: *** [app.o] Error 1
make[3]: Leaving directory /mnt/lfs/binutils-build/gas]]></description><category></category></item></channel></rss>