一、线上几百万的消息积压如何处理？

1、第一步我们要首先确定是什么导致的消息积压，基本上三个原因

•   消费者处理消息速度慢；
•   生产者生产消息速度太快；
•   消息处理流程异常导致大量重试；

       线上消息积压第一步先看日志，是否在消费端出现了系统异常，系统异常有可能是磁盘满了，挂载盘故障了，网络不稳定或者有黑客入侵植入了其他程序侵占了系统资源等等。

       系统异常排除，就通过日志查看是否存在业务异常，是否有大量的报错信息，如果存在那么应该是代码的问题，此时就要快速修复问题，然后上线。

       如果不是代码的问题，那么就要考虑当前消费线程的执行时间是否过长，每次消费的时间太长也会造成消息的积压，通过各种工具可以检测到消费的时长，如果很长那么也需要优化代码。

       优化代码毕竟需要时间，此时就需要临时增加消费端的实例数量，或者暂时关闭或者降级生产者的部分功能（比如暂停批量导入，定时同步等），同时时刻关注积压消息的数量。

       最后在有能力或者有可能得情况下，通过调整MQ的参数来提升性能，当然对于很多公司是直接使用的云服务的情况下，可以不考虑这块儿。

二、如何不停机进行数据的迁移？

       这里有两个要求，一个是数据迁移，另一个是不停机。这里我们假设是从A库迁移到B库。

       1、应该设定一个时间节点，比如2024年1月1日，先把这个事件点之前的数据全部通过数据迁移的方式迁移到B库中。

      2、要不停机，就必须有一段时间是双写，在2024年1月1日以后的，就要设置双写逻辑，新写入的数据在A、B两个库进行双写。

       3、此时再启动一个程序做数据对比和同步的工作，就是把A库和B库的每条数据进行比对，并对B库进行更新。

       4、稳定运行一段时间后，先把读请求切换到新库中，最后把写请求也切换到新库中。

三、大量数据批量过期通知

       这类问题一般是比如我有200万的注册用户，或者会员用户，到期时间不同，那么如何设计能提前一天通知用户会员到期了呢？

       这里要区分是一个点，如果是每天零点通知一次，那么可以通过定时任务轮询的方式，把今天要到期的用户都查出来，然后统一发送邮件或者短信等等；

      如果不是定时推送，而是根据过期时间推送，这就变成了延时任务的实现，一般可以使用redis的键过期监听或者rocketmq的延时任务来实现。

四、在2G大小的文件中，快速找出高频Top100的单词

        2G大小的文件如果一次性加载到内存中，估计面试就可以回家等通知了。我们必须要使用分治法。

        所以第一步一定是分割，分割成多少呢，不用太纠结，1MB，512K都可以。比如1MB，那么2GB的文件就会被分割成2048个小文件。

        分割之后，第二步就是统计，统计每个文件中，每个单词的出现的次数。这里可以使用一个2048大小的hash数组。数组的每一个index对应其中一个文件。

        最后一步就是提取，只要是什么top100，top100，我们就采用堆这个数据类型，用容量为100的小顶堆。

        具体代码可以参考下面这篇文章：

在 2G 大小的文件中，找出高频 top100 的单词_统计100个高频单词的代码、-CSDN博客

五、对接第三方接口需要注意什么？

        这个问题就比较灵活了，但是一般可以从如下几个方面来表达。

        1、安全性问题：接口是https的吗？是否有比如sign校验，或者数据加密等操作。

        2、稳定性问题：接口是否稳定，可承受的最大并发是多少。

        3、经济性问题：接口调用一次多少钱，有没有最大调用限制。

六、单表数据量大的时候，影响查询效率的都有哪些？

         1、磁盘IO，使用

         2、索引失效，有坑你是

         3、数据分页，数据分页要占用大量的CPU资源

         4、锁竞争，同时读写操作，会产生

         5、数量大就要更大的内存来缓存

