分布式一致性与共识协议：从 CAP、Paxos、Raft 到 PBFT、PoW 与 ZAB

分布式系统将数据和计算分散到多个节点后，真正困难的并不是让节点之间发送消息，而是在网络分区、节点宕机、并发写入，甚至恶意节点参与的条件下，让系统对外呈现可理解、可恢复的行为。本文围绕这一问题，将 CAP、ACID、BASE 与二阶段提交等事务机制，与 Paxos、Multi-Paxos、Raft、ZAB、PBFT、PoW 等共识协议联系起来，同时讨论一致哈希、Gossip、反熵和 Quorum N
Architecture
#分布式系统 #CAP #BASE #Paxos #Raft #Gossip #PBFT #ZAB

分布式一致性协议与算法工程实践：从 Raft、ZAB 到 PBFT、XA 与 TCC

分布式系统里的“一致性”并不是单一问题：复制状态机要保证节点对操作顺序达成共识，数据服务要决定读请求能否看到最新写入，跨数据库与跨业务系统还要处理事务原子性。不同问题对应的故障模型、协议机制与工程代价各不相同。本文把 Raft 与 HashiCorp Raft、ZooKeeper 的 ZAB 协议、拜占庭容错与 PBFT、MySQL XA、TCC，以及 InfluxDB Enterprise 的一
Architecture
#分布式系统 #Raft #PBFT #ZAB #一致性 #ZooKeeper #XA #TCC

Linux SSH 免密登录与批量主机管理：从 Passphrase、ssh-agent 到 SSH Config

简介在 Linux 服务器管理中，SSH 几乎是所有远程运维动作的基础。无论是日常登录服务器、远程执行命令、使用 scp 传输文件，还是通过 rsync 做增量同步，底层通常都依赖 SSH。 最开始接触 SSH 时，我们往往使用最直接的方式： 1ssh rocky@192.168.0.50 然后输入服务器密码。 这种方式对于一台服务器没有问题，但当需要长期管理多台机器时，问题会很快暴露出来： 1
Linux > 运维
#Rocky Linux #macOS #SSH #OpenSSH #ssh-agent #SSH Config #Passphrase #rsync #Linux 运维

Java 生产级工程实践：从函数式编程到故障诊断与 Kubernetes

写 Java 业务代码并不难，真正拉开工程能力差距的，往往是代码进入生产之后的那一段：如何用更清晰的方式表达业务逻辑，如何理解线程、内存、GC 与网络的真实运行状态，如何在没有 Debugger 的生产环境里留下证据并定位根因，以及应用迁移到 Kubernetes 后如何重新认识 CPU、内存、Pod 生命周期和故障现场。本文把这些问题放到同一条工程链路中，从 Java 8 的函数式编程讲到 JV
Java
#Java #JVM #Arthas #Kubernetes #Wireshark #Stream #Troubleshooting #MAT

Java 业务安全设计：从不信任客户端到幂等、注入防护与敏感数据保护

很多业务安全事故并不是因为缺少复杂的密码学算法，而是因为最基本的边界没有守住：服务端相信了客户端计算结果，把外部输入拼进了 SQL 或脚本，把用户 ID 当成普通参数接收，资金操作没有全链路幂等，敏感数据又以不合适的方式保存。本文从 Java 业务开发视角重新组织这些问题，建立一条从请求入口、身份与权限、资源防刷、资金幂等、注入防护，到密码、隐私数据和 TLS 传输的完整安全链路，并结合现代 Sp
Security
#Java #Spring Security #幂等 #Web 安全 #SQL 注入 #XSS #AES-GCM #TLS

Java 业务系统工程化设计：从反射、Spring 到缓存、异步与多存储架构

业务系统真正困难的地方，往往不是把一个接口写出来，而是让代码在长期演进、并发访问、依赖故障、版本升级和流量增长之后仍然保持可维护、可扩展、可恢复和可观测。本文从 Java 反射、泛型与注解的语言边界出发，逐步进入 Spring IoC/AOP、接口设计、缓存与异步可靠性、生产可观测性以及 MySQL、Redis、Elasticsearch、时序数据库协同设计，整理一套面向真实业务系统的工
Java
#Spring Boot #Spring #Java #Redis #RabbitMQ #NoSQL #Observability #API Design

