Golang后端面试汇总-002

流雨声 · · 779 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

  • micro服务发现


    image
服务的注册与发现是微服务必不可少的功能,这样系统才能有更高的性能,更高的可用性。go-micro框架的服务发现有自己能用的接口Registry。只要实现这个接口就可以定制自己的服务注册和发现。

    go-micro在客户端做的负载,典型的Balancing-aware Client模式。

参考链接: https://www.cnblogs.com/li-peng/p/9689786.html
  • mysql底层有哪几种实现方式
1 MySQL 的常用引擎
a InnoDB
b Myisam
c 存储结构

2 MySQL 的数据、索引存储结构
a 数据存储的原理(硬盘)
b 数据读写的原理
c 访盘请求完成过程
d 磁盘的读写原理
e 减少 I/O 的预读原理
f MySQL 的索引
g MySQL 的 B+Tree
目前大多数数据库系统及文件系统都采用 B-Tree 或其变种 B+Tree 作为索引结构。

B+ 树索引是 B+ 树在数据库中的一种实现,是最常见也是数据库中使用最为频繁的一种索引。B+ 树中的 B 代表平衡,而不是二叉。

因为 B+ 树是从最早的平衡二叉树演化而来的。B+ 树是由二叉查找树、平衡二叉树(AVLTree)和平衡多路查找树(B-Tree)逐步优化而来。

二叉查找树:左子树的键值小于根的键值,右子树的键值大于根的键值。

AVL 树:平衡二叉树(AVL 树)在符合二叉查找树的条件下,还满足任何节点的两个子树的高度最大差为 1。

平衡多路查找树(B-Tree):为磁盘等外存储设备设计的一种平衡查找树。

参考链接: https://www.cnblogs.com/xuxinstyle/p/9813747.html
  • channel底层实现


    image

参考链接: https://www.cnblogs.com/sunsky303/p/14007172.html
  • mysql索引为什么要用B+树?
B+树能显著减少IO次数,提高效率
B+树的查询效率更加稳定,因为数据放在叶子节点
B+树能提高范围查询的效率,因为叶子节点指向下一个叶子节点

么B树和B+树的区别在哪呢?
B+跟B树不同B+树的非叶子节点不保存键值对应的数据,这样使得B+树每个节点所能保存的键值大大增加;
B+树叶子节点保存了父节点的所有键值和键值对应的数据,每个叶子节点的关键字从小到大链接;
B+树的根节点键值数量和其子节点个数相等;
B+的非叶子节点只进行数据索引,不会存实际的键值对应的数据,所有数据必须要到叶子节点才能获取到,所以每次数据查询的次数都一样;

参考链接: https://blog.csdn.net/zzti_erlie/article/details/82973742
  • mysql语句性能评测?
1.硬件
2.系统配置
3.数据库表结构
4.SQL以及索引

参考链接: https://www.cnblogs.com/111testing/p/11440064.html
  • 服务发现有哪些机制
有两种主要的服务发现机制:客户端发现机制和服务端发现机制。首先来看一下客户端发现机制。

参考链接: https://blog.csdn.net/lmy86263/article/details/75156520
  • raft算法是那种一致性算法
这就是分布式系统的一致性问题。

在分布式环境中, 一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作之后, 应该能够保证系统的数据仍然处于一致的状态。

对于一个将数据副本分别在不同分布式节点上的系统来说,如果对于第一个节点的数据进行了更新操作,并且成功更新之后,却没有使得其他节点上的数据得到相应的更新,于是在对第二个节点的数据进行读操作时,获取的是老数据(脏数据),这就是典型的分布式数据不一致的情况。

在一个分布式系统中,如果能够做到针对一个数据项的更新操作执行成功之后,所有的用户都可以读取到其中的最新值,那么这样的系统就被认为是具有强一致性(严格一致性)。

当然,在有些分布式系统实现中,并不需要实时保证系统数据的强一致性,它允许数据存在中间状态,并认为该中间状态不会影响系统的整体可用性(允许数据在不同节点之间的同步存在延时),在经过一段时间之后,最终能够达到一个一致的状态,这就是最终一致性(弱一致性)。

参考链接: https://www.jianshu.com/p/b93e883b92ea
  • raft有什么特点
简单易学。Paxos算法由Leslie Lamport通过论文发表于1990年,是当时最实用的分布式存储一致性算法。有许多上了年头的分布式系统底层采用的是Paxos。而Raft是由Paxos简化得来。Diego Ongaro与John Ousterhout在自己的论文中指出:经过对比,学生学习Paxos所需时间明显长于学习Raft所需时间。
最终一致性。存储一致性根据对于各个服务器的同一份数据之间允许差异的严格程度不同,可以分为强一致性、最终一致性、弱一致性。根据CAP定理,一个分布式系统不能同时保障一致性(Consistency)、可用性(Availability)与分区容错性(Partition tolerence)。但是经过权衡,系统可以达到“BASE”效果:基本可用(Basically available)、软状态(Soft state)、最终一致性(Eventually consistent)。Raft所达到的最终一致性,是指各节点上的数据在经过足够的时间之后,最终会达到一致的状态。
  • 当go服务部署到线上了,发现有内存泄露,该怎么处理
内存泄露指的是程序运行过程中已不再使用的内存,没有被释放掉,导致这些内存无法被使用,直到程序结束这些内存才被释放的问题。

Go虽然有GC来回收不再使用的堆内存,减轻了开发人员对内存的管理负担,但这并不意味着Go程序不再有内存泄露问题。在Go程序中,如果没有Go语言的编程思维,也不遵守良好的编程实践,就可能埋下隐患,造成内存泄露问题。

怎么发现内存泄露
在Go中发现内存泄露有2种方法,一个是通用的监控工具,另一个是go pprof:

监控工具:固定周期对进程的内存占用情况进行采样,数据可视化后,根据内存占用走势(持续上升),很容易发现是否发生内存泄露。
go pprof:适合没有监控工具的情况,使用Go提供的pprof工具判断是否发生内存泄露。

参考链接: https://blog.csdn.net/amars_ding/article/details/105865165

有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:流雨声

查看原文:Golang后端面试汇总-002

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

779 次点击  ∙  1 赞  
加入收藏 微博
上一篇:Go jsonrpc
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传