勋章
我关注的人
粉丝
技术能力
- 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-11
前置知识 三阶段提交
【8月更文挑战第11天】
-
发表了文章 2024-08-10
TCC和本地事务 容错
【8月更文挑战第10天】
-
发表了文章 2024-08-09
TCC事务 基本思路
【8月更文挑战第9天】
-
发表了文章 2024-08-07
XA事务 面试准备
【8月更文挑战第7天】
-
发表了文章 2024-08-05
为什么需要MVCC 隔离级别
【8月更文挑战第5天】
-
发表了文章 2024-08-03
共享锁与排它锁 + 意向锁+记录锁
【8月更文挑战第3天】
-
发表了文章 2024-08-02
乐观锁和悲观锁+行锁和表锁
【8月更文挑战第2天】
-
发表了文章 2024-07-22
分库分表中间表优化
【7月更文挑战第21天】
-
发表了文章 2024-07-21
分库分表基本思路 引入中间表 主键生成
【7月更文挑战第20天】
-
发表了文章 2024-07-20
分库分表键的选择 重试方案
【7月更文挑战第19天】
-
发表了文章 2024-07-19
这样学Redis，才能技高一筹
【7月更文挑战第18天】
-
发表了文章 2024-07-17
Redis访问模式
【7月更文挑战第17天】
-
发表了文章 2024-07-16
分库分表面试准备
【7月更文挑战第16天】
-
发表了文章 2024-07-14
分库分表优化：平均分页
【7月更文挑战第14天】
-
发表了文章 2024-07-13
分库分表 全局排序问题 优化：归并排序
【7月更文挑战第13天】
-
发表了文章 2024-07-12
分库分表全局查询
【7月更文挑战第12天】
-
发表了文章 2024-07-11
MySQL分库分表
【7月更文挑战第11天】分库分表策略涉及数据源、库和表的划分，如订单表可能分布于多层结构中。面试时，主键生成是关键点。自增主键在不分库分表时适用，但在分表场景下会导致冲突。例如，按`buyer_id % 2`分两张表，自增ID无法保证全局唯一。因此，需要全局唯一且能自增的ID，如雪花算法，兼顾性能和高并发需求。
-
发表了文章 2024-07-10
发号器优化思路
【7月更文挑战第10天】
-
发表了文章 2024-07-07
顺序读和InnoDB的数据组织
【7月更文挑战第7天】自增主键优化顺序读：保证数据物理排序，提升范围查询效率。InnoDB引擎中，主键决定数据在页的存储。当插入的数据引起页分裂，如从1、2、3、5、6、7插入4，会导致相邻逻辑页在磁盘上可能分散，影响性能。了解页结构深化数据库知识，面试时可根据情况深入讨论。
-
发表了文章 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-20
【后端面经】【NoSQL】ElasticSearch - 1 -4 削峰 扩容
【6月更文挑战第19天】面试中，限流阈值设定、触发及恢复策略是关键点。熔断即停止新请求，降级需优先保障核心业务。可通过研发插件或使用网关（如极限网关）实现熔断、限流、降级，但网关可能引入性能损耗。客户端限流也是有效手段，尤其对高压力业务。然而，最佳解决方案仍是针对高并发需求进行扩容。
-
发表了文章 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-13
【后端面经】【NoSQL】ElasticSearch - 1 - 1 节点角色 写入数据
【6月更文挑战第12天】中间件高可用与高性能通过冗余、负载均衡和优化实现。Elasticsearch节点有候选主节点、协调节点和数据节点等角色，可兼任或独立。数据写入涉及Buffer、Page Cache和磁盘，通过段合并优化资源使用。查询通过Commit Point识别新段，确保近实时搜索。
-
发表了文章 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-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和本地事务 容错
