《不拘一格: 网飞的自由与责任工作法》 这本书是某次一位同事分享他的近期书单的时候看到的，在国内公司的高速增长，掩盖了很多公司管理上的问题，很多公司为了解决某个管理问题，引入了一个新的制度，结果往往适得让整个工作环境变得更加糟糕。

所以也想看看Netflix这样一家经历跨周期的企业，是如何管理与解决这些问题。刚好在阅读这本书的时候，Netflix正经历了一次非常糟糕的财报，股价大幅下跌，他是否能坚持神话，也是一个非常值得期待与学习的案例。

我的上一篇博客，已经是五年前的事情了。

这五年变化很大，第一次经历公司上市，买了第一辆车，换了个公司，经历家人生病， 结了个婚，在深圳也安家立业。

这几年下来我并没少写东西， 整理很多日常中的规划总结， 读了很多书也写了不少笔记与心得。 但感觉很多内容并不能满足作为公开内容去发表的要求，碎片化不成体系，觉得写得很浅，达不到对外输出的水平。

我们在从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的一些知识整理与经验汇总。