2021-06-20问题整理

答疑一：

1. 场景问题：公司目前是单库单表，有一个大表，数据量非常大，日后考虑ES集群的方式来解决可能面临的性能问题，这种设计是否合理？

详细内容

现在公司里有个大表是单库单表，询问项目负责人为什么不拆表，说是数据太大，且数据实时性要求很高，运维尝试主从结构，主从之间的同步速度赶不上要求，于是就是一直单表。然后后续的方案可能设计是es集群，想问一下作为这种设计是否合理？

答： 如果设计成ES的话，那么有一个问题，当数据从数据库同步到ES是有有实时性问题呢？如果存Mysql的主从数据同步都是有延迟的话，那么从数据库同步到ES同样会面临延迟问题，所以这种场景下，不一定要分库，如果需要实时性的话，可以分表。分表的好处是我们即可以保证事务（因为是在同一个数据库里面），同时又可以将一张大表拆成小表。

所以如果数据量大了之后，分库并不是绝佳选择哈。分库之后会有很多新的问题，事务问题、查询聚合的问题等。可以考虑先进行数据的归档，数据的归档可以根据业务场景，比如说啊，有些数据是有状态的，比如说已完成的数据，这部分其实可以直接删除了，或者说是弄到另外一张表里面去，减少数据量。

 

2. redis热key如何提前发现？生产环境出现热key的时候，如何快速处理，有什么解决方案？（面试常见）

答： Redis热Key其实和类似秒杀场景息息相关，应对秒杀/热Key最直接解决方式就是使用本地缓存，在Java里边比较多框架就是guava cache（老牌）、caffeine（流行），在我们每一次查询（数据库、Redis）之后，就将查询结果放到本地缓存里边去，同时需要给本地缓存设置一个过期时间以及容量大小，这样的话，如果说它是热Key（因为有过期时间、容量大小），那么它一定会在本地缓存中，我们就可以识别发现热Key了。

这种方式也会伴随一个问题，就是当每一个数据都放到本地缓存中，那么放入本地缓存中的并不是只有热Key，还会有其他数据，这就会导致延迟的问题，可能在分布式情况下，数据库数据已经变更了，而该服务的本地缓存还未变更。

彻底解决上面的方式是对Redis进行一定的改造（在大点的公司是有中间件团队），将Redis的前置命令处理器加一个插件，这个插件主要的作用就是计数的，当我们每次客户端去访问Redis的时候，都会经过这个插件（类似于MVC中的拦截器）并计数，这个时候设置一个阈值，比如当某个Key一秒内访问一万次或者十万次，就将它标记为热key。客户端和Redis建立连接之后，它们之间是有一个长链接通道的，当某个Key被标记为热Key后，经由这个长链接通道进行一个消息的下发，客户端收到消息后将这个热Key在本地进行一个缓存，然后当下一个对这个热Key的请求到来的时候会先在本地缓存进行一个获取，这样子就可以挡住这种热点key了，因为本地缓存（guava、caffeine）是和应用服务器是在一起的，这样有多少台应用服务器就有多少台本地缓存，也相当于做了一个水平扩展的功能。

文档阅读：https://zhuanlan.zhihu.com/p/349926734、https://www.jianshu.com/p/9a80c662dac4

 

3. TCP经过三次握手后建立了连接，然后其中一端因为某种不可控的原因物理断开了，另一端连接会一直保持么？以什么样的方式断开连接？

详细内容：

正常情况tcp连接要经历三次握手和四次挥手，假设连接在三次握手建立之后(A->B)，B主机突然因为某种原因宕机，A主机连接会一直保留嘛？连接会以什么样的方式结束？除了四次挥手，tcp有哪几种断开方式？

答： 首先强调一下，TCP是全双工的，也就是说客户端可以给服务端发消息，服务端可以给客户端发消息，相当于有两条通道，所以TCP四次挥手相当于客户端和服务端分别发送一个发起断开以及收到确认断开的流程。

书中关于这个场景的解答：TCP设有一个 保活计时器，假设上面的场景发生，客户端物理断开，服务端显然不能再接收到客户发来的数据了，因此也不可能让服务端一直等待下去，这时候就需要使用保活计时器了，服务器每次接收到客服的请求就会重置这个保活计时器，并将这个计时器设置为两个小时（可配置项），若两小时未收到客户的数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次，若一连发送10个探测报文段后仍未收到客户的响应，则服务器就认为客户端发生了故障，虽然单方面断开这个连接。

一般情况下关于上面的一些值，如计时器超时时间、探测次数、探测间隔都是可以通过对操作系统的配置进行动态设置的，在实际项目中应该是有一个系统管理员根据实际网络进行一个配置。这个TCP的超时策略和处理机制和RPC的超时重传是非常相似的，都是可以配置的。在这里需要找到一个关键点就是，他们的相似点，那么就是关于超时策略中的定时器和监测机制，是肯定有的，并且一定是可配置的，这里才是重点，也是解决超时问题的解决方案。

模拟方案： 类似于上面的问题&#