吞吐量

分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间我们自家的产品 RocketMQ (MetaQ的内核) 也顺利开源,得到大家的关注。 那么,消息中间件性能究竟哪家强? 带着这个疑问,我们中间件测试组对常见的三类消息产品(Kafka、RabbitMQ、RocketMQ)做了性能比较。 Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。 RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。 RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值

1：kafka可以通过多个broker形成集群，来存储大量数据；而且便于横向扩展。 2：kafka信息存储核心的broker，通过partition的segment只关心信息的存储，而生产者只负责向leader角色的partition提交数据，而消费者pull数据的时候自己通过zk存储offset信息，严格讲broker基本只关心存储数据； 3：kafka的ack策略也是提高吞吐量的手段： 　　1）生产者的acks如果设置0则只向leader发送数据，并不关心leader数据是否存储成功； 　　2）如果设置为1在向leader发送数据后需要等待leader存储成功后才会认为一次操作成功； 　　3）如果设置为-1在向leader发送数据后不但需要等待leader存储成功，还要等待各个follow角色的partition，从leader拉取数据后存储完成才算一次完整的ack，当然这种情况会降低kafka的吞吐量； ps:而且kafka底层是通过NIO顺序写数据，效率也是非常高的

吞吐率（Requests per second） 概念：服务器并发处理能力的量化描述，单位是reqs/s，指的是某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。 计算公式：总请求数 / 处理完成这些请求数所花费的时间，即 Request per second = Complete requests / Time taken for tests QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。 跟吞吐量有关的几个重要是：并发数、响应时间。 QPS（TPS），并发数、响应时间它们三者之间的关系是： QPS（TPS）= 并发数/平均响应时间 对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。 　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。 这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行

一、基本概念 1、测试计划是使用jmeter进行测试的起点，它是其它jmeter测试元件的容器。 2、线程组：代表一定数量的并发用户，它可以用来模拟并发用户发送请求。实际的请求内容在Sample中定义，它被线程组包含。可以在“测试计划->添加->线程组”来建立它，然后在线程组面板离有几个输入栏：Number of Threads(users)、Ramp-Up Period(in seconds)、loop count、其中Ram-Up Period(in seconds)表示在这个时间内创建完所有的线程。如：有8哥线程，Ramp-Up=200秒，那么线程的启动时间间隔为200/8=25秒，这样的好处是：一开始不会对服务器有太大的负载，线程组是为模拟鬓发负载而设计的。 3、取样器（Sampler）:模拟各种请求。所有实际的测试任务都由取样器承担，存在很多请求。如：HTTP 、ftp请求等等。 4、监听器：负责收集测试结果，同时耶被改制了结果显示的方式。功能是对取样器的请求结果显示，统计一些数据（吞吐量、KB/S）等。 5、断言：用于判断请求响应的结果是否如用户所期望，是都正确。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效测试时非常有用的。 6、定时器：负责定义请求（线程）之间的延迟间隔，模拟对服务器的连续请求。 7、逻辑控制器

使用消息队列的好处以及使用场景还有引发的问题 1.流量削峰,用于短时间高并发流量情况,如秒杀活动,双11活动 在传统模式中,用户请求到达服务器后,再由服务器将数据写入数据库,在高并发情况下,流量暴增,数据库写入压力剧增,造成服务器响应时间漫长. 使用消息队列后,服务器将数据发送到消息队列服务器,然后将响应结果返回给用户,消息队列的数据由其消费者去读取并异步的写入到数据库.通过拉长数据处理时间来减少数据库瞬时压力达到流量削峰的目的 2,服务解耦 假设有这样一个场景, 服务A产生数据, 而服务B,C,D需要这些数据, 那么我们可以在A服务中直接调用B,C,D服务,把数据传递到下游服务即可 但是,随着我们的应用规模不断扩大,会有更多的服务需要A的数据,如果有几十甚至几百个下游服务,而且会不断变更,再加上还要考虑下游服务出错的情况,那么A服务中调用代码的维护会极为困难 使用消息队列后, A服务只需要向消息服务器发送消息,而不用考虑谁需要这些数据;下游服务如果需要数据,自行从消息服务器订阅消息,不再需要数据时则取消订阅即可 3.异步调用 考虑定外卖支付成功的情况 支付后要发送支付成功的通知,再寻找外卖小哥来进行配送,而寻找外卖小哥的过程非常耗时,尤其是高峰期,可能要等待几十秒甚至更长 这样就造成整条调用链路响应非常缓慢 而如果我们引入消息队列,订单数据可以发送到消息队列服务器

