Mobabel Blog

[转]秒杀聊聊秒杀限流的多种实现 0

[转]秒杀聊聊秒杀限流的多种实现

前言 俗话说的好,冰冻三尺非一日之寒,滴水穿石非一日之功,罗马也不是一天就建成的。两周前秒杀案例初步成型,分享到了中国最大的同性交友网站-码云。同时也收到了不少小伙伴的建议和投诉。我从不认为分布式、集群、秒杀这些就应该是大厂的专利,在互联网的今天无论什么时候都要时刻武装自己,只有这样,也许你的春天就在明天。 在开发秒杀系统案例的过程中,前面主要分享了队列、缓存、锁和分布式锁以及静态化等等。缓存的目的是为了提升系统访问速度和增强系统的处理能力;分布式锁解决了集群下数据的安全一致性问题;静态化无疑是减轻了缓存以及DB层的压力。 限流 然而再牛逼的机器,再优化的设计,对于特殊场景我们也是要特殊处理的。就拿秒杀来说,可能会有百万级别的用户进行抢购,而商品数量远远小于用户数量。如果这些请求都进入队列或者查询缓存,对于最终结果没有任何意义,徒增后台华丽的数据。对此,为了减少资源浪费,减轻后端压力,我们还需要对秒杀进行限流,只需保障部分用户服务正常即可。 就秒杀接口来说,当访问频率或者并发请求超过其承受范围的时候,这时候我们就要考虑限流来保证接口的可用性,以防止非预期的请求对系统压力过大而引起的系统瘫痪。通常的策略就是拒绝多余的访问,或者让多余的访问排队等待服务。 限流算法 任何限流都不是漫无目的的,也不是一个开关就可以解决的问题,常用的限流算法有:令牌桶,漏桶。 令牌桶 令牌桶算法是网络流量整形(Traffic Shaping)和速率限制(Rate Limiting)中最常使用的一种算法。典型情况下,令牌桶算法用来控制发送到网络上的数据的数目,并允许突发数据的发送(百科)。 在秒杀活动中,用户的请求速率是不固定的,这里我们假定为10r/s,令牌按照5个每秒的速率放入令牌桶,桶中最多存放20个令牌。仔细想想,是不是总有那么一部分请求被丢弃。 漏桶 漏桶算法的主要目的是控制数据注入到网络的速率,平滑网络上的突发流量。漏桶算法提供了一种机制,通过它,突发流量可以被整形以便为网络提供一个稳定的流量(百科)。 令牌桶是无论你流入速率多大,我都按照既定的速率去处理,如果桶满则拒绝服务。 应用限流 Tomcat 在Tomcat容器中,我们可以通过自定义线程池,配置最大连接数,请求处理队列等参数来达到限流的目的。 Tomcat默认使用自带的连接池,这里我们也可以自定义实现,打开/conf/server.xml文件,在Connector之前配置一个线程池:

name:共享线程池的名字。这是Connector为了共享线程池要引用的名字,该名字必须唯一。默认值:None; namePrefix:在JVM上,每个运行线程都可以有一个name 字符串。这一属性为线程池中每个线程的name字符串设置了一个前缀,Tomcat将把线程号追加到这一前缀的后面。默认值:tomcat-exec-; maxThreads:该线程池可以容纳的最大线程数。默认值:200; maxIdleTime:在Tomcat关闭一个空闲线程之前,允许空闲线程持续的时间(以毫秒为单位)。只有当前活跃的线程数大于minSpareThread的值,才会关闭空闲线程。默认值:60000(一分钟)。 minSpareThreads:Tomcat应该始终打开的最小不活跃线程数。默认值:25。 配置Connector

executor:表示使用该参数值对应的线程池; minProcessors:服务器启动时创建的处理请求的线程数; maxProcessors:最大可以创建的处理请求的线程数; acceptCount:指定当所有可以使用的处理请求的线程数都被使用时,可以放到处理队列中的请求数,超过这个数的请求将不予处理。 API限流...

0

[转]TCP三次握手原理及故障排查

最近碰到一个问题,Client 端连接服务器总是抛异常。在反复定位分析、并查阅各种资料搞懂后,我发现并没有文章能把这两个队列以及怎么观察他们的指标说清楚。   因此写下这篇文章,希望借此能把这个问题说清楚。欢迎大家一起交流探讨。 问题描述 场景:Java 的 Client 和 Server,使用 Socket 通信。Server 使用 NIO。 问题: 间歇性出现 Client 向 Server 建立连接三次握手已经完成,但 Server 的 Selector 没有响应到该连接。 出问题的时间点,会同时有很多连接出现这个问题。 Selector 没有销毁重建,一直用的都是一个。 程序刚启动的时候必会出现一些,之后会间歇性出现。

