Apache Kafka 发布 1.0 的首个更新版本,Bug 修复 - 开源中国社区
Apache Kafka 发布 1.0 的首个更新版本,Bug 修复
局长 2018年03月07日

Apache Kafka 发布 1.0 的首个更新版本,Bug 修复

局长 局长 发布于2018年03月07日 收藏 9

Apache Kafka 1.0 重大版本于 2017 年 11 月发布,时隔 4 个月,现在迎来了它的首次更新。本次发布的 Apache Kafka 1.0.1 是一个 bug 修复版本,已修复了 49 个问题。虽然这些 bug 不是严重的错误,但这些修复会产生重大的影响,下面介绍一下一些重要的 bug 修复:

  • KAFKA-6277: Make loadClass thread-safe for class loaders of Connect plugins

  • KAFKA-6185: Selector memory leak with high likelihood of OOM in case of down conversion

  • KAFKA-6269: KTable state restore fails after rebalance

  • KAFKA-6190: GlobalKTable never finishes restoring when consuming transactional messages

  • KAFKA-6529: Stop file descriptor leak when client disconnects with staged receives

  • KAFKA-6238: Issues with protocol version when applying a rolling upgrade to 1.0.0

发布说明:https://dist.apache.org/repos/dist/release/kafka/1.0.1/RELEASE_NOTES.html  
源码下载:https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.1/kafka-1.0.1-src.tgz  
二进制包下载:  
https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.1/kafka_2.11-1.0.1.tgz (Scala 2.11)  
https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.1/kafka_2.12-1.0.1.tgz (Scala 2.12)

Apache Kafka 的目的是提供一个发布订阅解决方案,它可以处理消费者规模的网站中的所有动作流数据。 这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群机来提供实时的消费。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Apache Kafka 发布 1.0 的首个更新版本,Bug 修复
分享
评论(31)
精彩评论
3

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.
井底之蛙,总感觉自己说的很有道理的样子:sweat_smile:
1

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.

引用来自“honey_fansy”的评论

1.你不是说实时数据么?访问日志不是系统或应用的日志,就是业务数据,而且业务数据不是我们自己产生的。
2.我用过Redis做发布订阅,觉得毛病不少,需要考虑的东西太多了,后来实现之后又重新设计不采用Redis。1)Redis的PubSub不会在内存上存数据,如果redis需要重启或者出故障,相当于程序还要处理故障的时候需要把发布的信息存到其他介质,以防数据。2)在启动的时候需要把之前堆积的数据重新发布,那么发布的消息必须得在redis中存一份备份,你也可以用其他介质存,用其他介质存,跟kafka有什么区别。
你考虑的是消费的速率,完全没考虑到挤压的数据量,如果挤压一个小时,按峰值来算,好几T的挤压数据,怎么就不在上TB级别的消息?
3.我没说到可靠性

引用来自“eechen”的评论

数据源(日志)都在文件系统里,所以为什么Redis要保存PubSub的数据?秀逗么?
如果是即时生成的数据,可以保存在Redis的list里,并不需要什么第三方介质,别告诉我你不知道Redis有appendfsync.
会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.

JAVAer少吹牛,多做事.

引用来自“honey_fansy”的评论

数据存到文件系统里面后不需要分析的?只保存、查和删除?
即时生成的数据源源不断,你确定要保存在list里?能撑几分钟?
数据量大appendfsync有什么用?数据量大你试过磁盘空间满AOF写不进去一直在循环写入的情况没?
“Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.”“会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.”跟redis没任何关系,那你为什么要把redis扯进来说?
我哪句话吹牛了?说出来我改
对不起,我会GO、C和Java
兄dei,我这回复是给你看的, @eechen 你也知道,是OS远近闻名的杠精,他的言论一看就是无知妄言,看起来不待见(没做过)企业项目,我们回复的时候更正一下他提出的错误观点就行了,不用和他较劲了。

