JDK 工具一览

Java 坑如此大,需要慢慢填。

本文是列出JDK自带的一些工具,介于篇幅,简单列出工具列表及工具的作用。至少先做到知道有哪些工具,然后才能在实际中用到。

本文参考了官方介绍和本机man命令的介绍。

更多

storm笔记:Trident应用

本文内容部分来自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。

更多

常用消息队列对比

作为中间件,消息队列是分布式应用间交换信息的重要组件。消息队列可驻留在内存或磁盘上, 队列可以存储消息直到它们被应用程序读走。通过消息队列,应用程序可以在不知道彼此位置的情况下独立处理消息,或者在处理消息前不需要等待接收此消息。所以消息队列可以解决应用解耦、异步消息、流量削锋等问题,是实现高性能、高可用、可伸缩和最终一致性架构中不可以或缺的一环。下面对消息队列就直接使用MQ表示。

消息队列

更多

HTTP长连接和短连接

一直听别人说HTTP长连接,只知道长连接比短连接更节省资源、更快捷,但是并不真的知道原因。知其然不知其所以然,对于技术来说,这种状态是比较危险的。所以,还是要挖一下原理,即使挖的比较浅,也要迈出这一步。

HTTP是应用层协议,传输层使用的是TCP协议,网络层使用的是IP协议。

IP协议主要解决网络路由和寻址问题,TCP协议主要解决如何在IP层之上可靠的传递数据包,使在网络上的另一端收到发送端发出的所有包,并且顺序与发出顺序一致,HTTP协议主要基于TCP协议完成数据传递。

更多

Zookeeper客户端错误:Packet len8854970 is out of range!

这是一个生产环境使用zookeeper异常的情况,错误是java.io.IOException: Packet len8854970 is out of range!。然后就换了一个namespace,就没有在出错,以为是偶然发生,所以没有重视。但是年后居然又出现问题,才意识到严重性。分析之后发现,每隔一段时间,某一个znode节点下超过客户端所设置的大小,客户端连接会失败,zkCli.sh操作该节点也会失败。如果对于简单依赖zookeeper的系统,这种错误可以容忍(但是必须解决);如果是强依赖zookeeper的系统,这种错误可以说是灾难。

更多

解决方案之任务队列

在一些系统中,会有对某些任务状态进行跟踪,如果任务失败需要重新执行任务。本文主要是针对这种请求提出解决方案,因为时间原因,方案还没有在代码中实现。但是经过和朋友的推演,是目前能想到的比较有效的方案了。鉴于本人才疏学浅,如果有某位大神有更好的解决方案,请一定不吝赐教,感谢不尽。。。

更多

RabbitMQ运维

这是一次比较苦逼的运维,完全不熟悉的系统、不清楚环境、不清楚配置,两眼一抹黑。为啥?就是因为原来的负责人撤了、交接人休假、再次交接人也休假,再再次交接人只有一份不全的文档。而我是再、再、再次交接人,连文档也没有。更要命的是,这是生产环境,大家都懂得,生产环境就是不能出问题,自封一个“奉命于危难之间”吧。

抱怨了一整段了,还是简单的说下这次运维吧,运维的是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集群,所以基本上趟了一堆的坑,碰到了一堆不应该出现的错误,也算是新手村长经验了。按照套路,这里先说说正确的启动方式,然后再说说碰到的异常。

更多

微服务架构下的数据一致性:可靠事件模式

《微服务架构下的数据一致性:概念及相关模式》中介绍了在微服务中实现数据一致性的三种方式,包括可靠事件模式、业务补偿模式、TCC模式。本文重点说一下可靠事件投递。

更多

微服务架构下的数据一致性:概念及相关模式

从2014年开始,微服务逐渐进入大家的视线,被认为是下一代实现信息化的有效手段。设计到系统,其中绕不开的就是数据一致性,从本地事务,到后来的分布式事务,都能够有效的保证数据一致性。但是在微服务架构中,这两种方式都不是最好的选择。

更多

初始化Ubuntu工作环境

去年6月份开始使用Ubuntu 14.04 LTS,当时是在公司电脑上装的,因为是第一次搭建工作环境,很多东西不是很随心意。终于等到16.04 LTS版发布,就重装系统,公司的那个老爷本也不用了。
ubuntu desktop是一个很简单的桌面系统,比较适合菜鸟级的使用,学习曲线比较平缓。本文主要是记录一下这次搭建工作环境的经过,留作备份,下一次再需要重装的时候可以有个依据。
ubuntu-cloud

更多