乱七八糟清单

其他东西

  • 仔细阅读下两个项目的代码是怎么设计的

自我介绍

好的,那我先介绍我的一个Go语言的学习经历和学习过程的基本的情况

大概是在8个月前开始用Go语言做项目的,在这之前还花了大概两三个月用来学习Go语言,我主要是通过阅读官方文档、书籍、博客、视频教程等途径来学习的;然后通过自己写一些项目和参与别人开源的项目的issue来检验我的Go语言学习。

我的话就是特别喜欢go语言,因为Go语言的设计团队可能就是考虑到个人的水平参差不齐,所以他在编码的过程中定义了很多规范的要求,比如说经常被吐槽的if err!=nil啊,或者说是大括号不能单独成行之类的,导致他的一个代码就比较结构清晰,阅读门槛也不是特别高,这样Go语言编写的项目的话就对于新人或者说是小白来说,因为我是喜欢看一个抽象概念必须要落到实处的,就是实际的源码上,配合上Go语言清晰友好的代码结构和容易上手的特性,最后我就决定使用Go语言开发了。
小白也可以很轻易的使用并发、而且也不用自己主动去关注内存管理、垃圾回收之类的事情,就不同于c++之类的、而且go语言是直接编译成二进制不同于Java是编译成字节码再继续编译之类的。

最后就是Go语言的一些内存管理,他在语言层面对这些做了一些优化,让我们就是不用主动去关注这些过程也可以有一个非常友好的开发体验嘛。
(gc,小白不用去像cpp之类的去关注语言的分配)

我也热爱开源,熟悉Github仓库协作流程,我有自己的Github账号,上面有一些自己的项目,也参与过一些开源项目的贡献。
然后我也在平时的学习过程中比较喜欢做一些知识总结,把他整理成一类知识,然后发布在我的个人博客上。

最后我自己也非常喜欢折腾一些Linux服务器之类的,折腾过域名备案,网站部署之类的,在服务器上面部署自己的网站啊、博客啊、视频网站啊之类的。

GOGC并发三色垃圾回收算法和混合写屏障机制

Go语言的垃圾回收算法其实是在一个业内的标记-清扫算法上加上自己的对象标记方法和混合写屏障机制实现的,最朴素的标记-清扫算法就是我们从一个最稳定的根对象出发然后沿着各个对象之间的一个引用依赖关系出发把整个过程中一个可达的对象全部标记上,实际上就是一个宽度优先遍历的过程,然后那些没有被标记的不可达的对象就是一个垃圾对象做一个清扫回收它们分配的内存。

Go语言最开始的三色标记法也是比较朴素的,就是在比如说内存分配不够用了,或者说是我们GC按照某种规定定期的启动,为了防止GC协程受到我们其他的一个用户业务代码的协程的一个干扰,我们要开始垃圾回收了,就直接stop the world,暂停整个程序,然后我们就开始最稳定的一系列根对象出发进行一个对象的遍历,把被黑色对象引用的对象置为灰色,还没有被标记的就是白色,然后重复这个过程,直到没有灰色对象为止,然后我们就可以把白色对象分配的内存给回收释放了,最后再start the world,启动所有的程序。

但是这个过程中的话这个stop the world的过程作用在我们这个垃圾回收的过程中,这样的话肯定是不是特别好的,所以Go语言的设计团队他肯定首先就是从这个减少stw时间来入手,我们在垃圾回收的一开始就stw,然后标记最稳定的根对象,这个时候我们就立刻start the world。后续的一个三色标记的过程我们跟我们的一个业务代码一起并发执行,这样的话我们就可以减少stw的时间,这样的话我们的业务代码就可以更加的流畅。

但是这样的话就会遇到另外一个问题就是在并发场景下都很容易遇到的一个问题,就是不管是我们是GC协程走的快一点,还是我们的用户协程走的快一点,都会导致他们进行一个互相的干扰,导致我们对一个引用依赖关系的错判,误判从而导致多标或者是少标的问题,比方说就是我们有一个对象还是白色的,引用他的对象已经被标记为灰色了,但是这个时候就是在引用c对象的b对象的业务代码突然断开了对c的引用同时我们另外一个已经被扫描完的对象又建立起对这个白色对象的引用,那么这个白色对象因为因为在gc看来就是没人引用的,因为这个原本引用灰色的对象来扫描的时候已经扫描不到这个白色对象了,但是这个引用白色对象的黑色对象我们认为已经扫描完了,就会导致我们回收这个白色对象,对我们的一个程序造成一个有可能是致命的破坏吧。

另外一种情况就是多标的问题,多标的问题就是当我们的某个已经被我们扫描完置为黑色的对象所引用的灰色对象,我们扫描完这个黑色对象之后就断开了引用,这个时候我们这个灰色对象就是已经没人使用了,但是我们在前面一次扫描的时候已经认为他是一个可达的对象,把他置为了灰色,所以下一轮扫描的时候我们从这个灰色对象开始,就导致这个灰色对象后面所有被引用的对象都我们回收不了了,造成一个内存的浪费,但是这样的话其实问题没有之前严重,除非我们的内存到了一个非常危险的地步了,下一秒就要爆内存了。否则这个灰色对象在这一轮没有被gc的话,那么他在下一轮也会被gc掉

