欢聚集团测试开发一面
这个主要还是围绕在一些自动化测试,然后一些项目的风险管理的一些考察定位bug,然后反正就是那一堆的常规的业务场景题还是挺简单的,然后怎么写的UI自动化,怎么写的性能测试之类的,然后没啥特别难的八股问题,问了一个if else和switch的区别,这一块儿确实是太简单了。然后最后问了一下他那个是做啥的,是做一个跨境电商的建站的,涉及前端的比较多,接口层面的相对来说比较少一些,那就基本上是客户端测试,就不是服务端测试,然后测试中心有100多个人,然后涉及到一些交易呀,商品呐,大数据呀之类的相关的组。然后我问了一下会不会有一些专项?他说还是有很多专项的,你进来可能也跑不了的,然后一些AI测试啊什么的,自动化测试也有不少的相关的一些专项工作。然后我最后说如果觉得我还行的话,麻烦尽快推进吧,再不推进我就入职别的公司了。我对这家公司还是挺心仪的。
全部评论

一共50分钟
欢聚我有家人几年前在这家公司干过,好像加班也是很严重?
社招?

刚刚微信看了几篇文章,感觉这个业务前景非常一般啊,总共集团一年的营收是二十几亿美元,有个bigo业务直接占了十七八万美元,然后其他的业务大概两三亿,然后呢这个跨境电商建站还是其他业务里边儿的一个小业务,并且他的这个跨境电商建站的瓶颈明显,并且还有一个shopify与它竞争相当激烈。2021年他的CEO发展战略规划目标,是以电商为主,然后直播为辅,再加上一部分的广告收入,但是过了这3~5年已经他的发展依旧这么一般。感觉进了就是火坑了呀,有点儿难搞了。明天等着二面的时候,我问问这个负责人,看他有什么见解和看法。
哈哈哈我之前实习的部门
我之前面过实习,加油佬
哥还在战斗
这个面你肯定是通过了
薯哥加油
白薯哥打算去那了,欢聚嘛。
相关推荐

点赞 评论 收藏
分享


点赞 评论 收藏
分享
06-18 14:49
太原理工大学 后端 点赞 评论 收藏
分享
一笑而过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 工具自动迁移槽)。

点赞 评论 收藏
分享