随便寻个地方'Blog

好久没有更新博客了，断更是因为找到了实习工作确实很忙，还有就是实在不知道要学什么了。好像进入了一种非常迷茫的状态，不过在经过几次新的面试之后，我发现现在自己对 Go 语言的理解还是局限在八股文中。最近也是看了好多关于 Go 语言底层原理的书，觉得可以整合一下，虽然之前也做过类似的整理，但是现在看来有点乱七八糟的，还是重新再来一遍吧。 所以，这是秋招特辑——《深入理解 Go 语言》，这个系列的博客不再仅仅是解释几个问题或者总结面试的时候常问的问题了，我对这个系列的博客的期望是能够真正的从浅到深地学习和理解Go语言。 整个系列分为三个部分——基础、并发和内存管理，每一部分会分别从使用方法和场景、实现原理、使用陷阱、历史发展和拓展五个部分来写。下面是目录链接： 基础篇 Go 语言创世纪 命名、声明和赋值 基础数据结构 复合数据结构 顺序存储两兄弟——数组和切片，到底有什么区别？ 特殊的存在——只读的string 查询效率最高的数据结构——map 变量的合租公寓——结构体 接口 函数 方法 反射 指针 defer 延迟调用 错误处理 panic 和 recover 并发篇 G ...

RPC 和 gRPC 其实是笔者在几个月前就开始接触的东西，但是由于当时在 Windows 上配不好环境加上学起来确实有点难度，所以就放下没去做项目，就简单地了解了一下。最近几天实在是没什么想学的，在拿起来看看吧，环境已经在 WSL 上配置好了，回头可以直接开始做项目了。 那今天就先来学习总结一下基础概念吧。 关于 RPC对 RPC 不了解地人，或许会纠结其与 TCP、HTTP 等的关系。后者是网络传输种的协议，而 RPC 是一种设计、实现框架。通讯协议只是其中一部分，RPC 不仅要解决协议通讯的问题，还有序列化与反序列化，以及消息通知。 是什么？从本质上讲，它使一台机器上的程序能够调用另一台机器上的子程序，而不会意识到它是远程的。RPC 是一种软件通信协议，一个程序可以用来向位于网络上另一台计算机的程序请求服务，而不必了解网络的细节。 一个完整的 RPC 框架里面包含了四个核心的组件，分别是 CLient, Server, ClientOptions 以及 ServerOptions，这个 Options 就是 RPC 需要设计实现的东西。 客户端（Client）：服务的调用方。 ...

今天是分布式一致性算法的第三个——ZAB 算法。 关于 ZAB 算法ZAB协议，全称 Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。它是专门为分布式协调服务——Zookeeper，设计的一种支持 崩溃恢复 和 原子广播 的协议。 从设计上看，ZAB协议和 Raft 很类似。ZooKeeper集群中，只有一个Leader节点，其余均为Follower节点。整个ZAB协议一共定义了四个阶段：选举（Leader Election）、 发现（Discovery） 、 同步（Synchronization） 、 广播（Broadcast） 。 ZAB借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法。 在Zookeeper中主要依赖ZAB 协议来实现数据一致性，基于该协议，zk实现了一种主备模型（即Leader和Follower模型）的系统架构来保证集群中各个副本之间数据的一致性。 这里的主备系统架构模型，就是指只有一台客户端（Leader）负责处理外部的写事务请求，然后 Leader 客户端将数据同步到其他 Follower ...

几天前更新的文章里降到了一致性算法，也详细地写了 Paxos 算法的内部原理，今天我们继续学习分布式一致性算法的其他两种，由于篇幅有限，所以一篇博客写一个算法。 关于 Raft 算法Raft 是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。在这里强调了是在工程上，因为在学术理论界，最耀眼的还是大名鼎鼎的 Paxos。 Paxos 算法是分布式系统领域最重要的一致性算法，同时也是公认的极为艰深难懂的算法。为了解决这个晦涩难懂的问题，斯坦福大学的Diego Ongaro、John Ousterhout教授以容易理解（Understandability）为目标设计了这个新的一致性算法：Raft，并在2013年发布了论文：《In Search of an Understandable Consensus Algorithm》。为了验证这个容易理解的特性，他们分别在斯坦福大学和加州大学伯克利分校的分布式计算课程上，使用了Raft和Paxos两种算法，采用视频教学的方式来传授给学生，之后采用小测验的方式来验证。结果表明 Raft 比 Paxos 容易理解很多。 Raft 和 Paxo ...

