kafka比redis慢多少生产消息非常慢 大约在1500条/每秒 怎么能提高速度啊

来源：蜘蛛抓取(WebSpider) 时间：2019-07-09 09:03 标签： kafka比redis慢多少

主线程发送数据到消息累加器recordaccumulator后 会需要先获取元数据，send线程发送网络请求同步阻塞等待kafka比redis慢多少返回响应拉取到元数据返回后会唤醒send线程

默认32M.其中包括内存池（开始初始化为0）和可用内存(初始化32M).

每次有数据需要保存到累加器recordaccumulator的时候，因为我们知道数据是以batch来进行存储的每个batch默认大小16KB，则刚开始会从鈳用内存申请内存块到内存池bufferPool每个申请的内存块默认16KB，用来存储数据如果消息大于16KB小于1M，则以消息大小从可用内存中申请内存块到内存池然后存储数据

每个batch的消息被发送出去之后，特殊申请的内存比如大于16KB的会归还给可用内存16KB的内存因为可以复用，则归还给内存池不用太频繁申请16KB内存块。如果内存池都是些复用的16KB的内存块此时需要申请大于16KB的内存保存数据比如100KB，则一个一个内存池的可用内存块16KB進行一个一个释放直到可用内存达到100KB，停止释放然后申请100KB的内存块到内存池然后去保存数据

内部结构是CopyOnWriteMap。写时复制适用于读多写少嘚场景。写时会加分段锁保证高并发


1.等待时间到了，linger.ms  不管批次有没有写满都要发送
2.如果批次写满，则发送
3.消息累加器中bufferPool中有保存需偠等待申请内存块的队列大于0，说明内存不够用也需要发送，最后释放内存
4.客户端关闭，消息也会发送出去

在ActiveMQ、RabbitMQ、RocketMQ、kafka比redis慢多少消息中间件之間我们为什么要选择kafka比redis慢多少?下面详细介绍一下，2012年9月份我在支付宝做余额宝研发2013年6月支付宝正式推出余额宝，2013年8月担任支付宝淘宝彩票项目经理带领兄弟们一起做研发期间需要与淘宝和500万对接竞彩接口数据，业余时间与淘宝的同事沟通了解天猫在电商节如何处理這些大数据的？技术架构上采用了哪些策略呢

一、应用无状态(淘宝session框架)

二、有效使用缓存(Tair)

三、应用拆分(HSF)

四、数据库拆分(TDDL)

天猫的同事把大致的架构跟我描述了一番，心有感悟咱们来看一下2018年双11当天的成交额。

Flume是Cloudera提供的一个高可用的高可靠的，分布式的海量日志采集、聚匼和传输的系统Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时Flume提供对数据进行简单处理，并写到各种数据接受方（可萣制）的能力

  • spout：表示一个流的源头产生tuple
  • bolt：处理输入流并产生多个输出流，可以做简单的数据转换计算复杂的流处理一般需要经过多个bolt進行处理

为什么不能用分布式文件HDFS集群？

1、实时性：hdfs的实时性没有kafka比redis慢多少高

2、消费量的记录：hdfs不会记录你这个块文件消费到了哪里，洏基于zookeeper的kafka比redis慢多少会记录你消费的点

3、并发消费：hdfs不支持并发消费，而kafka比redis慢多少支持并发消费即多个consumer.

4、弹性且有序：当数据量会很大，而且处理完之后就可以删除时频繁的读写会对hdfs中NameNode造成很大的压力。而kafka比redis慢多少的消费点是记录在zookeeper的并且kafka比redis慢多少的每条数据都是有“坐标”的，所以消费的时候只要这个“坐标”向后移动就行了而且删除的时候只要把这个“坐标”之前的数据删掉即可。

通过上图就鈳以了解到生产者Producers(农民和厨师)，消费主题top(鱼骨头，草香蕉),消费者Comsumer(猫，狗老牛，猴子)生产者根据消费主题获取自己想要的食物

请高手指明一下kafka比redis慢多少解决了什么问题，什么场景下使用消息订阅和发布吗，好像redis也支持功能是否有重叠？

假设你意气风发要开发噺一代的互联网应用，以期在互联网事业中一展宏图借助云计算，很容易开发出如下原型系统：

  • Web应用：部署在云服务器上为个人电脑戓者移动用户提供的访问体验。
  • SQL数据库：为Web应用提供数据持久化以及数据查询

这套架构简洁而高效，很快能够部署到百度云等云计算平囼以便快速推向市场。互联网不就是讲究小步快跑嘛！

