- 博客(126)
- 收藏
- 关注
RSS订阅原创 【Go 每日一库】strings
功能推荐函数判断开头/结尾HasPrefixHasSuffix查找ContainsIndex替换ReplaceAll分割SplitFields拼接Join清理TrimTrimPrefix大小写ToLowerToUpperstrings包虽小，却是 Go 开发者的日常利器。掌握它，能让你的代码更简洁、更健壮、更高效！
2025-12-02 17:27:34
443
原创 2025-11-24 普通猿面试回顾【测试开发、python开发、AI应用开发】
整体来说，机会相比较疫情结束前后的市场，目前机会不是很多。自己的技能需要会的更多，对于技术有更深的思考，不断学习新东西的情况，机会还是挺多的，hr也会给你去争取好的薪资。再就是目前很多岗位他们的候选人比较多，对于你到岗时间有要求，这一块最好提前了解下离职时间大概多久，避免谈好后时间这块搞不定，措施机会再就是可以多看看一些机会，这不是一个听起来没用的，但是用处非常大的一句话，我们可以通过好的面试官来看到自己的技能上的不足。可能在目前来看自己的技能很高，但是在面试官哪里，你的技术真的很菜。
2025-11-24 12:06:19
47
原创 JWT 登录鉴权全流程详解
是一种开放标准（RFC 7519），用于在各方之间安全地传输信息。它常被用作用户登录后的身份凭证（替代传统的 Session）。登录→ 验证账号密码 → 生成带过期时间的 JWT请求→ 前端在 Header 中携带鉴权→ 后端验证签名 + 过期时间 + 用户状态安全→ 强密钥、短有效期、不存敏感信息、配合 HTTPS🌟记住：JWT 是工具，不是银弹。理解其原理，才能用得安全又高效。附：快速上手资源PyJWT库。
2025-11-18 23:29:06
351
原创 缓存一致性
缓存一致性（Cache Consistency）当数据库中的数据发生变化时，如何保证缓存中的数据与数据库保持同步，避免读到“脏数据”或“过期数据”。缓存提升性能，但引入了数据不一致的风险。在高并发场景下，一个看似简单的“更新用户信息”操作，可能因缓存处理不当，导致用户看到旧头像长达数分钟！一致性级别方案适用场景强一致分布式锁 + 同步更新极少（性能差）最终一致90%+ 场景弱一致仅设置 TTL非核心数据🌟记住没有完美的强一致性缓存方案。在性能与一致性之间做权衡，才是工程的艺术。
2025-11-16 21:43:27
1259
原创 Go 语言内存管理面试精讲：从分配到回收，彻底掌握 runtime 内存机制
✅ 回答：“逃逸分析是编译期优化技术，判断对象生命周期是否超出当前栈帧。若未逃逸，分配在栈上（高效、无 GC）；若逃逸，则分配在堆上。这减少了堆内存压力和 GC 频率。组件作用是否加锁mcacheP 级缓存，快速分配小对象❌ 无锁mcentral全局 mspan 池✅ 有锁mheap管理整个堆，分配大对象/span✅ 有锁决定栈 or 堆分配编译期🌟记住Go 的内存管理 = 分级缓存 + 无锁分配 + 精准 GC。理解它，你就能写出高性能、低延迟的 Go 服务。
2025-11-16 21:36:50
770
原创 Go 泛型（Generics）详解
/ 定义数字约束✅注意：约束本质是接口的联合类型（Union Types）。特性Go 泛型表现类型安全✅ 编译期检查性能✅ 零运行时开销代码复用✅ 显著减少重复学习成本⚠️ 需理解约束和类型参数适用场景容器、算法、中间件、工具库🌟记住泛型不是银弹，而是精准的手术刀。用对地方，事半功倍；滥用反而增加复杂度。
2025-11-16 21:35:55
1008
原创 并发模型详解：从多进程、多线程到协程与事件驱动
并发模型（Concurrency Model）是程序处理多个任务“同时进行”的方式。并发 ≠ 并行并发（Concurrency）：多个任务交替执行，宏观上“同时”，微观上可能串行（单核 CPU）；并行（Parallelism）：多个任务真正同时执行（多核 CPU）。在高并发服务（如 Web API、消息队列消费者）中，选择合适的并发模型直接影响系统的吞吐量、延迟和资源消耗。模型核心思想最佳场景Python 工具多进程多个独立执行单元CPU 密集型多线程共享内存的轻量级任务低并发 I/O。
2025-11-16 21:31:14
983
原创 RESTful API 设计规范：从入门到生产实践
是一种基于 HTTP 协议的软件架构风格，由 Roy Fielding 在 2000 年提出。指的是符合 REST 原则的 Web 接口设计。用统一的资源视角 + HTTP 方法语义，构建清晰、可扩展、易维护的 API。✅ 资源用复数名词，不用动词✅ 使用标准HTTP 方法表达操作✅ 合理嵌套路径，不超过 3 层✅ 列表接口支持分页、过滤、排序✅ 返回标准HTTP 状态码✅ 统一JSON 响应格式✅ API 路径带版本号（如/api/v1✅ 关键写操作保证幂等性🌟记住。
2025-11-16 21:24:56
806
原创 如何保证接口的幂等性？
幂等性（Idempotency）对同一个接口发起一次或多次相同请求，其结果完全一致，不会产生副作用。查询用户信息（GET） → 天然幂等取消一个“待支付”订单 → 成功后再次取消仍返回“已取消”，不报错扣减余额 10 元 → 调用两次就扣 20 元创建订单接口无去重 → 生成两个订单在分布式系统中，由于网络超时、客户端重试、消息重复投递等原因，幂等性不是“可选项”，而是“必选项”。保证接口幂等性，本质是“去重 + 状态判断”。创建类操作→ 用业务唯一键；状态变更→ 用状态机；表单提交。
2025-11-16 21:20:18
1382
原创 HTTP 与 HTTPS 的核心区别及 TLS 握手详解
HTTPS = HTTP + TLS/SSL 加密通道HTTP 是明文的，HTTPS 是加密的；HTTPS 的核心是 TLS 协议；TLS 握手通过非对称加密安全协商出对称密钥；现代 Web 必须全站 HTTPS，这是安全基线。🔒 安全是底线，不是选项。从今天起，让你的每一个 API、每一个页面都跑在 HTTPS 上。
2025-11-16 21:13:57
746
原创 Kubernetes【06】k8s-controller-manager
关键词： Kubernetes, K8s, kube-controller-manager, 控制器, 调谐循环, ReplicationController, Node Controller, 控制平面, CSDN传统运维中，我们通过一系列命令（如 , ）来管理系统，这称为“命令式操作”。Kubernetes 采用“声明式 API”：用户只需声明“我想要 3 个 Nginx 实例”，无需关心如何创建。这个“愿望”如何实现？答案就是 。它就像一个不知疲倦的“管家”，持续观察集群状态，一旦发现与用户声明的期望
2025-10-26 18:24:22
578
原创 Kubernetes【05】k8s-APIServer
摘要： 是 Kubernetes 集群的中央枢纽和唯一入口，所有组件（kubectl、控制器、调度器等）都通过它来读写集群状态。本文将深入剖析 kube-apiserver 的核心架构、工作原理与关键功能。从 RESTful API 设计、认证鉴权（Authentication & Authorization）流程，到准入控制（Admission Control）、数据存储（etcd）交互，全方位揭示其内部机制。通过实战演示 API 调用、配置高可用集群及性能调优技巧，助您彻底掌握这一 Kubernete
2025-10-25 15:15:41
926
原创 Kubernetes【02】k8s-pod从创建到终止的完整生命周期
Phase (相位)含义典型场景PendingPod已创建，但容器未全部运行调度中、拉取镜像、等待资源RunningPod已调度，至少一个容器在运行应用正常提供服务Succeeded所有容器成功退出，且不再重启Job任务成功完成Failed至少一个容器异常退出应用崩溃、配置错误、OOMKillUnknown无法获取Pod状态节点失联、kubelet故障。
2025-10-25 12:21:41
763
原创 Kubernetes【01】k8s的工作机制是什么
你不告诉 K8s “怎么做”（How），而是告诉它“最终要成什么样”（What）。例如：你声明“我要运行 3 个 Nginx 实例”，K8s 自己决定如何创建、在哪创建、如何维护。我们可以将 K8s 的工作机制总结为一个自动化闭环系统用户声明期望状态↓kube-apiserver 接收并持久化到 etcd↓控制器监听 etcd，发现“当前 ≠ 期望”↓控制器发起调度、创建、删除等动作↓kube-scheduler 为 Pod 选择节点↓。
2025-10-07 17:28:56
699
原创 Kubernetes【00】是什么？它有什么用？
Kubernetes是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用。名字中的 “K8s” 是一种缩写方式：K 和 s 之间有 8 个字母（ubernete），因此得名 K8s。传统运维使用 K8s 后手动部署、易出错声明式配置，自动化部署扩容靠人工，响应慢自动扩缩容，秒级响应服务故障需手动恢复自我修复，高可用保障环境不一致，“在我机器上能跑”环境一致，一次构建，处处运行多云管理复杂统一编排，跨云可移植一句话总结。
2025-10-07 17:20:08
691
原创 缓存引入的优缺点
缓存（Cache）是一种临时存储机制，把“计算耗时”或“读取慢”的数据保存在更快的存储介质中，下次直接读取，避免重复计算或查询。✅Redis（内存数据库）✅Memcached✅本地缓存（如✅浏览器缓存要不要✅ 要用于热点数据❌ 不要缓存所有数据✅ 要处理缓存穿透/雪崩/击穿❌ 不要假设数据100%一致✅ 要监控和降级❌ 不要在小项目过度设计缓存不是“银弹”，而是一把双刃剑。用得好，系统性能飞升；用不好，数据错乱、系统崩溃。理解它的优点，更要敬畏它的风险。
2025-09-21 22:16:53
979
原创 什么是吞吐量？
吞吐量是衡量系统性能的“心脏指标”。什么是吞吐量如何测量它如何优化它高吞吐量 ≠ 高复杂度，而是合理的设计 + 正确的工具 + 持续的优化。从今天开始，当你写完一个接口，不妨问自己一句：“这个接口，能扛住多少QPS？
2025-09-21 21:16:36
912
原创 什么是鲁棒性？
鲁棒性不是某个高级框架，而是一种工程思维永远假设：用户会输错、网络会断、文件会丢、服务会挂。一个鲁棒的系统，不会因为“意料之外”而崩溃，而是能优雅地应对混乱。作为Python开发者，从写每一行代码开始，就要有“鲁棒意识”。记住：优秀的程序员，不是写不出bug，而是让系统在有bug时也不崩溃。
2025-09-21 21:08:58
1949
原创 什么是“银弹”？
关键点说明🐺银弹 = 传说中的终极解决方案能一招解决所有问题🚫“没有银弹”是基本共识软件工程没有万能钥匙🔧技术是工具，不是救世主再牛的框架也需合理使用⚖️权衡利弊，避免过度依赖微服务、AI、低代码都不是银弹🛠️真正的“银弹”是：扎实的基本功 + 清晰的逻辑 + 持续学习而不是某个框架或工具下一次当你听到有人说：“只要用了XXX，所有问题就解决了！你可以微微一笑，说一句：别闹了，哪有什么银弹。真正的高手，从不迷信银弹，而是用合理的工具，解决具体的问题。
2025-09-20 20:03:45
1163
原创 为什么需要分库分表？
把原来的一个数据库，拆成多个数据库；把原来的一张大表，拆成多张小表。关键点说明🔍本质是“化整为零”把大问题拆成小问题并行处理⚖️不是银弹带来复杂性，需权衡利弊🧱先优化，再拆分索引、缓存、读写分离优先📈为增长而设计架构要能支撑未来1-2年业务发展分库分表不是高不可攀的技术，而是应对数据增长的必然选择。作为Python开发者，你不需要一开始就掌握分布式架构，但必须理解它的原理和适用场景。能用简单方法解决的，就不要过度设计；但当系统真的“长大”了，也要有勇气重构和拆分。
2025-09-20 19:59:29
1202
原创 什么是幂等性？
幂等性（Idempotence）是指：同一个操作执行一次或多次，产生的结果是一样的。做一次和做一百次，效果没区别。这就像你按电梯按钮——按一次，灯亮了；再按99次，灯还是亮的，不会变两盏灯。这个“亮灯”操作就是幂等的。要点说明✅ 幂等 = 多次执行结果一致不管调用多少次，系统状态不变✅GETPUTDELETE天生幂等设计API时优先考虑它们❌POST默认不幂等需要加等机制✅ 幂等性提升系统健壮性防止网络重试导致的数据错误✅ 转行者也必须掌握是API设计的基本素养。
2025-09-20 18:41:02
769
原创 面试｜Mysql｜DELETE、DROP、TRUNCATE的区别
你的需求推荐命令删除某些符合条件的行DELETEWHERE快速清空整张表，重置自增列彻底删除表及其所有结构DROP TABLEDELETETRUNCATEDROP虽然都与“删除”有关，但它们的威力和影响范围完全不同。理解它们的区别，不仅能避免“删库跑路”的悲剧，还能让你的数据库操作更加高效和安全。DELETE是“手术刀”，精准切除。TRUNCATE是“清道夫”，快速清空。DROP是“爆破手”，彻底摧毁。合理使用，方能游刃有余。
2025-09-13 13:44:01
915
原创 面试｜Python｜静态方法和类方法的区别
你需要操作“类本身”（如工厂方法、访问类属性）。：你需要一个“属于这个类的工具函数”，且不依赖类或实例。和是Python面向对象编程的利器。正确使用它们，不仅能提升代码的可读性和可维护性，还能体现你对Python设计哲学的深刻理解。用类方法创建灵活的工厂。用静态方法组织相关的工具函数。掌握这两者的区别，你的Python代码将更加专业和优雅。
2025-09-13 13:38:23
1110
原创 面试｜Python｜函数传参是值传递还是引用传递？
Python函数传参的本质是“传递对象引用的副本”。如果对象是可变的，函数内对其内容的修改会反映到外部。如果对象是不可变的，任何“修改”都会创建新对象，不影响外部。重新赋值只会改变局部变量的指向，不会影响外部变量。Python的参数传递机制看似复杂，实则遵循其“一切皆对象”的简洁设计。理解“传递对象引用”这一核心概念，结合对象的可变性分析，就能从容应对各种传参场景。“都不是，它是传递对象引用。掌握这一点，你不仅解决了参数传递的疑惑，也向深入理解Python的内存模型迈出了重要一步。
2025-09-13 13:33:53
1218
原创 B+树是怎么组织数据的？数据的顺序一定是从左到右递增的吗？
B+树作为数据库核心索引结构，其有序性是支撑高效查询的关键。本文解析了B+树的数据组织方式：非叶子节点作为索引层，叶子节点存储数据并通过双向链表连接。重点阐明叶子节点的键值严格遵循从左到右递增原则，这是保证搜索正确性、范围查询效率和动态维护的基础。文章还探讨了顺序性的维护机制，并指出逻辑顺序不等同于物理存储顺序。最后以MySQL聚簇索引为例，说明B+树有序性在实际数据库中的高效应用。B+树通过有序链表将随机访问转化为顺序访问，成为数据库索引的首选结构。
2025-08-31 21:35:12
696
原创 深入理解ZAB协议：ZooKeeper如何高效处理读写请求
ZAB 协议通过Leader 主导的原子广播机制，实现了 ZooKeeper 的高可用与强一致性。写请求：必须经 Leader，通过 Zxid 保证顺序，过半提交。读请求：本地快速响应，提升性能。Zxid：逻辑时钟，协调状态与选举。通过本文的原理剖析与 Python 模拟实现，相信你已对 ZAB 协议有了更深入的理解。掌握 ZAB，不仅是理解 ZooKeeper 的钥匙，更是迈向分布式系统设计的必经之路。
2025-08-31 21:20:42
1054
原创 ZAB协议深度解析：从故障中恢复
本文深入解析了ZooKeeper的核心协议ZAB（ZooKeeper Atomic Broadcast）的故障恢复机制。ZAB协议通过选举阶段、发现与同步阶段、广播阶段三部分实现高可用性，其中关键在于基于ZXID的Leader选举和前向同步策略。文章对比了ZAB与Paxos、Raft的差异，并总结了分布式系统设计的四大启示：状态收敛、数据完整性、任期机制和事务日志的重要性。ZAB协议的优雅设计展现了如何在分布式系统中实现从混乱到有序的恢复过程。
2025-08-31 21:10:47
715
原创 ZAB协议之主节点崩溃了怎么办？
本文深入解析了ZooKeeper的ZAB协议在Leader节点崩溃时的恢复机制。当Leader失效后，集群通过心跳检测触发选举流程，基于zxid和Server ID选出新Leader。恢复过程分为发现阶段（收集各节点最后处理的zxid）和同步阶段（补发缺失日志或回滚未提交事务），确保数据一致性。ZAB通过多数派确认、全局递增zxid和epoch机制，保障已提交事务不丢失且未提交事务不误提交，最终使集群重新进入广播模式恢复服务。该机制体现了分布式系统应对单点故障的健壮性，在短暂不可用后能自动恢复，维持数据一致
2025-08-27 23:17:58
916
原创 分布式之ZAB协议：如何实现操作的全局顺序性？
ZAB协议作为ZooKeeper的核心机制，通过全局唯一的zxid（48位epoch+16位counter）和单一Leader模式，为分布式系统提供严格的操作顺序保证。关键设计包括：1）集中式zxid分配确保全局可排序；2）Leader广播提案并按多数派确认提交；3）崩溃恢复时通过epoch递增和日志同步维持顺序连续性。这种顺序性支撑了分布式锁、选主等关键功能，相比Paxos更专注于状态机复制场景。实践建议：写操作需通过Leader，合理设置超时处理Leader切换，并注意读操作不参与ZAB流程。
2025-08-27 23:10:57
1246
原创 分布式系统基石：深入理解BASE理论
BASE理论是分布式系统设计的核心原则，强调牺牲强一致性（ACID）来换取高可用性和性能。它包含三大特性：基本可用（核心功能保底）、软状态（允许中间态）和最终一致性（数据最终同步）。通过Python+RabbitMQ的电商库存案例，演示了如何用消息队列实现最终一致性。BASE适用于高并发场景（如电商秒杀），但需注意幂等性、重试机制和监控。该理论是分布式系统在可用性与一致性之间的智慧权衡，通过异步通信等机制实现系统健壮性。
2025-08-27 22:30:53
841
原创 深入剖析分布式事务基石：两阶段提交（2PC）
两阶段提交（2PC）协议是分布式事务领域的一座丰碑。它清晰地揭示了在分布式环境下实现强一致性的基本思路和巨大挑战。深入理解2PC的原理、流程和致命缺陷，是掌握更高级、更实用的分布式事务解决方案（如TCC、Saga、消息队列）的。
2025-08-25 22:03:23
851
原创 学习记录|深入理解分布式系统基石：CAP 理论
摘要：CAP理论是分布式系统设计的核心原则，指出在Consistency（一致性）、Availability（可用性）和Partition tolerance（分区容错性）三者中只能同时满足两项。由于分区容错是分布式系统的必备特性，实际选择通常是在CP（强一致性）和AP（高可用性）之间权衡。CP系统优先保证数据一致性但可能牺牲可用性，适用于金融等关键场景；AP系统优先保证服务可用性但可能暂时牺牲一致性，适用于社交网络等场景。理解CAP理论有助于在分布式系统设计中做出合理的技术选型和架构决策。
2025-08-25 21:26:00
1161
原创 Redis 是如何保证数据不丢失的？
Redis 数据可靠性保障机制解析 Redis 通过多层次策略确保数据可靠性：1）持久化机制提供 RDB 快照和 AOF 日志两种方式，4.0+版本支持混合持久化（RDB+AOF）兼顾恢复速度与数据安全；2）主从复制实现数据冗余，支持全量/部分同步；3）高可用架构包含 Sentinel（自动故障转移）和 Cluster（数据分片+高可用）两种方案。生产环境建议开启混合持久化并部署主从复制，结合 Sentinel/Cluster 构建完整防护体系，同时定期远程备份 RDB 文件。这些机制在内存速度与数据安全间
2025-08-25 21:07:25
1252
原创 MySQL 主备复制：深入剖析数据一致性的实现原理
MySQL主备一致性对高可用系统至关重要。本文剖析了MySQL保障主备一致性的核心技术：1) 基于Binlog和Relay Log的异步复制机制；2) 两阶段提交(2PC)确保Redo Log与Binlog一致性；3) 半同步复制减少数据丢失；4) GTID简化复制管理；5) 多线程复制提升性能；6) 校验工具监测不一致。这些技术共同构建了MySQL主备数据同步的完整解决方案，涉及日志传输、事务协调、同步机制等多个层面，既保证了数据可靠性，又兼顾了系统性能。理解这些机制对运维MySQL集群和设计高可用架构具
2025-08-24 23:47:23
729
原创 MySQL 两阶段提交（2PC）：深入理解事务持久性与崩溃恢复的基石
本文深入剖析了MySQL两阶段提交（2PC）机制如何保证数据一致性。在InnoDB和Server层的"双日志"架构下，2PC通过协调Redo Log和Binlog的写入顺序解决数据一致性问题：先Prepare阶段将Redo Log标记为准备状态并落盘，再Commit阶段确保Binlog写入成功后才最终提交。崩溃恢复时以Binlog完整性为仲裁依据，保证主从数据一致。文章还分析了2PC的设计哲学、性能代价及优化策略（如组提交和参数调优），揭示了这一机制在确保数据安全与性能平衡中的关键作用。
2025-08-24 22:33:33
1130
原创 MySQL临键锁（Next-Key Lock）触发全解析：场景、陷阱与最佳实践
摘要：MySQL的RR隔离级别通过临键锁（Next-Key Lock）实现可重复读和防止幻读，它是记录锁与间隙锁的组合。临键锁在SELECT FOR UPDATE、UPDATE/DELETE等操作中自动触发，但不当使用会导致性能下降和死锁问题。主键/唯一索引查询通常只加记录锁，而普通索引查询会加临键锁，无索引查询可能锁表。解决方案包括强制使用高效索引、优先使用主键锁定、考虑READ COMMITTED级别、缩短事务周期等。正确理解临键锁的触发机制对优化MySQL并发性能至关重要。
2025-08-24 22:19:31
1249
原创 MySQL间隙锁（Gap Lock）深度解析：避免幻读的关键机制
摘要：间隙锁（Gap Lock）是InnoDB在REPEATABLE READ隔离级别下防止幻读的机制，锁定索引记录间的间隙而非记录本身。它与记录锁组合形成临键锁（Next-Key Lock），主要针对非唯一索引的等值查询和所有索引的范围查询。主键或唯一索引的等值查询不加间隙锁。间隙锁虽能保证数据一致性，但会增加死锁风险和降低并发性能。可通过降低隔离级别、优化索引设计或使用特定查询语法来减少其影响。
2025-08-24 22:00:00
985
1
原创 深入解析MySQL临键锁(Next-Key Lock)：原理、应用与优化指南
MySQL临键锁机制解析与应用实践 临键锁是InnoDB存储引擎在可重复读隔离级别下解决幻读问题的核心机制。作为记录锁与间隙锁的组合体，它通过锁定索引记录及之前的间隙，有效防止其他事务插入符合条件的新记录。本文深入剖析了临键锁的工作原理，包括其左开右闭的锁定范围特性，以及在不同查询条件下的三种退化模式（标准临键锁、记录锁、间隙锁）。通过典型场景案例展示了临键锁的实际应用效果，并提供了索引设计、事务控制等优化建议。文章还澄清了常见误区，帮助开发者正确理解和使用临键锁，提升高并发场景下的数据库性能。
2025-08-17 20:46:04
827
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人