Java 业务开发中的十类隐蔽陷阱：从对象判等到 OOM

Java 业务代码真正难排查的 Bug，往往不是复杂算法写错，而是一些“看起来理所当然”的语义在边界条件下突然失效：== 偶尔能正确比较包装类型、BigDecimal.equals 不认为 1.0 和 1 相等、subList 只是原 List 的视图、异步日志会丢数据、submit 会把线程池异常藏进 Future，甚至一个看似只是“放大限制”的 Tomcat 参数也可能把堆内存吃光。本文把对象
Java
#Spring Boot #Java #JVM #Logback #Collections #Jackson #BigDecimal #java.time

Java 业务开发常见陷阱：并发、池化、HTTP、事务与索引的工程化实践

Java 业务系统真正难处理的部分，往往不是把一个接口写通，而是在并发、超时、重试、资源耗尽和异常回滚同时发生时，仍然保证数据正确、吞吐稳定且问题可定位。本文围绕并发容器与锁、线程池、连接池、HTTP 调用、Spring 声明式事务和 MySQL 索引六条主线，重新组织这些看似分散的问题，并结合 JDK 21、Spring Framework 6.x、Spring Cloud OpenFeign、
Java
#Java #MySQL #并发编程 #HTTP #性能优化 #线程池 #连接池 #Spring事务

区块链应用与工程实践：从数字资产、交易所到 BaaS、供应链与 Tinychain

区块链真正进入工程实践后，问题很快就从“区块如何连接、共识如何工作”扩展到资产如何表示、交易所如何记账、钱包如何管理多条链、链上数据如何索引、身份和供应链怎样接入，以及一个最小区块链节点究竟由哪些模块组成。本文从数字资产出发，逐步串联交易平台、钱包服务、BaaS、数字身份、供应链和 Tinychain 实现，形成一套从业务应用到基础设施、再回到底层节点设计的完整区块链工程视角。
Blockchain
#区块链 #数字钱包 #数字资产 #数字货币交易所 #BaaS #DLT #供应链 #Tinychain

区块链系统设计进阶：性能、智能合约、共识、治理与公私链架构

区块链真正难理解的地方，不是哈希、签名或区块结构本身，而是这些机制放进一个开放分布式系统后产生的工程权衡：节点越开放，共识和数据传播越昂贵；执行能力越强，状态同步与安全边界越复杂；治理越自动化，投票权、激励与攻击面也越需要重新设计。本文从交易性能和“去中心化”的关系出发，串起智能合约与以太坊、Token 标准、公链项目的架构选择、联盟链与 Hyperledger、比特币扩容之争以及链上治理，并结合
Blockchain
#Blockchain #Ethereum #Bitcoin #Smart Contract #Consensus #Hyperledger #Scaling

区块链底层技术：P2P 网络、共识机制、密码学与账本模型

真正理解区块链，不能只停留在“分布式账本”和“不可篡改”几个概念上。一个能够运行的区块链系统，需要同时解决节点如何发现彼此、交易如何传播、恶意节点存在时如何达成共识、资产所有权如何通过密码学证明、历史数据如何组织，以及状态究竟采用 UTXO 还是账户模型表达。本文把这些原本分散的知识重新组织成一套完整技术体系，并结合 Bitcoin、Ethereum 等典型系统解释各层之间如何协作。
Blockchain
#区块链 #P2P #共识机制 #PoW #PoS #密码学 #UTXO

区块链基础原理：从分布式账本、共识机制到数字货币与钱包

