共 17 篇相关文章
这篇讲的是，作者从网络游戏开发转向网络存储、机器学习等场景后，对TCP“可靠性”的重新审视。他提出，在需要重连重试的严肃应用中，TCP的ACK机制和操作系统的发送成功通知并不可靠——比如网络故障后，应用层无法获知哪些数据丢失，已提交的缓冲区也可能被释放，导致数据无法重发。 文章的核心，是剖析了三个基于TCP的应用层协议设计陷阱：发送方无法确认接收状态、无法区分“成功”与“未失败”、以及重试可能导致数据重复。针对这些“坑”，作者给出了具体的应对方案：必须在应用层设计确认应答（ACK）；对于大文件追加，应采用带偏移量的positioned write；对于重复消息，则需在应用层进行去重。 最后，文章也讨论了优雅关闭连接的原则：应由接收最后一条消息的一方主动发起关闭。整篇文章从实际场景中的问题切入，深入浅出地阐明了在设计RPC协议时，不能盲目信任传输层，而必须在应用层构建自己的可靠性机制。
这篇文章探讨了在大型分布式Java系统中，如何在不改变原有POJO发布方式的前提下，实现跨语言RPC调用。作者指出，随着业务扩展，上层可能采用PHP、Ruby等技术，而底层服务又可能需要用C++、Python来追求更高性能，这就对现有的、基于Java的RPC框架（如Spring Remoting）提出了跨语言兼容的挑战。 文章首先梳理了业界三大主流方案：Google Protocol Buffers、Facebook Thrift 和 Apache Hadoop Avro。作者分析了各自的优劣：Protocol Buffers 的序列化格式高效但RPC能力弱，生成代码有侵入性；Thrift 提供了完整的服务栈和强大的接口支持，但与现有Java RPC体系不兼容；Avro 的动态类型机制灵活，但学习成本较高。 最终，作者提出了一种“扬长避短”的混合解决方案：核心采用Protocol Buffers的序列化格式和代码生成能力，服务接口定义借鉴Thrift的模式，并兼容现有的RPC传输层；同时，利用Avro的Schema机制来实现对原有POJO对象的无缝序列化与反序列化。这套方案旨在保留现有Java RPC架构的同时，优雅地打通多语言互操作。文章还留下了具体实现细节，为后续分享埋下了伏笔。
这篇讲的是如何为Thrift RPC框架引入异步调用能力。作者从团队广泛使用的同步模式出发，为优化大数据量传输等场景，探索了Thrift原生提供的异步客户端方案。 核心实现围绕生成的异步客户端类与`TAsyncChannel`接口展开。`TAsyncChannel`定义了异步收发消息的接口，目前标准的实现是基于libevent和HTTP协议的`TEvhttpClientChannel`。它的巧妙之处在于，通过将回调函数注册到事件循环中，使得客户端发送请求后无需阻塞等待，可以继续执行其他任务，待服务端响应到达时再触发回调处理结果。 文中一个关键发现是：异步客户端并非必须搭配异步服务器。通过实验验证，只要服务器端使用HTTP传输层（例如通过`THttpServerTransportFactory`），协议层保持一致，即可与异步客户端正常工作。这大大降低了现有同步服务的改造成本。 实验部分展示了一个完整的异步客户端与同步服务器交互的例子，运行结果证实了调用发起与响应接收在时间上是解耦的。不过，作者也指出当前实现限于HTTP传输层，这为后续扩展其他传输协议留下了探索空间。
当面对千万、亿级数据量时，对HBase表进行全表扫描来统计行数或分组聚合，会带来巨大的网络与RPC开销。这篇技术分享给出了一个优雅的解法：使用HBase的Endpoint协处理器。 作者的核心思路是，将计算逻辑直接部署到数据所在的RegionServer上执行，只将聚合后的结果返回客户端。这就好比把计算任务“下发”到每个数据分区，避免了海量原始数据的网络传输。文章将这个过程比作一个精简高效的、运行在RegionServer上的MapReduce。 具体实现分为三步：首先定义一个继承自CoprocessorProtocol的计数接口；然后在服务端实现该接口，在Region内完成数据扫描与计数；最后在客户端通过HBase API发起远程调用，并汇总各个Region的统计结果。文章不仅给出了清晰的代码示例，还详细说明了如何通过配置文件或Shell命令来部署这个协处理器。 通过行数统计这个简单例子，文章展示了Endpoint协处理器如何为HBase添加灵活的计算能力，使其成为高效应对大规模数据聚合挑战的利器。
这篇讲的是如何快速上手Thrift——这个最初由Facebook开发、现在由Apache维护的跨语言RPC框架。文章从“thrift”一词的节俭本意巧妙切入，指出在技术语境下，它代表的是一种高效解决跨语言服务通信的“节俭”之道。 作者没有停留在概念介绍，而是通过一个具体的成绩查询系统案例，生动对比了传统“手工作坊”式开发与使用RPC框架的效率差异。他清晰地拆解了Thrift的四个使用步骤：定义接口文件、生成代码、实现服务端逻辑、编写客户端调用，让读者对工作流程一目了然。 教程的详尽之处在于，它系统地讲解了Thrift接口描述文件（IDL）的编写规范，包括基础类型、容器、结构体、异常和服务等核心元素的定义方式，并辅以代码示例。特别是对required/optional字段、oneway异步调用等细节的说明，为初学者扫清了常见困惑。对于想了解如何在Linux环境下搭建并利用Thrift构建高效、跨语言服务的开发者，这是一份条理清晰、实例丰富的入门指南。
这篇讲的是 AMF（Action Message Format）协议，一种专为高效数据传输设计的二进制格式。与传统的 SOAP/XML 文本传输方式不同，AMF 采用二进制编码，能高度压缩数据，特别适合传递大量资料——数据量越大，传输效率优势越明显。文章梳理了 AMF 的核心特点：它可以直接传输 Flash 内置对象（如 Object、Array、Date），服务器端能自动解析，大幅简化开发流程。 作者从 Flash Remoting 的实际选择出发，对比了 AMF 与 SOAP 的关键差异。AMF 不仅比冗长的 XML 更高效，而且因为它专注于支持 ActionScript 数据类型，在浏览器中体积仅需约 4KB（压缩后），而 SOAP 则庞大得多，且存在头部请求不支持的问题。文章还列举了 AMF 协议支持的数据类型及其对应的十六进制值，展示了其结构的紧凑性。 在实现层面，文章介绍了 AMF 基于 HTTP 的典型处理流程：从客户端请求、反序列化、服务处理到响应序列化，并提及 PHP、.NET、Python、Ruby 等主流语言都已拥有成熟的 AMF 框架（如 AMFPHP、FluorineFx），开发者可以快速实现 Flash 与后端数据库的通信。 总的来说，这篇文章清晰地说明了 AMF 如何通过二进制优化和对 Flash 生态的专注，在特定场景下（尤其是需要高效、轻量交互的 Web 应用中）成为比 SOAP 更具优势的选择。
当Erlang集群采用默认的全联通架构时，节点间通过RPC通道的密集调用可能引发严重的通道拥塞。文章从社区主流的分层服务架构出发，指出大量节点间消息流易导致dist端口忙，进而阻塞发送进程——由于RPC模块基于单进程gen_server，这种阻塞会直接拖累系统响应时间。 作者指出，这类问题可通过`erlang:system_monitor`的`busy_dist_port`事件及时感知，例如Riak系统便利用此机制告警。解决关键在于调整`dist_buf_busy_limit`参数：默认1MB的分布缓冲区上限可能不足，通过启动参数`+zdbbl`将其调大（如Riak案例中增至8MB），即可显著缓解阻塞、提升吞吐。文章结合监控实践与参数调优案例，提供了从问题定位到彻底解决的完整路径。
这篇技术博客从实战角度出发，深入剖析了HBase客户端的Write Buffer机制。文章指出，每次单条Put都会引发一次网络往返（RTT），在数据量小、RTT较高的场景下，这个开销会成为性能瓶颈。通过开启Write Buffer进行批量提交，可以将N次RTT降低为一次，从而显著提升写入吞吐。 作者没有停留在概念介绍，而是结合HBase源码，揭示了底层实现细节：客户端会先按Region Server将Put对象分组打包，再统一发起RPC请求。文章还详细拆解了Write Buffer的触发条件（如autoFlush设置、缓冲区满），并给出了单个Put对象大小的预估公式 `((50~60) + L1) * N + L2 bytes`，帮助开发者根据自身数据特征（列数N、RowKey长度L1、Value长度L2）来预估并合理配置缓冲区大小。 最终，文章清晰地划分了适用场景：对于KB级别的小数据写入，调整Write Buffer收益明显；而对于MB级别的大记录，由于数据传输时间占主导，则不建议依赖此机制。这种从原理到源码再到实践的分析路径，为调优HBase写入性能提供了扎实的依据。
这篇讲的是作者在游戏服务器框架 Skynet 上进行的一次实战开发。他将前几天因会议而拖慢的进度赶了回来，最终完成了集群模块与 RPC 协议的设计与实现。 Skynet 本身以轻量和高性能著称，但其原生设计更偏向单机。作者这次的工作，正是为了解决分布式环境下的节点通信问题。他分享了从零开始，在 Skynet 架构中融入网络集群与远程过程调用（RPC）的关键步骤，这涉及到底层协议的封装与上层服务调用逻辑的整合。 对于关注服务器架构的开发者而言，这篇文章的价值在于呈现了一个具体的“从点到面”的扩展过程：如何让一个成熟的单机框架，通过模块化的设计，具备支撑起分布式集群的能力。作者没有停留在理论阐述，而是结合了实际编码中的取舍与思考，这对于需要处理类似技术挑战的读者，会是一份详实的参考。
这篇文章从RPC技术的实现难点出发，介绍了Thrift这个由Facebook开源的跨语言高性能RPC框架。它直接切入了开发者在构建分布式系统时面临的一个核心问题：如何高效、可靠地让不同语言编写的服务进行通信。 作者重点解析了Thrift的技术内核。它提供了一套简洁的IDL（接口定义语言），允许你像写接口一样定义数据结构和服务契约，然后通过编译器自动生成多种语言（如Java、Python、C++等）的客户端和服务端骨架代码。这解决了跨语言调用的繁琐工作。文章还提到了它内置的二进制序列化协议（如TBinaryProtocol），这使得数据在网络传输时的体积和速度都优于传统的文本格式，这是其高性能的关键之一。 作为一款经过大规模生产环境考验的成熟框架，Thrift的实现细节，比如连接池、IO模型、线程模型等，也值得深入了解。这篇分析帮助读者理解，选择Thrift不仅是为了调用远程方法，更是选择了一套完整的、经过优化的服务间通信解决方案。
这篇讲的是，作者从Apache Jackrabbit这个内容仓库项目的源码出发，开始探讨其技术选型上的一个“败笔”：使用RMI作为客户端与服务器之间的通信协议。 文章直指RMI在特定场景下的痛点——它基于Java，过于重量级且与语言强绑定，不够简单、灵活和跨平台。作者的核心观点很明确：对于这种需要远程调用的场景，应该果断抛弃RMI，转而采用更通用、更轻量的“HTTP + 简单RPC协议”。他主张通过这种组合，利用HTTP的普及性和简单RPC的清晰性，来构建一个更易用、更兼容的通信层。 作者没有停留在单纯批评，而是将这一具体的技术决策错误上升到了对项目架构和协议选择通用性的思考。他引导读者去审视那些看似“官方”或“默认”的技术栈，分析其背后真正的适用边界。这种对早期技术决策的反思，以及对更优替代方案的明确倡导，对于正在做类似技术选型的开发者来说，是一次很有价值的提醒。
这篇讲的是Hadoop RPC机制的工作原理，以及作者尝试引入Avro作为其序列化方案的初步探索。 文章前半部分深入Hadoop RPC的核心实现，剖析了它如何解决分布式系统中节点间高效通信的问题，特别指出其基于Java序列化的传统方式在跨语言兼容性和性能上的局限性。作者梳理了RPC连接建立、方法调用和响应返回的关键流程，让读者能看清其内部运作机制。 后半部分则转向优化方案。作者提出用Avro替代Java序列化，借助其自描述的数据格式和优秀的Schema演进能力，旨在提升Hadoop RPC的跨语言互操作性并可能优化数据传输效率。文章对比了两者在序列化速度、数据体积及向前/向后兼容性上的具体差异，并展示了初步集成的思路和可能遇到的挑战。 整个探索从实际问题出发，通过具体的技术对比和路径设想，为思考如何改造分布式系统基础组件提供了一个有价值的案例。
这篇讲的是淘宝Hadoop集群在应对业务数据突增时，NameNode面临的特殊挑战与优化思考的开篇。作者从淘宝的实际业务场景出发，指出随着集群规模和作业量的增长，NameNode的性能瓶颈开始凸显。 核心背景在于，淘宝的Hadoop数据性质与大型搜索公司存在显著差异：搜索公司处理的数据通常为TB级别以上，而淘宝的数据规模从数十MB到数百GB不等，颗粒度更细。这导致了作业特征的不同，也为NameNode的管理带来了独特的压力。 文章首先清晰地描绘了这一问题背景，为后续具体的优化方案和笔记做了扎实的铺垫。
这篇讲的是两种主流二进制通信框架 Avro 与 Thrift 的深度对比。 两者虽然都提供高性能序列化和RPC能力，但设计哲学大相径庭。Thrift 出自 Facebook，秉持“没有银弹”的思路，打造一个中立、可插入不同实现的多语言框架。而 Avro 由 Hadoop 之父 Doug Cutting 主导，目标更宏大：它不只想做个通信工具，更试图在云计算时代建立一套统一的数据交换与存储标准，为此不惜采用特定优化。 核心差异体现在 Schema 处理上。Avro 创造性地将显式声明式 Schema 与高效二进制编码结合，强调数据的自我描述。其 Schema 动态加载能力是 Thrift 所不具备的，这恰好满足了像 Hadoop 生态中 Hive、Pig 以及各类 NOSQL 数据库那样，既需要快速即席查询（ad hoc），又对性能有严苛要求的场景。 简单说，Thrift 提供的是一个灵活的、适应多种协议的连接器；而 Avro 则致力于定义数据本身。选择哪个，往往取决于你的系统更需要框架的灵活性，还是数据标准的统一性。
这篇讲的是，在微服务架构下，一个常见的技术选型困境：到底该用RPC（远程过程调用）框架，还是回归更直接的HTTP调用（即noRPC）？作者并没有给出一刀切的答案，而是从性能、开发复杂度、团队协作模式等多个维度进行了深入对比。 文章核心分析了两种模式的关键差异。RPC通常意味着更强的接口约束、更高的序列化效率和潜在的性能优势，适合构建内部高性能、强依赖的服务集群。但代价是增加了框架复杂度和团队间的协作成本。而看似“原始”的noRPC（如直接使用HTTP/REST），则胜在简单透明、调试方便、生态开放，尤其适合对外提供API，或是在技术栈多样、需要快速迭代的场景中。 最终，作者指出，选择的关键在于认清你的业务场景和团队现状。这篇文章就像一份清晰的对比清单，帮助你在面对具体项目时，能更有依据地权衡利弊，做出那个“对的问题”的解答。
这篇讲的是phprpc与hessian这两种序列化协议在性能上的直接较量。文章从“phprpc的性能在某些场景下甚至优于hessian”这个有点反直觉的结论切入，试图揭秘背后的真正原因。 作者没有停留在简单的跑分结果上，而是深入到了实现层面。关键差异可能在于两者序列化机制的根本不同：hessian作为一种二进制协议，追求的是紧凑与跨语言兼容性；而phprpc的设计可能在某些数据结构或编码策略上找到了更优的路径，比如针对特定类型的数据采用更精简的表示方法，或者在压缩与解压的权衡上做了更高效的取舍，从而在特定负载下赢得了速度优势。 文章最终会帮读者理清选择思路：如果你的场景高度契合phprpc的优势区间（例如大量使用其优化的数据类型），它可能带来惊喜；若更看重通用性、稳定性与跨语言生态，hessian依然是经过广泛验证的可靠选择。这种对具体技术细节的拆解，正是理解性能差异根源的关键。
作者在部署与优化 FS3 系统时，遇到了 NFS 随机 IOPS 性能始终无法达到预期的棘手问题。这篇内容详细拆解了从现象到根因的整个分析过程。 问题的根源被追溯到 NFS 协议自身的运行机制上。文章深入剖析了 NFS 客户端与服务端在处理小块随机读写时的交互逻辑，指出协议设计中对元数据访问的开销、客户端与服务端缓存策略的差异，以及网络往返延迟的累积效应，共同导致了随机 IOPS 的瓶颈。尤其是在高并发、小文件随机访问的场景下，这些机制性限制变得尤为明显。 通过这次细致的“解剖”，作者不仅定位了性能瓶颈的深层原因，也为后续的性能调优工作（例如，评估不同 NFS 版本的特性、调整挂载参数或考虑替代方案）提供了扎实的诊断依据。对于同样在存储网络性能上遇到困惑的工程师，这篇复盘提供了一个清晰的排查思路和有力的分析视角。