不得不说一下,我在一片博文里面见过一句话类似于『Redis is just a key-value store happened to have pub-sub feature』,大意就是『Redis是一个不幸拥有 P/S 功能的 KV 数据库』,它的本质依然是一个高性能的内存数据库,用它来做 PS 会有各种各样的坑。

同时我想聊一下你们上面讨论的几个点

1. 可靠性

至少redis在我做过的几个项目里面是把它当做易挥发缓存的,也就是丢了也不心疼的那种,即使有aof,rdb,我们还是无法信任redis做持久化,尤其是它的集群模型是 sentinel + master-slave,当规模一大,光是master 宕掉后的选举、同步数据流量就能能吃掉十几个百分点点的带宽,redis 的优势是小而迅速的缓存场景,当规模不大的小项目消息中间件也是得心应手,前提是你对你的消息不心疼,丢了就是丢了,不像RabbitMQ 会保证至少消费一次,或者 Kafka 更是支持重播消息队列(这些都是 eechen 口中喜欢吹牛的 JAVAer 的痛点)。

2. 吞吐量

Kafka 本身是一个面向大数据的项目,设计思想和应用场景和 Redis 很不一样,本质是一个『Data Pipeline 数据管道』,每个消息体可能都会非常大,通过分片分区和基于 hadoop 的同步读,理论上支持很高的水平扩展,即使单节点吞吐量比不上 Redis (吞吐量瓶颈其实在网络和数据模型而不是工具是用 JAVA 还是 C 写的),但是集群整体吞吐量还是非常可观的。而 Redis 的 Sentinel + Master-Slave 模式在水平扩展时会有很多坑,也许是我当时水平不济,但是对运维不是很友好,吞吐量也上不去。
1

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.
你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担
1

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.
因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。
最新评论
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.

引用来自“honey_fansy”的评论

1.你不是说实时数据么?访问日志不是系统或应用的日志,就是业务数据,而且业务数据不是我们自己产生的。
2.我用过Redis做发布订阅,觉得毛病不少,需要考虑的东西太多了,后来实现之后又重新设计不采用Redis。1)Redis的PubSub不会在内存上存数据,如果redis需要重启或者出故障,相当于程序还要处理故障的时候需要把发布的信息存到其他介质,以防数据。2)在启动的时候需要把之前堆积的数据重新发布,那么发布的消息必须得在redis中存一份备份,你也可以用其他介质存,用其他介质存,跟kafka有什么区别。
你考虑的是消费的速率,完全没考虑到挤压的数据量,如果挤压一个小时,按峰值来算,好几T的挤压数据,怎么就不在上TB级别的消息?
3.我没说到可靠性

引用来自“eechen”的评论

数据源(日志)都在文件系统里,所以为什么Redis要保存PubSub的数据?秀逗么?
如果是即时生成的数据,可以保存在Redis的list里,并不需要什么第三方介质,别告诉我你不知道Redis有appendfsync.
会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.

JAVAer少吹牛,多做事.

引用来自“honey_fansy”的评论

数据存到文件系统里面后不需要分析的?只保存、查和删除?
即时生成的数据源源不断,你确定要保存在list里?能撑几分钟?
数据量大appendfsync有什么用?数据量大你试过磁盘空间满AOF写不进去一直在循环写入的情况没?
“Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.”“会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.”跟redis没任何关系,那你为什么要把redis扯进来说?
我哪句话吹牛了?说出来我改
对不起,我会GO、C和Java

引用来自“catalogMan”的评论

兄dei,我这回复是给你看的, @eechen 你也知道,是OS远近闻名的杠精,他的言论一看就是无知妄言,看起来不待见(没做过)企业项目,我们回复的时候更正一下他提出的错误观点就行了,不用和他较劲了。

