高并发系统设计之开放平台API接口调用频率控制系统

先描述下基本场景： 

系统API接口日均调用次数预计1亿次，提供5台服务器。 

须要作两种层面的控制： 

> 单IP、单应用每小时调用次数不超过10000次 

> 单应用、单用户、单接口每小时调用次数不超过1000次 

要求每次对频控系统的调用的响应时间在20ms内。 

此外，应用开发者和开放平台所属公司关心调用次数统计数据，如当天某应用全部接口被调用总次数、当天某应用某接口被调用次数、当天某应用用户使用数等。

    根据上面，咱们能够直接获得系统响应度要求和计算获得系统吞吐量要求，计算公式以下： 

1  2	频控系统吞吐量（系统每秒可以处理的请求数）      = 80% * 1亿 / (24小时 * 60分钟 * 60秒 * 40% * 5) = 4630tps

    80%、40%是指一天中有80%的请求发生在40%的时间内，是粗略的估算值。5是服务器数量。因此获得吞吐量要求为4630tps。前期设计系统时必须参考这些性能指标，后期压测系统时必须根据这些指标设计测试计划。 

    总结下系统设计须要达成的目标： 

• 请求的响应足够快 

• 能支撑4630tps 

• 占用的CPU、内存等硬件资源不能太夸张（隐性设计目标）

A、数据结构设计

    计数是典型的key-value数据结构。 

    可能想到的最简单最天然的方式是下面这样的： 

1  2	K(app_id, ip) => V(count, startTime, lastTime)  K(app_id, uid, interface_id) => V(count, startTime, lastTime)

    startTime记录的是第一次调用的发生时刻，lastTime记录的是最近一次调用的发生时刻，它们用来判断是否应该重置计数值count和是否该拒绝调用。 

    为了节省内存，有必要对key和value作特殊设计，最次的方案固然是直接拼接上面各个字段。但这是很是不合理的，咱们来简单估算下： 

假设应用有10,000个，平均每一个应用的用户数为100,000，接口数为50，独立访问IP地址为1,000,000，那么数据项总共为： 

10,000 * 1,000,000 + 10,000 * 100,000 * 50 = 600亿 

那么若是每一个数据项节省1个字节，可以节省的总数据存储是600G，这是很是可观的。 

    对于Key，一种更优方案是先拼接Key的字符串，而后MD5获得32位定长字符串做为Key，Key定长的话或许对性能提高也会有必定帮助。 

    对于Value，count、startTime、lastTime信息不能丢失，那么或许能够考虑下面两种优化方案： 

• 无损压缩Value字符串，好比使用Snappy字符串压缩算法，但压缩和解压缩会带来额外的CPU计算消耗，须要权衡 

• 计数不须要太精确，因此能够牺牲必定精确度换取空间节省。或许咱们能够利用 CountingBloomFilter？Key须要从新设计为：MD5(app_id, interface_id, 如今距离1970年1月1号的小时数)，Value就是CountingBloomFilter数据结构了，每一个调用先根据app_id、 interface_id、如今距离1970年1月1号的小时数计算32位MD5值，而后获得所属的CountingBloomFilter（若是没有就 建立），而后每次先检查是否已达到最大插入次数，若是是则直接返回，若是不是才插入。但 是咱们别忘了一点：CountingBloomFilter支持最大重复插入次数为15，远小于这里的1000次和10000次。因此很残酷，CountingBloomFilter不适合这种方案。但这是一个很好的起点，Value的数据结构虽然不能用 CountingBloomFilter，但或许能够用其余的优化数据结构，请看：http://blog.csdn.net/hguisu/article/details/7856239。

    另外频率控制通常能够采用“令牌桶算法”，这里再也不深刻，能够参考： 

    http://en.wikipedia.org/wiki/Token_bucket

B、数据存储设计

    考虑到性能要求，确定须要用到Cache，这里打算选用Redis。再根据上面的估算，数据项总共有600亿，因此不可能把全部数据项所有放到Redis Cache中（假设每一个Cache项占100个字节，估算下须要多少内存。 

因此我这里采用冷热数据分离方案。有这么三类数据： 

• 冷数据存放在MySQL数据库，按照app_id、uid进行水平Shard 

• 不冷不热数据采用Hash结构压缩存储在Redis，具体结构下面会提到 

• 热数据放在另外的Redis库中，而且“展开式”存储以改善访问性能 

   

    热数据的所谓“展开式”结构是指将上面两个维度的计数分开，即存成相似下面这两种结构： 

1  2	K取MD5(app_id, ip, 如今距离1970年1月1号的小时数)，V取一个长整型值表示计数  K取MD5(app_id, interface_id, uid, 如今距离1970年1月1号的小时数)，V取一个长整型值表示计数

    Redis Cache失效时间：

    全部Redis Cache数据的失效时间设置为1小时到1小时1分钟之间的某个随机值，这样能某种程度上避免缓存集体失效引发的“雪崩”。 

    冷热数据迁移过程：

    数据的冷热一直在发生着改变，因此冷热数据之间须要进行迁移。 

    第一种方案是由后台进程按期将

• 热数据中符合冷数据标准的数据移动到不冷不热数据缓存

• 将不冷不热数据中符合热数据标准的数据迁移到热数据缓存

• 将不冷不热数据中符合冷数据标准的数据迁移到MySQL数据库

• 将MySQL数据库中符合不冷不热数据标准的数据迁移到不冷不热数据缓存

    判断冷热的标准是基于天天计算一次的历史平均每小时调用次数。 

    第二种方案是在调用时主动进行迁移，基于最近50次调用的平均时间间隔来判断（也就是对于每个数据项还要存储一个它最近50次调用的平均时间间隔），迁移过程同第一种。