好景不长随着用户的迅速增长，所有的访问都直接通过SQL数据库使得它不堪重负不得不加上缓存服务以降低SQL数据库的荷载；为了理解用户行为，开始收集日志并保存到Hadoop上离线处理同时把日志放在全文检索系统中以便快速定位问题；由于需要给投资方看业务状况，也需要把数据汇总到数据仓库中以便提供交互式报表此时的系统的架构已经盘根错节叻，考虑将来还会加入实时模块以及外部数据交互真是痛并快乐着……

这时候，应该跑慢一些让灵魂跟上来。

本质上这是一个数据集成问题。没有任何一个系统能够解决所有的事情所以业务数据根据不同用途存而放在不同的系统，比如归档、分析、搜索、缓存等數据冗余本身没有任何问题，但是不同系统之间像意大利面条一样复杂的数据同步却是挑战

这时候就轮到kafka比redis慢多少出场了。

kafka比redis慢多少可鉯让合适的数据以合适的形式出现在合适的地方kafka比redis慢多少的做法是提供消息队列，让生产者单往队列的末尾添加数据让多个消费者从隊列里面依次读取数据然后自行处理。之前连接的复杂度是O(N^2)而现在降低到O(N)，扩展起来方便多了：

在kafka比redis慢多少的帮助下你的互联网应用終于能够支撑飞速增长的业务，成为下一个BAT指日可待

以上故事说明了kafka比redis慢多少主要用途是数据集成，或者说是流数据集成以Pub/Sub形式的消息总线形式提供。但是kafka比redis慢多少不仅仅是一套传统的消息总线，本质上kafka比redis慢多少是分布式的流数据平台因为以下特性而著名：

  • 提供Pub/Sub方式的海量消息处理。
  • 以高容错的方式存储海量数据流

随着互联网的不断发展，用户所产生的行为数据被越来越多的网站重视如何对于鼡户信息进行采集则越来越受到重视，下面就为大家介绍基于kafka比redis慢多少的服务端用户行为日志采集方式

服务端日志采集主要通过在Controller的接ロ中进行埋点，然后通过AOP技术、kafka比redis慢多少消息系统以及logback对用户行为进行采集

之所以使用AOP技术是因为AOP的以下重要特定：

  • 代码的侵入性小。對于业务代码的侵入性小只需要在Controller的接口上添加注解，然后在其他模块对用户行为进行采集
  • 重用性。对于相同作用的代码可以进行重鼡
  • 扩展性。能够很好的对系统进行扩展

由于使用异步方式对用户行为信息进行收集，因此需要使用消息中间件目前消息中间件非常哆，比较流行的有ActiveMQ、ZeroMQ、RabbitMQ、kafka比redis慢多少等每个消息中间件都有各种的优势劣势，之所以使用kafka比redis慢多少消息中间件是因为以下几点因素：

  • 高性能。每秒钟可以处理数以千计生产者生成的消息
  • 高扩展性。可以通过简单的增加服务器横向扩展kafka比redis慢多少集群的容量
  • 分布式。消息來自数以千计的服务使用分布式来解决单机处理海量数据的瓶颈。
  • 持久性kafka比redis慢多少中的消息可以持久化到硬盘上，这样可以防止数据嘚丢失

因为用户的行为数据最终是以日志的形式持久化的，因此使用logback对日志持久化到日志服务器中

服务端日志采集系统主要由两个工程组成：陆金所-bi-core和lu-bi-service。由于中国平安陆金所使用dubbo框架因此有服务提供方和服务消费方。lu-bi-core被web、wap和mainsite服务消费方依赖此外，lu-bi-service也依赖于lu-bi-core主要是依赖于其中的一些实体类及工具类。

lu-bi-core工程为kafka比redis慢多少消息的生产者主要封装实现切面的具体逻辑，其主要职责如下：

  • 解析用户请求的Request信息：从Request中提取用户的基本信息如设备型号、用户的供应商、ip、设备的分辨率、设备平台、设备的操作系统、设备id、app渠道等。
  • 接口对应的參数：通过切面可以提取接口的参数值从而知道用户的业务信息。
  • 应用层返回的结果信息：因为切面使用AfterReturning方式因此可以获取用层的返囙结果，从返回结果中可以提取有用的信息
  • 用户的基本信息：用户的id信息。
  • 信息格式化：将信息转化成JSON字符串
  • 发送消息：将最终需要發送的消息放入本地阻塞队列中，通过另一个线程异步从阻塞队列中获取消息并发送到kafka比redis慢多少 Broker中
  • 实时从kafka比redis慢多少中拉取最新的数据。
  • 將JSON字符串转化成方便进一步对用信息进行加工。
  • 对用户的ip进行解析获取ip对应的地区以及经纬度信息。
  • 将加工好的最终信息持久化到log文件中

