勋章
我关注的人
粉丝
技术能力
- Go
- C++
- 开发框架
- 设计模式
- 微服务
- 中间件
暂时未有相关云产品技术能力~
暂无个人介绍
-
发表了文章 2024-05-21
【后端面经】【缓存】36｜Redis 单线程：为什么 Redis 用单线程而 Memcached 用多线程？-- Memcache + Redis 多线程
【5月更文挑战第20天】Redis采用单线程模式以避免上下文切换和资源竞争，简化调试，且其性能瓶颈在于网络IO和内存，而非多线程。相比之下，Memcache使用多线程能更好地利用多核CPU，但伴随上下文切换和锁管理的开销。尽管Redis单线程性能不俗，6.0版本引入多线程以提升高并发下的IO处理能力。启用多线程后，Redis结合Reactor和epoll实现并发处理，提高系统性能。
-
发表了文章 2024-05-20
【后端面经】【缓存】36｜Redis 单线程：为什么 Redis 用单线程而 Memcached 用多线程？epoll、poll和select + Reactor模式
【5月更文挑战第19天】`epoll`、`poll`和`select`是Linux下多路复用IO的三种方式。`select`需要主动调用检查文件描述符，而`epoll`能实现回调，即使不调用`epoll_wait`也能处理就绪事件。`poll`与`select`类似，但支持更多文件描述符。面试时，重点讲解`epoll`的高效性和`Reactor`模式，该模式包括一个分发器和多个处理器，用于处理连接和读写事件。Redis采用单线程模型结合`epoll`的Reactor模式，确保高性能。在Redis 6.0后引入多线程，但基本原理保持不变。
-
发表了文章 2024-05-19
【后端面经】【缓存】36｜Redis 单线程：为什么 Redis 用单线程而 Memcached 用多线程？--epoll调用和中断
【5月更文挑战第18天】`epoll`包含红黑树和就绪列表，用于高效管理文件描述符。关键系统调用有3个：`epoll_create()`创建epoll结构，`epoll_ctl()`添加/删除/修改文件描述符，`epoll_wait()`获取就绪文件描述符。`epoll_wait()`可设置超时时间（-1阻塞，0立即返回，正数等待指定时间）。当文件描述符满足条件（如数据到达）时，通过中断机制（如网卡或时钟中断）更新就绪列表，唤醒等待的进程。
-
发表了文章 2024-05-18
【后端面经】【缓存】36｜Redis 单线程：为什么 Redis 用单线程而 Memcached 用多线程？
【5月更文挑战第17天】Redis常被称为单线程，但实际上其在处理命令时采用单线程，但在6.0后IO变为多线程。持久化和数据同步等任务由额外线程处理，因此严格来说Redis是多线程的。面试时需理解Redis的IO模型，如epoll和Reactor模式，以及其内存操作带来的高性能。Redis使用epoll进行高效文件描述符管理，实现高性能的网络IO。在讨论Redis与Memcached的线程模型差异时，应强调Redis的单线程模型如何通过内存操作和高效IO实现高性能。
-
发表了文章 2024-05-17
【后端面经】【缓存】35｜缓存问题：怎么解决缓存穿透、击穿和雪崩问题？--主从切换方案
【5月更文挑战第16天】该方案提出了解决Redis缓存穿透、击穿和雪崩问题的策略。通过使用两个或多个互为备份的Redis集群，确保在单个集群故障时，另一个可以接管。在故障发生时，业务会与备用集群保持心跳检测，并根据业务重要性分批转移流量，逐步增加对备用集群的依赖，同时监控系统稳定性。对于成本敏感的小型公司，可以采用低成本的单机或小规模自建Redis备份。此方案强调渐进式流量转移，以保护系统免受突然压力冲击。
-
发表了文章 2024-05-16
【后端面经】【缓存】35｜缓存问题：怎么解决缓存穿透、击穿和雪崩问题？---解决缓存击穿和雪崩、限流
【5月更文挑战第15天】本文介绍了如何解决缓存击穿和雪崩问题。对于缓存击穿，采用singleflight模式，确保即使热点数据导致大量请求未命中缓存，也只允许一个请求真正查询数据，其他请求等待其结果。对于缓存雪崩，解决方案是在设置过期时间时添加随机偏移量，避免所有数据同时过期。偏移量应与过期时间成正比。此外，限流也是一个重要策略，可以在服务层和数据库层实施，以限制请求流量，保护数据库免受高并发压力。
-
发表了文章 2024-05-15
【后端面经】【缓存】35｜缓存问题：怎么解决缓存穿透、击穿和雪崩问题？---解决缓存穿透
【5月更文挑战第14天】解决缓存穿透问题有两种策略。一是回写特殊值，当数据不存在时，在缓存中存储特殊值以标记，避免下次重复查询数据库。但此方法可能被恶意请求利用，浪费内存。二是使用布隆过滤器，预先判断数据是否存在，减少无效数据库查询。布隆过滤器虽有假阳性可能，但概率低，可接受。此外，可先查缓存再查布隆过滤器，优化正常请求的效率。两种方式各有优劣，实际应用需根据场景选择。
-
发表了文章 2024-05-13
01.【微服务架构】服务注册与发现：AP和CP，你选哪个？ -- 客户端容错
【5月更文挑战第12天】客户端容错机制确保在服务端或注册中心故障时仍能正确发送请求。当服务端崩溃，由于延迟，客户端一段时间内仍会尝试发送请求。客户端应实施 failover 策略，即检测到调用失败后，切换到其他节点重试，并将故障节点从列表移除。延时通常等于服务端与注册中心心跳间隔加通知时间。若网络问题导致客户端无法访问服务端，客户端应发送心跳以检测服务端状态，成功则恢复，连续失败则视为崩溃。若客户端无法连接注册中心，它应使用本地缓存并考虑退出。
-
发表了文章 2024-05-12
【后端面经】【缓存】33｜缓存模式：缓存模式能不能解决缓存一致性问题？-03 Refresh Ahead + SingleFlight + 删除缓存 + 延迟双删
【5月更文挑战第11天】Refresh Ahead模式通过CDC异步刷新缓存，但面临缓存一致性问题，可借鉴Write Back策略解决。SingleFlight限制并发加载，减少数据库压力，适合热点数据。删除缓存模式在更新数据库后删除缓存，一致性问题源于读写线程冲突。延迟双删模式两次删除，理论上减少不一致，但可能降低缓存命中率。选用模式需权衡优劣，延迟双删在低并发下较优。装饰器模式可用于实现多种缓存模式，无侵入地增强现有缓存系统。
-
发表了文章 2024-05-07
【后端面经】【消息队列】22 | 消息队列：消息队列可以用来解决什么问题？-01
【5月更文挑战第6天】消息队列的核心特性是异步、削峰和解耦，常用于日志处理和消息通讯，实现事件驱动架构。面试中可能涉及问题包括公司是否使用消息队列、应用场景、优缺点以及延时队列、秒杀架构等。秒杀场景下，消息队列将校验和库存扣减（轻量级）与订单创建（重量级）分隔，减轻系统压力，依赖于Redis性能。使用消息队列能解决高并发、复杂流程同步等问题。
-
发表了文章 2024-05-11
【后端面经】【缓存】33｜缓存模式：缓存模式能不能解决缓存一致性问题？-02 Write Through + Write Back
【5月更文挑战第10天】`Write Through`是一种缓存策略，写操作仅需写入缓存，缓存负责更新数据库。异步版本可能丢失数据，而同步变种先写数据库再异步刷新缓存，减少丢数据风险。`Write Back`模式数据先写入缓存，过期时才写入数据库，可能导致数据丢失，但若使用Redis并确保高可用，可部分解决一致性问题。在特定条件下，如使用SETNX命令，能缓解一致性挑战。
-
发表了文章 2024-05-06
高并发推荐系统架构设计-1 基本介绍
【5月更文挑战第5天】推荐系统是信息过滤工具，通过处理物料数据和行为日志，运用预处理、特征工程、算法模型学习用户兴趣，实现个性化推荐。在线架构包括AB分流、多路召回、模型排序和业务规则重排序。旧版线上架构由C++编写的API和engine服务组成，HTTP请求经SLB、Nginx、FastCGI到达服务程序，召回和排序服务处理推荐。存在并发瓶颈问题。
-
发表了文章 2024-05-10
【后端面经】【缓存】33｜缓存模式：缓存模式能不能解决缓存一致性问题？
【5月更文挑战第9天】面试准备中，熟悉缓存模式如Cache Aside、Read Through、Write Through、Write Back、Singleflight，以及删除缓存和延迟双删策略，能解决缓存一致性、穿透、击穿和雪崩问题。在自我介绍时展示对缓存模式的理解，例如Cache Aside模式，它是基础模式，读写由业务控制，先写数据库以保证数据准确性，但无法解决所有一致性问题。Read Through模式在缓存未命中时自动从数据库加载数据，可异步加载优化响应时间，但也存在一致性挑战。
-
发表了文章 2024-05-14
【后端面经】【缓存】35｜缓存问题：怎么解决缓存穿透、击穿和雪崩问题？---缓存穿透、击穿和雪崩
【5月更文挑战第13天】本文讨论了三种常见的缓存问题：穿透、击穿和雪崩。缓存穿透发生时，请求的数据既不在缓存也不在数据库，可能导致数据库崩溃。缓存击穿指数据仅存在于数据库，热点数据的大量未命中请求会压垮数据库。缓存雪崩则是大量缓存在同一时间过期，引发数据库瞬间压力过大。为应对这些问题，需了解Redis部署（如Cluster或Sentinel）、故障恢复策略，以及公司如何保护数据库。解决缓存问题的经验和预防措施是面试中的重要话题。
-
发表了文章 2024-05-09
【后端面经】【消息队列】22 | 消息队列：消息队列可以用来解决什么问题？-03 扩展性+可用性+事件驱动思想
【5月更文挑战第8天】 本文探讨了扩展性、可用性和事件驱动的概念。扩展性方面，消息队列简化了新下游的接入，而同步调用需要复杂的协调。在保证高可扩展性和研发效率的设计中，若无法使用消息队列，可以提供一致性抽象来减轻接入负担。可用性上，消息队列只需确保消息发送，而同步调用需保证所有下游成功，更易出错。事件驱动是一种通过事件进行组件间通信的架构模式，具有低耦合、高扩展性和高可用性，适合处理复杂流程。结合SAGA的事件驱动方案能实现高级分布式事务管理，即使实时性稍弱，但能保证事务的异步和高效执行。
-
发表了文章 2024-05-08
【后端面经】【消息队列】22 | 消息队列：消息队列可以用来解决什么问题？-02 超时场景+性能问题
【5月更文挑战第7天】 本文介绍了电商中订单超时取消的处理方法，通过使用消息队列实现延时消息。当订单30分钟后未支付，消息队列将触发取消操作，但需注意并发问题，如采用分布式锁或乐观锁避免并发更新订单状态。乐观锁确保只有订单状态为未支付时才允许支付。主流消息队列如RocketMQ支持延迟消息，而Kafka不支持。 使用消息队列的好处在于解耦和提高系统性能、扩展性和可用性。同步调用会导致性能下降，因为必须等待所有调用完成。并发调用虽可提升性能，但仍逊于消息队列，且无法解决扩展性和可用性问题。
-
发表了文章 2024-05-04
01.【微服务架构】服务注册与发现：AP和CP，你选哪个？-- 服务端崩溃检测
【5月更文挑战第3天】保证服务注册与发现的高可用需关注三个方面：服务端崩溃检测、客户端容错和注册中心选型。服务端崩溃时，注册中心通过心跳检测来识别，若心跳中断，立即通知客户端服务不可用，同时持续尝试恢复心跳。若一段时间后仍无法连接，则断定服务端彻底崩溃。这种方法兼顾及时故障通知和防止误判。
-
发表了文章 2024-05-03
01.【微服务架构】服务注册与发现：AP和CP，你选哪个？-- 面试准备+基本模型
【5月更文挑战第2天】面试准备应涵盖公司所使用的注册中心类型及其优缺点，了解其集群规模、QPS和机器性能。准备故障排查及优化案例。若公司未采用微服务，可熟悉ZooKeeper、Nacos或etcd的基本特性以讨论注册中心概念。面试时，可将话题引导至服务注册与发现，如被问及特定中间件，阐述为何选择它并讨论优缺点。当涉及微服务高可用性时，可强调服务注册与发现的作用。基础模型部分，需解释服务上线和下线流程，提及注册数据和分组功能，并举例说明。最后，简述服务注册与发现的高可用挑战。
-
发表了文章 2024-05-02
01.【微服务架构】服务注册与发现：AP和CP，你选哪个？-- 服务注册与发现模型
【5月更文挑战第1天】本文探讨了服务注册与发现的关键作用，在微服务架构中，这一概念常出现在面试中。文章深入讲解基础模型，包括服务端注册、心跳维持、客户端缓存及服务端下线流程，并强调了高可用性的重要性，涉及服务端崩溃检测、客户端容错和注册中心选型。通过分析客户端、注册中心和服务端之间的交互，提出如何应对潜在故障的策略，以构建稳定的微服务架构。
-
发表了文章 2024-04-23
缓存命中率和过期机制的一般思路
【4月更文挑战第20天】缓存命中率是评估缓存效果的关键，目标是达到90%以上，但某些频繁的小请求场景可能无法实现。过期机制可采用定时删除（精确但开销大）、延迟队列（精确但有队列开销）、懒惰删除（简单但时间不精确）或定期删除（简单但性能损耗不可控）。
-
发表了文章 2024-04-22
【MySQL实战笔记】07 | 行锁功过：怎么减少行锁对性能的影响？-02 死锁和死锁检测
【4月更文挑战第19天】在高并发环境下，死锁发生在多个线程间循环等待资源时，导致无限期等待。MySQL中，死锁可通过`innodb_lock_wait_timeout`参数设置超时或`innodb_deadlock_detect`开启死锁检测来解决。默认的50s超时可能不适用于在线服务，而频繁检测会消耗大量CPU。应对热点行更新引发的性能问题，可以暂时关闭死锁检测（风险是产生大量超时），控制并发度，或通过分散记录减少锁冲突，例如将数据分拆到多行以降低死锁概率。
-
发表了文章 2024-04-20
【MySQL实战笔记】 06 | 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？-01
【4月更文挑战第17天】MySQL的锁分为全局锁、表级锁和行锁。全局锁用于全库备份，可能导致业务暂停或主从延迟。不加锁备份会导致逻辑不一致。推荐使用`FTWRL`而非`readonly=true`因后者可能影响其他逻辑且异常处理不同。表级锁如`lock tables`限制读写并限定操作对象，常用于并发控制。元数据锁（MDL）在访问表时自动加锁，确保读写正确性。
-
发表了文章 2024-04-24
淘汰算法
【4月更文挑战第21天】这篇内容介绍了两种主流的淘汰算法：LRU（Least Recently Used）和LFU（Least Frequently Used）。LRU基于最近最少使用原则，当缓存满时，淘汰最近最久未使用的键。实现上通常使用链表和Java的LinkedHashMap。而LFU根据访问次数淘汰最不常使用的对象，可以按访问频率排序并选择淘汰。LFU的变种可能关注一定时间窗口内的访问次数，实现上更复杂。
-
发表了文章 2024-04-18
【后端面经】【数据库与MySQL】12｜数据库锁：明明有行锁，怎么突然就加了表锁？
【4月更文挑战第15天】在MySQL的InnoDB引擎中，锁通过索引实现，主要锁定叶子节点。查询使用哪个索引，就锁哪个；无索引时锁全表。若查询值不存在，InnoDB会构造临键锁阻止插入。锁在事务结束（Rollback或Commit）时释放。乐观锁在尝试更新时检查数据变化，适合读多写少场景，悲观锁一开始就加锁，适用于写多读少。InnoDB支持行锁和表锁，行锁依赖索引。共享锁允许多个线程加同类型锁，排它锁则独占。
-
发表了文章 2024-04-16
【后端面经】【数据库与MySQL】SQL优化：如何发现SQL中的问题？-02
【4月更文挑战第13天】该文介绍了几个数据库查询优化技巧。首先，创建覆盖索引如<A,B,C>能加速`select A,B,C from student where A=? and B=? and C=?`的执行。其次，为常用于排序的列建立索引，如在`id,update_time`上建索引，可避免数据排序，显著提高查询速度。优化`count(*)`可通过预估值或使用Redis记录总数，但需注意数据一致性问题。使用索引提示如FORCE INDEX可强制使用特定索引，但应谨慎。将`having`的非聚合条件移到`where`里可提升效率。最后，处理深度分页时
-
发表了文章 2024-04-15
【后端面经】【数据库与MySQL】SQL优化：如何发现SQL中的问题？
【4月更文挑战第12天】数据库优化涉及硬件升级、操作系统调整、服务器/引擎优化和SQL优化。SQL优化目标是减少磁盘IO和内存/CPU消耗。`EXPLAIN`命令用于检查SQL执行计划，关注`type`、`possible_keys`、`key`、`rows`和`filtered`字段。设计索引时考虑外键、频繁出现在`where`、`order by`和关联查询中的列，以及区分度高的列。大数据表改结构需谨慎，可能需要停机、低峰期变更或新建表。面试中应准备SQL优化案例，如覆盖索引、优化`order by`、`count`和索引提示。优化分页查询时避免大偏移量，可利用上一批的最大ID进行限制。
-
发表了文章 2024-04-10
【MySQL实战笔记】03.事务隔离：为什么你改了我还看不见？-02
【4月更文挑战第7天】数据库通过视图实现事务隔离，不同隔离级别如读未提交、读已提交、可重复读和串行化采用不同策略。以可重复读为例，MySQL使用多版本并发控制（MVCC），每个事务有其独立的视图。回滚日志在无更早视图时被删除。长事务可能导致大量存储占用，应避免。事务启动可显式用`begin`或设置`autocommit=0`，但后者可能意外开启长事务。建议使用`autocommit=1`并显式管理事务，若需减少交互，可使用`commit work and chain`。
-
发表了文章 2024-04-08
【MySQL实战笔记】02.一条SQL更新语句是如何执行的-2
【4月更文挑战第5天】两阶段提交是为确保`redo log`和`binlog`逻辑一致，避免数据不一致。若先写`redo log`， crash后数据可能丢失，导致恢复后状态错误；若先写`binlog`，crash则可能导致重复事务，影响数据库一致性。一天一备相较于一周一备，能缩短“最长恢复时间”，但需权衡额外的存储成本。
-
发表了文章 2024-04-14
【后端面经】【数据库与MySQL】为什么MySQL用B+树而不用B树？-02
【4月更文挑战第11天】数据库索引使用规则：`AND`用`OR`不用，正用反不用，范围中断。索引带来空间和内存代价，包括额外磁盘空间、内存占用和数据修改时的维护成本。面试中可能涉及B+树、聚簇索引、覆盖索引等知识点。MySQL采用B+树，因其利于范围查询和内存效率。数据库不使用索引可能因`!=`、`LIKE`、字段区分度低、特殊表达式或全表扫描更快。索引与NULL值处理在不同数据库中有差异，MySQL允许NULL在索引中的使用。
-
发表了文章 2024-04-06
【MySQL实战笔记】01.一条SQL查询语句是如何执行的？
【4月更文挑战第3天】MySQL执行SQL的流程包括连接器、查询缓存、分析器、优化器和执行器。连接器负责建立连接、权限验证，查询缓存（MySQL 8.0已移除）存储查询结果，分析器解析SQL确保语法正确，优化器选择最佳索引和查询路径，执行器执行查询并管理权限。连接器使用长连接可能导致内存问题，可定期断开或使用`mysql_reset_connection`。注意，更新操作会导致查询缓存失效。
-
发表了文章 2024-04-07
【MySQL实战笔记】02.一条SQL更新语句是如何执行的-1
【4月更文挑战第4天】SQL更新语句执行涉及查询和日志模块，主要为`redo log`和`binlog`。`redo log`先写日志再写磁盘，保证`crash-safe`；`binlog`记录逻辑日志，支持所有引擎，且追加写入。执行过程分为执行器查找数据、更新内存和`redo log`（prepare状态）、写入`binlog`、提交事务（`redo log`转commit）。两阶段提交确保日志逻辑一致，支持数据库恢复至任意时间点。
-
发表了文章 2024-04-05
评论功能里数据库的设计
【4月更文挑战第2天】本文探讨了评论系统的树形结构设计，提出了四种方法：邻接表、分段式path、Nested Set和Closure Table。针对评论业务功能，如加载评论页和查看回复，优先考虑邻接表和分段式path。采用邻接表思路，设计了评论表结构，包括Uid、Biz、BizID、RootID、PID、Content、索引和级联删除规则。同时提到了索引设计，如Uid、Biz+BizID、PID和Ctime/Utime，以优化查询性能。
-
发表了文章 2024-04-04
第 284 场周赛（C++ | 枚举 | 分类讨论 | 最短路 | 建反图）
【4月更文挑战第1天】- [LeetCode 6031](https://leetcode-cn.com/problems/find-all-k-distant-indices-in-an-array/)：给定数组 `nums`、键值 `key` 和距离 `k`，找到所有与键值相等且与任意下标距离不超过 `k` 的下标，返回升序排序的列表。找到最小权重。
-
发表了文章 2024-03-09
【力扣】2645. 构造有效字符串的最小插入数（动态规划 贪心 滚动数组优化 C++ Go）
【2月更文挑战第17天】2645. 构造有效字符串的最小插入数（动态规划 贪心 滚动数组优化 C++ Go）
-
发表了文章 2024-03-11
2182.构造限制重复的字符串（模拟 贪心 优先队列 C++ Go）
【2月更文挑战第19天】2182.构造限制重复的字符串（模拟 贪心 优先队列 C++ Go）
-
发表了文章 2024-03-13
软件质量保证与测试知识点总结
【2月更文挑战第21天】软件质量保证与测试知识点总结
-
发表了文章 2024-03-07
微服务架构下服务注册的几种方式
【2月更文挑战第15天】微服务架构下服务注册的几种方式
-
发表了文章 2024-03-10
【力扣】2696. 删除子串后的字符串最小长度（模拟 栈 C++ Go实现栈）
【2月更文挑战第18天】2696. 删除子串后的字符串最小长度（模拟 栈 C++ Go实现栈）
-
发表了文章 2024-03-08
注册中心机制
【2月更文挑战第16天】注册中心机制
-
发表了文章 2024-03-05
ElasticSearch的HTTP操作 和Go客户端
【2月更文挑战第13天】ElasticSearch的HTTP操作 和Go客户端操作
-
发表了文章 2024-03-02
Golang里空结构体struct{}的介绍和使用
【2月更文挑战第10天】Golang里空结构体struct{}的介绍和使用
-
发表了文章 2024-03-04
【Sentinel Go】新手指南、流量控制、熔断降级和并发隔离控制
【2月更文挑战第12天】随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。
-
发表了文章 2024-03-01
【Golang】解决使用interface{}解析json数字会变成科学计数法的问题
【2月更文挑战第9天】解决使用interface{}解析json数字会变成科学计数法的问题
-
发表了文章 2024-02-29
Golang拼接字符串性能对比
【2月更文挑战第8天】Golang拼接字符串性能对比
-
发表了文章 2024-02-27
高效Go编程之格式化+代码注释+命名+分号+控制结构
【2月更文挑战第6天】高效Go编程之格式化+代码注释+命名+分号+控制结构
-
发表了文章 2024-02-26
Go语言面试题1
【2月更文挑战第5天】Go语言面试题15个问题
-
发表了文章 2024-04-21
【MySQL实战笔记】07 | 行锁功过：怎么减少行锁对性能的影响？-01
【4月更文挑战第18天】MySQL的InnoDB引擎支持行锁，而MyISAM只支持表锁。行锁在事务开始时添加，事务结束时释放，遵循两阶段锁协议。为减少锁冲突影响并发，应将可能导致最大冲突的锁操作放在事务最后。例如，在电影票交易中，应将更新影院账户余额的操作安排在事务末尾，以缩短锁住关键行的时间，提高系统并发性能。
-
发表了文章 2024-02-22
【小小思考】Redis实现去重任务队列
【2月更文挑战第1天】思考一下如何用Redis实现去重的任务队列，主要有List 、List + Set/Hash/Bloom Filter、ZSet、Lua和开源库等方式。
-
发表了文章 2024-04-11
【MySQL实战笔记】 04 | 深入浅出索引（上）-01
【4月更文挑战第8天】这篇文章除了介绍索引的作用和提高查询效率的原理，还探讨了三种常见的数据结构：哈希表、有序数组和搜索树。哈希表适合等值查询，但不支持范围查询；有序数组利用二分查找实现快速等值查询，但更新成本高；二叉搜索树保持平衡时查询高效，但磁盘存储时效率低。文章指出，由于磁盘读取延迟，实际数据库索引设计需考虑减少磁盘访问次数。
-
发表了文章 2024-04-09
【MySQL实战笔记】03.事务隔离：为什么你改了我还看不见？-01
【4月更文挑战第6天】MySQL事务的隔离性确保数据操作的完整性和一致性，ACID原则包括原子性、一致性、隔离性和持久性。事务隔离级别有四种：读未提交、读提交、可重复读和串行化，分别解决并发问题如脏读、不可重复读和幻读。不同隔离级别在效率和安全性间权衡，例如读未提交允许未提交变更可见，而串行化通过锁保证安全但可能降低效率。在不同隔离级别下，事务看到的数据状态会有所变化，例如在可重复读级别，事务始终看到初始数据，而在串行化级别，事务会等待其他事务完成再继续，避免数据冲突。
-
发表了文章
2024-10-24
Bitmap
-
发表了文章
2024-10-23
redis-set类型
-
发表了文章
2024-10-22
redis-hash
-
发表了文章
2024-10-21
redis-ZSet
-
发表了文章
2024-10-18
List Pub Sub
-
发表了文章
2024-10-17
基于Zookeeper的锁
-
发表了文章
2024-10-16
微服务
-
发表了文章
2024-09-02
1
-
发表了文章
2024-08-22
快慢路径降级慢路径
-
发表了文章
2024-08-21
熔断方案
-
发表了文章
2024-08-20
前置知识 判断服务的健康状态
-
发表了文章
2024-08-19
降级概述
-
发表了文章
2024-08-18
读写服务降级写服务
-
发表了文章
2024-08-17
常见的降级思路 面试准备
-
发表了文章
2024-08-16
跨服务降级
-
发表了文章
2024-08-15
整体方案 参数调优 innodb_buffer_pool_size
-
发表了文章
2024-08-13
查询缓存 面试准备
-
发表了文章
2024-08-12
TCC+ SAGA事务
-
发表了文章
2024-08-11
前置知识 三阶段提交
-
发表了文章
2024-08-10
TCC和本地事务 容错
