LightOf_社区达人页

2024年06月

• 06.22 22:08:25
  发表了文章 2024-06-22 22:08:25

  【后端面经】【NoSQL】ElasticSearch - 1 -6 保护协调节点

  【6月更文挑战第21天】
• 06.21 21:16:28
  发表了文章 2024-06-21 21:16:28

  【后端面经】【NoSQL】ElasticSearch - 1 -5 消息队列

  【6月更文挑战第20天】
• 06.20 22:01:28
  发表了文章 2024-06-20 22:01:28

  【后端面经】【NoSQL】ElasticSearch - 1 -4 削峰 扩容

  【6月更文挑战第19天】面试中，限流阈值设定、触发及恢复策略是关键点。熔断即停止新请求，降级需优先保障核心业务。可通过研发插件或使用网关（如极限网关）实现熔断、限流、降级，但网关可能引入性能损耗。客户端限流也是有效手段，尤其对高压力业务。然而，最佳解决方案仍是针对高并发需求进行扩容。

  
• 06.19 20:34:10
  发表了文章 2024-06-19 20:34:10

  Redis的热Key问题

  【6月更文挑战第18天】Redis中的热Key是高访问频率的Key，如QPS高、大带宽使用或CPU密集型操作。热Key可能导致CPU占用过高、访问倾斜、缓存击穿和系统性能下降。爆款商品、热点事件等可引发热Key。检测热Key可借助云服务、`redis-cli hotkeys`、业务层监控或`MONITOR`命令。优化策略包括复制热Key到多分片、采用读写分离，但需权衡代码复杂性和数据一致性。
• 06.18 21:57:44
  发表了文章 2024-06-18 21:57:44

  【后端面经】【NoSQL】ElasticSearch - 1 -3 基本思路 限流

  【6月更文挑战第17天】在面试中讨论Elasticsearch高可用性时，聚焦于分片机制和主从副本，确保数据冗余。Translog作为关键组件，用于数据安全，防止崩溃后丢失。为提升高可用性，实施了额外措施，如限流保护，通过Elasticsearch内置功能或自定义插件监控内存和CPU使用率，当超过阈值时动态限流，以应对突发流量，避免系统崩溃。
• 06.17 20:37:00
  发表了文章 2024-06-17 20:37:00

  【设计模式】建造者模式

  【6月更文挑战第16天】建造者模式是创建型设计模式，用于分离对象构造的步骤和其表示，允许构造多种表示。适用于构建过程复杂且部分可变的情况。关键角色包括产品、抽象建造者、具体建造者和导演。例如，汉堡套餐的组合。优点是灵活性高、隐藏构建细节，缺点是可能增加代码冗余。与工厂模式对比，更关注构建顺序。示例中展示了Go语言的建造者模式实现，用于创建`ResourcePoolConfig`，通过Builder进行参数校验和构建。
• 06.16 16:33:29
  发表了文章 2024-06-16 16:33:29

  【后端面经】【NoSQL】ElasticSearch - 1 -2 Translog + Elasticsearch索引与分片 + 面试准备

  【6月更文挑战第15天】Elasticsearch利用Translog确保数据安全，类比MySQL的redo log，它在内存缓冲后记录Translog，每隔5秒持久化磁盘，提供高效且顺序的写入。尽管如此，仍可能最多丢失5秒数据。索引由分片组成，每个分片有主从结构，分布于不同节点以降低故障影响。当主分片失败，主节点会选择新主分片。面试中可讨论公司如何使用Elasticsearch、其性能、索引设计、可用性策略及解决过的挑战。常见问题涉及Elasticsearch的应用场景、问题解决及写入流程。

  
• 06.15 19:04:25
  发表了文章 2024-06-15 19:04:25

  Redis大key问题 - 优化、清理

  【6月更文挑战第14天】Redis内置命令如STRLEN、LLEN等用于检测不同类型Key的大小。避免使用DEBUG OBJECT和MEMORY USAGE因高资源消耗。大Key优化包括业务设计避免大Key、数据拆分、更换存储方案、数据压缩和合理清理。清理大Key应选低峰期或分批异步进行，以减少阻塞。使用如HSCAN、SREM等命令避免一次性操作大量数据。
