莉莉丝面经,go后端实习
全程1小时左右
自我介绍
项目拷打
算法题,两个协程,一个输出1234,另一个输出abcd.....要求交错排列,写完发现没输出,让面试官看看也是调了半天都没输出,牛客你这面试ide怎么回事
接下来是场景题目,直接给我拷打麻了
fps服务器设计?
一张地图中随机获取圆的场景题
说实话,这个面经基本没法写,前半段基于项目扩展,后半段场景拷打,八股基本为0
更新:20号感谢信
自我介绍
项目拷打
算法题,两个协程,一个输出1234,另一个输出abcd.....要求交错排列,写完发现没输出,让面试官看看也是调了半天都没输出,牛客你这面试ide怎么回事
接下来是场景题目,直接给我拷打麻了
fps服务器设计?
一张地图中随机获取圆的场景题
说实话,这个面经基本没法写,前半段基于项目扩展,后半段场景拷打,八股基本为0
更新:20号感谢信
全部评论
算法题似乎可以三个 channel 控制,两个用作数字和字母输出的通知,另外一个通知主协程
。不过 fps 服务器设计?这是用 go 做游戏嘛?
确实挺难,这个岗我java技术栈打招呼都不带理的
相关推荐

点赞 评论 收藏
分享
真的会谢的海螺很喜欢...:问应届生业务,问工作过的八股

点赞 评论 收藏
分享
点赞 评论 收藏
分享
烤点老白薯:面试官还是挺坦诚的,也跟我说了,说他自己的性格。然后又说了一下对我的感受,然后他也说找工作这个东西就像找对象,没有好不好,只有合不合适。

点赞 评论 收藏
分享
一笑而过2222:4. Redis缓存更新机制
核心策略:
- 过期删除:通过 expire 设置键的过期时间,到期后由后台线程(惰性删除+定期删除)处理。
- 惰性删除:客户端访问时检查是否过期,过期则删除。
- 定期删除:每隔一段时间随机检查部分键,删除过期键(通过配置 hz 控制检查频率)。
- 主动更新:应用主动调用 set / del 等命令更新缓存,常见场景:
- 数据变更时(如数据库更新后),同步更新缓存。
- 缓存失效前(如提前30秒),后台线程主动刷新(“缓存预热”)。
- 淘汰策略:当内存不足时,按策略淘汰旧数据(如LRU、LFU、随机等,见第5点)。
5. Redis的LRU机制(Least Recently Used)
原理:
- 近似LRU:Redis并非严格实现LRU,而是采样少量键(默认5个),淘汰其中最久未使用的键,通过 maxmemory-samples 参数调整采样数量。
- 实现方式:每个键维护 lru 字段(记录最后一次访问时间),淘汰时比较采样键的 lru 值。
- 优化策略:
- Redis 4.0引入LFU(最不常用) 策略,结合访问频率和时间淘汰数据。
- 可通过 maxmemory-policy 配置淘汰策略,如 allkeys-lru (所有键中使用LRU)、 volatile-lru (仅过期键中使用LRU)。
6. Redis集群
核心架构(以Redis Cluster为例):
- 分片机制:
- 数据按哈希槽(Hash Slot)分布,共16384个槽,每个节点负责部分槽。
- 键通过 CRC16(key) % 16384 计算归属的槽,路由到对应节点。
- 节点角色:
- 主节点(Master):负责读写操作,维护数据和槽信息。
- 从节点(Slave):复制主节点数据,主节点故障时可自动选举为新主(通过Raft协议)。
- 高可用机制:
- 自动故障转移:当主节点下线,从节点通过投票成为新主,保证服务不中断。
- 数据冗余:每个主节点至少有一个从节点,避免单点故障。
- 集群通信:
- 节点间通过Gossip协议交换状态信息(如节点存活、槽分配),维护集群拓扑。
- 典型部署:
- 至少3个主节点(每个主带1个从),形成3主3从架构,保证容错性(最多允许1个主节点故障)。
补充:Redis集群的优缺点
- 优点:
- 支持海量数据(通过分片扩展内存)。
- 高可用性(故障自动转移)。
- 读写分离(从节点可承担读请求)。
- 缺点:
- 不支持多键事务(跨节点键无法原子操作)。
- 客户端需处理分片路由(或通过中间件如Codis、Twemproxy)。
- 集群扩展时需迁移数据(通过 redis-trib 工具自动迁移槽)。

点赞 评论 收藏
分享