前段时间搭建了一套Hadoop集群的测试环境，因为服务器故障，废了。这几天闲来无事，想着把Storm用Yarn管理起来，于是再来一遍，同时也梳理下Hadoop组件中的一些概念。所谓书读百遍其义自见，不熟的系统多搭几遍，总会熟悉了，也就是所谓的刻意练习吧。
先简单的说下。
Hadoop文件存储的基础是HDFS(Hadoop Distributed File System)，HDFS的实现依赖于NameNode和DataNode，DataNode用来存储具体数据，NameNode用来管理多个DataNode中分别存储的是什么。
理解起来也不难，因为HDFS是分布式的文件系统，也就是有很多机器用来存储数据，一个大文件可能分布在多个机器上，也可能是一台机器上，具体分布在哪些或哪个机器上，每块数据块的副本在哪，得需要一个总管来管理，这个总管就是NameNode，具体存储机器的就是DataNode。
简单的说完了，接下来就复杂的说。
你好，我是看山。
这几天压测预生产环境，发现 TPS 各种不稳。因为是重构的系统，据说原来的系统在高并发的时候一点问题没有，结果重构的系统被几十个并发压一下就各种不稳定。虽然测试的同事没有说啥，但自己感觉被啪啪的打脸。
于是各种排查，最先想到的就是 JVM 参数，于是优化一番，希望能够出一个好的结果。尽管后来证明不稳定的原因是安装 LoadRunner 的压测服务器不稳定，不关我的系统的事，不过也是记录一下，一是做个备份，二是可以给别人做个参考。
你好，我是看山。
Java 坑如此大，需要慢慢填。
本文是列出 JDK 自带的一些工具，介于篇幅，简单列出工具列表及工具的作用。至少先做到知道有哪些工具，然后才能在实际中用到。
本文参考了 官方介绍 和本机
man命令的介绍。
本文内容部分来自Trident Tutorial。
Trident是基于Storm的实时计算模型的高级抽象。它可以实现高吞吐（每秒数百万条消息）的有状态流处理和低延迟分布式查询。如果以前使用过高级批处理工具（比如Pig或Cascading），则对Trident的概念会非常熟悉，比如连接、聚合、分组、功能处理和过滤等。除此之外，Trident还增加了用于在数据库或持久化存储上进行有状态的增量处理的原语。Trident具有一致性、一次性语义，所以很容易就能够推导出Trident拓扑结构。
Trident的出现算是程序猿非常懒的又一个铁证。Strom是一个实时流处理工具，有很高的吞吐。在实际应用场景中，很多场景是借助这种实时处理能力，对实时数据进行统计，然后将统计结果实时推送到大屏或者其他可以实时浏览的地方，这样领导或者活动运营就可以实时查看销售或活动情况，比如，双十一时候的大屏，就可以使用Storm来做（我们现在就是这样做的，把全渠道的销售情况进行实时统计，然后显示在大屏上，据说领导会看）。然后，程序猿们就发现，很多统计功能非常类似，所以进行抽象，使用更加高级的功能代替一个一个的Spout、Bolt（当然，Trident拓扑结构运行的时候也是解析成Spout和Bolt运行）。
然后又有人发现，Trident这种方式也是比较麻烦，即使程序猿们通过高级抽先的Trident省去了很多麻烦，但是还是架不住运维、运营、产品等不断改变的需求，所以就有很多SQL方式解析为Trident或普通Topology的工具产生。既然运维、运营、产品等不断修改需求，那就简单的通过SQL查询（不同的SQL解析为不同的拓扑结构，在Storm中运行，可以得出不同的结果）。比如：squall。
这些都是题外话，下面继续说Trident。
该图片由Giada Turola在Pixabay上发布
你好，我是看山。
作为中间件，消息队列是分布式应用间交换信息的重要组件。消息队列可驻留在内存或磁盘上，队列可以存储消息直到它们被应用程序读走。通过消息队列，应用程序可以在不知道彼此位置的情况下独立处理消息，或者在处理消息前不需要等待接收此消息。所以消息队列可以解决应用解耦、异步消息、流量削锋等问题，是实现高性能、高可用、可伸缩和最终一致性架构中不可以或缺的一环。下面对消息队列就直接使用 MQ 表示。
你好，我是看山。
一直听别人说 HTTP 长连接，只知道长连接比短连接更节省资源、更快捷，但是并不真的知道原因。知其然不知其所以然，对于技术来说，这种状态是比较危险的。所以，还是要挖一下原理，即使挖的比较浅，也要迈出这一步。
HTTP 是应用层协议，传输层使用的是 TCP 协议，网络层使用的是 IP 协议。
IP 协议主要解决网络路由和寻址问题，TCP 协议主要解决如何在 IP 层之上可靠的传递数据包，使在网络上的另一端收到发送端发出的所有包，并且顺序与发出顺序一致，HTTP 协议主要基于 TCP 协议完成数据传递。
该图片由Mary Campos在Pixabay上发布
你好，我是看山。
这是一个生产环境使用 zookeeper 异常的情况，错误是java.io.IOException: Packet len8854970 is out of range!。然后就换了一个 namespace，就没有在出错，以为是偶然发生，所以没有重视。但是年后居然又出现问题，才意识到严重性。分析之后发现，每隔一段时间，某一个 znode 节点下超过客户端所设置的大小，客户端连接会失败，zkCli.sh 操作该节点也会失败。如果对于简单依赖 zookeeper 的系统，这种错误可以容忍（但是必须解决）；如果是强依赖 zookeeper 的系统，这种错误可以说是灾难。
你好，我是看山。
在一些系统中，会有对某些任务状态进行跟踪，如果任务失败需要重新执行任务。本文主要是针对这种请求提出解决方案，因为时间原因，方案还没有在代码中实现。但是经过和 朋友 的推演，是目前能想到的比较有效的方案了。鉴于本人才疏学浅，如果有某位大神有更好的解决方案，请一定不吝赐教，感谢不尽。
你好，我是看山。
这是一次比较苦逼的运维，完全不熟悉的系统、不清楚环境、不清楚配置，两眼一抹黑。为啥？就是因为原来的负责人撤了、交接人休假、再次交接人也休假，再再次交接人只有一份不全的文档。而我是再、再、再次交接人，连文档也没有。更要命的是，这是生产环境，大家都懂得，生产环境就是不能出问题，自封一个“奉命于危难之间”吧。
抱怨了一整段了，还是简单的说下这次运维吧，运维的是 RabbitMQ 集群，3 个节点 A、B、C，每个节点上启动了 2 个实例 a1/a2、b1/b2、c1/c2，其中 a1、b1、c1 组成一套集群环境 rabbit cluster1，a1 是磁盘节点；a2、b2、c2 组成一套集群环境 rabbit cluster2，c2 是磁盘节点。
就是因为完全不熟悉 RabbitMQ 集群，所以基本上趟了一堆的坑，碰到了一堆不应该出现的错误，也算是新手村长经验了。按照套路，这里先说说正确的启动方式，然后再说说碰到的异常。