我们在从Kafka，RabbitMQ，Storm 中摄入实时数据流时到Druid的时候，可以使用Realtime Node，Index Server，Tranquility进行数据摄入。

本文主要探索这几种数据摄入方式的区别。

最近我们我们在将部分业务从自有机房迁移到国内某云服务器上，在小规模上量后，发现Nginx间接性出现大量502。异常出现的特点是，一瞬间后端多个独立部署的服务全部出现502。

我们的服务架构如下:

1
2
3
4
5
6
7
8
9

+--------+  HTTP   +-------+  HTTP   +-------+
| Client | ------> |       | ------> | API A |
+--------+         |       |         +-------+
                   |       |  HTTP   +-------+
                   | Nginx | ------> | API B |
                   |       |         +-------+
                   |       |  HTTP   +-------+
                   |       | ------> | API C |
                   +-------+         +-------+

一般讲，Nginx 502就是后端处理不过来，但查看监控后端几个API的负载均很低，当前请求的QPS远远低于服务的上限。而且同一瞬间，多套独立部署的API均处理不过来的概率也比较低。

在讨论Redis内存压缩的时候，我们需要了解一下几个Redis的相关知识。

本篇主要介绍如何利用ELK分析Nginx日志，统计出API的耗时数据

ELK是ElasticSearch，Logstash，Kibana的简称，但我觉得这个名字已经过时了，现在叫ELKB更合适，因为Elastic家族近期迎来了一位新成员Beats，专职做数据采集工作。

我们先来介绍下ELK的整体架构吧。

Grok是ELK栈中，用来快速解析日志的一个脚本工具，运用得好的话，可以极大程度的降低日志解析的工作，最好的Grok表达式的学习方式是去阅读官方文档。

上一篇文章我们说过，Redis Cluster 采用Smart Client的方式，避免与节点的通讯还需要通过一层Proxy，以达到性能地提升。 Smart Client的优点与缺点网上也有很多人在讨论，我们现在来了解下Redis Client的运行规制。

Redis Cluster是Redis官方的集群实现方案，在此之前已经有一些民间的第三方Redis集群解决方案，如Twitter的Twenproxy，豌豆荚的Codis，与其不同的是，Redis Cluster并非使用Porxy的模式来连接集群节点，而是使用无中心节点的模式来组建集群，有一定性能优势也有缺点，本文主要是我调研Redis Cluster的一些知识整理与经验汇总。

工作中，我们经常需要将功能模块封装成库供合作厂商调用， 如何写好一个健壮的Android Library有很多讲究，使用注解可以对SDK暴露给开发者的接口做出一些限制，从而尽可能地避免开发者错误地使用API。 下面我们介绍几种封装SDK时常用到的注解。

一直以为UTF-8是万能的字符集问题解决方案. 直到遇到这个问题.
最近在做新浪微博的爬虫, 在存库的时候, 发现只要保持emoji表情, 就回抛出以下异常

1

Incorrect string value: '\xF0\x90\x8D\x83\xF0\x90...' 

众所周知UTF-8是3个字节, 其中已经包括我们日常能见过的绝大多数字体. 但3个字节远远不够容纳所有的文字, 所以便有了utf8mb4, utf8mb4是utf8的超集, 占4个字节, 向下兼容utf8. 我们日常用的emoji表情就是4个字节了.
所以在此我们像utf8的数据表插入数据就会报出Incorrect string value这个错误.