s********k
发帖数: 6180 | 1 卡夫卡什么都好，就是兼容太坑了，0.8和0.10兼容吗？0.8和1.0+呢？ |
d****n
发帖数: 12461 | 2 sub版本可以落后，但是pub一定要比sub版本高。本质上是wire protocol变化造成的，
当然最近都没啥变化。
【在 s********k 的大作中提到】
: 卡夫卡什么都好，就是兼容太坑了，0.8和0.10兼容吗？0.8和1.0+呢？
|
s********k
发帖数: 6180 | 3 client和server的版本之间兼容也是很多问题，得去趟坑啊
【在 d****n 的大作中提到】
: sub版本可以落后，但是pub一定要比sub版本高。本质上是wire protocol变化造成的，
: 当然最近都没啥变化。
|
d****n
发帖数: 12461 | 4 你就装上和pub一样的版本就可以了。
【在 s********k 的大作中提到】
: client和server的版本之间兼容也是很多问题，得去趟坑啊
|
s********k
发帖数: 6180 | 5 是啊，但是上下游很多不同的service不同部门，各自历史，用的版本都是不太一样，
虽说很多软件也有这样的问题，但是kafka太多version不能backward compatible实在
有点坑啊
【在 d****n 的大作中提到】
: 你就装上和pub一样的版本就可以了。
|
f******2
发帖数: 2455 | 6 为啥不用kinesis呢？便宜很多。
: sub版本可以落后，但是pub一定要比sub版本高。本质上是wire protocol变化造
成的，
: 当然最近都没啥变化。
【在 d****n 的大作中提到】
: 你就装上和pub一样的版本就可以了。
|
n***p
发帖数: 110 | 7 这正是头疼的地方。如果topic有很多不同consumer，不同的team在用，同时upgrade很
不现实。
【在 d****n 的大作中提到】
: 你就装上和pub一样的版本就可以了。
|
n***p
发帖数: 110 | 8 Kinesis 怎么便宜？ Kafka is free
【在 f******2 的大作中提到】
: 为啥不用kinesis呢？便宜很多。
:
:
: sub版本可以落后，但是pub一定要比sub版本高。本质上是wire protocol变化造
: 成的，
:
: 当然最近都没啥变化。
:
|
s********k
发帖数: 6180 | 9 不是所有都在AWS上啊，有自己需要搭建的，有需要在其他cloud的
【在 f******2 的大作中提到】
: 为啥不用kinesis呢？便宜很多。
:
:
: sub版本可以落后，但是pub一定要比sub版本高。本质上是wire protocol变化造
: 成的，
:
: 当然最近都没啥变化。
:
|
d****n
发帖数: 12461 | 10 事先定好upgrade path和support schedule，不发布就rate limit，再不行就block。
话说kafka不向后兼容的情况很少。
而且要管sub啥事情呢？这不是传输的内容而只是底层的东西。
【在 n***p 的大作中提到】
: 这正是头疼的地方。如果topic有很多不同consumer，不同的team在用，同时upgrade很
: 不现实。
|
|
|
n*w
发帖数: 3393 | |
d****n
发帖数: 12461 | 12 AWS MSK
【在 n*w 的大作中提到】
: kafka在aws上是不是只能搞个ec2？
|
w********m
发帖数: 1137 | 13 现在redis也有了stream，比kafka简单多了。 |
s********k
发帖数: 6180 | 14 怎么用？但是redis全memory肯定贵得多把
【在 w********m 的大作中提到】
: 现在redis也有了stream，比kafka简单多了。
|
w********m
发帖数: 1137 | 15 用message queue估计就是图个快。
卡夫卡一启动就耗1g内存，可以放好多message了。
redis加点内存。实在不行就上redis cluster吧。
卡夫卡太复杂了。redis就把它照抄了一遍。
以redis在后端的普及率，对卡夫卡是个威胁。
【在 s********k 的大作中提到】
: 怎么用？但是redis全memory肯定贵得多把
|
f******2
发帖数: 2455 | 16 kafka对msg是有retention功能的，和redis的那种pubsub场景的queue不在一个范畴。
一家之言哈
: 用message queue估计就是图个快。
: 卡夫卡一启动就耗1g内存，可以放好多message了。
: redis加点内存。实在不行就上redis cluster吧。
: 卡夫卡太复杂了。redis就把它照抄了一遍。
: 以redis在后端的普及率，对卡夫卡是个威胁。
【在 w********m 的大作中提到】
: 用message queue估计就是图个快。
: 卡夫卡一启动就耗1g内存，可以放好多message了。
: redis加点内存。实在不行就上redis cluster吧。
: 卡夫卡太复杂了。redis就把它照抄了一遍。
: 以redis在后端的普及率，对卡夫卡是个威胁。
|
n***p
发帖数: 110 | 17 Again, it's easy for you to say.
0.9和1.0 cluster的behavior都不一样。0.9 leader node如果server is up几乎不变。
1.0的leader node经常变动。0.9的sub code都必须动一个变量才能对付leader node变
动这种情况。这就是坑，所以楼主说得没错。
【在 d****n 的大作中提到】
: 事先定好upgrade path和support schedule，不发布就rate limit，再不行就block。
: 话说kafka不向后兼容的情况很少。
: 而且要管sub啥事情呢？这不是传输的内容而只是底层的东西。
|
n***p
发帖数: 110 | 18 的确，有retention能reset sub offset重新process是Kafka主要卖点。redis没有那功
能的话那就没什么可比性了
【在 f******2 的大作中提到】
: kafka对msg是有retention功能的，和redis的那种pubsub场景的queue不在一个范畴。
: 一家之言哈
:
:
: 用message queue估计就是图个快。
:
: 卡夫卡一启动就耗1g内存，可以放好多message了。
:
: redis加点内存。实在不行就上redis cluster吧。
:
: 卡夫卡太复杂了。redis就把它照抄了一遍。
:
: 以redis在后端的普及率，对卡夫卡是个威胁。
:
|
w********m
发帖数: 1137 | 19 你说的是Redis 3出来的pub/sub吧。
这个是最新的Redis 5的streams，相当于卡夫卡的C实现。
跟卡夫卡的区别是一个用内存，一个用硬盘。相当于hadoop和spark的区别。
【在 f******2 的大作中提到】
: kafka对msg是有retention功能的，和redis的那种pubsub场景的queue不在一个范畴。
: 一家之言哈
:
:
: 用message queue估计就是图个快。
:
: 卡夫卡一启动就耗1g内存，可以放好多message了。
:
: redis加点内存。实在不行就上redis cluster吧。
:
: 卡夫卡太复杂了。redis就把它照抄了一遍。
:
: 以redis在后端的普及率，对卡夫卡是个威胁。
:
|
n***p
发帖数: 110 | 20 用内存server一同时当机data就没了
【在 w********m 的大作中提到】
: 你说的是Redis 3出来的pub/sub吧。
: 这个是最新的Redis 5的streams，相当于卡夫卡的C实现。
: 跟卡夫卡的区别是一个用内存，一个用硬盘。相当于hadoop和spark的区别。
|
|
|
w********m
发帖数: 1137 | 21 Redis其实也有persistence，选AOF的话重启有可能丢一点数据。
不过，再快的硬盘也比内存慢十倍，需要速度的话用redis不错。
【在 n***p 的大作中提到】
: 用内存server一同时当机data就没了
|
s********k
发帖数: 6180 | 22 是啊，关键是0.8和0.9，0.9和1.0都有兼容问题，有些事参数设置，有些事client
server的不同behavior，有些事message format，有些事package，防不胜防啊
变。
【在 n***p 的大作中提到】
: Again, it's easy for you to say.
: 0.9和1.0 cluster的behavior都不一样。0.9 leader node如果server is up几乎不变。
: 1.0的leader node经常变动。0.9的sub code都必须动一个变量才能对付leader node变
: 动这种情况。这就是坑，所以楼主说得没错。
|
s********k
发帖数: 6180 | 23 redis如果用AOF做persistence会不会出现AOF的log太大的问题？如果选用RDB好像又不
能实时update，其实要是redis引入kafka的log compaction在AOF log里面倒是不错，
就不用记下那么多的log了
【在 w********m 的大作中提到】
: Redis其实也有persistence，选AOF的话重启有可能丢一点数据。
: 不过，再快的硬盘也比内存慢十倍，需要速度的话用redis不错。
|
w********m
发帖数: 1137 | 24 要选high availability的话，还是master/slave或者partition吧。
redis有sentinel还有cluster，方案比较成熟。
【在 s********k 的大作中提到】
: redis如果用AOF做persistence会不会出现AOF的log太大的问题？如果选用RDB好像又不
: 能实时update，其实要是redis引入kafka的log compaction在AOF log里面倒是不错，
: 就不用记下那么多的log了
|