在正式学习一致性算法之前，先来看一个问题。 基于前面对分布式系统环境下一致性与共识算法的基础理论，在分布式系统中进行节点通信大部分采用基于消息传递通信模型，不可避免的会发生如进程可能会变慢、被杀死或者重启等问题，会对分布式系统中各节点对某一值达成一致性产生问题。 如何解决这一问题，这就要引出今天的主角——Paxos。 关于 PaxosPaxos 算法是 Leslie Lamport（莱斯利·兰伯特open in new window）在 1990 年提出了一种分布式系统 共识 算法。这也是第一个被证明完备的共识算法（前提是不存在拜占庭将军问题，也就是没有恶意节点）。 为了介绍 Paxos 算法，兰伯特专门写了一篇幽默风趣的论文。在这篇论文中，他虚拟了一个叫做 Paxos 的希腊城邦来更形象化地介绍 Paxos 算法。 不过，审稿人并不认可这篇论文的幽默。于是，他们就给兰伯特说：“如果你想要成功发表这篇论文的话，必须删除所有 Paxos 相关的故事背景”。兰伯特一听就不开心了：“我凭什么修改啊，你们这些审稿人就是缺乏幽默细胞，发不了就不发了呗！”。 于是乎，提出 Paxos 算法的那篇论 ...

关于分布式系统相关的内容， 在之前的博客里面也提到过不少，主要包括一致性算法、分布式存储等相关的内容，但是对于分布式系统，并没有一个清晰的概念。今天主要来看一下分布式系统的基础概念和理论基础，分布式系统涉及很多的技术、理论和协议，很多人也说，分布式系统是“入门容易，深入难”，我之前的学习也只算是管中窥豹，只见得其中一斑。 在网上搜索“如何学习分布式系统”，看完之后还是觉得云里雾里，不进行记录不太容易理清楚这里边的内容。本系列的博客主要关注一些实际应用场景中的技术实现，偏向于算法方向，更多的还是作为了解的内容。 什么是分布式系统？ 一个分布式系统是一些独立的计算机集合，但是对这个系统的用户来说，系统就像一台计算机一样。 首先需要明确的是，只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候，且硬件的提升（加内存、加磁盘、使用更好的CPU）高昂到得不偿失的时候，应用程序也不能进一步优化的时候，我们才需要考虑分布式系统。因为，分布式系统要解决的问题本身就是和单机系统一样的，而由于分布式系统多节点、通过网络通信的拓扑结构，会引入很多单机系统没有的问题，为了解决这些问题又会引入更多的机 ...

腾讯二面，没想到上次面试还有下文，隔了四天，周日晚上约今天的面试，那时我还躺在南昌酒店的床上享受着美好的假期生活。腾讯是真给机会啊，面完的感受，觉得还是差太多了，面试官问的问题我甚至都没听懂，不知道为什么，感觉很奇怪。面试时间不长，面试官也没开摄像头，没有自我介绍，直接开始拷打项目，但是也没有问什么深入的内容，就让自己介绍、有什么收获、重做一遍会有什么改进、做了多长时间等等，后面问一些八股，答得也不好，二十五分钟结束面试。反问项目组用什么语言、做什么内容，主要用 Go 和 C++，做一些关于大数据的内容（这不刚好吗，我可是千年学府、百年名校的湖南大学的第二届大数据学生）。 由于问题并不是很多，而且问题好像也不是很难，只是我没懂面试官的意思，脑子坏掉了，我就说我总是关键时刻掉链子。所以就简单记录一下都问了什么问题吧。 挑一个项目介绍一下。 传统项目了，果断挑选博客系统，巴拉巴拉介绍完。 介绍一下项目里用到的数据结构和技术选型。 太专业了，脑子没转过来也不知道怎么回答了，就讲了一下GET、POST请求，想继续讲登录操作，被打断了，可能是我太啰嗦了。 项目里前端和后端是怎么通信的， ...

