每天推荐一个英文视频 [链接][链接] 本日看点 功能测试该怎么写，看这个视频就知道了。 [链接][链接]

花了一天的时间给 Stop the Guessing Performance Methodologies for Production Systems 制作了字幕：[链接]

本地的依赖其实是很复杂的问题。从操作系统的apt-get，到各种语言的pip, npm。包管理是无穷无尽的问题。但是所有的本地依赖已经被docker终结了。无论是依赖了什么，全部给你打包起来，从操作系统开始。除了你依赖的cpu指令集没法给你打包成镜像了，其他都给打包了。

Close to the metal code::dive conference 2014 - Scott Meyers: Cpu Caches and Why You Care CppCon 2014: Mike Acton "Data-Oriented Design and C++" Disruptor Chronicle Aeron scylladb Benchmarking Benchmarks, Performance, Scalability, and Capacity What's Behind the Numbers - Baron Schwartz Benchmarki...

当用户需要获取某个基础设施的时候，比如一个redis的集群，或者mysql的集群，可以无需在钉钉上找管理员，无需用邮件提申请。在web界面上自助就可以搞定。

测试代码 {代码...} 结果是 {代码...} 结论是 etcd 的 directory 类型节点可以通过设置recursive=True，watch其直接儿子的新增和删除 孙子节点的新增和删除无法被感知 没有加recursive=True无法感知其儿子的新增和删除 新增和删除的节点会在watch消息里给出，无需再去用get拉取内容。也就是watch给的是类似binlog的增量...

不同的类型的配置最开始可能都可以以配置文件的形式将就一下，但是其对管理和使用的需求却是相差很大的。etcd提供了一个很好的机制做为开头，但是未必适合所有的场景。

越来越多的公司言并称大数据，而大数据管道和存储集群的规模甚至可以是业务集群的一百倍的规模。这里有多少机器是真正在做有价值的事情，而有多少cpu cycle是白白被浪费掉了呢？data pipeline 中充斥着惊人的浪费！只是我们选择视而不见。廉不知耻地把集群规模到了xxx台做为自己的功劳。殊不知机器只是成本，集群规模只...

上报数据者直接是结果的受益者，并对其负责：因为上报数据的人直接是对最终的图表和监控负责的，他有最大的动机去选取合适的指标来帮助自己理解被监控的代码。这种模式可以避免“玩日志”的那帮人和那些平台出现。处理数据的人如果不负责被监控的业务，而上报数据的人不直接决定最终的图表，那么两方都做不好。

Excellent Talk，David Evans。我听过地最好的讲怎么写测试的演讲，受益匪浅。Our industry will be better if all the developer knows how to run their code with proper test, it is as simple as that.

虽然敏捷开发这个词已经臭大街，但是我仍然坚信TDD是正确的开发方式。其核心原理很简单就是更快的feedback cycle，即便TDD不能让我们可以在写代码之前就想好要写什么，但是起码它可以让我们在写完两三行代码之后就运行到那几行代码并验证一下。这总好过上线的时候发现php error去回滚要强吧。

通过存储packet的长度实现变长数据的存储。目标是把这样的内存结构存储到一个ring buffer里。整体的ring buffer的结构如下

用 golang 编写，解决事件快速同时可靠入Kafka的问题。绿色表示goroutine（可能是不同的线程），蓝色表示共享的资源。所有对蓝色资源的访问需要加锁。磁盘队列使用内存映射文件实现ring buffer。kafka agent启动的时候有一个bootstrap的broker列表，同时发送的时候会与每个相关的broker维护一个到多个连接。但是kafka ag...

