- 博客(34)
- 收藏
- 关注
RSS订阅原创 一文搞懂微服务架构之限流
限流是通过限制住流量大小来保护系统，能够。例如常见的某个攻击者在攻击你维护的系统，那么限流就是极大程度上保护住你的系统。
2024-09-03 20:55:22
956
原创 一文搞懂微服务架构之降级
比如双十一之类的大促高峰，平台是会关闭一些服务的，比如退款服务。这就是降级的典型应用，不过它是一种手动的跨服务降级，对于整个系统来说，提供了一部分服务，但是没有提供另外一部分服务，在整个系统层面上是降级的。好处有两个，一方面是腾出了服务器资源，可以给订单服务或支付服务；另外一方面是减少了对公共组件的压力，比如减少了对数据库的写入压力。如果仅仅是针对退款服务而言，也可以认为是退款服务整个熔断了。
2024-08-22 21:10:16
1142
原创 一文搞懂微服务架构之熔断
熔断在微服务架构里面是指当前微服务本身出现问题时，会拒绝新的请求，直到微服务恢复熔断给了服务端恢复的机会，比如如果CPU使用率已经100%了，服务端因此触发了熔断，那么拒绝了新的请求之后，服务端的CPU使用率就会在一段时间内降到100%以内。提炼出两个点进行讨论。
2024-08-21 21:31:25
918
原创 一文搞懂后端面试之数据库综合应用【中间件 | 数据库 | MySQL | 高可用 | 高性能】
在MySQL里面，允许用户开启查询缓存。你可以理解这个缓存就是用SQL作为键，而对应的查询结果集就是值。如果下次过来的还是同一个查询，那么就直接返回缓存起来的查询结果集。但是查询缓存不一定带来查询性能提升。如果你的查询每一次对应的SQL都不一样，那么查询缓存反而会降低性能。在实践中查询缓存的效果的确不怎么好。按照设计者的想法，查询缓存的最佳使用场景是一些特别复杂的查询，他们会扫描很多行，但是只有一小部分行满足条件。所以MySQL在8.0的时候移除了这个功能。
2024-08-15 21:24:27
1093
原创 一文搞懂后端面试之数据库分布式事务【中间件 | 数据库 | MySQL | ACID】
重点：两阶段提交协议、三阶段提交协议和XA协议的基本步骤跨服务的分布式事务：TCC、SAGA、AT容错基本就是重试监控+告警+人工介入处理读数据+数据修复监控+告警+故障自动处理单纯的分库分表跨表事务，可以考虑延迟事务。
2024-08-12 21:13:27
985
原创 一文搞懂后端面试之不停机数据迁移【中间件 | 数据库 | MySQL | 数据一致性】
修复的时候就只能以主库数据为准。也就是说，通过先写目标表，再写源表这种方式，万一发现数据迁移出现了问题，还可以回滚为先写源表，再写目标表，确保业务没有问题。正常来说，批量插入如果使用的是VALUES语法，那么生成的主键是连续的，可以从返回的最后一个主键推测出前面其他行的主键。我们采用的方案是利用更新时间戳找出最近更新过的记录，然后再去目标表里面找到对应的数据，如果两者不相等，就用源表的数据去修复目标表的数据。还有如果你是导出的数据，那么导出数据到你导入数据的这段时间，数据发生了变化，目标表依旧是没有的。
2024-08-11 15:05:37
1082
原创 一文搞懂后端面试之MySQL MVCC【中间件 | 数据库 | MySQL | 隔离级别 | Read View】
实际上和Read View相关的概念还有三个指的是m_ids中的最小值指的是下一个分配的事务ID当前事务IDm_up_limit_id 在左边，而 m_low_limit_id 在右边。
2024-08-06 21:06:37
1162
原创 一文搞懂后端面试之数据库MySQL的各种锁以及锁优化【中间件 | 数据库 | MySQL | 锁机制】
遇事不决临键锁：可以认为，全部都是加临键锁的，除了下面两个子句提到的例外情况右边缺省间隙锁：例如你的值只有(1,4,7)三个，但是你查询的条件是where id < 5，那么加的是间隙锁，因为7本身就不在查询范围里。等值查询记录锁：针对的是主键和唯一索引，不适用于普通索引。
2024-08-03 20:18:56
774
原创 一文搞懂后端面试之分库分表如何预估容量【中间件 | 数据库 | MySQL | 分库分表】
大部分数据库都支持分区表，以MySQL为例介绍分区表的主要特性：在MySQL里，分区表是表的底层组织方式，简单来说，就是把一张表分成几块，每一块存储在磁盘的一个地方，一块也叫做一个分区。比如典型的按月分区，是指每个月产生的数据在一个独立的区域，数据库可以单独处理某一块，也可以多块一起处理。分区表的优点和缺点如下：优点一些和时间有明显关系的业务场景，按照时间来进行分区要比直接使用分库分表更加简单高效大厂在容量规划时都是按照2的幂来规划的，比如428，或是8432，而且扩容的时候，也是按照2的幂进行的，基本
2024-07-23 20:58:22
1103
原创 万字长文之分库分表里无分库分表键如何查询【后端面试题 | 中间件 | 数据库 | MySQL | 分库分表 | 其他查询】
在很多业务里，分库分表键都是根据主要查询筛选出来的，那么不怎么重要的查询怎么解决呢？比如？或是买家找客服，客服要找到对应的订单，又该怎么找？
2024-07-22 21:10:33
983
原创 万字长文之分库分表里如何优化分页查询？【后端面试题 | 中间件 | 数据库 | MySQL | 分库分表 | 分页查询】
首次查询，拿到最小值二次查询，确实最小值的全局偏移量在二次查询的结果里根据最小值取到符合偏移量的数据首先发送查询语句 LIMIT X OFFSETY/N到所有的表找到返回结果中的最小值（升序），记作min执行第二次查询，关键是BETWEEN min AND max，其中max是第一次查询的数据中每个表各自的最大值根据min、第一次查询和第二次查询的值来确定min的全局偏移量。总的来说，min在某个表里的偏移量这样计算：如果第二次查询比第一次查询多了K条数据，偏移量就是Y/N-K。
2024-07-16 22:36:42
1394
2
原创 万字长文之分库分表里如何设计一个主键生成算法？【后端面试题 | 中间件 | 数据库 | MySQL | 分库分表】
大多数情况下，如果自己设计一个类似的算法，那么每个字段的含义、长度都可以灵活控制的，比如时间戳41比特可以改的更短或更长。机器ID虽然明面上是机器ID，但是实际上并不是指物理机器，准确说是算法实例。例如，一台机器部署两个进行，每个进行的ID是不同的；又或者进一步切割，机器ID前半部分表示机器，后半部分可以表示这个机器上用于产生ID的进程、协程或线程。甚至机器ID也并不一定非得表示机器，也可以引入一些特定的业务含义。而序列号也是可以考虑加长或缩短的。最后一句总结，升华主题。
2024-07-15 21:51:54
1115
原创 【力扣 - 每日一题】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
919
原创 【后端面试题】【中间件】【NoSQL】MongoDB查询优化3（拆分、嵌入文档，操作系统）
很常见的一种优化手段，在一些特定的业务场景中，会有一些很大的文档，这些文档有很多字段，而且有一些特定的字段还特别的大。之前拆分过一个文档，非常庞大。而且在业务中，有一些庞大的字段根本用不上，在这种情况下，一次拆除了三个文档。这样做的优点很明显，比较多的业务查询，极少数会需要第二种文档；但是缺点也很明显，如果调用者，也就意味着需要查询三次，再合并组成一个业务上完整的文档。也可以升华一下：这种拆分终究是下策，最好还是在一开始使用MongoDB的时候就约束住文档的大小。
2024-07-06 18:29:44
1333
原创 【后端面试题】【中间件】【NoSQL】MongoDB查询优化2（优化排序、mongos优化）
在MongoDB里面，如果能够利用索引来排序的话，。如果不能利用索引来排序的话，就必须在加载了数据之后，再次进行排序，也就是进行内存排序。可想而知，如果内存排序，再叠加分页查询的话，性能会更差。比如你要查询，那么在最坏情况下，MongoDB要把所有的文件加载到内存里排序，然后找到从10000开始的100条数据优化的思路也类似MySQL。第一种是，可以考虑修改查询，也可以考虑修改索引。比如你可以新建索引。我还优化过一个分页查询。
2024-07-05 21:38:38
890
原创 【后端面试题】【中间件】【NoSQL】MongoDB查询过程、ESR规则、覆盖索引的优化
任何中间件的面试说到底都是以高可用、高性能和高并发为主，而高性能和高并发基本是同时存在的。性能优化一直被看作一个高级面试点，因为只有对原理了解得很透彻的人，在实践中才能找准性能优化的关键点，从而通过各种优化手段解决性能问题。
2024-07-04 21:00:25
1047
原创 【后端面试题】【中间件】【NoSQL】MongoDB提高可用性的方案（主从结构、仲裁节点、分片、写入语义）
MongoDB的高可用和别的中间件的高可用方案基本类似。比如在MySQL里，接触了分库分表和主从同步；在Redis里，Redis也有主从结构；在Kafka里，分区也是有主从结构的。所以先介绍我们的系统有一个关键组件 - MongoDB，但是在最开始的时候，MongoDB没有启用主从，是一个单节点的。因此每年总会有一两次，MongoDB崩溃不可用。所以我把MongoDB改成了主从同步，最开始的时候业务量不多，为了节省成本，我们用了推荐的配置一主两从。
2024-07-03 20:36:55
1381
原创 【力扣 - 每日一题】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
1053
原创 【力扣 - 每日一题】3115. 质数的最大距离（一次遍历、头尾遍历、空间换时间、埃式筛、欧拉筛、打表）Golang实现
考虑这样一件事情：对于任意一个大于 1 的正整数 n，那么它的 x 倍就是合数（x > 1）。如果我们从小到大考虑每个数，然后同时把当前这个数的所有（比自己大的）倍数记为合数，那么运行结束的时候没有被标记的数就是素数了。解释： nums[1]、nums[3] 和 nums[4] 是质数。的更新过程进行优化，含义为最大的质数出现的位置，所以倒序遍历找第一个质数即可。在思路1的基础上，考虑有的数如果重复出现的话，会被重复判断。极端情况下，最中间的数是质数，还是会把全部的数都判断一遍。
2024-07-02 21:56:09
775
原创 【后端面试题】【中间件】【NoSQL】MongoDB的配置服务器、复制机制、写入语义和面试准备
引入了分片机制之后，MongoDB启用了(config server) 来存储元数据，这些元数据包括，用来控制分布式锁。其中分片信息还会被负责执行查询mongos使用。MongoDB的配置服务器有一个很大的优点，就是。大多数中间件的主从结构都是在主节点崩溃之后完全不可用，直到选举出了一个新的主节点。但是不管怎么说，配置服务器在MongoDB里是一个非常关键的组件，如果一旦配置服务器有问题，哪怕只是轻微地性能抖动一下，对整个MongoDB集群的影响都很大。
2024-07-02 20:47:19
1281
原创 【后端面试题】【中间件】【NoSQL】MongoDB的优点和分片机制
MongoDB因其灵活的文档模型和自动化的横向扩展备受青睐。当数据模型易变或难以预估时，MongoDB优于传统关系型数据库。分片机制确保数据分布在多个分片上，每个分片含多个128MB的块。当块超过128MB或文档数超阈值时，块会被拆分。MongoDB自动平衡数据负载，当分片间数据不均时执行再平衡，通过moveChunk命令迁移块，保持数据均衡。再平衡触发阈值基于块数量，例如最大和最小分片间差值超过2块时开始。这个过程保证了数据的无缝迁移和集群的高效运行。
2024-07-01 21:03:52
751
原创 【DDIA笔记】第二章 数据模型和查询语言（数据模型、关系模型与文档模型）
基本考察点：数据基本元素和元素之间的对应关系（一对多、多对多）比较几种的常用模型：关系模型（最为流行），文档模型（树状），图模型（极大自由度）schema模式：强Schema（写时约束），弱Schema（读时解析）如何与数据模型关联、匹配声明式和命令式。
2024-06-29 22:17:51
1024
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch的优化方案2（减少字段、冷热分离、参数优化）
一般性的性能优化方案可以做个总结优化查询本身：可能涉及到改写SQL、优化索引等优化中间件本身：调整中间件的各种参数优化操作系统：调整内存、网络IO和磁盘方面有关的参数。
2024-06-29 21:18:04
1191
原创 【Redis从入门到入土】管道传输Pipeline -- 批量操作处理必备
一般情况下，客户端和Redis通信的时候采用的是Ping-pong模式，即客户端发送命令后会等待服务端返回的命令执行的结果，在客户端收到服务端返回的结果后再发送下一个命令。而Pipeline模式类似流水线的模式：客户端发送一个命令后无需等待执行结果，会继续发送其他的命令。当所有的命令都发送完后，客户端关闭请求，开始接收响应，收到执行结果后再和之前发送的命令按顺序匹配。大部分客户端采用批处理的方式，即一次发送多个命令，等接收完所有命令执行结果后再返回。
2024-06-28 17:41:35
992
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch的优化方案1（分页查询、刷新间隔、批量提交）
ElasticSearch的三种优化方案，优化分页查询、增大刷新间隔和批量提交
2024-06-27 21:33:27
716
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch索引机制和高性能的面试思路
Elasticsearch的倒排索引机制、查找关键词的过程、高性能的面试思路
2024-06-26 21:16:54
1257
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch面试基本思路和高可用方案（限流、消息队列、协调节点、双集群）
首先介绍了面试准备中需要了解的相关问题。在高可用方案方面，文章提出了限流插件设计、消息队列削峰、降级策略和协调节点隔离等方案，以提高Elasticsearch的可用性
2024-06-25 21:08:12
958
原创 【后端面试题】【中间件】【NoSQL】ElasticSearch 节点角色、写入数据过程、Translog和索引与分片
Elasticsearch利用Translog确保数据安全，类比MySQL的redo log，它在内存缓冲后记录Translog，每隔5秒持久化磁盘，提供高效且顺序的写入。尽管如此，仍可能最多丢失5秒数据。索引由分片组成，每个分片有主从结构，分布于不同节点以降低故障影响。当主分片失败，主节点会选择新主分片。面试中可讨论公司如何使用Elasticsearch、其性能、索引设计、可用性策略及解决过的挑战。常见问题涉及Elasticsearch的应用场景、问题解决及写入流程。
2024-06-24 20:55:54
1091
原创 【后端面试题】【中间件】【缓存】Redis的热Key问题
Redis中的热Key是高访问频率的Key，如QPS高、大带宽使用或CPU密集型操作。热Key可能导致CPU占用过高、访问倾斜、缓存击穿和系统性能下降。爆款商品、热点事件等可引发热Key。检测热Key可借助云服务、`redis-cli hotkeys`、业务层监控或`MONITOR`命令。优化策略包括复制热Key到多分片、采用读写分离，但需权衡代码复杂性和数据一致性。
2024-06-19 20:34:13
525
原创 【后端面试题】【中间件】【缓存】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
1356
原创 【设计模式】创建型设计模式之建造者模式（基本介绍、适用场景、go代码实例）
建造者模式是创建型设计模式，用于分离对象构造的步骤和其表示，允许构造多种表示。适用于构建过程复杂且部分可变的情况。关键角色包括产品、抽象建造者、具体建造者和导演。例如，汉堡套餐的组合。优点是灵活性高、隐藏构建细节，缺点是可能增加代码冗余。与工厂模式对比，更关注构建顺序。示例中展示了Go语言的建造者模式实现，用于创建`ResourcePoolConfig`，通过Builder进行参数校验和构建。
2024-06-17 20:38:11
449
原创 【设计模式】创建型设计模式之工厂模式（简单工厂、工厂方法、抽象工厂、go简单实例）
当创建逻辑比较复杂，是一个大工程的时候，考虑使用工厂模式，封装对象的创建过程，将对象的创建和使用分离。什么情况是创建逻辑比较复杂呢？类似规则配置解析的例子，代码里存在if-else判断，动态的根据不同的类型创建不同的对象。单个对象本身的创建过程比较复杂，比如要组合其他类对象，做各种初始化操作。对于情况1。
2024-06-12 21:27:19
1028
原创 【DDIA笔记】第一章 可靠性、可扩展性和可维护性
数据系统是一种模糊的统称，在信息社会中，一切皆可信息化，或者，某种程度上来说–数字化。这些数据的采集、存储和使用，是构成信息社会的基础。因此作为IT从业人员，有必要系统性地了解一下现代的、分布式地数据系统。学习本书，能够学习到数据系统地背后的原理、了解其常见的实践，进而将其应用到我们工作的系统设计中。
2024-06-05 21:32:51
896
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人