LightOfNight的博客

如何实现分布式任务调度，Redis实现分布式锁，MySQL实现任务调度，或是借助开源框架xxl-job等，注意负载均衡

限流是通过限制住流量大小来保护系统，能够。例如常见的某个攻击者在攻击你维护的系统，那么限流就是极大程度上保护住你的系统。

比如双十一之类的大促高峰，平台是会关闭一些服务的，比如退款服务。这就是降级的典型应用，不过它是一种手动的跨服务降级，对于整个系统来说，提供了一部分服务，但是没有提供另外一部分服务，在整个系统层面上是降级的。好处有两个，一方面是腾出了服务器资源，可以给订单服务或支付服务；另外一方面是减少了对公共组件的压力，比如减少了对数据库的写入压力。如果仅仅是针对退款服务而言，也可以认为是退款服务整个熔断了。

熔断在微服务架构里面是指当前微服务本身出现问题时，会拒绝新的请求，直到微服务恢复熔断给了服务端恢复的机会，比如如果CPU使用率已经100%了，服务端因此触发了熔断，那么拒绝了新的请求之后，服务端的CPU使用率就会在一段时间内降到100%以内。提炼出两个点进行讨论。

在MySQL里面，允许用户开启查询缓存。你可以理解这个缓存就是用SQL作为键，而对应的查询结果集就是值。如果下次过来的还是同一个查询，那么就直接返回缓存起来的查询结果集。但是查询缓存不一定带来查询性能提升。如果你的查询每一次对应的SQL都不一样，那么查询缓存反而会降低性能。在实践中查询缓存的效果的确不怎么好。按照设计者的想法，查询缓存的最佳使用场景是一些特别复杂的查询，他们会扫描很多行，但是只有一小部分行满足条件。所以MySQL在8.0的时候移除了这个功能。

重点：两阶段提交协议、三阶段提交协议和XA协议的基本步骤跨服务的分布式事务：TCC、SAGA、AT容错基本就是重试监控+告警+人工介入处理读数据+数据修复监控+告警+故障自动处理单纯的分库分表跨表事务，可以考虑延迟事务。

修复的时候就只能以主库数据为准。也就是说，通过先写目标表，再写源表这种方式，万一发现数据迁移出现了问题，还可以回滚为先写源表，再写目标表，确保业务没有问题。正常来说，批量插入如果使用的是VALUES语法，那么生成的主键是连续的，可以从返回的最后一个主键推测出前面其他行的主键。我们采用的方案是利用更新时间戳找出最近更新过的记录，然后再去目标表里面找到对应的数据，如果两者不相等，就用源表的数据去修复目标表的数据。还有如果你是导出的数据，那么导出数据到你导入数据的这段时间，数据发生了变化，目标表依旧是没有的。

实际上和Read View相关的概念还有三个指的是m_ids中的最小值指的是下一个分配的事务ID当前事务IDm_up_limit_id 在左边，而 m_low_limit_id 在右边。

遇事不决临键锁：可以认为，全部都是加临键锁的，除了下面两个子句提到的例外情况右边缺省间隙锁：例如你的值只有(1,4,7)三个，但是你查询的条件是where id < 5，那么加的是间隙锁，因为7本身就不在查询范围里。等值查询记录锁：针对的是主键和唯一索引，不适用于普通索引。

大部分数据库都支持分区表，以MySQL为例介绍分区表的主要特性：在MySQL里，分区表是表的底层组织方式，简单来说，就是把一张表分成几块，每一块存储在磁盘的一个地方，一块也叫做一个分区。比如典型的按月分区，是指每个月产生的数据在一个独立的区域，数据库可以单独处理某一块，也可以多块一起处理。分区表的优点和缺点如下：优点一些和时间有明显关系的业务场景，按照时间来进行分区要比直接使用分库分表更加简单高效大厂在容量规划时都是按照2的幂来规划的，比如428，或是8432，而且扩容的时候，也是按照2的幂进行的，基本

在很多业务里，分库分表键都是根据主要查询筛选出来的，那么不怎么重要的查询怎么解决呢？比如？或是买家找客服，客服要找到对应的订单，又该怎么找？

首次查询，拿到最小值二次查询，确实最小值的全局偏移量在二次查询的结果里根据最小值取到符合偏移量的数据首先发送查询语句 LIMIT X OFFSETY/N到所有的表找到返回结果中的最小值（升序），记作min执行第二次查询，关键是BETWEEN min AND max，其中max是第一次查询的数据中每个表各自的最大值根据min、第一次查询和第二次查询的值来确定min的全局偏移量。总的来说，min在某个表里的偏移量这样计算：如果第二次查询比第一次查询多了K条数据，偏移量就是Y/N-K。

大多数情况下，如果自己设计一个类似的算法，那么每个字段的含义、长度都可以灵活控制的，比如时间戳41比特可以改的更短或更长。机器ID虽然明面上是机器ID，但是实际上并不是指物理机器，准确说是算法实例。例如，一台机器部署两个进行，每个进行的ID是不同的；又或者进一步切割，机器ID前半部分表示机器，后半部分可以表示这个机器上用于产生ID的进程、协程或线程。甚至机器ID也并不一定非得表示机器，也可以引入一些特定的业务含义。而序列号也是可以考虑加长或缩短的。最后一句总结，升华主题。