所谓 structured logging 就是往日志文件里打json格式的日志，然后按照固定字段去检索的需求。这种需求目前一般是用这样的一个基础设施来满足的：

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。要真正把Elasticsearch当作数据库来使，Join是一个绕不过的话题。关于Elasticsearch如何支持join，这个slide总结得很好：[链接]。总体来说有这么几种方式：

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。前面我们使用sum或者avg的输入都是document的字段。如果需要对聚合的结果再次进行sum或者avg也是支持的。

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。下钻未必一定是GROUP BY，每记过一层GROUP BY，桶的数量就会增加一层。还有一种下钻是用 filter 来下钻，这种下钻方式会使下一层的 match的文档数量变少，但是桶的数量不变。

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。传统的 SQL 的语义是每一层查询是对下一层查询的综合，也就是每SELECT一层行数就会变少。比如

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。Elasticsearch 2.0引入的一个重大特性是支持了PipelineAggregation。在有这个特性之前，elasticsearch聚合之后可以做的计算仅仅是对TermsAggregation的结果做一个排寻，并取个TOP N。初此之外什么计算都做不了。而SQL里一个重要的特性是HAVING字句，用其过滤我们不关...

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。前面我们了解到在聚合之前可以做很多种变换，然后把变换之后的key再去分桶。这种变换的终极形式就是自定义表达式，当然自定义表达式的效率也是最低的。

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。有的时候分桶聚合之后会产生很多的桶，我们只对其中部分的桶关心。最简单的办法就是排序之后然后取前几位的结果。

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。前面histogram的聚合要求范围是固定的interval，而有的时候我们希望自己定义的range来做group by。这个时候就需要用CASE WHEN语句来把字段人为地分为几类。也就是相当于把这个字段先做了一个转换，然后再用转换过的字段进行聚合。

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。按已有字段来分桶是最简单的一种分桶的方式。很多时候我们希望用于分桶的key是需要先经过计算而来的。其中最简单的一种计算方式是按区间段来算histogram。用于计算的字段可以是时间戳，也可能是数值。

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。最简单的聚合是把整个index当作一个巨大的bucket（桶），然后去数这个桶里的数字。复杂一些的聚合我们先要能够把文档分到不同的桶里，然后去分别数每个桶的数字。统计聚合需要 分桶 （GROUP BY XXX INTO BUCKET），也需要 指标（METRIC）

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。今天需要做一些最简单的聚合查询 COUNT(*) SQL {代码...} {代码...} Elasticsearch {代码...} {代码...} 这个就不算聚合，只是看了一下最终满足过滤条件的 total hits count。 COUNT(ipo_year) 这个和 COUNT(*) 的区别是 COUNT(ipo_year) 要求字段必须有值才算一个。...

使用 [链接] 可以用 SQL 进行 elasticsearch 的查询。本章介绍简单的文档过滤条件 exchange='nyse' SQL {代码...} {代码...} Elasticsearch {代码...} {代码...} Profile {代码...} exchange='nyse' AND sector='Technology' SQL {代码...} {代码...} Elasticsearch {代码...} {代码...} Profile {代码...} last_sale &g...

Elaticsearch 有非常好的查询性能，以及非常强大的查询语法。在一定场合下可以替代RDBMS做为OLAP的用途。但是其官方查询语法并不是SQL，而是一种Elasticsearch独创的DSL。主要是两个方面的DSL：

Go开发者们请加入我们，滴滴出行平台技术部 taowen@didichuxing.com 推销Elasticsearch 时间序列数据库的秘密（1）—— 介绍时间序列数据库的秘密（2）——索引时间序列数据库的秘密（3）——加载和分布式计算 用SQL查询Elasticsearch [链接] 【01】把 Elasticsearch 当数据库使：表结构定义【02】把 Elasticsearch 当数据库使...

这是一篇老帖子了，我是来学习的。原文在这里：[链接]。问题是图片都没有了。我费了很大功夫才把原文的图片给找回来。排版之后重新发布一遍。 淘宝的notify是一个非常有特色的消息中间件。它用创新地方式解决了分布式事务的问题，用相对较低的成本，实现了跨micro service的最终一致性。这种把最终一致性用application q...

这段代码打印出!!!而不是???，因为resume的时候把执行重新跳转回interrupt的地方了。这种行为类似vba里的on error resume next（[链接]）。