勋章
我关注的人
粉丝
技术能力
- Go
- C++
- 开发框架
- 设计模式
- 微服务
- 中间件
暂时未有相关云产品技术能力~
暂无个人介绍
-
发表了文章 2024-10-24
Bitmap
【10月更文挑战第7天】
-
发表了文章 2024-10-23
redis-set类型
【10月更文挑战第6天】
-
发表了文章 2024-10-21
redis-ZSet
【10月更文挑战第4天】
-
发表了文章 2024-10-16
微服务
【10月更文挑战第1天】微服务是一种将大型应用分解为小型、独立服务的设计理念，每个服务负责单一业务功能，独立部署、运行，通过轻量级通信机制（如HTTP API或RPC）互联。相比单体应用，微服务提高了部署效率、团队协作效能和系统可用性，但也增加了系统复杂性、通信开销和数据一致性管理的难度。实现微服务架构涉及服务拆分、服务发现、配置管理、服务治理、数据一致性、安全性、监控与日志、持续集成与部署等多个方面。
-
发表了文章 2024-08-21
熔断方案
【8月更文挑战第20天】
-
发表了文章 2024-08-19
降级概述
【8月更文挑战第18天】
-
发表了文章 2024-08-17
常见的降级思路 面试准备
【8月更文挑战第16天】
-
发表了文章 2024-08-15
整体方案 参数调优 innodb_buffer_pool_size
【8月更文挑战第14天】
-
发表了文章 2024-08-12
TCC+ SAGA事务
【8月更文挑战第12天】
-
发表了文章 2024-08-10
TCC和本地事务 容错
【8月更文挑战第10天】
-
发表了文章 2024-08-09
TCC事务 基本思路
【8月更文挑战第9天】
-
发表了文章 2024-08-05
为什么需要MVCC 隔离级别
【8月更文挑战第5天】
-
发表了文章 2024-08-03
共享锁与排它锁 + 意向锁+记录锁
【8月更文挑战第3天】
-
发表了文章 2024-08-02
乐观锁和悲观锁+行锁和表锁
【8月更文挑战第2天】
-
发表了文章 2024-07-20
分库分表键的选择 重试方案
【7月更文挑战第19天】
-
发表了文章 2024-07-19
这样学Redis，才能技高一筹
【7月更文挑战第18天】
-
发表了文章 2024-07-16
分库分表面试准备
【7月更文挑战第16天】
-
发表了文章 2024-07-13
分库分表 全局排序问题 优化：归并排序
【7月更文挑战第13天】
-
发表了文章 2024-07-12
分库分表全局查询
【7月更文挑战第12天】
-
发表了文章 2024-07-06
MongoDB拆分大文档、嵌入文档
【7月更文挑战第6天】
-
发表了文章 2024-07-05
MongoDB优化分页
【7月更文挑战第5天】
-
发表了文章 2024-07-03
MongoDB多数据中心的主从结构
【7月更文挑战第3天】
-
发表了文章 2024-07-02
MongoDB的配置服务器和复制机制
【7月更文挑战第2天】MongoDB配置服务器存储分片和权限元数据，支持在主节点故障时保持读服务。关键组件，性能影响显著。复制集包含Primary和Secondary，通过oplog实现数据同步，类似MySQL binlog。oplog的幂等性可能导致大量set操作，且大小受限，可能导致从节点需全量同步。读写分离提升效率，主从切换确保高可用。
-
发表了文章 2024-07-01
【后端面试题】【中间件】【NoSQL】MongoDB的优点和分片机制
【7月更文挑战第1天】
-
发表了文章 2024-06-22
【后端面经】【NoSQL】ElasticSearch - 1 -6 保护协调节点
【6月更文挑战第21天】
-
发表了文章 2024-06-21
【后端面经】【NoSQL】ElasticSearch - 1 -5 消息队列
【6月更文挑战第20天】
-
发表了文章 2024-06-19
Redis的热Key问题
【6月更文挑战第18天】Redis中的热Key是高访问频率的Key，如QPS高、大带宽使用或CPU密集型操作。热Key可能导致CPU占用过高、访问倾斜、缓存击穿和系统性能下降。爆款商品、热点事件等可引发热Key。检测热Key可借助云服务、`redis-cli hotkeys`、业务层监控或`MONITOR`命令。优化策略包括复制热Key到多分片、采用读写分离，但需权衡代码复杂性和数据一致性。
-
发表了文章 2024-06-18
【后端面经】【NoSQL】ElasticSearch - 1 -3 基本思路 限流
【6月更文挑战第17天】在面试中讨论Elasticsearch高可用性时，聚焦于分片机制和主从副本，确保数据冗余。Translog作为关键组件，用于数据安全，防止崩溃后丢失。为提升高可用性，实施了额外措施，如限流保护，通过Elasticsearch内置功能或自定义插件监控内存和CPU使用率，当超过阈值时动态限流，以应对突发流量，避免系统崩溃。
-
发表了文章 2024-06-16
【后端面经】【NoSQL】ElasticSearch - 1 -2 Translog + Elasticsearch索引与分片 + 面试准备
【6月更文挑战第15天】Elasticsearch利用Translog确保数据安全，类比MySQL的redo log，它在内存缓冲后记录Translog，每隔5秒持久化磁盘，提供高效且顺序的写入。尽管如此，仍可能最多丢失5秒数据。索引由分片组成，每个分片有主从结构，分布于不同节点以降低故障影响。当主分片失败，主节点会选择新主分片。面试中可讨论公司如何使用Elasticsearch、其性能、索引设计、可用性策略及解决过的挑战。常见问题涉及Elasticsearch的应用场景、问题解决及写入流程。
-
发表了文章 2024-06-15
Redis大key问题 - 优化、清理
【6月更文挑战第14天】Redis内置命令如STRLEN、LLEN等用于检测不同类型Key的大小。避免使用DEBUG OBJECT和MEMORY USAGE因高资源消耗。大Key优化包括业务设计避免大Key、数据拆分、更换存储方案、数据压缩和合理清理。清理大Key应选低峰期或分批异步进行，以减少阻塞。使用如HSCAN、SREM等命令避免一次性操作大量数据。
-
发表了文章 2024-06-14
Redis大Key问题 - 标准、原因、查找
【6月更文挑战第13天】**大Key标准**在不同场景各异，一般string超1MB或容器超10k元素视为大；高并发场景中，string超10KB，容器超5k或整体10MB。**阿里云Redis**中，大Key可能表现为String值5MB，ZSET成员10k，或Hash总值100MB。**大Key影响**包括高读取成本、操作阻塞、存储压力不均。**产生原因**多源于业务设计、动态增长管理和程序错误。**查找大Key**可通过云服务的实时/离线统计，`redis-cli --bigkeys`或使用Redis RDB Tools分析RDB文件。注意，某些特定需求可能需额外工具。
-
发表了文章 2024-06-09
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展，允许节点有多重父节点，但导航复杂，需要预知数据库结构。关系模型将数据组织为元组和关系，强调声明式查询，解耦查询语句与执行路径，简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据，提供弱模式灵活性，但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系，适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read，写入时不校验，读取时解析，牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
-
发表了文章 2024-06-08
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型，比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本（如region_id代替"Greater Seattle Area"），可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中，需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂，若无Join，需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性，层次模型以树形结构限制了多对多关系处理。为克服层次模型局限，发展出了关系模型和网状模型。
-
发表了文章 2024-06-07
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型，以二维表形式展示数据，支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战，如网状和层次模型，但关系模型仍占主导。然而，随着大数据增长和NoSQL的出现（如MongoDB、Redis），强调伸缩性、专业化查询和表达力，关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题，ORM框架缓解但未完全解决。文档模型（如JSON）提供更自然的嵌套结构，适合表示复杂关系，具备模式灵活性和更好的数据局部性。
-
发表了文章 2024-06-05
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题，指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题，Twitter采用混合策略，大部分用户推文扇出至粉丝主页时间线，而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟，其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展，以及自动和手动调整。文章强调了可维护性的重要性，包括可操作性、简单性和可演化性，以减轻维护负担和适应变化。此外，良好设计应减少复杂性，提供预测性行为，并支持未来改动。
-
发表了文章 2024-06-04
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可扩展性
【6月更文挑战第3天】可扩展性关乎系统应对负载增长的能力，但在产品初期过度设计可能导致失败。理解基本概念以应对可能的负载增长是必要的。衡量负载的关键指标包括日活、请求频率、数据库读写比例等。推特的扩展性挑战在于"扇出"，即用户关注网络的广度。两种策略包括拉取（按需查询数据库）和推送（预计算feed流）。推送方法在推特案例中更为有效，因为它减少了高流量时的实时计算压力。
-
发表了文章 2024-06-03
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- part1 可靠性
【6月更文挑战第2天】本书探讨现代数据系统，阐述其在信息社会中的关键作用，包括数据库、缓存、搜索引擎、流处理、批处理和消息队列等组成部分。随着技术发展，工具如Kafka、Spark和Redis等多功能组件使得系统设计更为复杂。面对可靠性、可扩展性和可维护性的挑战，书中强调了容错和韧性的重要性，区分了硬件故障、软件错误和人为错误，并提出了应对措施。可靠性关乎用户数据、企业声誉和生存，因此是系统设计的核心考量。
-
发表了文章 2024-06-02
【Redis从入门到入土】布隆过滤器简介、特点和原理
【6月更文挑战第1天】布隆过滤器是一种节省内存的不确定数据结构，用于判断元素是否可能在一个集合中。它由位数组和多个哈希函数组成，能快速插入和查询，但存在误判风险：可能存在假阳性（判断存在但实际不存在），但绝无假阴性（判断不存在则确实不存在）。适用于大规模数据的去重问题，如电话号码判断、安全网站链接检查、黑名单和白名单校验。其工作原理是通过多个哈希函数将元素映射到位数组中，添加时设置相应位置为1，查询时所有位置都为1则可能存在，有0则肯定不存在。由于哈希冲突，可能导致误判，且一旦添加元素无法删除，以避免影响其他元素。
-
发表了文章 2024-05-22
【后端面经】【缓存】36｜Redis 单线程：为什么 Redis 用单线程而 Memcached 用多线程？-- Redis多线程
【5月更文挑战第21天】Redis启用多线程后，主线程负责接收事件和命令执行，IO线程处理读写数据。请求处理流程中，主线程接收客户端请求，IO线程读取并解析命令，主线程执行后写回响应。业界普遍认为，除非必要，否则不建议启用多线程模式，因单线程性能已能满足多数需求。公司实际场景中，启用多线程使QPS提升约50%，或选择使用Redis Cluster以提升性能和可用性。
-
发表了文章 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-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和本地事务 容错