不得不说一下,我在一片博文里面见过一句话类似于『Redis is just a key-value store happened to have pub-sub feature』,大意就是『Redis是一个不幸拥有 P/S 功能的 KV 数据库』,它的本质依然是一个高性能的内存数据库,用它来做 PS 会有各种各样的坑。

同时我想聊一下你们上面讨论的几个点

1. 可靠性

至少redis在我做过的几个项目里面是把它当做易挥发缓存的,也就是丢了也不心疼的那种,即使有aof,rdb,我们还是无法信任redis做持久化,尤其是它的集群模型是 sentinel + master-slave,当规模一大,光是master 宕掉后的选举、同步数据流量就能能吃掉十几个百分点点的带宽,redis 的优势是小而迅速的缓存场景,当规模不大的小项目消息中间件也是得心应手,前提是你对你的消息不心疼,丢了就是丢了,不像RabbitMQ 会保证至少消费一次,或者 Kafka 更是支持重播消息队列(这些都是 eechen 口中喜欢吹牛的 JAVAer 的痛点)。

2. 吞吐量

Kafka 本身是一个面向大数据的项目,设计思想和应用场景和 Redis 很不一样,本质是一个『Data Pipeline 数据管道』,每个消息体可能都会非常大,通过分片分区和基于 hadoop 的同步读,理论上支持很高的水平扩展,即使单节点吞吐量比不上 Redis (吞吐量瓶颈其实在网络和数据模型而不是工具是用 JAVA 还是 C 写的),但是集群整体吞吐量还是非常可观的。而 Redis 的 Sentinel + Master-Slave 模式在水平扩展时会有很多坑,也许是我当时水平不济,但是对运维不是很友好,吞吐量也上不去。
受教了,没事啦,如果是技术讨论的话吵吵无所谓,他在某些技能方面还是有不错的,如果是纯喷的话我一般不鸟他。之前用redis做发布订阅,遇到过坑,有时候吵吵起码可以让其他人知道,不要重蹈覆辙就行了。
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.

引用来自“honey_fansy”的评论

1.你不是说实时数据么?访问日志不是系统或应用的日志,就是业务数据,而且业务数据不是我们自己产生的。
2.我用过Redis做发布订阅,觉得毛病不少,需要考虑的东西太多了,后来实现之后又重新设计不采用Redis。1)Redis的PubSub不会在内存上存数据,如果redis需要重启或者出故障,相当于程序还要处理故障的时候需要把发布的信息存到其他介质,以防数据。2)在启动的时候需要把之前堆积的数据重新发布,那么发布的消息必须得在redis中存一份备份,你也可以用其他介质存,用其他介质存,跟kafka有什么区别。
你考虑的是消费的速率,完全没考虑到挤压的数据量,如果挤压一个小时,按峰值来算,好几T的挤压数据,怎么就不在上TB级别的消息?
3.我没说到可靠性

引用来自“eechen”的评论

数据源(日志)都在文件系统里,所以为什么Redis要保存PubSub的数据?秀逗么?
如果是即时生成的数据,可以保存在Redis的list里,并不需要什么第三方介质,别告诉我你不知道Redis有appendfsync.
会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.

JAVAer少吹牛,多做事.

引用来自“honey_fansy”的评论

数据存到文件系统里面后不需要分析的?只保存、查和删除?
即时生成的数据源源不断,你确定要保存在list里?能撑几分钟?
数据量大appendfsync有什么用?数据量大你试过磁盘空间满AOF写不进去一直在循环写入的情况没?
“Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.”“会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.”跟redis没任何关系,那你为什么要把redis扯进来说?
我哪句话吹牛了?说出来我改
对不起,我会GO、C和Java

引用来自“eechen”的评论