• 06.14 21:51:06
  发表了文章 2024-06-14 21:51:06

  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文件。注意，某些特定需求可能需额外工具。
• 06.13 21:08:35
  发表了文章 2024-06-13 21:08:35

  【后端面经】【NoSQL】ElasticSearch - 1 - 1 节点角色 写入数据

  【6月更文挑战第12天】中间件高可用与高性能通过冗余、负载均衡和优化实现。Elasticsearch节点有候选主节点、协调节点和数据节点等角色，可兼任或独立。数据写入涉及Buffer、Page Cache和磁盘，通过段合并优化资源使用。查询通过Commit Point识别新段，确保近实时搜索。
• 06.12 20:58:45
  发表了文章 2024-06-12 20:58:45

  设计模式-工厂模式-1-2

  【6月更文挑战第11天】工厂模式用于封装对象创建，但当load函数与工厂类耦合时，问题出现。为解决此问题，引入了工厂的工厂，如`RuleConfigParserFactoryMap`，它创建并缓存工厂对象，简化了代码修改。然而，过多的Factory类会增加复杂性，简单工厂模式在此类应用中更为适用。当对象创建逻辑复杂，需组装其他对象或避免if-else时，采用工厂方法模式。抽象工厂则处理多维度分类的对象创建。总结：工厂模式的核心价值在于封装变化、代码复用、隔离复杂性和控制复杂度，适用于创建逻辑复杂的情况，否则直接使用new操作即可。
• 06.11 21:07:39
  发表了文章 2024-06-11 21:07:39

  设计模式-工厂模式-1-1

  【6月更文挑战第10天】本文介绍了工厂模式的两种主要类型：简单工厂和工厂方法。简单工厂模式通过工厂类动态创建对象，例如根据配置文件后缀选择不同解析器。为提高可读性和复用性，可将创建逻辑封装到独立类中。当需添加新解析器时，可能涉及对工厂类的修改，但这在偶尔调整时可接受。工厂方法模式则通过多态消除if分支，增加扩展性，更符合开闭原则。当需要新增解析器时，只需创建实现特定接口的新工厂类。

  
• 06.10 13:07:01
  发表了文章 2024-06-10 13:07:01

  DDIA文档型和关系型 工厂模式总结

  【6月更文挑战第9天】文档型数据库在全量访问时效率高，但部分字段访问仍需加载全文档。不同数据库通过特定方式优化，如Spanner的嵌入式表，HBase和Cassandra的列族，图数据库的点边集中。关系型与文档型融合，如MySQL、PostgreSQL的JSON支持和RethinkDB的relational-link Joins。复杂对象创建可采用工厂模式，封装变化、复用代码、隔离和控制复杂度。简单场景下直接用`new`关键字即可。
• 06.09 21:56:17
  发表了文章 2024-06-09 21:56:17

  【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性

  【6月更文挑战第8天】网状模型是层次模型的扩展，允许节点有多重父节点，但导航复杂，需要预知数据库结构。关系模型将数据组织为元组和关系，强调声明式查询，解耦查询语句与执行路径，简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据，提供弱模式灵活性，但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系，适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read，写入时不校验，读取时解析，牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
• 06.08 22:19:47
  发表了文章 2024-06-08 22:19:47

  【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多

  【6月更文挑战第7天】该文探讨数据模型，比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本（如region_id代替"Greater Seattle Area"），可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中，需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂，若无Join，需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性，层次模型以树形结构限制了多对多关系处理。为克服层次模型局限，发展出了关系模型和网状模型。
• 06.07 21:57:02
  发表了文章 2024-06-07 21:57:02

  【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型

  【6月更文挑战第6天】关系模型是主流数据库模型，以二维表形式展示数据，支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战，如网状和层次模型，但关系模型仍占主导。然而，随着大数据增长和NoSQL的出现（如MongoDB、Redis），强调伸缩性、专业化查询和表达力，关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题，ORM框架缓解但未完全解决。文档模型（如JSON）提供更自然的嵌套结构，适合表示复杂关系，具备模式灵活性和更好的数据局部性。
