Other

杂七杂八的一些技术,包括但不限于jquery,js,日志,新闻等

[转]开放平台API接口调用频率控制系统设计浅谈 Other

[转]开放平台API接口调用频率控制系统设计浅谈

先描述下基本场景: 系统API接口日均调用次数预计1亿次,提供5台服务器。 需要做两种层面的控制: > 单IP、单应用每小时调用次数不超过10000次 > 单应用、单用户、单接口每小时调用次数不超过1000次 要求每次对频控系统的调用的平均响应时间在20ms内。 此外,应用开发者和开放平台所属公司关心调用次数统计数据,如当天某应用所有接口被调用总次数、当天某应用某接口被调用次数、当天某应用用户使用数等。 根据上面,我们可以直接得到系统响应度要求和计算得到系统吞吐量要求,计算公式如下: 80%、40%是指一天中有80%的请求发生在40%的时间内,是粗略的估算值。5是服务器数量。所以得到吞吐量要求为4630tps。前期设计系统时必须参考这些性能指标,后期压测系统时必须根据这些指标设计测试计划。 总结下系统设计需要达成的目标: 请求的响应足够快 能支撑4630tps 占用的CPU、内存等硬件资源不能太夸张(隐性设计目标) A、数据结构设计初步尝试 计数是典型的key-value数据结构。 可能想到的最简单最自然的方式是下面这样的: startTime记录的是第一次调用的发生时刻,lastTime记录的是最近一次调用的发生时刻,它们用来判断是否应该重置计数值count和是否该拒绝调用。startTime和lastTime都只精确到秒级。 为了节省内存,有必要对key和value做特殊设计,最次的方案当然是直接拼接上面各个字段。但这是非常不合理的,我们来简单估算下: 假设应用有10,000个,平均每个应用的用户数为100,000,接口数为50,独立访问IP地址为1,000,000,那么数据项总共为: 那么如果每个数据项节省1个字节,能够节省的总数据存储是600G,这是非常可观的。 对于Key,一种更优方案是先拼接Key的字符串,然后MD5得到16位定长字符串作为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号的小时数”计算16位MD5值,然后得到所属的CountingBloomFilter(如果没有就创建),然后每次先检查是否已达到最大插入次数,如果是则直接返回,如果不是才插入。但是我们别忘了一点:CountingBloomFilter支持最大重复插入次数为15,远小于这里的1000次和10000次。所以很遗憾,CountingBloomFilter不适合这种方案。但这是一个很好的起点,Value的数据结构虽然不能用CountingBloomFilter,但或许可以用其他的优化数据结构,可以参考: http://blog.csdn.net/hguisu/article/details/7856239 还有一篇文章标题大概是用1k内存来排序亿级数组,找不到了。另外频率控制数据结构模型还可以参考“令牌桶算法”,这里不再深入,详情看:http://en.wikipedia.org/wiki/Token_bucket B、进一步的数据存储和数据结构设计 考虑到性能要求,肯定需要用到Cache,这里打算选用Redis做Cache。再根据上面的估算,数据项总共有600亿,所以不可能把所有数据项全部放到Redis Cache中(假设每个Cache项占100个字节,估算下需要多少内存,嘿嘿)。 所以我这里采用冷热数据分离方案。有这么三类数据: 冷数据存放在MySQL数据库,按照app_id、uid进行水平Shard 不冷不热数据采用Redis Hash结构存储(这种内存结构更加紧凑) 热数据放在另外的Redis库中,并且“展开式”存储以改善访问性能 先简单说下不冷不热数据的Redis Hash结构,Key是app_id,Field是MD5(ip, interface_id, uid, 现在距离1970年1月1号的小时数),Value包括两个计数值,即单IP、单应用已调用次数和单应用、单接口、单用户已调用次数。这样设计相当于把本来应该存成两项的数据合并到了一个缓存数据项中。 热数据的所谓“展开式”结构是指将上面两个维度的计数分开,即存成类似下面这两种结构: 这种方案有一个小缺陷,那就是小时区间的划分不太符合用户的直觉。用户的直觉是认为真正第一次调用的时刻才是计时起点。为了满足这个需求,可以回归到A节的数据结构上,变成如下: 另外,我后面仔细思考过,不冷不热数据采用Redis Hash和热数据展开存储,是否真的会像我推断的那样展开存储更快? 答案是不一定。因为Redis Hash存储的话,只需要一次Redis访问外加一些解析计算开销,而展开存储需要两次Redis访问。应该不是绝对的,需实际进行测量后才能下结论。 Redis···
[转]舌尖上的程序猿, 真牛,这韵味,像极了 Other

