Redis 作为一个单线程高性能的内存缓存 Server 而被人熟知。作为一个典型的 Reactor 式网络应用，Redis 能够达到如此高的性能，必然要依靠足够可靠的事件循环库。
Redis 内置了一个高性能事件循环器，叫做 AE。其定义和实现可以在 ae*.h/cpp 这些文件中找到。
AE 本身就是 Redis 的一部分，所以整体设计原则就是够用就行。也正因为这个背景，AE 的代码才可以简短干净，非常适合阅读和学习。
本文将基于 Redis 5.0.6 的源码分析下其事件循环器 (AE) 的实现原理。
同时本人也提供了一个 Redis 注释版，用以辅助理解 Redis 的源码。
本文属于 《Golang源码剖析系列》
Filebeat 是使用 Golang 实现的轻量型日志采集器，也是 Elasticsearch stack 里面的一员。本质上是一个 agent，可以安装在各个节点上，根据配置读取对应位置的日志，并上报到相应的地方去。
Filebeat 的可靠性很强，可以保证日志 At least once 的上报，同时也考虑了日志搜集中的各类问题，例如日志断点续读、文件名更改、日志 Truncated 等。
Filebeat 并不依赖于 Elasticsearch，可以单独存在。我们可以单独使用 Filebeat 进行日志的上报和搜集。filebeat 内置了常用的 Output 组件, 例如 kafka、Elasticsearch、redis 等。出于调试考虑，也可以输出到 console 和 file。我们可以利用现有的 Output 组件，将日志进行上报。
当然，我们也可以自定义 Output 组件，让 Filebeat 将日志转发到我们想要的地方。
filebeat 其实是 elastic/beats 的一员，除了 filebeat 外，还有 HeartBeat、PacketBeat。这些 beat 的实现都是基于 libbeat 框架。
本文属于 《Golang源码剖析系列》
uber 在 Github 上开源了一套用于服务限流的 go 语言库 ratelimit, 该组件基于 Leaky Bucket(漏桶) 实现。
我在之前写过一篇 《Golang 限流器 time/rate 实现剖析》，分析了 Golang 标准库中基于 Token Bucket 实现限流组件的 time/rate 原理，同时也讲了限流的一些背景。
相比于 TokenBucket 中，只要桶内还有剩余令牌，调用方就可以一直消费的策略。Leaky Bucket 相对来说更加严格，调用方只能严格按照预定的间隔顺序进行消费调用。(虽然 uber-go 对这个限制也做了一些优化，具体可以看下文详解)
还是老规矩，在正式讲其实现之前，我们先看下 ratelimit 的使用方法。
本文属于 《Golang源码剖析系列》
限流器是微服务中必不缺少的一环，可以起到保护下游服务，防止服务过载等作用。上一篇文章 《Golang 限流器 time/rate 使用介绍》 简单介绍了 time/rate 的使用方法，本文则着重分析下其实现原理。建议在正式阅读本文之前，先阅读下上一篇文章。
上一篇文章讲到，time/rate 是基于 Token Bucket(令牌桶) 算法实现的限流。本文将会基于源码，深入剖析下 Golang 是如何实现 Token Bucket 的。其代码也非常简洁，去除注释后，也就 200 行左右的代码量。
同时，我也提供了 time/rate 注释版，辅助大家理解该组件的实现。
本主题为系列文章，分上下两篇。本文主要介绍
time/rate的具体使用方法，另外一篇文章 《Golang 限流器 time/rate 实现剖析》 则着重介绍其内部实现原理。
限流器是后台服务中的非常重要的组件，可以用来限制请求速率，保护服务，以免服务过载。
限流器的实现方法有很多种，例如滑动窗口法、Token Bucket、Leaky Bucket 等。
其实 Golang 标准库中就自带了限流算法的实现，即 golang.org/x/time/rate。该限流器是基于 Token Bucket(令牌桶) 实现的。
简单来说，令牌桶就是想象有一个固定大小的桶，系统会以恒定速率向桶中放 Token，桶满则暂时不放。
而用户则从桶中取 Token，如果有剩余 Token 就可以一直取。如果没有剩余 Token，则需要等到系统中被放置了 Token 才行。
libco 是微信后台开发和使用的协程库，同时也是极少数的直接将 C/C++ 协程运用到如此大规模的生产环境中的案例。
在 《云风 coroutine 协程库源码分析》 中，介绍了有栈协程的实现原理。相比云风的 coroutine，libco 在性能上号称可以调度千万级协程。 从使用上来说，libco 不仅提供了一套类 pthread 的协程通信机制，同时可以零改造地将三方库的阻塞 IO 调用进行协程化。
本文将从源码角度着重分析 libco 的高效之道。
在正式阅读本文之前，如果对有栈协程的实现原理不是特别了解，建议提前阅读 《云风 coroutine 协程库源码分析》。
同时，我也提供了 libco 注释版，用以辅助理解 libco 的源码