子节点服务器上面写入,然后推送到 master 节点统一处理。
比如有 100 台服务器 ,写入消息,然后这 100 台服务器推送到 master 节点。然后 由 master 消费
1
Kilerd 2017-07-11 16:05:22 +08:00
redis.
slave 写,master 读. done, next one, please. |
3
fwee 2017-07-11 16:22:51 +08:00
etcd
|
6
hiboshi OP up
|
7
whywhy36 2017-07-11 19:00:03 +08:00
你的需求感觉用一个单独的 queue 就可以了
假如你可以容忍数据丢失,Redis 就可以了。假如不能容忍,可以考虑 RabbitMQ 或者 etcd,不过取决于你消息的大小。两者感觉都是对于相对较小的消息比较友好。 或者直接上 amazon 的 SQS |
8
hiboshi OP @whywhy36 本来是一台 消息队列就可以,但是目前来看,这 100 台服务器 存在 全球 ,肯定会有国际带宽波动影响,阻塞的。
|
9
Lax 2017-07-11 20:34:25 +08:00
感觉你这个 master - slave 的叫法弄反了,远端做写入端,它们就是 master,相对的被同步到的端是 slave。
这种多 master-单 slave 的方案,redis 本身不支持,可以写一个脚本全读回来写到中心的队列里。 因为 redis 队列读出来之后就删掉了,自己写脚本的确认到达代码复杂。 RMQ / Kafka 都有确认到达的同步工具,比较成熟,不过运维复杂性高于 redis。 |
10
vingz 2017-07-11 20:47:39 +08:00 via Android
这是 producer 和 consumer 模型,任何一款消息队列都可以满足需求,可以去看看 kafka
|
11
hiboshi OP @Lax 有想过用这种 多主到单个 slave 但是没有实践过不知道能不能行,另外还想过,在主服务器端去 主动拉取也想过,但是目前更倾向于 消息队列本身能够解决。
|
12
hiboshi OP @vingc723 是消费者和生产者关系,但是问题不在这里,而在于 ,如何把存在很多地方的消费者和生产者的队列( 100 台服务器中),同步到一个地方。
|
13
Lax 2017-07-11 23:48:50 +08:00 1
@hiboshi
redis 另一个比较坑的是同步机制,如果中断时间长会触发全量复制,如果网络本来就差这无疑是雪上加霜。因此没有脱离这个机制作同步都不太靠谱。 kafka 同步是依赖记录的 offset,中断后还能从断点继续。不太方便的是要把记录 offset 的 zookeeper 暴露出来,你提到这种场景好像问题不大。 有个 Kafka MirrorMaker 你可以调研一下。https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27846330 |
14
msg7086 2017-07-12 04:17:52 +08:00 1
自己写一个不行吗……
for redis100 in 100 redis servers: .. len = redis100->llen() .. data = redis100->lrange(0,len-1) .. redislocal->rpush(data) .. redis100->ltrim(len, -1) 还有一种比较难看的 workaround,就是用 MySQL 的 Multi-master replication,中心节点开 100 个 slave 从世界各地读数据。队列表不要用 auto_increment 的主键,避免多主写入数据时产生唯一性冲突。世界各地的程序用不冲突的 uuid 来做主键。不太好看,但是很可靠。master 上的历史数据可以通过 SET sql_log_bin = 0; DELETE WHERE UUID = x; 做本地删除。 |
15
hljjhb 2017-07-12 08:39:09 +08:00 via Android 1
|