[转]去哪儿网开源消息队列QMQ 0

[转]去哪儿网开源消息队列QMQ

GitHub 开源项目地址传送门: https://github.com/qunarcorp/qmq 背   景 2012 年,随着公司业务的快速增长,公司当时的单体应用架构很难满足业务快速增长的要求,和其他很多公司一样,去哪儿网也开始了服务化改造,按照业务等要素将原来庞大的单体应用拆分成不同的服务。那么在进行服务化改造之前首先就是面临是服务化基础设施的技术选型,其中最重要的就是服务之间的通信中间件。一般来讲服务之间的通信可以分为同步方式和异步方式。同步的方式的代表就是 RPC,我们选择了当时还在活跃开发的 Alibaba Dubbo(在之后 Dubbo 官方停止了开发,但是最近 Dubbo 项目又重新启动了)。 异步方式的代表就是消息队列 (Message Queue),MQ 在当时也有很多开源的选择:RabbitMQ, ActiveMQ, Kafka, MetaQ(RocketMQ 的前身)。首先因为技术栈我们排除了 erlang 开发的 RabbitMQ,而 Kafka 以及 Java 版 Kafka 的 MetaQ 在当时还并不成熟和稳定。而 ActiveMQ...

[转]妥妥的吃透“”负载均衡” 0

[转]妥妥的吃透“”负载均衡”

我们都对高可用有一个基本的认识,其中负载均衡是高可用的核心工作。本文将通过如下几个方面,让你妥妥的吃透“”负载均衡”。 负载均衡是什么 常用负载均衡策略图解 常用负载均衡策略优缺点和适用场景 用健康探测来保障高可用 结语

[总结]Spring事务管理中@Transactional的参数 0

[总结]Spring事务管理中@Transactional的参数

@Transactional注解就代表支持事务管理,如果这个注解在类上,那么表示该注解对于所有该类中的public方法都生效;如果注解出现在方法上,则代表该注解仅对该方法有效,会覆盖先前从类层次继承下来的注解。 一般情况下不要将这个注解加到接口和抽象类上,因为注解是不能被继承的。

0

[转] Istio是什么

如果你比较关注新兴技术的话,那么很可能在不同的地方听说过 Istio,并且知道它和 Service Mesh 有着牵扯。 这篇文章可以作为了解 Istio 的入门介绍,了解什么是 Istio,Istio 为什么最近这么火,以及 Istio 能给我们带来什么好处。 什么是 Istio? 官方对 Istio 的介绍浓缩成了一句话: An open platform to connect, secure, control and observe services.

算法资源汇总 0

算法资源汇总

红黑树 计数排序 如何用字典树进行 500 万量级的单词统计 教你如何迅速秒杀掉:99%的海量数据处理面试题

0

[转]微前端 – 将微服务理念延伸到前端开发中

本文描述了采用不同 JavaScript 技术框架的多个团队中协同构建一个现代化前端 Web 应用所需要的技术、策略和方法。 什么是微前端? 微前端这个术语最初来自 2016 年的 ThoughtWorks 技术雷达[ https://www.thoughtworks.com/radar/techniques/micro-frontends ],它将微服务的概念扩展到了前端领域。目前的趋势是构建一个功能丰富且强大的前端应用,即单页面应用(SPA),其本身一般都是建立在一个微服务架构之上。前端层通常由一个单独的团队开发,随着时间的推移,会变得越来越庞大而难以维护。这就是传说中的前端巨无霸(Frontend Monolith) [ https://www.youtube.com/watch?v=pU1gXA0rfwc ]。

程序员忧虑语言和框架,感觉自己跟不上,是因为没掌握核心? 0

程序员忧虑语言和框架,感觉自己跟不上,是因为没掌握核心?

近日看了一篇公众号的文章“写给期待年薪百万的IT同学”,作者是做海量分布式服务器系统设计开发的,文中提到: 核心能力是什么?是架构设计,关键细节设计的能力和经验。 在海量服务器设计领域,核心能力,大概包含物理设计和软件设计。物理设计包含:磁盘存储设计,内存缓存设计,核心数据结构设计,一致性问题处理,容灾设计等;软件设计方面包含:模块划分,接口定义,设计模式应用,核心数据传输结构设计等。拥有上面的核心能力,你用C/C++,Java,甚至python都可以实现。在这里,核心竞争能力跟语言其实没有多大的关系。