• 06.06 20:34:40
  发表了文章 2024-06-06 20:34:40

  【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型

  【6月更文挑战第5天】本文探讨了数据模型的分析，关注点包括数据元素、关系及不同类型的模型（关系、文档、图）与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用，理想模型应具备简洁直观和可组合性。
• 06.05 21:29:01
  发表了文章 2024-06-05 21:29:01

  【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性

  【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题，指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题，Twitter采用混合策略，大部分用户推文扇出至粉丝主页时间线，而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟，其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展，以及自动和手动调整。文章强调了可维护性的重要性，包括可操作性、简单性和可演化性，以减轻维护负担和适应变化。此外，良好设计应减少复杂性，提供预测性行为，并支持未来改动。
• 06.04 21:32:08
  发表了文章 2024-06-04 21:32:08

  【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可扩展性

  【6月更文挑战第3天】可扩展性关乎系统应对负载增长的能力，但在产品初期过度设计可能导致失败。理解基本概念以应对可能的负载增长是必要的。衡量负载的关键指标包括日活、请求频率、数据库读写比例等。推特的扩展性挑战在于"扇出"，即用户关注网络的广度。两种策略包括拉取（按需查询数据库）和推送（预计算feed流）。推送方法在推特案例中更为有效，因为它减少了高流量时的实时计算压力。
• 06.03 21:16:31
  发表了文章 2024-06-03 21:16:31

  【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- part1 可靠性

  【6月更文挑战第2天】本书探讨现代数据系统，阐述其在信息社会中的关键作用，包括数据库、缓存、搜索引擎、流处理、批处理和消息队列等组成部分。随着技术发展，工具如Kafka、Spark和Redis等多功能组件使得系统设计更为复杂。面对可靠性、可扩展性和可维护性的挑战，书中强调了容错和韧性的重要性，区分了硬件故障、软件错误和人为错误，并提出了应对措施。可靠性关乎用户数据、企业声誉和生存，因此是系统设计的核心考量。
• 06.02 19:46:21
  发表了文章 2024-06-02 19:46:21

  【Redis从入门到入土】布隆过滤器简介、特点和原理

  【6月更文挑战第1天】布隆过滤器是一种节省内存的不确定数据结构，用于判断元素是否可能在一个集合中。它由位数组和多个哈希函数组成，能快速插入和查询，但存在误判风险：可能存在假阳性（判断存在但实际不存在），但绝无假阴性（判断不存在则确实不存在）。适用于大规模数据的去重问题，如电话号码判断、安全网站链接检查、黑名单和白名单校验。其工作原理是通过多个哈希函数将元素映射到位数组中，添加时设置相应位置为1，查询时所有位置都为1则可能存在，有0则肯定不存在。由于哈希冲突，可能导致误判，且一旦添加元素无法删除，以避免影响其他元素。

2024年05月

• 05.22 20:51:24
  发表了文章 2024-05-22 20:51:24

  【后端面经】【缓存】36｜Redis 单线程：为什么 Redis 用单线程而 Memcached 用多线程？-- Redis多线程

  【5月更文挑战第21天】Redis启用多线程后，主线程负责接收事件和命令执行，IO线程处理读写数据。请求处理流程中，主线程接收客户端请求，IO线程读取并解析命令，主线程执行后写回响应。业界普遍认为，除非必要，否则不建议启用多线程模式，因单线程性能已能满足多数需求。公司实际场景中，启用多线程使QPS提升约50%，或选择使用Redis Cluster以提升性能和可用性。
• 05.21 21:05:37
  发表了文章 2024-05-21 21:05:37

  【后端面经】【缓存】36｜Redis 单线程：为什么 Redis 用单线程而 Memcached 用多线程？-- Memcache + Redis 多线程

  【5月更文挑战第20天】Redis采用单线程模式以避免上下文切换和资源竞争，简化调试，且其性能瓶颈在于网络IO和内存，而非多线程。相比之下，Memcache使用多线程能更好地利用多核CPU，但伴随上下文切换和锁管理的开销。尽管Redis单线程性能不俗，6.0版本引入多线程以提升高并发下的IO处理能力。启用多线程后，Redis结合Reactor和epoll实现并发处理，提高系统性能。
• 05.20 21:58:47
  发表了文章 2024-05-20 21:58:47

  【后端面经】【缓存】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后引入多线程，但基本原理保持不变。