很常见的一种优化手段，在一些特定的业务场景中，会有一些很大的文档，这些文档有很多字段，而且有一些特定的字段还特别的大。之前拆分过一个文档，非常庞大。而且在业务中，有一些庞大的字段根本用不上，在这种情况下，一次拆除了三个文档。这样做的优点很明显，比较多的业务查询，极少数会需要第二种文档；但是缺点也很明显，如果调用者，也就意味着需要查询三次，再合并组成一个业务上完整的文档。也可以升华一下：这种拆分终究是下策，最好还是在一开始使用MongoDB的时候就约束住文档的大小。

在MongoDB里面，如果能够利用索引来排序的话，。如果不能利用索引来排序的话，就必须在加载了数据之后，再次进行排序，也就是进行内存排序。可想而知，如果内存排序，再叠加分页查询的话，性能会更差。比如你要查询，那么在最坏情况下，MongoDB要把所有的文件加载到内存里排序，然后找到从10000开始的100条数据优化的思路也类似MySQL。第一种是，可以考虑修改查询，也可以考虑修改索引。比如你可以新建索引。我还优化过一个分页查询。

任何中间件的面试说到底都是以高可用、高性能和高并发为主，而高性能和高并发基本是同时存在的。性能优化一直被看作一个高级面试点，因为只有对原理了解得很透彻的人，在实践中才能找准性能优化的关键点，从而通过各种优化手段解决性能问题。

MongoDB的高可用和别的中间件的高可用方案基本类似。比如在MySQL里，接触了分库分表和主从同步；在Redis里，Redis也有主从结构；在Kafka里，分区也是有主从结构的。所以先介绍我们的系统有一个关键组件 - MongoDB，但是在最开始的时候，MongoDB没有启用主从，是一个单节点的。因此每年总会有一两次，MongoDB崩溃不可用。所以我把MongoDB改成了主从同步，最开始的时候业务量不多，为了节省成本，我们用了推荐的配置一主两从。

引入了分片机制之后，MongoDB启用了(config server) 来存储元数据，这些元数据包括，用来控制分布式锁。其中分片信息还会被负责执行查询mongos使用。MongoDB的配置服务器有一个很大的优点，就是。大多数中间件的主从结构都是在主节点崩溃之后完全不可用，直到选举出了一个新的主节点。但是不管怎么说，配置服务器在MongoDB里是一个非常关键的组件，如果一旦配置服务器有问题，哪怕只是轻微地性能抖动一下，对整个MongoDB集群的影响都很大。

MongoDB因其灵活的文档模型和自动化的横向扩展备受青睐。当数据模型易变或难以预估时，MongoDB优于传统关系型数据库。分片机制确保数据分布在多个分片上，每个分片含多个128MB的块。当块超过128MB或文档数超阈值时，块会被拆分。MongoDB自动平衡数据负载，当分片间数据不均时执行再平衡，通过moveChunk命令迁移块，保持数据均衡。再平衡触发阈值基于块数量，例如最大和最小分片间差值超过2块时开始。这个过程保证了数据的无缝迁移和集群的高效运行。

一般性的性能优化方案可以做个总结优化查询本身：可能涉及到改写SQL、优化索引等优化中间件本身：调整中间件的各种参数优化操作系统：调整内存、网络IO和磁盘方面有关的参数。

ElasticSearch的三种优化方案，优化分页查询、增大刷新间隔和批量提交

Elasticsearch的倒排索引机制、查找关键词的过程、高性能的面试思路

首先介绍了面试准备中需要了解的相关问题。在高可用方案方面，文章提出了限流插件设计、消息队列削峰、降级策略和协调节点隔离等方案，以提高Elasticsearch的可用性

Elasticsearch利用Translog确保数据安全，类比MySQL的redo log，它在内存缓冲后记录Translog，每隔5秒持久化磁盘，提供高效且顺序的写入。尽管如此，仍可能最多丢失5秒数据。索引由分片组成，每个分片有主从结构，分布于不同节点以降低故障影响。当主分片失败，主节点会选择新主分片。面试中可讨论公司如何使用Elasticsearch、其性能、索引设计、可用性策略及解决过的挑战。常见问题涉及Elasticsearch的应用场景、问题解决及写入流程。

Redis中的热Key是高访问频率的Key，如QPS高、大带宽使用或CPU密集型操作。热Key可能导致CPU占用过高、访问倾斜、缓存击穿和系统性能下降。爆款商品、热点事件等可引发热Key。检测热Key可借助云服务、`redis-cli hotkeys`、业务层监控或`MONITOR`命令。优化策略包括复制热Key到多分片、采用读写分离，但需权衡代码复杂性和数据一致性。

Redis大Key标准与影响 在不同场景下，大Key的定义不同，如string超1MB或容器超10K。大Key导致读取延迟高、带宽消耗大、操作阻塞及内存不均衡。常见原因包括业务设计不合理、未处理value增长和程序bug。找到大Key可借助云服务、`redis-cli --bigkeys`或Redis RDB Tools。优化策略包括业务设计避免大Key、拆分Key、更换存储方案、数据压缩、清理机制和异步删除。