- 博客(24)
- 收藏
- 关注
RSS订阅原创 万字长文之分库分表里如何优化分页查询？【后端面试题 | 中间件 | 数据库 | MySQL | 分库分表 | 分页查询】
首次查询，拿到最小值二次查询，确实最小值的全局偏移量在二次查询的结果里根据最小值取到符合偏移量的数据首先发送查询语句 LIMIT X OFFSETY/N到所有的表找到返回结果中的最小值（升序），记作min执行第二次查询，关键是BETWEEN min AND max，其中max是第一次查询的数据中每个表各自的最大值根据min、第一次查询和第二次查询的值来确定min的全局偏移量。总的来说，min在某个表里的偏移量这样计算：如果第二次查询比第一次查询多了K条数据，偏移量就是Y/N-K。
2024-07-16 22:36:42
739
原创 万字长文之分库分表里如何设计一个主键生成算法？【后端面试题 | 中间件 | 数据库 | MySQL | 分库分表】
大多数情况下，如果自己设计一个类似的算法，那么每个字段的含义、长度都可以灵活控制的，比如时间戳41比特可以改的更短或更长。机器ID虽然明面上是机器ID，但是实际上并不是指物理机器，准确说是算法实例。例如，一台机器部署两个进行，每个进行的ID是不同的；又或者进一步切割，机器ID前半部分表示机器，后半部分可以表示这个机器上用于产生ID的进程、协程或线程。甚至机器ID也并不一定非得表示机器，也可以引入一些特定的业务含义。而序列号也是可以考虑加长或缩短的。最后一句总结，升华主题。
2024-07-15 21:51:54
888
原创 【力扣 - 每日一题】3101. 交替子数组计数 | 朴素枚举 + 递推思想 + 优化空间 | Go
假设当前枚举到下标为i的元素，前面已经有now个符合条件的子数组，那么如果下标为i的元素和下标为i-1的元素不同，相当于以下标为i的元素结尾的符合条件的子数组一共有now+1个，其中+1是第i个单独元素的集合，这个时候now也要加1，因为这个元素对后面的元素也是有贡献的；如果下标为i的元素和下标为i-1的元素相同，相当于以下标为i的元素结尾的符合条件的子数组只有1个，即第i个单独元素的集合，这个时候now也要重新计数。以下子数组是交替子数组：[0] 、[1] 、[1] 、[1] 以及 [0,1]。
2024-07-06 19:04:02
883
原创 【后端面试题】【中间件】【NoSQL】MongoDB查询优化3（拆分、嵌入文档，操作系统）
很常见的一种优化手段，在一些特定的业务场景中，会有一些很大的文档，这些文档有很多字段，而且有一些特定的字段还特别的大。之前拆分过一个文档，非常庞大。而且在业务中，有一些庞大的字段根本用不上，在这种情况下，一次拆除了三个文档。这样做的优点很明显，比较多的业务查询，极少数会需要第二种文档；但是缺点也很明显，如果调用者，也就意味着需要查询三次，再合并组成一个业务上完整的文档。也可以升华一下：这种拆分终究是下策，最好还是在一开始使用MongoDB的时候就约束住文档的大小。
2024-07-06 18:29:44
1275
原创 【后端面试题】【中间件】【NoSQL】MongoDB查询优化2（优化排序、mongos优化）
在MongoDB里面，如果能够利用索引来排序的话，。如果不能利用索引来排序的话，就必须在加载了数据之后，再次进行排序，也就是进行内存排序。可想而知，如果内存排序，再叠加分页查询的话，性能会更差。比如你要查询，那么在最坏情况下，MongoDB要把所有的文件加载到内存里排序，然后找到从10000开始的100条数据优化的思路也类似MySQL。第一种是，可以考虑修改查询，也可以考虑修改索引。比如你可以新建索引。我还优化过一个分页查询。
2024-07-05 21:38:38
867
原创 【后端面试题】【中间件】【NoSQL】MongoDB查询过程、ESR规则、覆盖索引的优化
任何中间件的面试说到底都是以高可用、高性能和高并发为主，而高性能和高并发基本是同时存在的。性能优化一直被看作一个高级面试点，因为只有对原理了解得很透彻的人，在实践中才能找准性能优化的关键点，从而通过各种优化手段解决性能问题。
2024-07-04 21:00:25
986
原创 【后端面试题】【中间件】【NoSQL】MongoDB提高可用性的方案（主从结构、仲裁节点、分片、写入语义）
MongoDB的高可用和别的中间件的高可用方案基本类似。比如在MySQL里，接触了分库分表和主从同步；在Redis里，Redis也有主从结构；在Kafka里，分区也是有主从结构的。所以先介绍我们的系统有一个关键组件 - MongoDB，但是在最开始的时候，MongoDB没有启用主从，是一个单节点的。因此每年总会有一两次，MongoDB崩溃不可用。所以我把MongoDB改成了主从同步，最开始的时候业务量不多，为了节省成本，我们用了推荐的配置一主两从。
2024-07-03 20:36:55
1312
原创 【力扣 - 每日一题】3099. 哈沙德数 | 模拟 (Go/C++)
如果一个整数能够被其各个数位上的数字之和整除，则称之为 哈沙德数（Harshad number）。给你一个整数 x。如果 x 是 哈沙德数 ，则返回 x 各个数位上的数字之和，否则，返回 -1。输入： x = 18输出： 9解释：x 各个数位上的数字之和为 9。18 能被 9 整除。因此 18 是哈沙德数，答案是 9。输入： x = 23输出： -1解释：x 各个数位上的数字之和为 5。23 不能被 5 整除。因此 23 不是哈沙德数，答案是 -1。
2024-07-03 20:02:57
1004
原创 【力扣 - 每日一题】3115. 质数的最大距离（一次遍历、头尾遍历、空间换时间、埃式筛、欧拉筛、打表）Golang实现
考虑这样一件事情：对于任意一个大于 1 的正整数 n，那么它的 x 倍就是合数（x > 1）。如果我们从小到大考虑每个数，然后同时把当前这个数的所有（比自己大的）倍数记为合数，那么运行结束的时候没有被标记的数就是素数了。解释： nums[1]、nums[3] 和 nums[4] 是质数。的更新过程进行优化，含义为最大的质数出现的位置，所以倒序遍历找第一个质数即可。在思路1的基础上，考虑有的数如果重复出现的话，会被重复判断。极端情况下，最中间的数是质数，还是会把全部的数都判断一遍。
2024-07-02 21:56:09
749
原创 【后端面试题】【中间件】【NoSQL】MongoDB的配置服务器、复制机制、写入语义和面试准备
引入了分片机制之后，MongoDB启用了(config server) 来存储元数据，这些元数据包括，用来控制分布式锁。其中分片信息还会被负责执行查询mongos使用。MongoDB的配置服务器有一个很大的优点，就是。大多数中间件的主从结构都是在主节点崩溃之后完全不可用，直到选举出了一个新的主节点。但是不管怎么说，配置服务器在MongoDB里是一个非常关键的组件，如果一旦配置服务器有问题，哪怕只是轻微地性能抖动一下，对整个MongoDB集群的影响都很大。
2024-07-02 20:47:19
1202
原创 【后端面试题】【中间件】【NoSQL】MongoDB的优点和分片机制
MongoDB因其灵活的文档模型和自动化的横向扩展备受青睐。当数据模型易变或难以预估时，MongoDB优于传统关系型数据库。分片机制确保数据分布在多个分片上，每个分片含多个128MB的块。当块超过128MB或文档数超阈值时，块会被拆分。MongoDB自动平衡数据负载，当分片间数据不均时执行再平衡，通过moveChunk命令迁移块，保持数据均衡。再平衡触发阈值基于块数量，例如最大和最小分片间差值超过2块时开始。这个过程保证了数据的无缝迁移和集群的高效运行。
2024-07-01 21:03:52
720
原创 【DDIA笔记】第二章 数据模型和查询语言（数据模型、关系模型与文档模型）
基本考察点：数据基本元素和元素之间的对应关系（一对多、多对多）比较几种的常用模型：关系模型（最为流行），文档模型（树状），图模型（极大自由度）schema模式：强Schema（写时约束），弱Schema（读时解析）如何与数据模型关联、匹配声明式和命令式。
2024-06-29 22:17:51
991
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch的优化方案2（减少字段、冷热分离、参数优化）
一般性的性能优化方案可以做个总结优化查询本身：可能涉及到改写SQL、优化索引等优化中间件本身：调整中间件的各种参数优化操作系统：调整内存、网络IO和磁盘方面有关的参数。
2024-06-29 21:18:04
1144
原创 【Redis从入门到入土】管道传输Pipeline -- 批量操作处理必备
一般情况下，客户端和Redis通信的时候采用的是Ping-pong模式，即客户端发送命令后会等待服务端返回的命令执行的结果，在客户端收到服务端返回的结果后再发送下一个命令。而Pipeline模式类似流水线的模式：客户端发送一个命令后无需等待执行结果，会继续发送其他的命令。当所有的命令都发送完后，客户端关闭请求，开始接收响应，收到执行结果后再和之前发送的命令按顺序匹配。大部分客户端采用批处理的方式，即一次发送多个命令，等接收完所有命令执行结果后再返回。
2024-06-28 17:41:35
931
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch的优化方案1（分页查询、刷新间隔、批量提交）
ElasticSearch的三种优化方案，优化分页查询、增大刷新间隔和批量提交
2024-06-27 21:33:27
671
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch索引机制和高性能的面试思路
Elasticsearch的倒排索引机制、查找关键词的过程、高性能的面试思路
2024-06-26 21:16:54
1212
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch面试基本思路和高可用方案（限流、消息队列、协调节点、双集群）
首先介绍了面试准备中需要了解的相关问题。在高可用方案方面，文章提出了限流插件设计、消息队列削峰、降级策略和协调节点隔离等方案，以提高Elasticsearch的可用性
2024-06-25 21:08:12
910
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch 节点角色、写入数据过程、Translog和索引与分片
Elasticsearch利用Translog确保数据安全，类比MySQL的redo log，它在内存缓冲后记录Translog，每隔5秒持久化磁盘，提供高效且顺序的写入。尽管如此，仍可能最多丢失5秒数据。索引由分片组成，每个分片有主从结构，分布于不同节点以降低故障影响。当主分片失败，主节点会选择新主分片。面试中可讨论公司如何使用Elasticsearch、其性能、索引设计、可用性策略及解决过的挑战。常见问题涉及Elasticsearch的应用场景、问题解决及写入流程。
2024-06-24 20:55:54
1017
原创 【后端面试题】【中间件】【缓存】Redis的热Key问题
Redis中的热Key是高访问频率的Key，如QPS高、大带宽使用或CPU密集型操作。热Key可能导致CPU占用过高、访问倾斜、缓存击穿和系统性能下降。爆款商品、热点事件等可引发热Key。检测热Key可借助云服务、`redis-cli hotkeys`、业务层监控或`MONITOR`命令。优化策略包括复制热Key到多分片、采用读写分离，但需权衡代码复杂性和数据一致性。
2024-06-19 20:34:13
487
原创 【后端面试题】【中间件】【缓存】Redis的大Key问题
Redis大Key标准与影响 在不同场景下，大Key的定义不同，如string超1MB或容器超10K。大Key导致读取延迟高、带宽消耗大、操作阻塞及内存不均衡。常见原因包括业务设计不合理、未处理value增长和程序bug。找到大Key可借助云服务、`redis-cli --bigkeys`或Redis RDB Tools。优化策略包括业务设计避免大Key、拆分Key、更换存储方案、数据压缩、清理机制和异步删除。
2024-06-18 21:57:00
1299
原创 【设计模式】创建型设计模式之建造者模式（基本介绍、适用场景、go代码实例）
建造者模式是创建型设计模式，用于分离对象构造的步骤和其表示，允许构造多种表示。适用于构建过程复杂且部分可变的情况。关键角色包括产品、抽象建造者、具体建造者和导演。例如，汉堡套餐的组合。优点是灵活性高、隐藏构建细节，缺点是可能增加代码冗余。与工厂模式对比，更关注构建顺序。示例中展示了Go语言的建造者模式实现，用于创建`ResourcePoolConfig`，通过Builder进行参数校验和构建。
2024-06-17 20:38:11
409
原创 【设计模式】创建型设计模式之工厂模式（简单工厂、工厂方法、抽象工厂、go简单实例）
当创建逻辑比较复杂，是一个大工程的时候，考虑使用工厂模式，封装对象的创建过程，将对象的创建和使用分离。什么情况是创建逻辑比较复杂呢？类似规则配置解析的例子，代码里存在if-else判断，动态的根据不同的类型创建不同的对象。单个对象本身的创建过程比较复杂，比如要组合其他类对象，做各种初始化操作。对于情况1。
2024-06-12 21:27:19
1011
原创 【DDIA笔记】第一章 可靠性、可扩展性和可维护性
数据系统是一种模糊的统称，在信息社会中，一切皆可信息化，或者，某种程度上来说–数字化。这些数据的采集、存储和使用，是构成信息社会的基础。因此作为IT从业人员，有必要系统性地了解一下现代的、分布式地数据系统。学习本书，能够学习到数据系统地背后的原理、了解其常见的实践，进而将其应用到我们工作的系统设计中。
2024-06-05 21:32:51
811
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人