你会什么,以及你会吹什么,跟你能不能做出来什么,天差地别.
动不动说Kafka吞吐量比Redis多一个数量级,动不动就扯TB级别的实时数据,这特喵还不是TreeNewBee?!
不要动不动就是内存装不下我的实时数据,还是那句话,你有个屁内存都装不下的即时数据.
我会什么是表达我不仅仅是JAVAer,没说我能不能做出什么
说Kafka吞吐量比Redis多一个数量级的是我吗?你是不是瞎了?
没TB级别的用得上kafka?kafka本来就是一个高吞吐量的发布订阅消息系统,为高吞吐量而设计的,就几十W的数据用得上kafka?我看你是完全没了解过kafka就来瞎说。
内存装不下的即时数据很少见?
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.

引用来自“honey_fansy”的评论

1.你不是说实时数据么?访问日志不是系统或应用的日志,就是业务数据,而且业务数据不是我们自己产生的。
2.我用过Redis做发布订阅,觉得毛病不少,需要考虑的东西太多了,后来实现之后又重新设计不采用Redis。1)Redis的PubSub不会在内存上存数据,如果redis需要重启或者出故障,相当于程序还要处理故障的时候需要把发布的信息存到其他介质,以防数据。2)在启动的时候需要把之前堆积的数据重新发布,那么发布的消息必须得在redis中存一份备份,你也可以用其他介质存,用其他介质存,跟kafka有什么区别。
你考虑的是消费的速率,完全没考虑到挤压的数据量,如果挤压一个小时,按峰值来算,好几T的挤压数据,怎么就不在上TB级别的消息?
3.我没说到可靠性

引用来自“eechen”的评论

数据源(日志)都在文件系统里,所以为什么Redis要保存PubSub的数据?秀逗么?
如果是即时生成的数据,可以保存在Redis的list里,并不需要什么第三方介质,别告诉我你不知道Redis有appendfsync.
会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.

JAVAer少吹牛,多做事.

引用来自“honey_fansy”的评论

数据存到文件系统里面后不需要分析的?只保存、查和删除?
即时生成的数据源源不断,你确定要保存在list里?能撑几分钟?
数据量大appendfsync有什么用?数据量大你试过磁盘空间满AOF写不进去一直在循环写入的情况没?
“Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.”“会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.”跟redis没任何关系,那你为什么要把redis扯进来说?
我哪句话吹牛了?说出来我改
对不起,我会GO、C和Java
你会什么,以及你会吹什么,跟你能不能做出来什么,天差地别.
动不动说Kafka吞吐量比Redis多一个数量级,动不动就扯TB级别的实时数据,这特喵还不是TreeNewBee?!
不要动不动就是内存装不下我的实时数据,还是那句话,你有个屁内存都装不下的即时数据.
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.
php是宇宙中最好的语言
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.

引用来自“honey_fansy”的评论

1.你不是说实时数据么?访问日志不是系统或应用的日志,就是业务数据,而且业务数据不是我们自己产生的。
2.我用过Redis做发布订阅,觉得毛病不少,需要考虑的东西太多了,后来实现之后又重新设计不采用Redis。1)Redis的PubSub不会在内存上存数据,如果redis需要重启或者出故障,相当于程序还要处理故障的时候需要把发布的信息存到其他介质,以防数据。2)在启动的时候需要把之前堆积的数据重新发布,那么发布的消息必须得在redis中存一份备份,你也可以用其他介质存,用其他介质存,跟kafka有什么区别。
你考虑的是消费的速率,完全没考虑到挤压的数据量,如果挤压一个小时,按峰值来算,好几T的挤压数据,怎么就不在上TB级别的消息?
3.我没说到可靠性

引用来自“eechen”的评论

数据源(日志)都在文件系统里,所以为什么Redis要保存PubSub的数据?秀逗么?
如果是即时生成的数据,可以保存在Redis的list里,并不需要什么第三方介质,别告诉我你不知道Redis有appendfsync.
会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.

JAVAer少吹牛,多做事.

引用来自“honey_fansy”的评论