七、如何考虑分库分表？

        首先这个问题应该问的是mysql，如果是oracle，单库oracle的单表存储一亿条数据，在做好了分区的情况下，查询的性能也是可以保障的。

      什么情况下需要分库分表

        1、在分布式的场景下，使用微服务构建的后台系统，在有条件的情况可以先分库，尽量在业务逻辑拆分的情况下，数据库也是拆分的。这样单个微服务在上线维护的时候很便利不会影响到其他的微服务；

         2、影响数据库性能的主要有几个方面：

         一个是网络IO，当请求量很大，单个数据库无法招架的时候，不管你数据量级是多少，哪怕就几万的数据也得考虑分库；

         第二就是数据量级，阿里的数据专家建议单表的存储不要超过500万条，这里是基于数据库的性能，查询的优化和索引的性能，还有数据备份与恢复的总和考量得出的，我们可以根据自身的系统情况定一个标准，超过了数据量级就需要考虑分表；

         3、能不切分尽量不要切分

         在很多的场景下， 只需要做读写分离就可以满足大部分的需求了，不需要一开始就进行分库分表的操作，第一提升了业务的复杂度和维度的难度，第二还增加了硬件的开销。

      分表方式

         根据上一个问题的回答，我们可以总结出分表的几种方式

        1、垂直分表：这主要是考虑到单行字段过多或者单字段存储过大，比如存在blob字段，大文本字段，甚至有些二进制字段等等，此时可以对单表的字段进行拆分，将一张表拆分成主表，副表，副表2等，大部分的查询只需要针对主表即可；

        2、水平拆分：这就主要是考虑单表的性能，一般出现在单表数据量超过百万的情况下。此时就要按记录（行）分成多张表，分完后结构仍相同。水平拆分有一定的拆分规则，常见的规则如下：

        a、主键自增分表，前100万条放在表1，每增加100万条数据就增加一张表，这主要适用于类似日志的查询，或者只需要查询近一个月数据这样的场景；

        b、主键取模分表，这就是完全的离散分表，如果分成两个表，那么每个表的主键自增步长都设置为2，这种分表模式也是常见的分表，主要是为了应对大数据量的查询，可以把查询压力分散到不同的表中（或者库中）。

       c、按业务模型分表，比如电商经常会根据user_id来进行分表，这有一个好处，就是对同一个用户的查询永远是单表查询。但是也会造成数据表的数据不平衡，因为很有可能某些用户下单量大，某些用户下单量小。

       d、按时间分表：这种也常见，对于某些日志的存储，业务上就需要按照月份进行统计或者查询，那么按照时间分表就很适合。

    分库分表引发的问题  

问题	问题描述	解决方法
事务一致性	跨库、表的分布式事务问题比如数据库拆分后，订单和库存在两个库中，一个下单减库存的操作，就涉及跨库事务。	分布式事务中间件，实现 TCC 等事务模型；也可以使用基于本地消息表的分布式事务实现。
跨节点关联查询、分页、排序函数等	查询的数据存在于多表、多库之间，SQL无法正常执行	1）利用中间件比如Mycat、ShardingSphere 2)  把关联数据放在同一个库中，避免夸库查询 3）把需要夸库查询的数据塞入ES中
主键避重	分布式id问题	uuid、雪花算法、数据库维护区间分配等

    分库分表中间件

分库分表中间件	优点	缺点	性质
mycat	独立部署，使用不需要修改代码；性能高，JDBC 直连数据库，无需二次转发	配置比较复杂，分布式事务还需要做一些配置	代理模式
Sharding-JDBC	化分库分表之后数据相关操作，它一个轻量级的Java框架，是增强版的JDBC驱动，以jar包的形式提供引入非常简单，适用于很多ORM框架以及数据库连接池	嵌入式，要修改代码； 仅支持java	jar包，JDBC层
ShardingSphere	由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar 这三款相互独立的产品组成	支持多种语言	代理模式、JDBC层

        蘑菇街的TSharding、携程开源的Ctrip-DAL和Sharding-JDBC相似，都是对JDBC驱动的扩展，就不单独列出来了。