服务组件

  • Rocketmq,  技术,  服务组件

    Rocketmq知识点整理(一)

    自研NameServer 摒弃业界常用的Zookeeper,使用自研的NameServer实现元数据的管理(Topic路由信息等)。 从实际场景出发,topic路由在集群中无需保持强一致性,仅需保持最终一致性,且能够容忍分钟级别的不一致,因此,rockermq自研的NameServer摒弃了集群之间的相互通信,而是相互独立,不仅极大的降低了NameServer实现的复杂度,降低了对网络的要求,同时也因此,性能相比Zookeeper有了极大地提升。 高效的IO存储机制 为了追求消息发送的高吞吐量,rocketmq引入了内存映射机制。rocketmq以文件组的方式,存储消息的存储文件,每个文件组内的单个文件大小固定,所有Topic下的消息全部基于顺序写,极大的提高了消息的写性能。 为了消息的消费和查找,rocketmq还引入了消息消费队列文件和索引文件。 为了避免消息不断累积,rocketmq引入了消息文件过期机制(默认保留3天)以及文件存储空间报警机制。 消费者幂等消费消息 rocketmq通过消息消费确认机制(ACK)确保消息至少被消费一次,但不保证消息不会被重复消费,也就是说,消费者可能会消费同条消息多次,这里就需要消费者消费时,逻辑上实现幂等。

  • mysql
    Mysql,  技术,  服务组件

    Mysql集群部署(MHA)

    MySQL高可用方案中,MHA(Master High Availability)是一个相对成熟的解决方案,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。 该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。 mysql主从部署 参见 Mysql集群部署(主从复制) 配置公钥互信 创建mha管理节点 目前容器和ip对应关系为: mysql-master 172.17.0.2 mysql-slave-1 172.17.0.3 mysql-slave-1 172.17.0.4 mysql-mha-manager 172.17.0.5 设置所有容器的root密码, 配置互信时需要: MHA部署 增加文件脚本/usr/local/bin/master_ip_failover: 进入容器 mysql-mha-manager 创建mha配置文件 /etc/mha-manager.cnf: 配置文件校验 其他命令 masterha_check_ssh…

  • mysql
    Mysql,  技术,  服务组件

    Mysql集群部署(主从复制)

    基础环境准备 # 获取centos镜像,注:以下镜像为整合了 ansible 的centos镜像,可以解决大量的依赖问题 docker pull ansible/centos7-ansible 容器中安装基础工具 启动容器: 进入容器: 安装Mysql 记住生成的临时用户名和密码,保存下来,之后会用到 编辑配置文件 查看my.cnf 文件位置 ./mysql –help | grep my.cnf 这个实际上就是mysql尝试去读取配置文件的路径顺序,没有找到话,mysql会走默认配置 所以,看下这几处位置是否有配置文件,有的话,编辑该文件,没有的话,直接在第一读取位置,创建配置文件,如: 创建 /etc/my.cnf 配置文件。 /etc/my.cnf: 添加mysqld服务到系统 启动mysql 将mysql命令添加到服务 登录mysql 使用之前随机生成的密码 修改root密码 使支持远程连接…

  • redis
    Redis,  技术

    Redis Cluster集群节点间通信

    Redis 的集群节点之间的通信采取 gossip 协议进行通信,在 redis cluster 架构下,每个 redis 要放开两个端口号,比如一个是 6379,另外一个就是 加10000 的端口号,比如 16379,16379 端口号是用来进行节点间通信的。 Gossip协议 Gossip protocol 也叫 Epidemic Protocol (流行病协议),顾名思义,就像流言蜚语一样,利用一种随机、带有传染性的方式,将信息传播到整个网络中,并在一定时间内,使得系统内的所有节点数据一致。这里简单介绍下Gossip协议的执行过程: 当一个种子节点有状态需要更新到网络中的其他节点时,它会随机的选择周围几个节点散播消息,收到消息的节点也会重复该过程,直至最终网络中所有的节点都收到了消息。 Gossip协议优势: 扩展性 网络可以允许节点的任意增加和减少,新增加的节点的状态最终会与其他节点一致。 容错 网络中任何节点的宕机和重启都不会影响 Gossip 消息的传播,Gossip 协议具有天然的分布式系统容错特性。 去中心化 Gossip 协议不要求任何中心节点,所有节点都可以是对等的,任何一个节点无需知道整个网络状况,只要网络是连通的,任意一个节点就可以把消息散播到全网。…

  • redis
    Redis,  技术,  服务组件

    Redis Cluster “cluster nodes”命令

    redis cluster集群部署后,可以通过redis-cli的 cluster nodes 命令查看集群的节点信息。 输出的每行,都代表一个节点,下面我们讲解下这些信息的含义,为了更直观些,我们将这些信息放入表格里: id ip:port flags master ping-sent pong-recv config-epoch config-epoch slot 46dc4de072aad1e44548cfde5b56239001eaff5a 127.0.0.1:6380@16380 master – 0 1623402917302 2 connected 5461-10922 18cc5a352ba7a567bdbad5d777b3712a7b81b0f8 127.0.0.1:6384@16384 slave 99b3c660b15114ef55247e5b07cbf8f34621bee3 0 1623402916327 3 connected 99b3c660b15114ef55247e5b07cbf8f34621bee3…

  • redis
    Redis,  技术,  服务组件

    Redis Cluster集群为何是16384个哈希槽

    我们都知道,对于客户端请求的key,redis是根据公式 HASH_SLOT=CRC16(key) mod 16384,计算出映射到哪个分片上,然后Redis会去相应的节点进行操作。 CRC16算法产生的hash值有16bit,该算法可以产生65536(2^16)个值。换句话说,值是分布在0~65535之间。那作者在做mod运算的时候,为什么不mod 65536,而选择mod 16384?这个问题,作者是给出了回答的,详见: https://github.com/antirez/redis/issues/2576,下面我们来具体的讲一下。 1. 如果槽位为65536,发送心跳信息的消息头达8k,发送的心跳包过于庞大。 redis集群的节点之间会定期发送ping/pong消息,交换数据信息的,交换的数据信息,由消息体和消息头组成。 消息体无外乎是一些节点标识,IP,端口号,发送时间等等,这里我们主要关注的是消息头: 可以看到有个字段名为 myslots 的char数组,长度为 CLUSTER_SLOTS/8,CLUSTER_SLOTS为常量16384,所以该数组长度为16384/8,这其实是一个bitmap,每一个位代表一个槽,如果该位为1,表示这个槽是属于这个节点的。 该数组所占空间大小为 16384÷8÷1024=2kb,当槽位为65536时,这块的大小是: 65536÷8÷1024=8kb。消息体中会携带一定数量的其他节点的信息,节点信息里同样包含其槽位信息,节点数大约占集群节点总数量的十分之一,至少是3个节点的信息。节点数量越多,消息体内容越大。 因为每秒钟,redis节点需要发送一定数量的ping消息作为心跳包,如果槽位为65536,这个ping消息的消息头太大了,浪费带宽。 2. redis的集群主节点数量基本不可能超过1000个 如上所述,集群节点越多,心跳包的消息体内携带的数据越多。如果节点过1000个,也会导致网络拥堵。因此redis作者,不建议redis cluster节点数量超过1000个。 3. 槽位越小,节点少的情况下,压缩率高 Redis主节点的配置信息中,它所负责的哈希槽是通过一张bitmap的形式来保存的,在传输过程中,会对bitmap进行压缩,但是如果bitmap的填充率slots / N很高的话(N表示节点数),bitmap的压缩率就很低。 如果节点数很少,而哈希槽数量很多的话,bitmap的压缩率就很低。 综上所述,作者决定取16384个槽,不多不少,刚刚好! 相关链接 https://www.cnblogs.com/rjzheng/p/11430592.html https://zhuanlan.zhihu.com/p/99037321

  • redis
    Redis,  技术,  服务组件

    Redis Cluster集群部署

    Redis Cluster是Redis官方提供的Redis集群功能。 下载镜像 docker pull redis:6.2.4 运行镜像 我们需要创建6个redis容器(redis集群,最少必须有6个节点,3主3从) redis-node1:6379 redis-node2:6380 redis-node3:6381 redis-node4:6382 redis-node5:6383 redis-node6:6384 创建挂载目录 分别在每个conf目录下创建文件redis.conf node1/conf/redis.conf : 同样,node1 ~ 6端口号依次为: 6379,6380,6381,6382,6383,6384 创建虚拟网卡 创建虚拟网卡,主要是用于redis-cluster能于外界进行网络通信,一般常用桥接模式。 docker network create redis-net 编辑docker-compose.yml文件 启动容器 docker-compose up -d…

  • 技术
    Prometheus,  技术,  服务组件

    Grafana配置Prometheus

    结合grafana,展示prometheus的数据。 步骤一 Grafana, 操作 Add data source,选择Prometheus 步骤二 配置Prometheus相关信息,primetheus服务地址,以及抓取频率等 ps: HTTP-Access选择Server(default)的话,URL就不要填写127.0.0.1或localhost这种,因为Server是直接从Grafana容器内访问,找不到该地址,可以填写实际IP地址 步骤三 导入prometheus模板 模板导入后,就可以看到导入的模板了,点击进入模板,就可以看到相应模板的图表 步骤四 我们也可以创建自己的图表