数据存到文件系统里面后不需要分析的?只保存、查和删除?
即时生成的数据源源不断,你确定要保存在list里?能撑几分钟?
数据量大appendfsync有什么用?数据量大你试过磁盘空间满AOF写不进去一直在循环写入的情况没?
“Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.”“会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.”跟redis没任何关系,那你为什么要把redis扯进来说?
我哪句话吹牛了?说出来我改
对不起,我会GO、C和Java

引用来自“catalogMan”的评论

兄dei,我这回复是给你看的, @eechen 你也知道,是OS远近闻名的杠精,他的言论一看就是无知妄言,看起来不待见(没做过)企业项目,我们回复的时候更正一下他提出的错误观点就行了,不用和他较劲了。

不得不说一下,我在一片博文里面见过一句话类似于『Redis is just a key-value store happened to have pub-sub feature』,大意就是『Redis是一个不幸拥有 P/S 功能的 KV 数据库』,它的本质依然是一个高性能的内存数据库,用它来做 PS 会有各种各样的坑。

同时我想聊一下你们上面讨论的几个点

1. 可靠性

至少redis在我做过的几个项目里面是把它当做易挥发缓存的,也就是丢了也不心疼的那种,即使有aof,rdb,我们还是无法信任redis做持久化,尤其是它的集群模型是 sentinel + master-slave,当规模一大,光是master 宕掉后的选举、同步数据流量就能能吃掉十几个百分点点的带宽,redis 的优势是小而迅速的缓存场景,当规模不大的小项目消息中间件也是得心应手,前提是你对你的消息不心疼,丢了就是丢了,不像RabbitMQ 会保证至少消费一次,或者 Kafka 更是支持重播消息队列(这些都是 eechen 口中喜欢吹牛的 JAVAer 的痛点)。

2. 吞吐量

Kafka 本身是一个面向大数据的项目,设计思想和应用场景和 Redis 很不一样,本质是一个『Data Pipeline 数据管道』,每个消息体可能都会非常大,通过分片分区和基于 hadoop 的同步读,理论上支持很高的水平扩展,即使单节点吞吐量比不上 Redis (吞吐量瓶颈其实在网络和数据模型而不是工具是用 JAVA 还是 C 写的),但是集群整体吞吐量还是非常可观的。而 Redis 的 Sentinel + Master-Slave 模式在水平扩展时会有很多坑,也许是我当时水平不济,但是对运维不是很友好,吞吐量也上不去。
有时候要提 要不新手看了 会误导
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“靠谱的傻梦兽”的评论

腾讯一个5年的群 包信息数据库也不大 ,就80G 而已,我要看看你内存什么什么时候上80g 的成本比用ssd的成本低

引用来自“eechen”的评论

群消息肯定是要持久化到数据库(落地),所以不用担心在PubSub过程中丢失.
另外,PubSub用于即时推送数据,并不会在内存堆积消息,Redis PubSub不是Redis list.
而且也不需要把所有群消息加载到Redis中.

群消息的实现:
用户订阅若干群频道,用户向群发消息用publish,
订阅该群的其他用户(在线)就能即时获取到群内用户发出的消息.
群的内容统一写入数据库,并且记录每个群用户最后阅读到的消息位置,
实现不在线用户登录后继续从该位置开始阅读群消息.
另外系统消息推送的实现类似群聊,即所有用户建立连接时订阅系统消息这个Redis频道.

你等在Tree New Bee的时候,建议还是多了解了解,再来高谈阔论.
受教
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.

引用来自“靠谱的傻梦兽”的评论

不是redis 不行 秒购不需用redis 但是做某些业务还不如用ssd redis跑内存你买台16g的电脑也要很贵了吧
秒购必须用redis
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.
不是redis 不行 秒购不需用redis 但是做某些业务还不如用ssd redis跑内存你买台16g的电脑也要很贵了吧
1

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.

引用来自“honey_fansy”的评论