[转]舌尖上的程序猿, 真牛,这韵味,像极了

码完代码,他起身关上电脑,用滚烫的开水为自己泡制一碗腾着热气的老坛酸菜面。中国的程序员更偏爱拉上窗帘,在黑暗中享受这独特的美食。这是现代工业给一天辛苦劳作的人最好的馈赠。 南方一带生长的程序员虽然在京城多年,但仍口味清淡,他们往往不加料包,由脸颊自然淌下的热泪补充恰当的盐分。他们相信,用这种方式,能够抹平思考着现在是不是过去想要的未来而带来的大部分忧伤… 小李的父亲在年轻的时候也是从爷爷手里接收了祖传的代码,不过令人惊讶的是,到了小李这一代,很多东西都遗失了,但是程序员苦逼的味道保存的是如此的完整。 就在24小时之前,最新的需求从PM处传来,为了得到这份自然的馈赠,码农们开机、写码、调试、重构,四季轮回的等待换来这难得的丰收时刻。码农知道,需求的保鲜期只有短短的两天,码农们要以最快的速度对代码进行精致的加工,任何一个需求都可能在24小时之后失去原本的活力,变成一文不值的垃圾创意。
2011,2012,2013年中国软件开发者薪资大调查 Other

2011,2012,2013年中国软件开发者薪资大调查

自2011年起,CSDN携手《程序员》杂志发起了“2011,2012,2013年中国软件开发者薪资大调查”活动。通过对调查问卷数据进行整理分析形成的调查报告,为我们了解国内软件开发者待遇水平、生存状态以及行业现状提供了支撑。 2013年中国软件开发者薪资调查报告:软件开发者薪资增幅放缓 2012年软件开发者薪资调查报告:开发者薪资水平明显提高 2011程序员薪资调查揭晓:5年和5000元是分水岭
教你怎么使用Gravatar全球通用头像 Other

教你怎么使用Gravatar全球通用头像

如果你在人家博客留言时使用邮箱,而没有显示一个比较个性的头像的话,那么我们完全可以说,你已经OUT了。 先来普及一下Gravatar全球通用头像: Globally Recognized Avatar的缩写,是 http://cn.gravatar.com 推出的一项服务,意为“全球通用头像”。如果在Gravatar的服务器上放置了你自己的头像,那么在任何支持Gravatar的blog或者留言本上留言时,只要提供你与这个头像关联的email地址,就能够显示出你的Gravatar头像来。 那么Gravatar全球通用头像如何申请呢,下面上教程。 打开 http://cn.gravatar.com,点击左上角菜单里的Sign Up。 然后会进入一个页面,需要你输入Email地址,输入后,会向你的邮箱里发一封确认信。 进入你的邮箱,从Gravatar发出的信件打开一个确认链接。 打开后,输入用户名和密码,注意,名字不能大写,而且不能跟别人注册的名字重复,否则无法注册成功的。 注册好了登陆进去,点击“add a new image”;然后选择上传图片,一般都是从电脑中上传(My computer’s hard drive)。 上传并裁剪,这个地方很灵活,头像选择框是可以伸缩的,效果可以在右侧看到。 头像上传后,图片要分级的,选择你上传的图片的级数,一般的,如果你上传的图片不太恶劣的话,就选G级,也就是大众都可以看的。 等待审核,可能需要几分钟短暂审核一下,一般选择了G,而你的图片没什么特别的,很快就通过。一般遇上慢的情况也就10分钟左右。 到支持Gravatar头像功能的网站,输入申请头像时的邮箱发表评论试试吧,要想改头像的话只需要到http://cn.gravatar.com网站里登陆后修改即可。