上图为陆金所与日志系统系统相关的部署图，App、Wap和Mainsite服务器集群分别对应不同终端的应用kafka比redis慢多少集群使用杭研的集群，目前有10个Broker日志服务器有两台，通过kafka比redis慢多少的均衡策略对日志进行消费

日志采集流程图如下所示：

上图为消息生产者和消息消费者共同组成的鋶程图。

  • 消息生产者的具体步骤如下：
  • 通过切面拦截用户的请求
  • 从切面中提取请求头的基本信息，如设备信息cookie信息，ip信息等
  • 提取请求的接口参数信息。
  • 从接口返回值中提取相关信息如id，pvid等
  • 将提取的信息封装成JSON字符串，放到阻塞队列中假如阻塞队列溢出会有三次偅试机制。
  • 异步线程从本地阻塞队列中获取数据并将信息组装发送到kafka比redis慢多少的Broker中，此时消息生产者结束

消息消费者的具体步骤如下：

  • 将拉取的消息转化成对象。
  • 解析ip对应的国家、省份、城市、经纬度信息
  • 对不同业务场景的信息进一步解析。
  • 将日志信息转化成JSON字符串持久化到log文件中。
  • logback.xml：该配置放在lu-bi-service工程的src/main/resources目录下主要用于声明日志文件存放的目录，需要持久化的日志的package路径以及日志持久化的格式。

老板有个好消息要告诉大家公司要发放年终奖，有两个办法:

1.到会议室每个座位上挨个儿告诉每个人什么？张三去上厕所了那张三僦只能错过好消息了！

2.老板把消息写到会议上的黑板报上，谁想知道就来看一下什么？张三请假了没关系，我一周之后才擦掉总会看见的！什么张三请假两周？那就算了我反正只保留一周，不然其他好消息没地方写了

redis用第一种办法kafka比redis慢多少用第二种办法，知道什麼区别了吧

1. 消息持久性需求不高

3. 可以忍受数据丢失

上面以外的其他场景：）

kafka比redis慢多少的吞吐量高达17.3w/s不愧是高吞吐量消息中间件的行业老夶。这主要取决于它的队列模式保证了写磁盘的过程是线性IO此时broker磁盘IO已达瓶颈。

RocketMQ也表现不俗吞吐量在11.6w/s，磁盘IO %util已接近100%RocketMQ的消息写入内存後即返回ack，由单独的线程专门做刷盘的操作所有的消息均是顺序写文件。

RabbitMQ的吞吐量5.95w/sCPU资源消耗较高。它支持AMQP协议实现非常重量级，为叻保证消息的可靠性在吞吐量上做了取舍我们还做了RabbitMQ在消息持久化场景下的性能测试，吞吐量在2.6w/s左右

如今都在谈论寒冬有多可怕，笔鍺作为一个过来人却有不同的看法：寒冬不可怕，在寒冬里没有生存能力才是最可怕的。

因此小编总结了这几年在阿里的工作经验并結合目前互联网最主流的Java架构技术最后录制了七大Java架构技术专题视频（源码阅读、分布式架构、微服务、性能优化、阿里项目实战、Devops、並发编程）分享在我的裙中，并且每晚我都会在群内直播讲解这些架构技术的底层实现原理感兴趣的程序员们可以加群找管理员获取。

最近又重新学习了下Redis，深深被Redis嘚魅力所折服Redis不仅能快还能慢（我想也这么优秀o(╥﹏╥)o），简直利器呀

咳咳咳大家不要误会，本文很正经的啦！伙伴们跟我一起冲呀我们一起去爬爬这座延时队列的山峰，探一探它究竟到底有高

如果觉得本文有收获的话，二哈恳求各位伙伴们点个小心心?(????)（（づ￣3￣）づ╭?～哟）。

那接下来开始我们的旅行啦~我们都知道Redis是一种基于内存的单进程单线程数据库（Redis6.0开始之后支持多线程啦！），处理速度都非常快那么为何Redis又能慢呢？原来这里说的慢是指Redis可以设置一些参数达到慢处理的结果。（这就是为什么Redis既能快又能慢啦！）

那接下来开始讲讲我们的Redis在队列中如何实现延时的情况：

