暂时未有相关云产品技术能力~
暂无个人介绍
【5月更文挑战第10天】`Write Through`是一种缓存策略,写操作仅需写入缓存,缓存负责更新数据库。异步版本可能丢失数据,而同步变种先写数据库再异步刷新缓存,减少丢数据风险。`Write Back`模式数据先写入缓存,过期时才写入数据库,可能导致数据丢失,但若使用Redis并确保高可用,可部分解决一致性问题。在特定条件下,如使用SETNX命令,能缓解一致性挑战。
【5月更文挑战第5天】推荐系统是信息过滤工具,通过处理物料数据和行为日志,运用预处理、特征工程、算法模型学习用户兴趣,实现个性化推荐。在线架构包括AB分流、多路召回、模型排序和业务规则重排序。旧版线上架构由C++编写的API和engine服务组成,HTTP请求经SLB、Nginx、FastCGI到达服务程序,召回和排序服务处理推荐。存在并发瓶颈问题。
【5月更文挑战第9天】面试准备中,熟悉缓存模式如Cache Aside、Read Through、Write Through、Write Back、Singleflight,以及删除缓存和延迟双删策略,能解决缓存一致性、穿透、击穿和雪崩问题。在自我介绍时展示对缓存模式的理解,例如Cache Aside模式,它是基础模式,读写由业务控制,先写数据库以保证数据准确性,但无法解决所有一致性问题。Read Through模式在缓存未命中时自动从数据库加载数据,可异步加载优化响应时间,但也存在一致性挑战。
【5月更文挑战第13天】本文讨论了三种常见的缓存问题:穿透、击穿和雪崩。缓存穿透发生时,请求的数据既不在缓存也不在数据库,可能导致数据库崩溃。缓存击穿指数据仅存在于数据库,热点数据的大量未命中请求会压垮数据库。缓存雪崩则是大量缓存在同一时间过期,引发数据库瞬间压力过大。为应对这些问题,需了解Redis部署(如Cluster或Sentinel)、故障恢复策略,以及公司如何保护数据库。解决缓存问题的经验和预防措施是面试中的重要话题。
【5月更文挑战第8天】 本文探讨了扩展性、可用性和事件驱动的概念。扩展性方面,消息队列简化了新下游的接入,而同步调用需要复杂的协调。在保证高可扩展性和研发效率的设计中,若无法使用消息队列,可以提供一致性抽象来减轻接入负担。可用性上,消息队列只需确保消息发送,而同步调用需保证所有下游成功,更易出错。事件驱动是一种通过事件进行组件间通信的架构模式,具有低耦合、高扩展性和高可用性,适合处理复杂流程。结合SAGA的事件驱动方案能实现高级分布式事务管理,即使实时性稍弱,但能保证事务的异步和高效执行。
【5月更文挑战第7天】 本文介绍了电商中订单超时取消的处理方法,通过使用消息队列实现延时消息。当订单30分钟后未支付,消息队列将触发取消操作,但需注意并发问题,如采用分布式锁或乐观锁避免并发更新订单状态。乐观锁确保只有订单状态为未支付时才允许支付。主流消息队列如RocketMQ支持延迟消息,而Kafka不支持。 使用消息队列的好处在于解耦和提高系统性能、扩展性和可用性。同步调用会导致性能下降,因为必须等待所有调用完成。并发调用虽可提升性能,但仍逊于消息队列,且无法解决扩展性和可用性问题。
【5月更文挑战第3天】保证服务注册与发现的高可用需关注三个方面:服务端崩溃检测、客户端容错和注册中心选型。服务端崩溃时,注册中心通过心跳检测来识别,若心跳中断,立即通知客户端服务不可用,同时持续尝试恢复心跳。若一段时间后仍无法连接,则断定服务端彻底崩溃。这种方法兼顾及时故障通知和防止误判。
【5月更文挑战第2天】面试准备应涵盖公司所使用的注册中心类型及其优缺点,了解其集群规模、QPS和机器性能。准备故障排查及优化案例。若公司未采用微服务,可熟悉ZooKeeper、Nacos或etcd的基本特性以讨论注册中心概念。面试时,可将话题引导至服务注册与发现,如被问及特定中间件,阐述为何选择它并讨论优缺点。当涉及微服务高可用性时,可强调服务注册与发现的作用。基础模型部分,需解释服务上线和下线流程,提及注册数据和分组功能,并举例说明。最后,简述服务注册与发现的高可用挑战。
【5月更文挑战第1天】本文探讨了服务注册与发现的关键作用,在微服务架构中,这一概念常出现在面试中。文章深入讲解基础模型,包括服务端注册、心跳维持、客户端缓存及服务端下线流程,并强调了高可用性的重要性,涉及服务端崩溃检测、客户端容错和注册中心选型。通过分析客户端、注册中心和服务端之间的交互,提出如何应对潜在故障的策略,以构建稳定的微服务架构。
【4月更文挑战第20天】缓存命中率是评估缓存效果的关键,目标是达到90%以上,但某些频繁的小请求场景可能无法实现。过期机制可采用定时删除(精确但开销大)、延迟队列(精确但有队列开销)、懒惰删除(简单但时间不精确)或定期删除(简单但性能损耗不可控)。
【4月更文挑战第19天】在高并发环境下,死锁发生在多个线程间循环等待资源时,导致无限期等待。MySQL中,死锁可通过`innodb_lock_wait_timeout`参数设置超时或`innodb_deadlock_detect`开启死锁检测来解决。默认的50s超时可能不适用于在线服务,而频繁检测会消耗大量CPU。应对热点行更新引发的性能问题,可以暂时关闭死锁检测(风险是产生大量超时),控制并发度,或通过分散记录减少锁冲突,例如将数据分拆到多行以降低死锁概率。
【4月更文挑战第17天】MySQL的锁分为全局锁、表级锁和行锁。全局锁用于全库备份,可能导致业务暂停或主从延迟。不加锁备份会导致逻辑不一致。推荐使用`FTWRL`而非`readonly=true`因后者可能影响其他逻辑且异常处理不同。表级锁如`lock tables`限制读写并限定操作对象,常用于并发控制。元数据锁(MDL)在访问表时自动加锁,确保读写正确性。
【4月更文挑战第21天】这篇内容介绍了两种主流的淘汰算法:LRU(Least Recently Used)和LFU(Least Frequently Used)。LRU基于最近最少使用原则,当缓存满时,淘汰最近最久未使用的键。实现上通常使用链表和Java的LinkedHashMap。而LFU根据访问次数淘汰最不常使用的对象,可以按访问频率排序并选择淘汰。LFU的变种可能关注一定时间窗口内的访问次数,实现上更复杂。
【4月更文挑战第15天】在MySQL的InnoDB引擎中,锁通过索引实现,主要锁定叶子节点。查询使用哪个索引,就锁哪个;无索引时锁全表。若查询值不存在,InnoDB会构造临键锁阻止插入。锁在事务结束(Rollback或Commit)时释放。乐观锁在尝试更新时检查数据变化,适合读多写少场景,悲观锁一开始就加锁,适用于写多读少。InnoDB支持行锁和表锁,行锁依赖索引。共享锁允许多个线程加同类型锁,排它锁则独占。
【4月更文挑战第12天】数据库优化涉及硬件升级、操作系统调整、服务器/引擎优化和SQL优化。SQL优化目标是减少磁盘IO和内存/CPU消耗。`EXPLAIN`命令用于检查SQL执行计划,关注`type`、`possible_keys`、`key`、`rows`和`filtered`字段。设计索引时考虑外键、频繁出现在`where`、`order by`和关联查询中的列,以及区分度高的列。大数据表改结构需谨慎,可能需要停机、低峰期变更或新建表。面试中应准备SQL优化案例,如覆盖索引、优化`order by`、`count`和索引提示。优化分页查询时避免大偏移量,可利用上一批的最大ID进行限制。
【4月更文挑战第7天】数据库通过视图实现事务隔离,不同隔离级别如读未提交、读已提交、可重复读和串行化采用不同策略。以可重复读为例,MySQL使用多版本并发控制(MVCC),每个事务有其独立的视图。回滚日志在无更早视图时被删除。长事务可能导致大量存储占用,应避免。事务启动可显式用`begin`或设置`autocommit=0`,但后者可能意外开启长事务。建议使用`autocommit=1`并显式管理事务,若需减少交互,可使用`commit work and chain`。
【4月更文挑战第5天】两阶段提交是为确保`redo log`和`binlog`逻辑一致,避免数据不一致。若先写`redo log`, crash后数据可能丢失,导致恢复后状态错误;若先写`binlog`,crash则可能导致重复事务,影响数据库一致性。一天一备相较于一周一备,能缩短“最长恢复时间”,但需权衡额外的存储成本。
【4月更文挑战第3天】MySQL执行SQL的流程包括连接器、查询缓存、分析器、优化器和执行器。连接器负责建立连接、权限验证,查询缓存(MySQL 8.0已移除)存储查询结果,分析器解析SQL确保语法正确,优化器选择最佳索引和查询路径,执行器执行查询并管理权限。连接器使用长连接可能导致内存问题,可定期断开或使用`mysql_reset_connection`。注意,更新操作会导致查询缓存失效。
【4月更文挑战第4天】SQL更新语句执行涉及查询和日志模块,主要为`redo log`和`binlog`。`redo log`先写日志再写磁盘,保证`crash-safe`;`binlog`记录逻辑日志,支持所有引擎,且追加写入。执行过程分为执行器查找数据、更新内存和`redo log`(prepare状态)、写入`binlog`、提交事务(`redo log`转commit)。两阶段提交确保日志逻辑一致,支持数据库恢复至任意时间点。
【4月更文挑战第2天】本文探讨了评论系统的树形结构设计,提出了四种方法:邻接表、分段式path、Nested Set和Closure Table。针对评论业务功能,如加载评论页和查看回复,优先考虑邻接表和分段式path。采用邻接表思路,设计了评论表结构,包括Uid、Biz、BizID、RootID、PID、Content、索引和级联删除规则。同时提到了索引设计,如Uid、Biz+BizID、PID和Ctime/Utime,以优化查询性能。
【2月更文挑战第17天】2645. 构造有效字符串的最小插入数(动态规划 贪心 滚动数组优化 C++ Go)
【2月更文挑战第21天】软件质量保证与测试知识点总结
【2月更文挑战第15天】微服务架构下服务注册的几种方式
【2月更文挑战第18天】2696. 删除子串后的字符串最小长度(模拟 栈 C++ Go实现栈)
【2月更文挑战第16天】注册中心机制
【2月更文挑战第13天】ElasticSearch的HTTP操作 和Go客户端操作
【2月更文挑战第10天】Golang里空结构体struct{}的介绍和使用
【2月更文挑战第12天】随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件,主要以流量为切入点,从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。
【2月更文挑战第9天】解决使用interface{}解析json数字会变成科学计数法的问题
【2月更文挑战第8天】Golang拼接字符串性能对比
【2月更文挑战第6天】高效Go编程之格式化+代码注释+命名+分号+控制结构
【2月更文挑战第5天】Go语言面试题15个问题
【4月更文挑战第18天】MySQL的InnoDB引擎支持行锁,而MyISAM只支持表锁。行锁在事务开始时添加,事务结束时释放,遵循两阶段锁协议。为减少锁冲突影响并发,应将可能导致最大冲突的锁操作放在事务最后。例如,在电影票交易中,应将更新影院账户余额的操作安排在事务末尾,以缩短锁住关键行的时间,提高系统并发性能。
【2月更文挑战第1天】思考一下如何用Redis实现去重的任务队列,主要有List 、List + Set/Hash/Bloom Filter、ZSet、Lua和开源库等方式。
【4月更文挑战第6天】MySQL事务的隔离性确保数据操作的完整性和一致性,ACID原则包括原子性、一致性、隔离性和持久性。事务隔离级别有四种:读未提交、读提交、可重复读和串行化,分别解决并发问题如脏读、不可重复读和幻读。不同隔离级别在效率和安全性间权衡,例如读未提交允许未提交变更可见,而串行化通过锁保证安全但可能降低效率。在不同隔离级别下,事务看到的数据状态会有所变化,例如在可重复读级别,事务始终看到初始数据,而在串行化级别,事务会等待其他事务完成再继续,避免数据冲突。
【2月更文挑战第11天】使用泛型对数组进行去重
【2月更文挑战第7天】ElasticSearch 入门 简介 ElasticSearch 的基本概念 ElasticSearch 的查询流程 ElasticSearch 的更新流程
【2月更文挑战第4天】分析Golang高性能内存缓存库BigCache设计
【2月更文挑战第3天】一个类只允许创建一个对象或实例,而且自行实例化并向整个系统提供该实例,这个类就是一个单例类,它提供全局访问的方法。这种设计模式叫单例设计模式,简称单例模式。
【2月更文挑战第2天】本文主要介绍了分布式任务调度的几种实现,使用Redis实现分布式锁方案,使用MySQL实现任务调度,开源框架 XXL-JOB等方案,最后需要考虑到负载均衡的问题。
【力扣】1106. 解析布尔表达式(C++/Go 栈的应用)
【力扣】1620. 网络信号最好的坐标 (Go 遍历)
【力扣】1662. 检查两个字符串数组是否相等(Go 一行代码版)
【力扣】1700. 无法吃午餐的学生数量(思维 Go/C++实现)
【Go开发】go-redis快速入门
C++智能指针
【力扣 · 每日一题】1582. 二进制矩阵中的特殊位置 (枚举 + Go实现)
2022年牛客多校第2场 J . Link with Arithmetic Progression (三分+枚举)
2022杭电多校第二场1011 DOS Card(线段树)
ECNA2013 C . Playing Fair with Cryptography (模拟)