gossip标签存档

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 本文基于redis 6.2.7 1.引言 Redis-Cluster集群的搭建非常简单。搭建过程见参考资料1。 执行 redis-cli –cluster create 127.0.0.1:7000 127.0.0.1:7001 \ 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \ –cluster-replicas 1 root@BJ-02:~/cluster-test# redis-cli –cluster create 127.0.0.1:7000 127.0.0.1:7001 \ > 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \ > –cluster-replicas 1 >>> Performing hash slots allocation on 6… 继续阅读 Redis-Cluster集群创建内部细节详解

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 引言 今天有朋友问萌叔，consul能否在大规模生产环境下进行应用。场景是总计大约10w+台机器，分为3 ~ 4个机房，单个机房最多3w万+机器。这个问题大的，可把萌叔吓了跳，部门里面consul集群的规模也就是1k+, 还分好几个机房。 不过他的问题确实也让我十分好奇，consul是否有能力支撑这么规模，我决定针对每个可能性能瓶颈进行定量分析 2. 分析 在进行分析前，我们来看看可能遇到瓶颈有哪些？ 下图是consul在多DC情况下的体系架构图 2.1 明确一些概念 consul agent分2种模式server模式和client模式。在每个机房consul server(以下简称为server)会部署3 ~ 5台, 其余的consul节点都是consul client(以下简称为server)。 server的数量不宜过多，否则选主的速度会变慢 数据(包括kv数据，service信息，node信息)都是分机房存储的，由所在机房的server负责。如果需要请求其它机房的数据，则server会将请求转发到对应的机房。 比如dc1的某个应用app1想要获取dc2中key “hello”对应的值 过程如下 app1 –> client –> server(dc1) –> server(dc2) 如果读者仔细观察会发现,consul中，很多api都是可以加上dc参数的 consul kv get hello -datacenter dc2 每个dc的所有server构成一个raft集群，client不参与选主。注意上图的leader和follower标识。 单个机房内部consul节点之间有gossip(端口8301)… 继续阅读 玩转consul(3)–大规模部署的性能开销定量分析

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 引言 Gossip是一种去中心化、容错并保证最终一致性的协议。它的基本思想是通过不断的和集群中的节点gossip交换信息，经过 O(log(n))个回合, gossip协议即可将信息传递到所有的节点。 这里介绍Gossip的一个实现库hashicorp/memberlist，并讲一下需要注意的事项。 2. hashicorp/memberlist memberlist是HashiCorp公司开源的Gossip库，这个库被consul（也是HashiCorp公司开源的）所引用。 它是SWIM的一个扩展实现。 下面的例子test_gossip.go中它被用来做集群节点发现 package main import ( “flag” “fmt” “github.com/hashicorp/memberlist” // “net” “os” “strconv” “time” ) var ( bindPort = flag.Int(“port”, 8001, “gossip port”) ) func main() { flag.Parse() hostname, _ := os.Hostname()… 继续阅读 聊聊Gossip的一个实现