XIAOSUO 记录个人学习的足迹

摘要：Kafka最初是领英公司开发的消息流组件，后来捐献给了Apche。 一、拓扑结构 Broker 是 Kafka 集群中的核心服务器，你可以把它想象成一个邮局： 生产者(Producer)就像寄信人，把消息(信件)送到 Broker(邮局) 消费者(Consumer)就像收信人，从 Broker 取走自己的消息 一个 Kafka 集群通常由多个 Broker 组成，共同处理消息存储和转发Broker 的核心职责 1. 消息存储中心 持久化存储 ：所有消息最终都会写入磁盘，而不仅仅是内存 分区管理 ：每个 Broker 负责存储某些分区的数据 日志分段 ：将大日志文件分割成多个段(segment)，便于维护和清理 2. 消息路由中心 维护所有主题/分区的元数据信息 决定生产者应该把消息发送到哪个分区 协调消费者从哪个分区获取消息 3. 副本协调者 管理 Leader 副本和 Follower 副本的同步 监控副本的健康状态 在 Leader 失效时组织新的选举Broker的工作流程 Kafka的存储结构就像一本书的目录： 主题(Topic) ：相当于书的标题，是消息的分类。比如用户注册、订单支付等。 分区(Partition) ：相当于书的章节，每个主题可以被分成多个分区。分区使Kafka可以并行处理消息。 副本(Replica) ：相当于书的复印本，每个分区可以有多个副本（通常3个）。分为Leader副本(主本)和Follower副本(副本)。 Kafka 会智能地将副本分布在不同 Broker 上： 同一个分区的不同副本不会放在同一个 Broker 尽量将分区的 Leader 均匀分布在所有 Broker 例如下图有 2个 Broker 和 1 个主题(分区数=3，副本数=2)： Kafka的消息存储就像写日记： 消息以追加(append-only) 方式写入分区，不可修改 每个消息都有一个位移(offset) ，相当于日记的行号 消息按时间保留（默认7天），超过时间自动删除 分区日志被分成多个段(segment) 文件，便于管理 基于日志结构构建的消息引擎：消费消息时是读取日志文件，消息不会删除 二、消息流程 1. 消息写入流程 生产者连接到任意 Broker 获取元数据 Broker 返回主题分区信息和 Leader Brok…… 阅读全文

摘要：★★★★★★http://www.rabbitmq.com/which-erlang.html （rabbitmq和erlang版本对应表） RabbitMQ 群集安装（每一台机器都操作） 一、环境描述 1、操作系统 主机名 IP地址 操作系统版本 erlang 版本 rabbitmq 版本 192.168.3.99 node02 CentOS Linux release 7.4.1708 (Core) 21.0 3.7.7 192.168.3.100 node01 CentOS Linux release 7.4.1708 (Core) 21.0 3.7.7 192.168.3.222 node03 CentOS Linux release 7.4.1708 (Core) 21.0 3.7.7 2、设置linux静态IP+ 命令： # cd /etc/sysconfig/network-scripts/ # vim ifcfg-ens33 修改内容为： TYPE=Ethernet PROXY_METHOD=none BOOTPROTO=static #静态IP BROWSER_ONLY=no DEFROUTE=yes IPADDR=192.168.1.189 #调整 NETMASK=255.255.255.0 #调整 GATEWAY=192.168.1.1 #调整 DNS1=202.106.0.20 #调整 DNS2=8.8.8.8 IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=ens33 UUID=312fb2fd-eade-4e6f-8abb-5602fc8d2da4 DEVICE=ens33 ONBOOT=yes # 支持静态IP 修改完毕后：执行命令： # service network restart 重启网卡： # systemctl restart network 3.关闭防火墙 查看防火墙： # systemctl status firewalld.service 开…… 阅读全文

摘要： 一、消息队列的核心价值 应用场景 异步处理：电商订单支付成功后，异步通知库存系统扣减，避免主流程阻塞。 削峰填谷：秒杀活动瞬间高并发请求先入队，后端按处理能力消费，保护系统稳定性。 系统解耦：支付系统与物流系统通过消息传递数据，无需直接接口调用。 核心概念 生产者（Producer）：发送消息的程序（如订单系统）。 消费者（Consumer）：接收消息的程序（如库存系统）。 队列（Queue）：消息的缓冲存储区，遵循先进先出（FIFO）原则。 二、主流消息队列产品对比 产品 特点 适用场景 RabbitMQ 基于AMQP协议，支持灵活的路由规则（交换机）、消息确认机制，功能全面 复杂业务逻辑、企业级应用 Kafka 高吞吐、持久化、分布式设计，支持百万级TPS 日志采集、实时流处理 RocketMQ 阿里开源，低延迟、高可用，专为金融场景优化 电商交易、大规模事务消息 Redis List 轻量级，基于内存操作，无高级特性（如重试、持久化） 简单任务队列、缓存场景 三、消息模型深度解析 队列模型（P2P） 单消费者消费消息，适用于订单支付、库存扣减等需严格顺序的场景。 发布-订阅模型（Pub/Sub） 典型应用：新闻推送、用户行为广播（如积分系统、数据分析系统同时消费）。 交换机模式——RabbitMQ特有 四、AMQP协议 AMQP核心组件 交换机（Exchange）：接收生产者消息，按规则路由到队列（直连、广播、主题等模式）。 队列（Queue）：临时存储消息的容器。 绑定（Binding）：定义交换机与队列的映射关系。 工作流程 建立连接 选择/创建虚拟主机 创建交换机和队列 绑定交换机和队列 发布消息 路由消息 消息消费 消息确认 ACK 断开连接 五、RabbitMQ实战 1. RabbitMQ部署 docker run -d \ --name rabbit-01 \ --hostname my-rabbit \ -p 5672:5672 \ # AMQP端口 -p 15672:15672 \ # 管理界面端口 -e RABBITMQ_DEFAULT_USER=admin \ -e RABBITMQ_DEFAULT_PASS=passw…… 阅读全文

摘要：一、MongoDB核心概念 1. 定位与优势 目标：处理海量数据（名称源自humongous），支持高可用、水平扩展。 数据模型： JSON文档结构：天然贴合面向对象思想，支持嵌套对象和数组。 动态模式：使用BSON（JSON的二进制扩展）存储，支持日期、二进制等扩展类型。 核心优势： 易用性：类JSON语法降低学习成本。 高性能：内存映射引擎、写优化设计。 高可靠性：副本集自动故障转移。 高扩展性：原生分布式架构（分片集群）。 2. SQL vs MongoDB概念对比 关键差异：MongoDB属于半结构化数据模型，无固定表结构，不支持事务级JOIN。 二、基础操作实战 1. 集合与文档操作 // 创建/切换数据库 use sample // 插入文档 db.persons.insertOne({ name: 张三, age: 22 }) db.persons.insertMany([...]) // 查询文档 db.movies.find( { year : 1975 } ) //单条件查询 db.movies.find( { year : 1989, title : Batman } ) //多条件and查询 db.movies.find( { $and : [ {title : Batman}, { category : action }] } ) // and的另一种形式 db.movies.find( { $or: [{year : 1989}, {title : Batman}] } ) //多条件or查询 db.movies.find( { title : /^B/} ) //按正则表达式查找 // 更新与删除 db.persons.updateMany({ age: 22 }, { $set: { status: active }}) db.persons.deleteMany({ age: { $lt: 18 }}) db.runCommand({ drop: persons }) // 删除集合 2. 查询条件对照表 SQL MQL a = 1 { a: 1 } a 1 { a: { $ne: 1 } } a 1 { a: { $gt: 1 } } a = 1 { a: …… 阅读全文