riemann_的博客

欢迎大家关注我的微信公众号【老周聊架构】，Java后端主流技术栈的原理、源码分析、架构以及各种互联网高并发、高性能、高可用的解决方案。一、前言在前三篇我们介绍了我的架构梦：（九十七）消息中间件之RocketMQ的高可用机制——消息存储高可用我的架构梦：（九十八）消息中间件之RocketMQ的高可用机制——消息发送高可用我的架构梦：（九十九）消息中间件之RocketMQ的高可用机制——消息消费高可用这一篇我们来说一下集群管理是如何保证高可用的，不仅是最后一篇关于 RocketMQ 的高可用机制.

欢迎大家关注我的公众号【老周聊架构】，Java后端主流技术栈的原理、源码分析、架构以及各种互联网高并发、高性能、高可用的解决方案。一、前言在前两篇我们介绍了我的架构梦：（九十七）消息中间件之RocketMQ的高可用机制——消息存储高可用我的架构梦：（九十八）消息中间件之RocketMQ的高可用机制——消息发送高可用这一篇我们来说一下消息消费是如何保证高可用的。要想知道消息消费的高可用，那我们得知道消息是怎么消费的吧。我们知道 Consumer 集群中每个 Consumer 都有消费组，那一个.

欢迎大家关注我的公众号【老周聊架构】，Java后端主流技术栈的原理、源码分析、架构以及各种互联网高并发、高性能、高可用的解决方案。一、前言在上一篇我们介绍了 我的架构梦：（九十七）消息中间件之RocketMQ的高可用机制——消息存储高可用，这一篇我们来说一下消息发送是如何保证高可用的。我们从前面的几篇文章也了解到，RocketMQ 的消息发送机制是通过 NameServer 监听 Broker 集群的心跳，Producer 从 NameServer 中获取 Broker、Topic 以及 Cons.

一、前言作为一款消息中间件产品，高可用起着至关重要的作用。那 RocketMQ 是怎么保证高可用机制的呢？老周从四个维度来分析：消息存储高可用、消息发送高可用、消息消费高可用以及消息管理高可用。本文主要侧重讲消息存储高可用，其它三个维度老周也会说一下。话不多说，我们现在就开始 RocketMQ 的高可用机制之旅吧。二、消息存储高可用很多需要持久化的产品，它们的高可用机制一般都是主从复制和读写分离。RocketMQ 消息存储的高可用也不例外。既然这样，那我们就从这两个方向来分析一下。1、主从复制2、

一、源码下载从官方仓库 https://github.com/apache/rocketmq clone 或者 download下来。这里老周先来解释下源码目录结构：broker: broker 模块(broke 启动进程)client :消息客户端，包含消息生产者、消息消费者相关类common :公共包dev :开发者信息(非源代码)distribution :部署实例文件夹(非源代码)example: RocketMQ 示例代码filter :消息过滤相关基础类filtersrv