PS：下面是性能测试的主要概念和计算公式，记录下： 一．系统吞度量要素： 一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。 单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）： 每秒钟request/事务 数量 并发数： 系统同时处理的request/事务数 响应时间： 一般取平均响应时间 （很多人经常会把并发数和TPS理解混淆） 理解了上面三个要素的意义之后，就能推算出它们之间的关系： QPS（TPS）= 并发数/平均响应时间 一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。 决定系统响应时间要素 我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。 系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间； 关键路径是有CPU运算、IO、外部系统响应等等组成。 二．系统吞吐量评估：

ActiveMQ 　　 单机吞吐量： 万级 　　 topic数量对吞吐量的影响： 　　 时效性： ms级 　　 可用性： 高，基于主从架构实现高可用性 　　 消息可靠性： 有较低的概率丢失数据 　　 功能支持： MQ领域的功能极其完备 　　 总结： 　　　　非常成熟，功能强大，在早些年业内大量的公司以及项目中都有应用 　　　　偶尔会有较低概率丢失消息 　　　　现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本 　　　　主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用 RabbitMQ 　　 单机吞吐量： 万级 　　 topic数量对吞吐量的影响： 　　 时效性： 微秒级，延时低是一大特点。 　　 可用性： 高，基于主从架构实现高可用性 　　 消息可靠性： 　　 功能支持： 基于erlang开发，所以并发能力很强，性能极其好，延时很低 　　 总结： 　　 　　　　erlang语言开发，性能极其好，延时很低； 　　　　吞吐量到万级，MQ功能比较完备 　　　　开源提供的管理界面非常棒，用起来很好用 　　　　社区相对比较活跃，几乎每个月都发布几个版本分 　　　　在国内一些互联网公司近几年用rabbitmq也比较多一些 但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。 　　　

转自 吞吐量（TPS）、QPS、并发数、响应时间（RT）概念 - 付金波的博客园 - 博客园 吞吐量(tps) 吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。 　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。 每秒查询率(qps)

分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间我们自家的产品 RocketMQ (MetaQ的内核) 也顺利开源,得到大家的关注。 那么,消息中间件性能究竟哪家强? 带着这个疑问,我们中间件测试组对常见的三类消息产品(Kafka、RabbitMQ、RocketMQ)做了性能比较。 Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。 RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。 RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值

已经不记得最早接触到 Disruptor 是什么时候了，只记得发现它的时候它是以具有闪电般的速度被介绍的。于是在脑子里， Disruptor 和“闪电”一词关联了起来，然而却一直没有时间去探究一下。 最近正在进行一项对性能有很高要求的产品项目的研究，自然想起了闪电般的 Disruptor ，这必有它的用武之地，于是进行了一番探查，将成果和体会记录在案。 一、什么是 Disruptor 从功能上来看，Disruptor 是实现了“队列”的功能，而且是一个有界队列。那么它的应用场景自然就是“生产者-消费者”模型的应用场合了。 可以拿 JDK 的 BlockingQueue 做一个简单对比，以便更好地认识 Disruptor 是什么。 我们知道 BlockingQueue 是一个 FIFO 队列，生产者(Producer)往队列里发布(publish)一项事件(或称之为“消息”也可以)时，消费者(Consumer)能获得通知；如果没有事件时，消费者被堵塞，直到生产者发布了新的事件。 这些都是 Disruptor 能做到的，与之不同的是，Disruptor 能做更多： 同一个“事件”可以有多个消费者，消费者之间既可以并行处理，也可以相互依赖形成处理的先后次序(形成一个依赖图)； 预分配用于存储事件内容的内存空间； 针对极高的性能目标而实现的极度优化和无锁的设计； 以上的描述虽然简单地指出了