• 05.19 20:53:08
  发表了文章 2024-05-19 20:53:08

  【后端面经】【缓存】36｜Redis 单线程：为什么 Redis 用单线程而 Memcached 用多线程？--epoll调用和中断

  【5月更文挑战第18天】`epoll`包含红黑树和就绪列表，用于高效管理文件描述符。关键系统调用有3个：`epoll_create()`创建epoll结构，`epoll_ctl()`添加/删除/修改文件描述符，`epoll_wait()`获取就绪文件描述符。`epoll_wait()`可设置超时时间（-1阻塞，0立即返回，正数等待指定时间）。当文件描述符满足条件（如数据到达）时，通过中断机制（如网卡或时钟中断）更新就绪列表，唤醒等待的进程。
• 05.18 21:12:11
  发表了文章 2024-05-18 21:12:11

  【后端面经】【缓存】36｜Redis 单线程：为什么 Redis 用单线程而 Memcached 用多线程？

  【5月更文挑战第17天】Redis常被称为单线程，但实际上其在处理命令时采用单线程，但在6.0后IO变为多线程。持久化和数据同步等任务由额外线程处理，因此严格来说Redis是多线程的。面试时需理解Redis的IO模型，如epoll和Reactor模式，以及其内存操作带来的高性能。Redis使用epoll进行高效文件描述符管理，实现高性能的网络IO。在讨论Redis与Memcached的线程模型差异时，应强调Redis的单线程模型如何通过内存操作和高效IO实现高性能。

  
• 05.17 22:10:34
  发表了文章 2024-05-17 22:10:34

  【后端面经】【缓存】35｜缓存问题：怎么解决缓存穿透、击穿和雪崩问题？--主从切换方案

  【5月更文挑战第16天】该方案提出了解决Redis缓存穿透、击穿和雪崩问题的策略。通过使用两个或多个互为备份的Redis集群，确保在单个集群故障时，另一个可以接管。在故障发生时，业务会与备用集群保持心跳检测，并根据业务重要性分批转移流量，逐步增加对备用集群的依赖，同时监控系统稳定性。对于成本敏感的小型公司，可以采用低成本的单机或小规模自建Redis备份。此方案强调渐进式流量转移，以保护系统免受突然压力冲击。

  
• 05.16 20:40:58
  发表了文章 2024-05-16 20:40:58

  【后端面经】【缓存】35｜缓存问题：怎么解决缓存穿透、击穿和雪崩问题？---解决缓存击穿和雪崩、限流

  【5月更文挑战第15天】本文介绍了如何解决缓存击穿和雪崩问题。对于缓存击穿，采用singleflight模式，确保即使热点数据导致大量请求未命中缓存，也只允许一个请求真正查询数据，其他请求等待其结果。对于缓存雪崩，解决方案是在设置过期时间时添加随机偏移量，避免所有数据同时过期。偏移量应与过期时间成正比。此外，限流也是一个重要策略，可以在服务层和数据库层实施，以限制请求流量，保护数据库免受高并发压力。

  
• 05.15 22:04:18
  发表了文章 2024-05-15 22:04:18

  【后端面经】【缓存】35｜缓存问题：怎么解决缓存穿透、击穿和雪崩问题？---解决缓存穿透

  【5月更文挑战第14天】解决缓存穿透问题有两种策略。一是回写特殊值，当数据不存在时，在缓存中存储特殊值以标记，避免下次重复查询数据库。但此方法可能被恶意请求利用，浪费内存。二是使用布隆过滤器，预先判断数据是否存在，减少无效数据库查询。布隆过滤器虽有假阳性可能，但概率低，可接受。此外，可先查缓存再查布隆过滤器，优化正常请求的效率。两种方式各有优劣，实际应用需根据场景选择。
• 05.14 21:26:58
  发表了文章 2024-05-14 21:26:58

  【后端面经】【缓存】35｜缓存问题：怎么解决缓存穿透、击穿和雪崩问题？---缓存穿透、击穿和雪崩

  【5月更文挑战第13天】本文讨论了三种常见的缓存问题：穿透、击穿和雪崩。缓存穿透发生时，请求的数据既不在缓存也不在数据库，可能导致数据库崩溃。缓存击穿指数据仅存在于数据库，热点数据的大量未命中请求会压垮数据库。缓存雪崩则是大量缓存在同一时间过期，引发数据库瞬间压力过大。为应对这些问题，需了解Redis部署（如Cluster或Sentinel）、故障恢复策略，以及公司如何保护数据库。解决缓存问题的经验和预防措施是面试中的重要话题。

  
