Provide Best Programming Tutorials

消息队列:秒杀时如何处理每秒上万次的下单请求?

在课程一开始,我就带你了解了高并发系统设计的三个目标:性能、可用性和可扩展性,而 在提升系统性能方面,我们一直关注的是系统的查询性能。也用了很多的篇幅去讲解数据库 的分布式改造,各类缓存的原理和使用技巧。究其原因在于,我们遇到的大部分场景都是读 多写少,尤其是在一个系统的初级阶段。 比如说,一个社区的系统初期一定是只有少量的种子用户在生产内容,而大部分的用户都 在“围观”别人在说什么。此时,整体的流量比较小,而写流量可能只占整体流量的百分之 一,那么即使整体的 QPS 到了 10000 次 / 秒,写请求也只是到了每秒 100 次,如果要对 写请求做性能优化,它的性价比确实不太高。 但是,随着业务的发展,你可能会遇到一些存在高并发写请求的场景,其中秒杀抢购就是最 典型的场景。假设你的商城策划了一期秒杀活动,活动在第五天的 00:00 开始,仅限前 200 名,那么秒杀即将开始时,后台会显示用户正在疯狂地刷新 APP 或者浏览器来保证自 己能够尽量早的看到商品。 这时,你面对的依旧是读请求过高,那么应对的措施有哪些呢? 因为用户查询的是少量的商品数据,属于查询的热点数据,你可以采用缓存策略,将请求尽 量挡在上层的缓存中,能被静态化的数据,比如说商城里的图片和视频数据,尽量做到静态 化,这样就可以命中 CDN…

Continue Reading

Zipkin 和 Pinpoint 选型对比

一、背景 Pinpoint 是一款开源的应用程序性能管理(Application Performance Management)工具,开发团队来自韩国的搜索引擎门户 Naver(截止到 2016 年 5月,Alexa 全球排名第 58 位,韩国本土排名第一位)。该项目于 2012 年 7 月开始,2015 年 1 月开源,至今的稳定版本是 1.5.2。与 Zipkin 类似,其理论基础也是基于 Google Dapper 的那篇论文。 二、Pinpoint 与 Zipkin 的差异性 Pinpoint…

Continue Reading
Close Menu