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

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

该图片由chanwit whanset在Pixabay上发布

你好，我是看山。

去年 6 月份开始使用 Ubuntu 14.04 LTS，当时是在公司电脑上装的，因为是第一次搭建工作环境，很多东西不是很随心意。终于等到 16.04 LTS 版发布，就重装系统，公司的那个老爷本也不用了。

ubuntu desktop 是一个很简单的桌面系统，比较适合菜鸟级的使用，学习曲线比较平缓。本文主要是记录一下这次搭建工作环境的经过，留作备份，下一次再需要重装的时候可以有个依据。

你好，我是看山。

用 Ubuntu 已经将近 1 年了，最近重装了 16.04 之后，每天到下午 5 点左右，都会发现 Swap 交换空间有几百兆的写入，系统内存 8G，硬盘是 SSD，i5 处理器，配置中档，也没有启动什么大型软件，就是用 IDEA 做开发，虽然没有影响，但本着一颗求知的心，google 一下，第一篇是 《All about Linux swap space》，口气很大，直接翻译了。

你好，我是看山。

HTTP（Hyper Text Transfer Protocol）即超文本传输协议，采用请求/响应模型，是目前互联网使用最为广泛的一种网络协议。主要的过程：客户端向服务器发送一个请求，请求的请求头包含请求的方法、URI、协议版本、请求修饰符、客户信息、以及请求的内容等信息；服务器以一个状态行作为响应，包括消息协议的版本、成功或者错误编码、服务器信息、实体元信息以及实体内容。http 服务默认端口是 80,https 默认端口是 443。下图为 HTTP 服务简单的处理图。

本着实用主义，本文对 http 协议的原理不做过多解释，只是分享一下日常使用 Chrome 调试 http 服务的经验，希望能得到同行们的指点。

伴随着各大互联网公司开源自己的大数据框架，大数据处理领域的框架已经比较完善。到现在所谓大数据的框架已经用过habase（后来换成了elasticsearch）、zookeeper、kafka、storm，根据项目计划，接下来还要使用spark。虽然在众多框架中仅仅几个，但是也是已经涉及多个方面：数据存储、分布式协调、消息、实时计算等。没有找到任何一个框架能够完美解决所有问题，也就应了那句话，开发领域根本就没有银色子弹。所以即使是比较年长的hadoop（2004年到现在已经12年了，年纪也比较大了），也有能够体现其价值的地方。

最近用了storm，部署topology的时候总是感觉资源使用不平衡，于是想到了yarn能够对hadoop实现资源的协调，那是不是可以扩展一下，对storm也提供资源协调呢。google一下，果然yahho!已经开源了一个storm-yarn组件，于是学习一下，同时也把hadoop的部署复习了一遍。（关于hadoop的单机部署、伪分布式部署可以查看Hadoop环境部署）

Strom集群结构是有一个主节点（nimbus）和多个工作节点（supervisor）组成的主从结构，主节点通过配置静态指定（还有一种主从结构是在运行时动态选举，比如zookeeper）。通常这种主从结构存在出现单点故障的风险，Storm通过特殊处理规避这种风险，后面将解释Storm的半容错结构。

本文主要介绍storm中的基本概念，从基础上了解strom的体系结构，便于后续编程过程中作为基础指导。主要的概念包括：

1. topology（拓扑）
2. stream（数据流）
3. spout（水龙头、数据源）
4. bolt（螺栓，数据筛选处理）
5. stream group（数据流分组）
6. reliability（可靠性）
7. task（任务）
8. worker（执行者）

因为上述概念中除了可靠性reliability翻译起来比较合适，其他几个词实在找不到合适的对应词语，就直接使用原词。
另外一点需要注意的是，本文使用的storm-core版本是0.10.0，包路径为backtype.storm。因为阿里巴巴开源了jstorm，据说strom2.0之后使用jstorm作为master主干，从github上可以看到包路径修改为了org.apache.storm，如果发现有包路径错误的地方，请对应修改。

这几天工作需要使用storm+kafka，基本场景是应用出现错误，发送日志到kafka的某个topic，storm订阅该topic，然后进行后续处理。场景非常简单，但是在学习过程中，遇到一个奇怪的异常情况：使用KafkaSpout读取topic数据时，没有向ZK写offset数据，致使每次都从头开始读取。纠结了两天，终于碰巧找到原因：应该使用BaseBasicBolt作为bolt的父类，而不是BaseRichBolt。

通过本文记录一下这种情况，后文中根据上述场景提供几个简单的例子。基础理论查看storm笔记：storm基本概念，或查看Storm 简介。

该图片由Ian Lindsay在Pixabay上发布

你好，我是看山。

众所周知，每一个 HTTP 响应都会带有一个 HTTP 状态码（HTTP Status Code），是用来表示 HTTP 服务器响应状态的代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918 等规范扩展。作为 web 开发者，平时经常 200、301、302、404、500、503 等。最近正在开发一些对外的接口（公司内部各系统间互相调用的接口，也算是内部 Open API 吧），接口调用失败时需要返回一些状态码，考虑借用 HTTP 状态码的含义，可以让调用方通过状态码就能够大体知道出了什么问题，不用彼此重新约定不熟悉的编码规则，方便沟通及错误定位。自认为想法不错，但是在实际编写中遇到了问题，这个多的状态码该怎么用？就用这个机会好好学习下什么场景用什么状态码，也通过本文记录一下 HTTP 状态码的内容。在本文中借 Michael Kropat 的 《Choosing an HTTP Status Code — Stop Making It Hard》 中提供的状态码使用决策树，区分常用状态码的使用场景。

注：本文提供 HTTP 状态码的状态信息及含义，以及 Michael Kropat 总结的常用状态码决策树。