很久很久以前（三天前），我被问到一个熟悉又陌生的问题，了解I/O多路复用吗？我回答，了解但是还没开始学？是的，我学习的领域就是这么广泛又浅显，名词我都了解，但是就是不知道具体是什么。 说到 I/O多路复用，我学习的博客都把他归到了操作系统一类里面，我也学过操作系统啊，为什么就不知道这是什么呢？我问了我周围的同学，好像都不知道，应该是当时老师没讲，也可能是讲了我们都没听。我知道这个算法是在学习 Redis 的时候，我们在 Redis 为什么这么快 那篇博客里提到了 多路复用 这个算法，今天我们就来看一看 I/O多路复用的前世今生。 最基础的 Socket 模型要想客户端和服务器能在网络中通信，那必须得使用 Socket 编程，它是进程间通信里比较特别的方式，特别之处在于它是可以跨主机间通信。 Socket 的中文名叫做插口，乍一看还挺迷惑的。事实上，双方要进行网络通信前，各自得创建一个 Socket，这相当于客户端和服务器都开了一个“口子”，双方读取和发送数据的时候，都通过这个“口子”。这样一看，是不是觉得很像弄了一根网线，一头插在客户端，一头插在服务端，然后进行通信。 创建 Socke ...

从刚开始找实习，我就一直说要重学算法，还是老毛病，拖延症。每次面试到了算法环节就只能讲自己的思路，因为代码实现不出来，题倒也做了不少，可惜就是没什么收获，还是慢慢重新学习吧。 学习算法的第一站，我选择排序算法，主要原因还是因为昨天晚上的面试打击到我了，要先把之前一直拖着没总结的东西重新学习并总结一下。 排序算法排序算法（sorting algorithm）用于对一组数据按照特定的顺序进行排序。排序算法有着广泛的应用，因为有序数据通常能够被更高效地查找、分析和处理。 排序算法中的数据类型可以是整数、浮点数、字符或字符串等。排序的判断规则可根据需求设定，如数字大小、字符 ASCII 码顺序或自定义规则。 评价维度运行效率：我们期望排序算法的时间复杂度尽量低，且总体操作数量较少（时间复杂度中的常数项变小）。对于大数据量的情况，运行效率显得尤为重要。 就地性：顾名思义，原地排序通过在原数组上直接操作实现排序，无须借助额外的辅助数组，从而节省内存。通常情况下，原地排序的数据搬运操作较少，运行速度也更快。 稳定性：稳定排序在完成排序后，相等元素在数组中的相对顺序不发生改变。 稳定排序是多级排序场 ...

一致性哈希算法，一个躺在我书签里两周的知识点，之前就一直说要看要看，结果一直拖，拖到昨天被面试官问了，只能回答说不会。 一致性哈希算法、一致性算法，这两个内容我一直以为是一样的，所以刚开始决定放在一起学，刚刚得知，两个不是一个东西。露出尴尬的笑容，那就先学一致性哈希算法吧。 一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希（DHT）实现算法，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题，使得分布式哈希（DHT）可以在P2P环境中真正得到应用。 一致性哈希算法是一种常用的分布式算法，其主要用途是在分布式系统中，将数据根据其键（key）进行散列（hash），然后将散列结果映射到环上，再根据数据节点的数量，将环划分为多个区间，每个节点负责处理环上一定区间范围内的数据。 按照老传统，我们逐步进行学习。 如何分配请求？大多数网站背后肯定不是只有一台服务器提供服务，因为单机的并发量和数据量都是有限的，所以都会用多台服务器构成集群来对外提供服务。 但是问题来了，现在有这么多个节点，要如何保证分配客户 ...