自我介绍非科班，问了一下专业和计算机有什么关系对docker、k8s、监控系统等有无了解项目相关项目是课程设计吗为什么你用go实现的redis服务端测试结果略优于redis，有分析过是什么原因吗第一点是应用了Golang优秀的并发性能，每一个Redis连接都会启一个协程去服务它；而Redis线程模型的命令处理部分是单线程而第二点比较主要的原因是，测试性能的时候，都关闭了aof持久化的设置第二点比较关键吧，因为我也提到了golang实现redis服务端时，遇到的一个难点是aof重写实现比较复杂。所以比较的时候没有开启aof持久化的设置如果开启aof设置，有没有测过性能吗开启aof持久化，关闭rdb持久化，aof刷盘策略为everysec时：50个连接、100000个请求下：写接口比Redis少2000，大概在25000qps实现的刷盘策略原理是什么介绍一下刷盘策略是按照redis三种策略 always、everysec、no来写的。刷盘策略的不同在于调用 fsync 的时机不同在我的实现中，比如always策略，是每次将写命令write进aof文件后，就同步调用 sync，将数据真正刷入磁盘；而 everysec策略是起一个后台协程，每秒调用一次sync来刷盘，而no策略是由内核决定刷盘的时机fsync在刷盘这块是怎么用的，刚刚没听清比如像always策略，我们将对数据库的写操作的resp协议文本 write进aof文件中，此时数据只在缓存中，我们会同步调用sync去将数据真正刷入磁盘；而everysec就是后台协程每秒调用sync刷入磁盘always策略每次写都要刷，磁盘io是不是会爆了？对，我们一般推荐使用的是 everysec策略，redis自己也推荐使用 everysec策略。真的要用到always策略，也是哪些对数据可靠性要求比较高的业务。不过这些不适合用内存型kv数据库去存储八股让你用栈来实现队列的先进先出，你会如何实现，用几个栈golang实现一个限流器mysql索引为什么用B+树B+树的特性是叶子节点存了全量数据，而非叶子节点只存储键值和索引一般我们是将它和B树进行比较，第一个点：讲节点的增加或删除，由于B+树冗余节点比较多，所以变形操作不会很复杂第二个点：由于非叶子节点仅存储键值，所以同一个数据页可以存放更多索引，B+树更矮胖；而像B树或者二叉搜索树等，它们的高度在数据量很大情况下比较高，所以磁盘io更多第三个点：B+树叶子节点通过链表组织起来，范围查询效率更高，而B树等需要通过中序遍历算法滑动窗口题目，很简单杂项对前端开发有兴趣吗评价一下自己，比起其他同学有什么优势反问