本主题为系列文章，分上下两篇。本文主要介绍
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 的源码
C++11 中推出了三种智能指针，unique_ptr、shared_ptr 和 weak_ptr，同时也将 auto_ptr 置为废弃 (deprecated)。
但是在实际的使用过程中，很多人都会有这样的问题：
本文将从这几方面讲解智能指针：
最近在写 C++ 时，有这样一个代码需求：在 lambda 中，将一个捕获参数 move 给另外一个变量。
看似一个很简单常规的操作，然而这个 move 动作却没有生效。
具体代码如下：
std::vector<int> vec = {1,2,3};
auto func = [=](){
auto vec2 = std::move(vec);
std::cout << vec.size() << std::endl; // 输出：3
std::cout << vec2.size() << std::endl; // 输出：3
};代码可在 wandbox 运行。
我们期望的是，将对变量 vec 调用 std::move 后，数据将会移动至变量 vec2, 此时 vec 里面应该没有数据了。但是通过打印 vec.size() 发现 vec 中的数据并没有按预期移走。
这也就意味着，构造 vec2 时并没有按预期调用移动构造函数，而是调用了拷贝构造函数。
为什么会造成这个问题呢, 我们需要结合 std::move 和 lambda 的原理看下。（最终的解决方案可以直接看 这里）
随着 Golang 的兴起，协程尤其是有栈协程 (stackful coroutine) 越来越受到程序员的关注。协程几乎成了程序员的一套必备技能。
云风实现了一套 C 语言的协程库，整体背景可以参考其 博客。
这个协程库非常轻量级，一共也才 200 多行代码，使用上更贴近于 lua 的写法（众所周知，云风是知名的 lua 粉)。整体基于 ucontext 和共享栈模型实现了有栈协程，代码质量毋庸置疑，本文将详细剖析该协程库的实现原理。
同时，我也提供了 coroutine 注释版，辅助大家理解 coroutine 的代码。
微信云支付 Android 智能 POS 使用 WebSocket 实现了用户订单的实时推送。即，顾客在扫描了门店的付款码，客户端会随即进行语音播报和打印等动作。
客户端利用 WebSocket 与后端维持长连接，当后端收到该门店订单时，即将成功态的订单通过对应的连接中。
然而，商户网络环境的多样性会导致 WebSocket 链路出现各种异常，从而引发漏单问题。
我们根据实际的场景，对此订单推送系统在稳定性上进行了大量优化，尽可能地提升了服务的可用性及自我恢复的能力。