• 05.13 22:54:08
  发表了文章 2024-05-13 22:54:08

  01.【微服务架构】服务注册与发现：AP和CP，你选哪个？ -- 客户端容错

  【5月更文挑战第12天】客户端容错机制确保在服务端或注册中心故障时仍能正确发送请求。当服务端崩溃，由于延迟，客户端一段时间内仍会尝试发送请求。客户端应实施 failover 策略，即检测到调用失败后，切换到其他节点重试，并将故障节点从列表移除。延时通常等于服务端与注册中心心跳间隔加通知时间。若网络问题导致客户端无法访问服务端，客户端应发送心跳以检测服务端状态，成功则恢复，连续失败则视为崩溃。若客户端无法连接注册中心，它应使用本地缓存并考虑退出。

  
• 05.12 13:35:48
  发表了文章 2024-05-12 13:35:48

  【后端面经】【缓存】33｜缓存模式：缓存模式能不能解决缓存一致性问题？-03 Refresh Ahead + SingleFlight + 删除缓存 + 延迟双删

  【5月更文挑战第11天】Refresh Ahead模式通过CDC异步刷新缓存，但面临缓存一致性问题，可借鉴Write Back策略解决。SingleFlight限制并发加载，减少数据库压力，适合热点数据。删除缓存模式在更新数据库后删除缓存，一致性问题源于读写线程冲突。延迟双删模式两次删除，理论上减少不一致，但可能降低缓存命中率。选用模式需权衡优劣，延迟双删在低并发下较优。装饰器模式可用于实现多种缓存模式，无侵入地增强现有缓存系统。
• 05.11 21:45:19
  发表了文章 2024-05-11 21:45:19

  【后端面经】【缓存】33｜缓存模式：缓存模式能不能解决缓存一致性问题？-02 Write Through + Write Back

  【5月更文挑战第10天】`Write Through`是一种缓存策略，写操作仅需写入缓存，缓存负责更新数据库。异步版本可能丢失数据，而同步变种先写数据库再异步刷新缓存，减少丢数据风险。`Write Back`模式数据先写入缓存，过期时才写入数据库，可能导致数据丢失，但若使用Redis并确保高可用，可部分解决一致性问题。在特定条件下，如使用SETNX命令，能缓解一致性挑战。

  
• 05.10 21:30:14
  发表了文章 2024-05-10 21:30:14

  【后端面经】【缓存】33｜缓存模式：缓存模式能不能解决缓存一致性问题？

  【5月更文挑战第9天】面试准备中，熟悉缓存模式如Cache Aside、Read Through、Write Through、Write Back、Singleflight，以及删除缓存和延迟双删策略，能解决缓存一致性、穿透、击穿和雪崩问题。在自我介绍时展示对缓存模式的理解，例如Cache Aside模式，它是基础模式，读写由业务控制，先写数据库以保证数据准确性，但无法解决所有一致性问题。Read Through模式在缓存未命中时自动从数据库加载数据，可异步加载优化响应时间，但也存在一致性挑战。
• 05.09 20:23:41
  发表了文章 2024-05-09 20:23:41

  【后端面经】【消息队列】22 | 消息队列：消息队列可以用来解决什么问题？-03 扩展性+可用性+事件驱动思想

  【5月更文挑战第8天】 本文探讨了扩展性、可用性和事件驱动的概念。扩展性方面，消息队列简化了新下游的接入，而同步调用需要复杂的协调。在保证高可扩展性和研发效率的设计中，若无法使用消息队列，可以提供一致性抽象来减轻接入负担。可用性上，消息队列只需确保消息发送，而同步调用需保证所有下游成功，更易出错。事件驱动是一种通过事件进行组件间通信的架构模式，具有低耦合、高扩展性和高可用性，适合处理复杂流程。结合SAGA的事件驱动方案能实现高级分布式事务管理，即使实时性稍弱，但能保证事务的异步和高效执行。
