分布式限速服务

分布式限速服务

好久没写技术博客了，由于工作中一直比较忙的状态，开发和研究了一些技术，但是没有很好地沉淀下来，还是需要通过博客，加深理解，进行进一步沉淀，在此立flag，之后工作每进行一个topic，都要在此进行总结沉淀。

程序=算法+数据结构，设计=算法+架构

• 本文从算法，架构两个方面来进行分析和设计

要解决的问题

• 准确性
• 低延迟
• 可扩容
• 降低资源占用
• 灵活
• 容错
• 5000w10个类型10倍容量=50亿数量级别的key，大小5G*100B = 500GB

系统设计就是在各种条件下的trade off,所以我们得先了解我们有什么东西可以trade off.

算法

算法好比数学定律，前人已经研究到位了，没必要赘述，这篇文章写得比较浅显易懂：https://blog.csdn.net/huangshulang1234/article/details/79371558
主要就是：计数器，滑动窗口，leaky bucket，token bucket

架构

从上图可以看出，限速架构大致分为两大类：ClientSide，ServerSide。
区别在于限速逻辑的判断发生在调用侧还是服务侧。

左边两类为ServerSide，右边为ClientSide

从以上几种架构大概可以看出来几个关键点：

• 蓝线通信的部分
• 黑线通信的部分
• ClienSide或者ServerSide计算的部分
• LimiterServer存储部分

存储：

• etcd

etcd is designed to be a highly available storage.
etcd's main use case is for storing metadata. We want to ensure there is no additional cost for that use case. 
etcd是一个高可用的kv存储系统，主要设计来存储meta信息。
etcd有一个配置：--quota-backend-bytes
MaxQuotaBytes = int64(8 * 1024 * 1024 * 1024) // 8GB
参见: https://github.com/etcd-io/etcd/issues/7045
性能参见官方数据：https://coreos.com/etcd/docs/latest/op-guide/performance.html

综上，etcd适用于节点间通信一些meta信息，但是对于超过8G的kv存储就不友好了。

• redis
• memcached
• Tikv

总结了一下，我提出了一种增强型架构：

存储

• ssd
• ram

如果能够直接用ssd进行随机读写的话，当然是非常便宜的方案，但是基于ssd的存储，当QD比较高的时候，latency就不满足要求了。性能参考：https://www.anandtech.com/show/8104/intel-ssd-dc-p3700-review-the-pcie-ssd-transition-begins-with-nvme/3

所以我们还是只能考虑ram的方案，需要一个distributed in-memory cache。
各种cache参考：https://en.wikipedia.org/wiki/Distributed_cache

主要考虑点：

• CAP
• latency，throughput
• 扩容
• 节点负载平衡性

下表为各个cache的对比
|||

cache名	CAP	latency	throughput	扩容	partition-hash算法
ignite
tikv
redis

ignite

reference:

1. Cloud Control with Distributed Rate Limiting
2. grpc load balance
3. Quota enforcement for high-performance
   distributed storage systems
4. golimit
5. doorman
6. etcd
7. aerospike
8. tikv
9. ignite
10. SN