1.你不是说实时数据么?访问日志不是系统或应用的日志,就是业务数据,而且业务数据不是我们自己产生的。
2.我用过Redis做发布订阅,觉得毛病不少,需要考虑的东西太多了,后来实现之后又重新设计不采用Redis。1)Redis的PubSub不会在内存上存数据,如果redis需要重启或者出故障,相当于程序还要处理故障的时候需要把发布的信息存到其他介质,以防数据。2)在启动的时候需要把之前堆积的数据重新发布,那么发布的消息必须得在redis中存一份备份,你也可以用其他介质存,用其他介质存,跟kafka有什么区别。
你考虑的是消费的速率,完全没考虑到挤压的数据量,如果挤压一个小时,按峰值来算,好几T的挤压数据,怎么就不在上TB级别的消息?
3.我没说到可靠性

引用来自“eechen”的评论

数据源(日志)都在文件系统里,所以为什么Redis要保存PubSub的数据?秀逗么?
如果是即时生成的数据,可以保存在Redis的list里,并不需要什么第三方介质,别告诉我你不知道Redis有appendfsync.
会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.

JAVAer少吹牛,多做事.

引用来自“honey_fansy”的评论

数据存到文件系统里面后不需要分析的?只保存、查和删除?
即时生成的数据源源不断,你确定要保存在list里?能撑几分钟?
数据量大appendfsync有什么用?数据量大你试过磁盘空间满AOF写不进去一直在循环写入的情况没?
“Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.”“会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.”跟redis没任何关系,那你为什么要把redis扯进来说?
我哪句话吹牛了?说出来我改
对不起,我会GO、C和Java
兄dei,我这回复是给你看的, @eechen 你也知道,是OS远近闻名的杠精,他的言论一看就是无知妄言,看起来不待见(没做过)企业项目,我们回复的时候更正一下他提出的错误观点就行了,不用和他较劲了。

不得不说一下,我在一片博文里面见过一句话类似于『Redis is just a key-value store happened to have pub-sub feature』,大意就是『Redis是一个不幸拥有 P/S 功能的 KV 数据库』,它的本质依然是一个高性能的内存数据库,用它来做 PS 会有各种各样的坑。

同时我想聊一下你们上面讨论的几个点

1. 可靠性

至少redis在我做过的几个项目里面是把它当做易挥发缓存的,也就是丢了也不心疼的那种,即使有aof,rdb,我们还是无法信任redis做持久化,尤其是它的集群模型是 sentinel + master-slave,当规模一大,光是master 宕掉后的选举、同步数据流量就能能吃掉十几个百分点点的带宽,redis 的优势是小而迅速的缓存场景,当规模不大的小项目消息中间件也是得心应手,前提是你对你的消息不心疼,丢了就是丢了,不像RabbitMQ 会保证至少消费一次,或者 Kafka 更是支持重播消息队列(这些都是 eechen 口中喜欢吹牛的 JAVAer 的痛点)。

2. 吞吐量

Kafka 本身是一个面向大数据的项目,设计思想和应用场景和 Redis 很不一样,本质是一个『Data Pipeline 数据管道』,每个消息体可能都会非常大,通过分片分区和基于 hadoop 的同步读,理论上支持很高的水平扩展,即使单节点吞吐量比不上 Redis (吞吐量瓶颈其实在网络和数据模型而不是工具是用 JAVA 还是 C 写的),但是集群整体吞吐量还是非常可观的。而 Redis 的 Sentinel + Master-Slave 模式在水平扩展时会有很多坑,也许是我当时水平不济,但是对运维不是很友好,吞吐量也上不去。
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.

引用来自“honey_fansy”的评论