• 05.08 21:09:42
  发表了文章 2024-05-08 21:09:42

  【后端面经】【消息队列】22 | 消息队列：消息队列可以用来解决什么问题？-02 超时场景+性能问题

  【5月更文挑战第7天】 本文介绍了电商中订单超时取消的处理方法，通过使用消息队列实现延时消息。当订单30分钟后未支付，消息队列将触发取消操作，但需注意并发问题，如采用分布式锁或乐观锁避免并发更新订单状态。乐观锁确保只有订单状态为未支付时才允许支付。主流消息队列如RocketMQ支持延迟消息，而Kafka不支持。 使用消息队列的好处在于解耦和提高系统性能、扩展性和可用性。同步调用会导致性能下降，因为必须等待所有调用完成。并发调用虽可提升性能，但仍逊于消息队列，且无法解决扩展性和可用性问题。
• 05.07 21:30:29
  发表了文章 2024-05-07 21:30:29

  【后端面经】【消息队列】22 | 消息队列：消息队列可以用来解决什么问题？-01

  【5月更文挑战第6天】消息队列的核心特性是异步、削峰和解耦，常用于日志处理和消息通讯，实现事件驱动架构。面试中可能涉及问题包括公司是否使用消息队列、应用场景、优缺点以及延时队列、秒杀架构等。秒杀场景下，消息队列将校验和库存扣减（轻量级）与订单创建（重量级）分隔，减轻系统压力，依赖于Redis性能。使用消息队列能解决高并发、复杂流程同步等问题。
• 05.06 21:00:54
  发表了文章 2024-05-06 21:00:54

  高并发推荐系统架构设计-1 基本介绍

  【5月更文挑战第5天】推荐系统是信息过滤工具，通过处理物料数据和行为日志，运用预处理、特征工程、算法模型学习用户兴趣，实现个性化推荐。在线架构包括AB分流、多路召回、模型排序和业务规则重排序。旧版线上架构由C++编写的API和engine服务组成，HTTP请求经SLB、Nginx、FastCGI到达服务程序，召回和排序服务处理推荐。存在并发瓶颈问题。
• 05.05 22:01:33
  发表了文章 2024-05-05 22:01:33

  01.【微服务架构】服务注册与发现：AP和CP，你选哪个？-- 高可用性

  【5月更文挑战第4天】注册中心通过心跳检测服务端状态，当心跳失败时预判服务端崩溃并通知客户端停止使用。心跳机制应对网络不稳定，需平衡重试次数与间隔，避免误判和延迟。即使如此，从服务端宕机到客户端获知仍存在时间差，因此需要客户端具备容错能力。
• 05.04 21:23:42
  发表了文章 2024-05-04 21:23:42

  01.【微服务架构】服务注册与发现：AP和CP，你选哪个？-- 服务端崩溃检测

  【5月更文挑战第3天】保证服务注册与发现的高可用需关注三个方面：服务端崩溃检测、客户端容错和注册中心选型。服务端崩溃时，注册中心通过心跳检测来识别，若心跳中断，立即通知客户端服务不可用，同时持续尝试恢复心跳。若一段时间后仍无法连接，则断定服务端彻底崩溃。这种方法兼顾及时故障通知和防止误判。
• 05.03 21:07:33
  发表了文章 2024-05-03 21:07:33

  01.【微服务架构】服务注册与发现：AP和CP，你选哪个？-- 面试准备+基本模型

  【5月更文挑战第2天】面试准备应涵盖公司所使用的注册中心类型及其优缺点，了解其集群规模、QPS和机器性能。准备故障排查及优化案例。若公司未采用微服务，可熟悉ZooKeeper、Nacos或etcd的基本特性以讨论注册中心概念。面试时，可将话题引导至服务注册与发现，如被问及特定中间件，阐述为何选择它并讨论优缺点。当涉及微服务高可用性时，可强调服务注册与发现的作用。基础模型部分，需解释服务上线和下线流程，提及注册数据和分组功能，并举例说明。最后，简述服务注册与发现的高可用挑战。