一、存储方式业界主流的 MQ 产品像 RabbitMQ、RocketMQ、ActiveMQ、Kafka 都是支持持久化存储的，而 ZeroMQ 不需要支持持久化存储。业务系统也确实需要 MQ 支持持久化存储能力，这样可以增大系统的高可用性。但存储方式和效率来看，我们可以分为文件系统、分布式 KV 存储、关系型数据库三种方式：1、文件系统目前业界较为常用的几款产品(RabbitMQ、RocketMQ、ActiveMQ、Kafka)均采用的是消息刷盘至所部署虚拟机/物理机的文件系统来做持久化(刷盘一般可以

一、安装及启动1、在线下载rocketmq（如果不想使用wget下载，可以直接使用上述提供的软件包）# 下载 wget https://archive.apache.org/dist/rocketmq/4.5.1/rocketmq-all-4.5.1-bin-release.zip2、解压缩unzip rocketmq-all-4.5.1-bin-release.zip -d /opt/# 如果unzip命令找不到，则需要执行下面这条命令，修改yum源，在线下载解压工具，然后再执行unzip

一、前言随着业务的扩展以及集群的扩大，越来越多的业务系统对日志收集面临了很大的挑战。我们急需一种收集日志的工具将散落在各个服务器节点上的日志收集起来，进行统一的查询及管理统计。我们之前的系统就是采用ELK来实现的。鉴于有些小伙伴们对ELK还不是很了解，我这里就先提一些概念，方便大家理解。1、ElasticSearch(简称ES)Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它允许您快速、实时地存储、搜索和分析大量数据。它通常用作底层引擎/技术，为具有复杂搜索特性和需求的应用程序

一、集群搭建要求1、搭建设计2、架构介绍分配六台Linux，用于安装拥有三个节点的Kafka集群和三个节点的Zookeeper集群。ip地址节点名称10.211.55.3zookeeperCluster310.211.55.4zookeeperCluster410.211.55.5zookeeperCluster510.211.55.7kafkaCluster710.211.55.8kafkaCluster810.211.55.9kaf

一、概念1、水位标记水位或水印(watermark)一词，表示位置信息，即位移(offset)。Kafka源码中使用的名字是高水位，HW(high watermark)。2、副本角色Kafka分区使用多个副本(replica)提供高可用3、LEO和HW每个分区副本对象都有两个重要的属性:LEO和HW。LEO：即日志末端位移(log end offset)，记录了该副本日志中下一条消息的位移值。如果 LEO=10，那么表示该副本保存了10条消息，位移值范围是[0, 9]。另外，Leader

一、概念可靠性是系统的一个属性，而不是一个独立的组件，所以讨论kafka的可靠性保证时，应当从系统的整体出发。kafka在数据传递可靠性方面具备很大的灵活性。我们知道，kafka被用在生活中各种场景里。有些场景要求很高的可靠性，而有些则更看重速度和简便性。kafka被设计成高度可配置的，而且它的客户端API可以满足不同程度的可靠性需求。再讲可靠性之前我们来先了解以下几点的概念：创建Topic的时候可以指定 --replication-factor 3 ，表示分区的副本数，不要超过broker的数量。

一、幂等性保证在消息重发的时候，消费者不会重复处理。即使在消费者收到重复消息的时候，重复处理，也要保证最终结果的一致性。所谓幂等性，数学概念就是: f(f(x)) = f(x) 。f函数表示对消息的处理。比如，银行转账，如果失败，需要重试。不管重试多少次，都要保证最终结果一定是一致的。二、引入幂等性之前Producer向Broker发送消息，然后Broker将消息追加到消息流中后再给Producer返回Ack信号值。实现流程如下:生产中，会出现各种不确定的因素，比如在Producer在发送给B

一、前言各位读者朋友们，博主给大家拜年了。因为在写这篇文章的时候正是2021年的除夕夜，刚和家人吃完年夜饭，去睡之前，想着脑海里还有个问题困惑着我。这个问题是什么呢？没错，就是本篇的标题：Kafka基于磁盘存储为啥这么快？Kafka基于磁盘存储，却具有高性能、高吞吐、低延时的特点，其吞吐量动辄几十上百万。小伙伴们是否也有和我一样的困惑？磁盘存储io相对于内存来说不是很慢吗？那Kafka怎么会有如此高的性能呢！！！kafka高性能，是多方面协同的结果，包括宏观架构、分布式partition存储、ISR数

一、事务场景发的多条消息组成一个事务，这些消息需要对同时可见或者同时不可见。producer可能会给多个topic，多个partition发消息，这些消息也需要能放在一个事务里面，这就形成了一个典型的分布式事务。kafka的应用场景经常是应用先消费一个topic，然后做处理再发到另一个topic，这个consume-transform-produce过程需要放到一个事务里面，比如在消息处理或者发送的过程中如果失败了，消费偏移量也不能提交。producer或者producer所在的应用

一、环境准备jdk下载地址链接：jdk 1.8，提取码: dv5hzookeeper下载地址链接：zookeeper3.4.14 ，提取码: 3dchkafka下载地址链接：kafka2.12，提取码: 61bc1、Java环境为前提1.1 上传jdk-8u261-linux-x64.rpm到服务器并安装# 安装命令rpm -ivh jdk-8u261-linux-x64.rpm 1.2 配置环境变量# 编辑配置文件,jdk的bin目录到/etc/profile文件，对所有用户的she

一、Kafka介绍Kafka是最初由 Linkedin 公司开发，是一个 分布式、分区的、多副本的、多生产者、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统）。常见可以用于web/nginx日志、访问日志，消息服务等等。Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。1、主要应用场景日志收集系统消息系统2、Kafka主要设计目标以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。高吞吐率。即

一、分片集群安全认证1、进入路由创建管理员和普通用户1.1 创建管理员1.2 创建普通用户2、关闭所有的配置节点、分片节点和路由节点ps -ef | grep mongo*3、生成密钥文件并修改权限注意：这里所有节点都需要！！！3.1 创建data/mongodb目录存放生成的密钥mkdir -p data/mongodb3.2 生成密钥（便于配置节点集群和分片节点集群交互）openssl rand -base64 756 > data/mongodb/tes

一、前言1、拓扑结构一台路由节点IP地址：10.211.55.3端口：11111三套复制集（每个分片节点中的复制集，都需要有仲裁节点）IP地址： 10.211.55.7 ， 端口：15555/15556/15557IP地址： 10.211.55.8 ， 端口：15555/15556/15557IP地址： 10.211.55.9 ， 端口：15555/15556/15557集群都是在一台机器上搭建此集群，使用不同端口进行区分。一套配置集群IP地址： 10.211.55.4 ，

一、MongoDB的基本操作1、查看数据库show dbs;2、切换数据库，如果没有对应的数据库则创建use 数据库名;切换库，如果库不存在则自动创建此库。创建新的库，再次查询时，并没有显示新创建的库信息，因为库中没有内容，所有不显示。3、创建集合 （相当于创建表）db.createCollection("集合名")4、查看集合show tables;show collections;5、删除集合db.集合名.drop();6、删除当前数据库db.dro

一、安装MongoDB1、下载社区版 MongoDB 4.1.3去官网下载对应的MongoDB 然后上传到Linux虚拟机或者直接从云盘下载：MongoDB 4.1.3 云盘下载地址 ， 提取码： hj9e2、将下载的mongodb上传到linux系统3、将压缩包解压即可tar -zxvf mongodb-linux-x86_64-4.1.3.tgz4、启动./bin/mongod启动失败，缺少目录。创建缺少的目录，重新启动mongodb。mkdir -p /data/db

一、NoSQL 和 MongoDBNoSQL=Not Only SQL，支持类似SQL的功能， 与Relational Database相辅相成。其性能较高， 不使用SQL意味着没有结构化的存储要求(SQL为结构化的查询语句)，没有约束之后架构更加灵活。NoSQL数据库四大家族：列存储 Hbase，键值(Key-Value)存储 Redis，图像存储 Neo4j，文档存储 MongoDB。MongoDB 是一个基于分布式文件存储的数据库，由 C++ 编写，可以为 WEB 应用提供可扩展、 高性能、易部

一、前言1、搭建要求搭建 两套一主二从 主从集群 架构，如下图。基于user_id对c_order表进行数据分片（分库）基于id对c_order表进行数据分表，分别是：c_order1和c_order2基于master1和master2 实现 读写分离2、建表语句CREATE TABLE `c_order1`( `id` bigint(20) NOT NULL AUTO_INCREMENT, `is_del` bit(1) NOT NULL DEFAULT 0 COMMENT '是否

一、MHA架构MHA(Master High Availability)是一套比较成熟的 MySQL 高可用方案，也是一款优秀的故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。MHA还支持在线快速将Master切换到其他主机，通常只需0.5-2秒。目前MHA主要支持一主多从的架构，要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器。MH

一、读写分离1、读写分离引入时机大多数互联网业务中，往往读多写少，这时候数据库的读会首先成为数据库的瓶颈。如果我们已经优化了SQL，但是读依旧还是瓶颈时，这时就可以选择“读写分离”架构了。读写分离首先需要将数据库分为主从库，一个主库用于写数据，多个从库完成读数据的操作，主从库之间通过主从复制机制进行数据的同步，如图所示。在应用中可以在从库追加多个索引来优化查询，主库这些索引可以不加，用于提升写效率。读写分离架构也能够消除读写锁冲突从而提升数据库的读写性能。使用读写分离架构需要注意：主从同步延迟

一、前言上一篇：我的架构梦：（七十五） MySQL主从复制架构搭建 中遗留了一点问题，我们这节来消灭掉。mysql主从复制存在的问题：主库宕机后，数据可能丢失从库只有一个SQL Thread，主库写压力大，复制很可能延时解决方法：半同步复制（解决数据丢失的问题）并行复制（解决从库复制延迟的问题）这一节我们就来介绍半同步复制和并行复制来解决上一节遗留的问题。二、半同步复制1、半同步复制概述为了提升数据安全，MySQL让Master在某一个时间点等待Slave节点的 ACK(Ac

一、搭建准备1、软件版本软件版本虚拟机 Parallels Desktop16.1.2服务器 CentOS LinuxCentOS-7-x86_64-DVD-1810.iso数据库 MySQL5.7.28远程连接 ZenTermLite4.2.02、架构介绍机器名称角色权限IPMaster数据库Master可读写、主库10.211.55.3Slave1数据库Slave只读、从库10.211.55.4Sl

之前用的Windows的VMWare，现在换成MAC系统后，听朋友说Parallels Desktop是专为MAC系统量身打造的虚拟机，所以下载下来搭建了一番。1、Parallels Desktop安装Parallels Desktop官网下载地址: https://www.parallels.cn/products/desktop/pro/想要免费版的也可以找我哈~2、Centos Linux安装这里博主直接给你分享了，直接点击下载完事。链接: https://pan.baidu.com/s/

一、消费的方式1、拉消息// 指定从哪个消费者消费消息// 指定是否自动确认消息 true表示自动确认final GetResponse getResponse = channel.basicGet("queue.biz", true);2、推消息// 监听消息，一旦有消息推过来，就调用第一个lambda表达式channel.basicConsume("queue.ca", (consumerTag, message)->{ System.out.println(new String

一、消息发送案例public class MyProducer { public static void main(String[] args) throws Exception { ConnectionFactory factory = new ConnectionFactory(); factory.setUri("amqp://root:123456@47.113.82.141:5672/%2f"); final Connection con

一、前言消息流转示意图:rabbit_channel进程确定了消息将要投递的目标队列，rabbit_amqqueue_process是队列进程，每 个队列都有一个对应的进程，实际上rabbit_amqqueue_process进程只是提供了逻辑上对队列的相关操作，他的真正操作是通过调用指定的backing_queue模块提供的相关接口实现的，默认情况该 backing_queue的实现模块为rabbit_variable_queue。 RabbitMQ队列中的消息随着系统的负载会不断的变化，一个消息可

一、案例你用支付宝给商家支付，如果是个仔细的人，会考虑我转账的话，会不会把我的钱扣了，商家没有收到我的钱?一般我们使用支付宝或微信转账支付的时候，都是扫码，支付，然后立刻得到结果，说你支付了多少钱，如果你绑定的是银行卡，可能这个时候你并没有收到支付的确认消息。往往是在一段时间之后， 你会收到银行卡发来的短信，告诉你支付的信息。小伙伴有没有想过：支付平台如何保证这笔帐不出问题？支付平台必须保证数据正确性，保证数据并发安全性，保证数据最终一致性。支付平台通过如下几种方式保证数据一致性：1、分布式

一、安装环境1、阿里云主机2、操作系统：centos-release-7-8.2003.0.el7.centos.x86_643、Erlang：erlang-23.0.2-1.el7.x86_644、RabbitMQ：rabbitmq-server-3.8.5-1.el7.noarchRabbitMQ的安装需要首先安装Erlang，因为它是基于Erlang的VM运行的。RabbitMQ需要的依赖：socat和logrotate，logrotate操作系统中已经存在了，只需要安装socat就可以了

一、RabbitMQ整体逻辑架构二、RabbitMQ Exchange类型RabbitMQ常用的交换器类型有: fanout 、 direct 、 topic 、 headers 四种。1、Fanout会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中，如图:2、Directdirect类型的交换器路由规则很简单，它会把消息路由到那些BindingKey和RoutingKey完全匹配的 队列中，如下图:3、Topictopic类型的交换器在direct匹配规则上进行了扩展，也

一、消息中间件概念维基百科对消息中间件的解释:面向消息的系统(消息中间件)是在分布式系统中完成消息的发送 和接收的基础软件。消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基 于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进 程的通信。消息中间件就是在通信的上下游之间截断：break it，Broker然后利用中间件解耦、异步的特性，构建弹性、可靠、稳定的系统。异步处理、流量削峰、限流、缓冲、排队、最终一致性、消息驱动等

一、分布式架构通信原理1、SOA架构来看下某招聘网站的架构根据实际业务，把系统拆分成合适的、独立部署的模块，模块之间相互独立。优点：分布式、松耦合、扩展灵活、可重用。SOA架构系统中，使用Dubbo和Zookeeper进行服务间的远程通信。优点：Dubbo使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以减少报文的体积，提高传输效率。2、微服务架构SpringCloud中使用Feign解决服务之间远程通信的问题。Feign：轻量级RESTful的HTTP服务

一、环境准备1、环境软件版本操作系统：CentOS7.7Redis：5.0.82、Redis主从架构架构如下表所示，4台机器，4个主节点，4个从节点：名称IP端口角色master147.113.82.1426379主节点1master247.113.82.1426380主节点2master347.113.82.1426381主节点3master447.113.82.1426382主节点4slave147.113.82.14

一、缓存穿透、缓存雪崩、缓存击穿Redis面试毫无疑问，这个应该是最常遇见的吧。。。那我们就来看看业界是怎么处理这些问题的。1、缓存穿透一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找(比如 DB)。缓存穿透是指在高并发下查询key不存在的数据，会穿过缓存查询数据库。导致数据库压力过大而宕机。解决方案：对查询结果为空的情况也进行缓存，缓存时间(ttl)设置短一点，或者该key对应的数据insert了之后清理缓存。问题：缓存太多空值占用了更多的空间使

分布式缓存 Redis 之持久化一、前言1、学习目标2、为什么要持久化二、RDB1、触发快照的方式2、RDB执行流程(原理)3、RDB文件结构4、RDB的优缺点三、AOF1、AOF持久化实现2、AOF原理3、AOF重写、触发方式、混合持久化4、AOF文件的载入与数据还原四、RDB与AOF对比五、应用场景一、前言1、学习目标理解RDB的原理和执行流程了解RDB的文件结构理解AOF的原理和执行流程理解AOF重写原理和触发方式掌握RDB和AOF的区别和应用场景2、为什么要持久化Redis是

分布式缓存 Redis 之底层数据结构一、前言二、RedisDB结构1、id2、dict3、expires三、RedisObject结构1、结构信息概览2、7种type3、10种encoding一、前言Redis作为Key-Value存储系统，数据结构如下:Redis没有表的概念，Redis实例所对应的db以编号区分，db本身就是key的命名空间。比如:user:1000作为key值，表示在user这个命名空间下id为1000的元素，类似于user表的id=1000的行。二、RedisDB结构

缓存有三种读写模式1、Cache Aside Pattern(常用)Cache Aside Pattern(旁路缓存)，是最经典的缓存+数据库读写模式。1.1 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。1.2 更新的时候，先更新数据库，然后再删除缓存。1.3 问题：为什么是删除缓存，而不是更新缓存呢?缓存的值是一个结构:hash、list，更新数据需要遍历懒加载，使用的时候才更新缓存也可以采用异步的方式填充缓存1.4 高并发脏读