腾讯云一面（处男面）面经

上来先手撕lru , si完问优化
● 1. 如何实现一个lockfree 的并发控制的缓存
  ○ 问ringbuffer的优点?  无锁并发
● 2. lru结合lfu 实现兼顾折中, 结合优点的算法实现

● 也可以使用结构体记录, 在数据存储基本单元上
● 面试官给的思路: 设计多个lruclass, 或者多个队列, hot, warm, cold 队列
  ○ 访问频率高的就放入hot里边( 比如多少次以上评价为高
  ○ 那么可以使用结构体, 记录每一个访问的次数
  ○ 那如何解决这个过期呢? 还能设计一个过期时间, 每次要检索这个数据的时候, 获取这个过期时间,看是否过期, 过期就直接丢掉,  不能访问了

● 另一个思路 :  整体还是按照lru来，替换之前检查一下，前三个即将被替换的里面选择频率最低的删除，但是每个最多连续比较三次（我瞎说的）
  ○ 避免某些短时间频繁访问的节点被删除
    ■ 防止抖动现象产生

布隆过滤器+ redis bitmap 的原理

● 自己的思路, 使用一个散列函数, 根据你当前的访问频率(设计一个struct node ), 去决定你随机的在list里边的插入位置
  ○ 如果频率比较高, 就将其在get 的时候放到靠近队头的位置
  ○ 频率比较低, 将其get 的时候放在队尾的位置(反正你短期大量访问, 后续频率上来了也会逐渐的放到队头的
  ○ 并且反正插入和查询都是O1
    ■ 如果是伪高频,  插入位置比较低, 后续也会直接被淘汰, 说明你根本不是真正的短期热数据
● 如果再问频率优化?
  ○ CMS, caffeine 的本地淘汰策略算法
● lru和lfu 的区别, lfu适合短期高频, 而lfu适合长期高频数据

paxos和raft 的区别
● paxos 对比raft 的优点?
● raft 为啥容易实现? 和paxos对比? 不允许空洞->强leader->容易实现
● 选主的时候有没有可能设计一个方案, 无锁选主?
  ○ 1. 回答哨兵机制, 交给另一个集群哨兵去做选举这件事( 从而让数据节点专心做数据
  ○ 2. 问其他思路, 我说不锁不行, 不锁的话可能导致选票许诺给多个人->整个集群的逻辑总票数增加 -> 脑裂问题

均摊分析, 插入1e数据 ,扩容因子为4的 hash插入的复杂度( 不会

● 两阶段提交的缺点
  ○ 全局阻塞, io次数多( 根据mysql 的两阶段提交谈了谈, 三级队列优化思路
  ○ 没有事先通知参与者, 不知道他可不可达, 宕机没就直接提交了( 浪费网络带宽
  ○ 协调者比重太大,  一旦故障, 其他参与者也会跟着阻塞
  ○ 可能导致的数据库不一致, 比如commit阶段 ,参与者并没有收到提交请求, 导致落后 ( 可以引入mq解决消息消费问题
    ■ 回答数据同步机制, 结合项目增量和全量, 以及mysql 的集群组提交策略(半数以上
● 解决,引入tcc,  不过侵入性较大, 并且实际效率也不一定高 (

腾讯云一面（处男面）面经

全站热榜

创作者周榜