1.你不是说实时数据么?访问日志不是系统或应用的日志,就是业务数据,而且业务数据不是我们自己产生的。
2.我用过Redis做发布订阅,觉得毛病不少,需要考虑的东西太多了,后来实现之后又重新设计不采用Redis。1)Redis的PubSub不会在内存上存数据,如果redis需要重启或者出故障,相当于程序还要处理故障的时候需要把发布的信息存到其他介质,以防数据。2)在启动的时候需要把之前堆积的数据重新发布,那么发布的消息必须得在redis中存一份备份,你也可以用其他介质存,用其他介质存,跟kafka有什么区别。
你考虑的是消费的速率,完全没考虑到挤压的数据量,如果挤压一个小时,按峰值来算,好几T的挤压数据,怎么就不在上TB级别的消息?
3.我没说到可靠性

引用来自“eechen”的评论

数据源(日志)都在文件系统里,所以为什么Redis要保存PubSub的数据?秀逗么?
如果是即时生成的数据,可以保存在Redis的list里,并不需要什么第三方介质,别告诉我你不知道Redis有appendfsync.
会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.

JAVAer少吹牛,多做事.
数据存到文件系统里面后不需要分析的?只保存、查和删除?
即时生成的数据源源不断,你确定要保存在list里?能撑几分钟?
数据量大appendfsync有什么用?数据量大你试过磁盘空间满AOF写不进去一直在循环写入的情况没?
“Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.”“会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.”跟redis没任何关系,那你为什么要把redis扯进来说?
我哪句话吹牛了?说出来我改
对不起,我会GO、C和Java
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.

引用来自“honey_fansy”的评论

1.你不是说实时数据么?访问日志不是系统或应用的日志,就是业务数据,而且业务数据不是我们自己产生的。
2.我用过Redis做发布订阅,觉得毛病不少,需要考虑的东西太多了,后来实现之后又重新设计不采用Redis。1)Redis的PubSub不会在内存上存数据,如果redis需要重启或者出故障,相当于程序还要处理故障的时候需要把发布的信息存到其他介质,以防数据。2)在启动的时候需要把之前堆积的数据重新发布,那么发布的消息必须得在redis中存一份备份,你也可以用其他介质存,用其他介质存,跟kafka有什么区别。
你考虑的是消费的速率,完全没考虑到挤压的数据量,如果挤压一个小时,按峰值来算,好几T的挤压数据,怎么就不在上TB级别的消息?
3.我没说到可靠性
数据源(日志)都在文件系统里,所以为什么Redis要保存PubSub的数据?秀逗么?
如果是即时生成的数据,可以保存在Redis的list里,并不需要什么第三方介质,别告诉我你不知道Redis有appendfsync.
会在短时间内大量挤压的数据,根本就不应该用PubSub机制,跟Redis有毛线关系.

JAVAer少吹牛,多做事.
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担

引用来自“eechen”的评论

访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.
1.你不是说实时数据么?访问日志不是系统或应用的日志,就是业务数据,而且业务数据不是我们自己产生的。
2.我用过Redis做发布订阅,觉得毛病不少,需要考虑的东西太多了,后来实现之后又重新设计不采用Redis。1)Redis的PubSub不会在内存上存数据,如果redis需要重启或者出故障,相当于程序还要处理故障的时候需要把发布的信息存到其他介质,以防数据。2)在启动的时候需要把之前堆积的数据重新发布,那么发布的消息必须得在redis中存一份备份,你也可以用其他介质存,用其他介质存,跟kafka有什么区别。
你考虑的是消费的速率,完全没考虑到挤压的数据量,如果挤压一个小时,按峰值来算,好几T的挤压数据,怎么就不在上TB级别的消息?
3.我没说到可靠性
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“靠谱的傻梦兽”的评论

腾讯一个5年的群 包信息数据库也不大 ,就80G 而已,我要看看你内存什么什么时候上80g 的成本比用ssd的成本低
群消息肯定是要持久化到数据库(落地),所以不用担心在PubSub过程中丢失.
另外,PubSub用于即时推送数据,并不会在内存堆积消息,Redis PubSub不是Redis list.
而且也不需要把所有群消息加载到Redis中.