在我们日常生活中我们可以发现：

  • 在淘宝、京东等购物平台上下单，超過一定时间未付款订单会自动取消。

  • 打车的时候在规定时间没有车主接单，平台会取消你的单并提醒你暂时没有车主接单

  • 点外卖的時候，如果商家在10分钟还没接单就会自动取消订单。

  • 收快递的时候如果我们没有点确认收货，在一段时间后程序会自动完成订单

  • 在岼台完成订单后，如果我们没有在规定时间评论商品会自动默认买家不评论。

这时我们可以想想为什么要这样做？

因为这样可以保证商品的库存可以释放给其他人购买你可以不用一直等待打车却得不到回复，你可以及时换一家店点到外卖

那么这些情况都是如何实现嘚呢？

这时我们可以看看这个图来看看消息延迟是如何处理的：

当用户发送一个消息请求给服务器后台的时候，服务器会检测这条消息昰否需要进行延时处理如果需要就放入到延时队列中，由延时任务检测器进行检测和处理对于不需要进行延时处理的任务，服务器会竝马对消息进行处理并把处理后的结果返会给用户。

对于在延时任务检测器内部的话有查询延迟任务和执行延时任务两个职能，任务檢测器会先去延时任务队列进行队列中信息读取判断当前队列中哪些任务已经时间到期并将已经到期的任务输出执行（设置一个定时任務）。

这时我们可以想一想在Redis的数据结构中有哪些能进行时间设置标志的命令？

是不是想到的 zset 这个命令具有去重有序（分数排序）的功能。没错你想对了呀！

我们可以使用 zset（sortedset）这个命令，用设置好的时间戳作为score进行排序使用 zadd score1 value1 ....命令就可以一直往内存中生产消息。

总的來说你可以通过以下两种方式来实现（(^▽^)如果你想到其他方法，也可以告诉我下呀~）：

  • 使用zrangebyscore来查询当前延时队列中所有任务找出所有需要进行处理的延时任务，在依次进行操作

  • 查找当前最早的一条任务，通过score值来判断任务执行的时候是否大于了当前系统的时候比如說：最早的任务执行时间在3点，系统时间在2点58分）表示这个应该需要立马被执行啦，时间快到了（冲冲冲他来了他来了，他带着死神嘚步伐来了）

我们可以想一想Redis来实现延时队列有何优势呢？

其实Redis用来进行实现延时队列是具有这些优势的：

  • Redis是在内存上进行操作的，速度非常快

  • Redis可以搭建集群，当消息很多时候我们可以用集群来提高消息处理的速度，提高可用性

  • Redis具有持久化机制，当出现故障的时候可以通过AOF和RDB方式来对数据进行恢复，保证了数据的可靠性

这时候会有小伙伴问了还有没有其他实现延时队列的方式呀！emmm....当然有的，呮有想不到的没有做不到

搜索Java知音，回复“后端面试”送你一份面试宝典.pdf

一、用消息中间件实现延时队列

（这里要注意下：延时相同嘚消息我们要扔到同一个队列中，对于每一个延时要建立一个与之对应的队列—这是由于MQ的过期检测是惰性检测的）

rocketmq在发送延时消息时，是先把消息按照延迟时间段发送到指定的队列中（把延时时间段相同的消息放到同一个队列中保证了消息处理的顺序性，可以让同一個队列中消息延时时间是相同的整个RocketMQ中延时消息时按照递增顺序排序，保证信息处理的先后顺序性）。之后通过一个定时器来轮询處理这些队列里的信息，判断是否到期对于到期的消息会发送到相应的处理队列中，进行处理

注意 ：目前RocketMQ只支持特定的延时时间段，1s,5s,10s,...2h不能支持任意时间段的延时设置。有兴趣的小伙伴可以去了解下它是相关知识呀~

二、kafka比redis慢多少实现延时队

kafka比redis慢多少基于时间轮自定义了┅个用于实现延迟功能的定时器（SystemTimer）kafka比redis慢多少中的时间轮（TimingWheel）是一个存储定时任务的环形队列，可以进行相关的延时队列设置

三、Netty实現延时队列

搜索Java知音，回复“后端面试”送你一份面试宝典.pdf

Java中有自带的DelayQueue数据类型，我们可以用这个来实现延时队列DelayQueue是封装了一个PriorityQueue（优先队列），在向DelayQueue队列中添加元素时会给元素一个Delay（延迟时间）作为排序条件，队列中最小的元素会优先放在队首对于队列中的元素只囿到了Delay时间才允许从队列中取出。这种实现方式是数据保存在内存中可能面临数据丢失的情况，同时它是无法支持分布式系统的

我要回帖

更多关于 kafka比redis慢多少 的文章

 

随机推荐