区块链并不只是“把数据串成链”，也不等于比特币或数字货币。真正理解它，需要把 P2P 网络、密码学、交易模型、区块结构、共识机制、经济激励和数字资产放到同一个系统里观察。本文从中心化记账的问题出发，以比特币为主要样本，梳理一笔交易从钱包签名、网络广播、矿工打包到最终确认的完整过程，并进一步讨论 PoW、双花、钱包、Token、数字货币、联盟链、应用边界以及区块链工程选型。
Blockchain
#分布式系统 #区块链 #共识机制 #PoW #比特币 #数字货币 #数字钱包

RFC 10：Documentation Conventions——当技术讨论开始扩容，RFC 如何成为一套可运行的协作协议

RFC 10 没有定义一个网络报文，却解决了另一个同样真实的系统问题：当参与 ARPANET 协议设计的人和站点迅速增加时，技术意见怎样被唯一编号、稳定引用、可靠分发，又怎样避免“写成文档就自动变成权威结论”。它对 RFC 3 的修订幅度并不大，恰恰因此更值得读——真正发生变化的不是写作哲学，而是这套协作机制开始从几个人之间的工作笔记，向一个需要治理编号、参与者和分发拓扑的技术基础设施演化。
RFC
#RFC #Network Working Group #Documentation Conventions #Internet History #RFC Series

经典软件架构风格与子风格：数据流、调用返回、独立构件、虚拟机与仓库

软件架构风格关注的并不是某个具体框架，而是系统中构件如何组织、构件之间如何连接、数据怎样流动以及控制权如何转移。经典软件体系结构通常可以从数据流、调用/返回、独立构件、虚拟机和以数据为中心的仓库五个家族理解，并进一步细分为批处理、管道-过滤器、主程序-子程序、面向对象、分层、通信进程、事件系统、解释器、规则系统、数据库仓库和黑板等具体子风格。本文从构件、连接件、控制模型、数据模型、优缺点
Architecture
#软件架构 #架构风格 #管道过滤器 #分层架构 #事件驱动 #虚拟机 #黑板架构

软件架构方法论：ABSD、DSSA、SAAM、ATAM、CBAM 与 Architectural Thinking

软件架构并不是画出一张组件关系图就结束了。从领域共性提炼、架构设计，到质量属性评估、风险与权衡分析，再到成本收益决策，不同阶段需要解决完全不同的问题。本文系统整理 ABSD、DSSA、SAAM、ATAM、CBAM 与 Architectural Thinking，重点说明它们各自解决什么问题、核心流程是什么、彼此如何衔接，以及如何在真实软件项目中组合使用。
Architecture
#软件架构 #ABSD #DSSA #SAAM #ATAM #CBAM #Architectural Thinking

RPC 高级工程实践与源码脉络：异步、安全、可观测、流量治理与协议演进

RPC 真正进入生产环境之后，问题很快就会超出“如何完成一次远程方法调用”的范围：吞吐量为什么上不去、内部服务如何鉴权、跨服务异常怎样定位、大量超时任务怎样低成本调度、架构升级如何利用真实流量验证、隔离集群怎样快速扩容、没有接口 Jar 如何调用服务，以及新旧 RPC 协议如何平滑共存。本文从这些工程问题出发，结合一套插件化、纯异步 RPC 的代码结构，把性能、安全、可观测性、流量治理、泛化调用、
Architecture
#RPC #微服务 #可观测性 #分布式系统 #服务治理 #CompletableFuture #Service Mesh

RPC 框架进阶设计：从插件化架构到服务治理与无损上下线

RPC 的核心目标看似简单：把本地方法调用转换成网络请求，再在远端恢复方法语义。但真正进入生产环境后，问题很快会从“如何完成一次远程调用”扩展到“如何发现实例、判断节点是否健康、控制流量、处理失败、保护上下游以及实现无损发布”。本文从 RPC 框架整体架构出发，系统梳理插件化设计、服务发现、健康检测、路由、负载均衡、异常重试、优雅启停、熔断限流与业务分组，并把这些能力重新组织成一套完整的 RPC
Architecture
#RPC #微服务 #分布式系统 #服务治理 #服务发现 #负载均衡 #高可用