群消息的实现:
用户订阅若干群频道,用户向群发消息用publish,
订阅该群的其他用户(在线)就能即时获取到群内用户发出的消息.
群的内容统一写入数据库,并且记录每个群用户最后阅读到的消息位置,
实现不在线用户登录后继续从该位置开始阅读群消息.
另外系统消息推送的实现类似群聊,即所有用户建立连接时订阅系统消息这个Redis频道.

你等在Tree New Bee的时候,建议还是多了解了解,再来高谈阔论.
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.

引用来自“honey_fansy”的评论

你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担
访问日志量1天几个TB跟Redis有毛关系么?
就好比Nginx日志量几个TB跟Redis有个屁关系呀.

另外Redis的PubSub根本不会在内存上堆积数据,
pub发布消息,没有客户端sub订阅,消息直接就没了.
我看你等连Redis PubSub都没用过就开始哔哔Redis不行了,这不秀逗么?

为了丢消息,可以在publish前把数据写入list(入队),在message事件中获取数据后删除list中的数据(出队),即list+pubsub.而list这个Redis数据结构才会持久占用内存.而如果你的数据来自日志(比如Nginx日志),则根本不用使用list来持久化消息,自然也就不存在你所谓的要在内存即时处理生成的TB级别消息的场景.

而应用层的消息投递的可靠性需要应用自己保证.A通过Redis发消息给B,保证可靠性,需要B通知Redis收到,Redis通知A收到.
1

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.
你没有并不代表我没有,之前做电信IDC的,访问日志量一天能到几T,上海深圳的一天的访问日志量是几十T,一天一百多T也是经常的,存储服务器上千台,何止T级别的。还有,redis不存实时数据,最多也就用来存热数据或者存一下小表数据减轻一下数据库负担
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.
腾讯一个5年的群 包信息数据库也不大 ,就80G 而已,我要看看你内存什么什么时候上80g 的成本比用ssd的成本低
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.
回错了 我要回的是eechen 大神的
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,

引用来自“eechen”的评论

搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.
大哥你试试用ssd 来做文件数据库试试 你没钱就没说啦 ssd 的读写成本 够你买好多条内存成本谢谢。
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“君枫”的评论

井底之蛙,总感觉自己说的很有道理的样子:sweat_smile:
你不知道他是OSC著名(脑残)喷子嘛?
0

引用来自“eechen”的评论

Redis就自带了PubSub发布订阅功能,还用什么Java的东西,还得装JRE+Scala环境.

引用来自“catalogMan”的评论

因为kafka是工业规模的,redis与之相比的吞吐量少了一个数量级,例如 redis 的 P/S 峰值吞吐量是 10M/s 那么 kafka 可以达到 数个 100M/s。

此外使用场景也有差异,redis 擅长的是 central cache,kafka 是企业级别的 message hub。

引用来自“eechen”的评论

JAVAer惯用的伎俩,动不动就企业级.
真会Tree New Bee.

一个Java写的同类服务,怎么吞吐量就比C写的Redis快出数量级来了?
有可以重现的测试数据么?还有快一个数量级的原理是什么?

引用来自“angelboy”的评论

架构上就快好吧,支持多分区消费,不要人云亦云,语言只是一个方面,而且kafka是基于文件的,数据量大不会像redis那样撑死

引用来自“eechen”的评论

kafka基于文件,速度就更加不可能比完全基于内存的Redis PubSub快一个数量级了.
没有黑科技,更没有银弹.

引用来自“honey_fansy”的评论

kafka有存储,redis完全依赖内存,一旦数据到峰值,如果上T,上十T,磁盘扛得住,内存绝对扛不住,kafka存取速度没有redis高,但也不需要redis这么高

引用来自“angelboy”的评论

无知者无畏,他都没用过,散了吧楼上兄弟,
搞得好像用kafka的内存都不够装PubSub数据似的.
事实是,你们有个屁TB级别的实时数据.
顶部