共 6 篇相关文章
这篇讲的是如何从头实现一个JSON解析器。作者从JSON解析器的基本定义出发——即将JSON字符串转换为语言内存中的数据结构，对比了它与XML的差异，并梳理了JSON基本类型与Java数据结构（如Map、List）的映射关系。 文章的核心在于拆解实现思路。它强调解析器应采用流式单次扫描，本质是一个状态机。实现的关键步骤被清晰地勾勒出来：首先，需要封装一个`CharReader`来支持`peek()`操作，以便在不移动指针的情况下预判字符；其次，将原始字符流进一步抽象为Token流（如`BEGIN_OBJECT`、`STRING`等），从而大幅简化状态判断逻辑。最后，文章点出了处理嵌套结构的技巧：利用栈来管理Object和Array的构建，遇到开始标记时创建对应的Map或List并压栈，以此高效地完成递归解析。 整个实现过程体现了从具体到抽象、逐步化繁为简的设计思想，将看似复杂的解析任务分解为字符读取、Token识别和栈操作几个清晰的模块。
这篇讲的是微博为应对实时Feed流挑战而构建的消息队列架构。作者从数据流处理从离线走向实时的行业趋势切入，详细拆解了支撑海量社交信息流的底层架构。 核心是一个由三部分构成的体系：中间是feed主流程处理，通过MQ worker异步写入缓存和数据库，完成核心的削峰填谷；左侧是流式计算，用于大数据实时分析；此外还有负责多机房数据同步的“虫洞”模块。整个系统建立在几个关键单元上：单机队列MQ、支持一对多投递的统一通道Firehose（具备基于社交关系的fan-out能力），以及无状态的Worker。 架构设计上，文章强调了其高实时性（要求100ms内处理完成）、线性可扩展性与超高可用性（99.999%）。最后，文章还对比了LinkedIn Databus、Apache Storm和Kafka等技术路线，解释了为何其业务主动写入事件的方案在复杂分库场景下，比数据库触发方案更具原子性和简洁性。
这篇讲的是如何动手搭建一个Storm集群的实战指南。文章基于Storm官方Wiki，从介绍集群架构开始——它由负责分发任务的Nimbus主节点和执行任务的Supervisor工作节点构成，两者通过Zookeeper进行协调，且设计为无状态、快速失败，保证了高可用性。 其价值不止于罗列安装步骤。作者真正强调的是部署中容易遇到的“坑”以及对应的解决方案。例如，在搭建Zookeeper时，提醒要配置监控程序实现自动重启，并定期清理日志以避免磁盘占满；在安装ZeroMQ依赖库时，明确指出应避开有严重bug的2.1.10版本，推荐使用2.1.7，并提供了特定系统报错时的解决方法。这些来自实践的细节，能帮开发者避开很多重复摸索。 对于想从零开始部署Storm或理解其底层协调机制的技术人员，这篇教程提供了清晰的路线图和宝贵的避坑经验，将理论步骤与实战注意事项结合得相当扎实。
这篇讲的是Storm源码中topology提交的实现细节。作者从拓扑提交的整体流程切入，逐步剖析了Storm Master如何接收客户端请求、序列化拓扑结构，并借助ZooKeeper进行协调，将配置分发到集群的Supervisor节点。核心实现思路围绕着提交过程中的几个关键阶段：包括拓扑的验证、资源的预分配以及worker的启动调度。文章巧妙揭示了Storm如何在源码层面处理故障恢复，比如通过持久化拓扑状态到ZooKeeper，确保集群重启后能自动重新部署。 具体来说，作者深入分析了提交流程中涉及的核心类和方法，如`StormSubmitter`和`Nimbus`服务的交互逻辑。文中突出了Storm的一个巧妙设计——在提交时动态计算并调整worker的数量，以适应集群资源变化，这增强了系统的弹性和负载均衡能力。通过源码走读，读者能清晰看到从客户端提交拓扑到集群执行的数据流转和错误处理机制，例如网络通信的重试策略和序列化格式的选择。这对于理解分布式流处理框架的部署和运维提供了扎实的底层视角，尤其适合对Storm内部运作感兴趣的开发者参考。
这篇讲的是Apache Storm中，一个topology从提交到成功运行的完整源码旅程。作者没有停留在概念层，而是直接从客户端发起`submitTopology`调用开始，一路追踪到底。 核心在于展示客户端如何将整个拓扑的计算图（spouts和bolts的连接关系、配置等）序列化，并通过Thrift RPC发送给Nimbus主节点。文章细致地拆解了Nimbus接收请求后的处理流程，比如它如何将提交的拓扑信息持久化到ZooKeeper，从而保证即使Nimbus重启，拓扑状态也能恢复。 巧妙之处在于，Storm将“提交”这个动作设计为一个异步过程。客户端提交后得到的只是一个拓扑ID，实际的调度和启动完全由Nimbus和Supervisor节点在后台协作完成。这种设计解耦了客户端操作与集群资源调度，是理解Storm分布式协调机制的一个绝佳入口。对于想深入理解分布式系统如何处理元数据提交与容错的开发者来说，跟着这篇源码分析走一遍，会对Storm的鲁棒性有更直观的认识。
这篇整理自作者收到的真实邮件提问，集中解答了 Apache Storm 在使用中遇到的一系列常见问题。文章并非空谈理论，而是从开发运维人员的实际困惑出发，涵盖了从集群部署运维、性能调优到拓扑开发中 API 使用的多个层面。 比如，对于“如何提高拓扑处理性能”这类高频问题，作者没有停留在概念上，而是具体给出了通过调整并行度、优化序列化以及合理设置acker数量等一整套可操作的建议。对于初学者容易混淆的 Spout 与 Bolt 交互、消息可靠性保障机制等问题，也通过具体代码片段和案例进行了清晰辨析。 整体来看，这篇文章像是一份来自一线开发者的实战问答手记，它将零散的痛点问题串联起来，提供了切实可行的解决思路，对于正在使用或打算使用 Storm 的开发者而言，是一份不错的速查与避坑参考。
