美团后台一面面经

缓存相关也做了个大概总结,分享一下吧,从网上看得资料 解决缓存的相关问题 a.缓存穿透的问题: 解决方案: 1.布隆过滤器 把所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉 2.如果一个查询返回的数据是空的,无论数据是否存在,还是系统故障,我们仍然将这个空结果进行缓存,但设置很短的过期时间 b.缓存雪崩的问题: 设置缓存的时候采用了相同的过期时间,导致缓存在同一时刻失效,请求全部转发到db,db压力瞬间变大雪崩。 解决方案 1.用加锁或者队列的方式保证缓存的单线程写,避免失效时大量的并发请求落到底层的存储系统上 2.将缓存的失效时间分散开,在原来失效时间的基础上加上一个随机值,比如说1-5分钟的随机,这样每一个缓存过期时间的重复率就会降低,很难引起集体失效的事件。 c.缓存击穿的问题。对于一些设置了过期时间的key,这些key某些时间点被超高并发地访问,是非常热点的数据,缓存在某个时间点过期的时候,恰好这个时间节点对这个key有大量的并发请求过来,这些请求发现缓存的key过期就一般都会从后端数据库请求数据并且设置到缓存,大的并发请求就可能会压垮后端db 解决方案 1.使用互斥锁(mutex) , 在缓存失效的时候,判断拿出来的值为空,不立即去load db,而是先使用缓存工具的某些带有返回值的操作(比如说redis的setnx),去set一个mutex key,当操作返回成功的时候,在进行load db的操作并且设置回缓存,否则,就重试整个get缓存的方法。 String get(String key){     String value = reids.get(key);     if(value == null){         if(redis.setnx(key_mutex,"1")){             reids.expire(key_mutex,3*60);             value = db.get(key);             redis.set(key,value);             redis.delete(key_mutex);         }else{             //其他线程休息50ms后重试             Thread.sleep(50);             get(key);         }     } } 2.设置热点数据永不过期 a.从redis上来看,确实不设置过期时间,保证不会出现热点key过期的问题,也就是物理上的不过期 b.从功能上看,我们把过期时间存在key对应的value里面,如果发现要过期了,通过一个后台的异步线程进行缓存的构建,设置"逻辑"过期时间 String get(final String key){     V v = redis.get(key);     String value = v.getValue();     long timeout = v.getTimeout();     if(v.timeout <= System.currentTimeMillis()){         //异步更新后台异常执行         threadPool.execute(new Runnable(){             public void run(){                 String keyMutex = "mutex:"+key;                 if(redis.setnx(keyMutex,"1")){                     //设置三分钟的超时                     redis.expire(keyMutex,3*60);                     String dbValue = db.get(key);                     redis.set(key,dbValue);                     redis.delete(keyMutex);                 }             }            });     }   } 3.提前使用互斥锁 在value内部设置一个超时值(timeout1),timeout1比实际的mem*** timeout(timeout2)小,当从***读取到timeout1发现它已经过期的时候,马上延长timeout1并重新设置到***。然后再从数据库加载数据并且设置到***中 v = mem***.get(key); if(v==null){     if(mem***.add(key_mutex,3*60*1000) == true){         value = db.get(key);         mem***.set(key,value);         mem***.delete(key_mutex);     }else{         sleep(50);         retry();     }else{         if(v.timeout <= now()){             if(mem***.add(key_mutex,3*60*1000) == true){                 v.timeout += 3*60*1000;                 mem***.set(key,v,KEY_TIMEOUT*2);                                  //从数据库加载最新的数据                 v = db.get(key);                 v.timeout = KEY_TIMEOUT;                 mem***.set(key,value,KEY_TIMEOUT*2);                 mem***.delete(key_mutex);             }else{                 sleep(50);                 retry();             }         }     } }

学习帖,有关time_wait的一些总结 服务器端出现大量的TIME_WAIT连接的原因 TIME_WAIT是主动关闭连接的一方保持的状态,在发起主动关闭连接后,发送完最后一次ACK包之后,就会进入到这个状态,然后在保持这个状态2MSL(max segment lifetime) 时间之后,彻底关闭回收资源。 为什么要保持这一段时间的资源呢?原因有下面两个方面 防止上一次连接中的包,迷路后再次出现,影响新的连接(经过2msl,上一次连接的所有的重复包都会消失) 可靠的关闭tcp连接。在主动关闭方发送最后一个ack(fin)是有可能丢失的,这个时候被动方会重新发送fin,这个时候如果主动方处于CLOSED状态,就会响应rst而不是ack。所以主动方要处于TIME_WAIT状态而不是CLOSED。另外这么设计TIME_WAIT会定时的回收资源,并不会占用很大资源的,除非短时间内接受大量请求或者受到攻击。 解决思路:快速回收和重新用哪些TIME_WAIT的资源 应用层面: 避免频繁关闭连接,如业务优化或者使用长连接等. 系统层面: 1.缩短msl时间 2.增加可用端口的数量 msl时间修改: 默认为2分钟 查看：sysctl -a | grep time | grep wait vi /etc/sysctl.conf net.ipv4.tcp_fin_timeout = 30 执行 /sbin/sysctl -p让参数生效 进行一些参数的配置 net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。 net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。 net.ipv4.tcp_keepalive_*一系列参数，是用来设置服务器检测连接存活的相关配置。 我看的文章链接 https://zhuanlan.zhihu.com/p/60382685 https://zhuanlan.zhihu.com/p/45102654

楼主约二面了吗

第8题怎么分析的呀

哪个大佬知道 close_wait 的具体作用 求私聊

卧槽

面了多久啊?

蛮全面的...有些也不好答

请问16.17怎么回答

楼主前几天做过笔试吗

现场面的吗