在这样的一个背景下,go语言为了解决这两个问题就是引入了类似锁的机制嘛,主要就是为了解决这个更严重的多标问题,就是说比如黑色对象引用某个对象的时候,我们就主动的去给他写为灰色对象,防止他作为一个白色对象被垃圾回收了,然后还有就是我们在删除某个白色对象引用的时候,我们手动的给他置为灰色,就是我们gc垃圾回收的一个插入写屏障机制和删除写屏障机制。

然后就是我们的混合写屏障机制,因为我们的屏障机制是一种比较重型的过程,对性能耗费不是特别低,然后一个分配在栈上的对象一般是一些经常频繁使用的对象,所以我们直接在一开始的时候stw就把所有的栈对象给他置为黑色,而且后面不管是这个栈对象创建一个新的对象的时候,我们就直接给他置为黑色,不走屏障机制了。在我们的堆上的一个对象就是正常的进行一个插入写屏障和混合写屏障。

断点上传怎么实现的

主要是分为三步来完成,

  • 首先就是我们的客户端发起一个post请求来告诉数据节点,要上传大文件了,同时告诉数据节点我们的总共的size和这个大对象的uuid
  • 然后数据服务返回一个token,接口服务对token进行一个解码,获取第一个分片信息的size和uuid,
  • 获取第一个分片当前的长度,乘以分片的数量后我门就知道已经上传了几个分片,然后就继续走上传流程

断点上传的流程主要分为以下几个阶段:

  • 开始上传前的协商:客户端在知道要上传大对象时,改用对象的POST接口,并提供对象的散列值和大小给接口服务。接口服务搜索6个数据服务并分别POST临时对象接口,数据服务地址以及返回的UUID会被记录在一个token中,随后返回给客户端。
  • 上传并获取token:客户端POST对象后会得到一个token。后续通过PUT方法访问token可以上传数据。
  • 指定数据范围:在上传时,客户端需要通过range头部来告诉接口服务上传数据的范围。
  • 服务端处理上传数据:接口服务对token解码,获取6个数据片所在的数据服务地址以及UUID,分别调用PATCH将数据写入6个临时对象。
  • 数据接收特性:服务端在接收数据时可能不会完全接收客户端发送的数据量。数据是以块的形式分批写入的,每次写入32000字节的整数倍,除非是最后一批数据。
  • 进度查询:客户端在每次PUT操作前,需要用HEAD方法获取当前已上传的数据量。接口服务解码token,获取第一个分片当前的长度,乘以分片的数量后作为Content-Length响应头部返回给客户端。

总的来说,这个过程涉及了多个服务的交互,客户端和服务端共同维护了上传的进度和状态信息,以支持断点续传的功能。通过特定的接口和协议来处理数据校验与进度跟踪,确保数据的完整性和上传效率。

项目有什么难点和亮点

哈希值断开(获取的文件下载链接老是有问题,排查了老半天才发现是哈希)
网络端口重定向(ipconfig重定向问题)
断点上传中的上传逻辑问题
channel调度的问题
不要在频繁变更的表里面随便修改字段(实际经验吧)

  • 亮点:人很少,练习和了解了分布式相关知识

后续优化和改进

mysql多用户呀
raft做一个保证数据一致性
定期删除存储和过期的元数据:给元数据表去设置一个timer字段,然后定期的去删除过期的元数据

为什么做这样的一个项目

其实我最开始的想法还是做出一个家庭影院吧,因为我个人是比较喜欢看动漫的,然后我就是想着做一个视频点播网站,然后我就是用Go语言来实现了这个项目之后,他的视频是通过本地存储的

然后我自己对云储存其实也是比较感兴趣的,以为在我整个的自学过程中吧,百度网盘还有一些什么阿里网盘之类的老是限速,我就想自己弄一个存储系统嘛

个人的优势或者劣势

  • 缺少真正的实战经验,毕竟还没毕业,没有独立owner过某功能业务代码的需求,比如说什么运营需求、产品功能需求,主要还是做的一些团队内部的技术需求、项目代码优化之类的比如完善单元测试覆盖率啥的
  • 优势就是然后对一个新技术什么的也比较喜欢折腾,公司想做一些什么新技术啥的都可以主动的去学习,另外就是我几乎是一个纯自学的过程,所以我的自学能力,我自我感觉还是比较可以的。然后就是我比较容易接受新事物也喜欢折腾新事物,包括AI啥的我基本上是最早ChatGPT火的时候就开始在使用了,所以对新事物的接受能力挺强的。容易相处,能快速融入团队

最后谢谢加反问

  • 主要是做什么具体业务
  • 一共几面、大概什么时候有通知
  • 有没有一个内部技术文档之类的
  • 对我的一个建议

热爱开源熟悉Github仓库协作流程,对Go语言的熟悉程度还是比较高的,热爱折腾Linux服务器,对Linux系统也比较熟悉,我觉得这也是我的一个优势。

【自我介绍,千万别来虚的!-哔哩哔哩】 https://b23.tv/S6jaqY5

岗位合集

作者

JIeJaitt

发布于

2020-07-24

更新于

2024-04-10

许可协议

Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×