• 05.02 22:30:16
  发表了文章 2024-05-02 22:30:16

  01.【微服务架构】服务注册与发现：AP和CP，你选哪个？-- 服务注册与发现模型

  【5月更文挑战第1天】本文探讨了服务注册与发现的关键作用，在微服务架构中，这一概念常出现在面试中。文章深入讲解基础模型，包括服务端注册、心跳维持、客户端缓存及服务端下线流程，并强调了高可用性的重要性，涉及服务端崩溃检测、客户端容错和注册中心选型。通过分析客户端、注册中心和服务端之间的交互，提出如何应对潜在故障的策略，以构建稳定的微服务架构。

  
• 04.24 20:47:36
  发表了文章 2024-04-24 20:47:36

  淘汰算法

  【4月更文挑战第21天】这篇内容介绍了两种主流的淘汰算法：LRU（Least Recently Used）和LFU（Least Frequently Used）。LRU基于最近最少使用原则，当缓存满时，淘汰最近最久未使用的键。实现上通常使用链表和Java的LinkedHashMap。而LFU根据访问次数淘汰最不常使用的对象，可以按访问频率排序并选择淘汰。LFU的变种可能关注一定时间窗口内的访问次数，实现上更复杂。
• 04.23 21:26:05
  发表了文章 2024-04-23 21:26:05

  缓存命中率和过期机制的一般思路

  【4月更文挑战第20天】缓存命中率是评估缓存效果的关键，目标是达到90%以上，但某些频繁的小请求场景可能无法实现。过期机制可采用定时删除（精确但开销大）、延迟队列（精确但有队列开销）、懒惰删除（简单但时间不精确）或定期删除（简单但性能损耗不可控）。
• 04.22 21:01:12
  发表了文章 2024-04-22 21:01:12

  【MySQL实战笔记】07 | 行锁功过：怎么减少行锁对性能的影响？-02 死锁和死锁检测

  【4月更文挑战第19天】在高并发环境下，死锁发生在多个线程间循环等待资源时，导致无限期等待。MySQL中，死锁可通过`innodb_lock_wait_timeout`参数设置超时或`innodb_deadlock_detect`开启死锁检测来解决。默认的50s超时可能不适用于在线服务，而频繁检测会消耗大量CPU。应对热点行更新引发的性能问题，可以暂时关闭死锁检测（风险是产生大量超时），控制并发度，或通过分散记录减少锁冲突，例如将数据分拆到多行以降低死锁概率。
• 04.21 10:20:44
  发表了文章 2024-04-21 10:20:44

  【MySQL实战笔记】07 | 行锁功过：怎么减少行锁对性能的影响？-01

  【4月更文挑战第18天】MySQL的InnoDB引擎支持行锁，而MyISAM只支持表锁。行锁在事务开始时添加，事务结束时释放，遵循两阶段锁协议。为减少锁冲突影响并发，应将可能导致最大冲突的锁操作放在事务最后。例如，在电影票交易中，应将更新影院账户余额的操作安排在事务末尾，以缩短锁住关键行的时间，提高系统并发性能。
• 04.20 21:27:44
  发表了文章 2024-04-20 21:27:44

  【MySQL实战笔记】 06 | 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？-01

  【4月更文挑战第17天】MySQL的锁分为全局锁、表级锁和行锁。全局锁用于全库备份，可能导致业务暂停或主从延迟。不加锁备份会导致逻辑不一致。推荐使用`FTWRL`而非`readonly=true`因后者可能影响其他逻辑且异常处理不同。表级锁如`lock tables`限制读写并限定操作对象，常用于并发控制。元数据锁（MDL）在访问表时自动加锁，确保读写正确性。
• 04.19 21:35:39
  发表了文章 2024-04-19 21:35:39

  【MySQL实战笔记】 05 | 深入浅出索引（下）-02

  【4月更文挑战第16天】B+树索引利用最左前缀原则加速检索，即使只是部分字段匹配也能生效。联合索引[name-age]可按最左字段"张"找到记录，并遍历获取结果。优化索引顺序能减少维护成本，通常先考虑复用性。若需独立查询部分字段，则需权衡空间占用，如(name,age)与(age)。索引下推自MySQL5.6起，允许在索引遍历时预过滤条件，减少回表次数，提高效率。