牧马人的忧伤

1. 集群搭建方式1.1 集群特点 NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。 Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一 个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master,非0表示Slave。Master也可以部署多个。 每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。 Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。 Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master、S ...

1. 环境搭建依赖工具JDK ：1.8+MavenIntelliJ IDEA 1.1 源码拉取从官方仓库 https://github.com/apache/rocketmq clone 或者 download 源码。​ 源码目录结构： broker: broker 模块（broke 启动进程） client ：消息客户端，包含消息生产者、消息消费者相关类 common ：公共包 dev ：开发者信息（非源代码） distribution ：部署实例文件夹（非源代码） example: RocketMQ 例代码 filter ：消息过滤相关基础类 filtersrv：消息过滤服务器实现相关类（Filter启动进程） logappender：日志实现相关类 namesrv：NameServer实现相关类（NameServer启动进程） openmessageing：消息开放标准 remoting：远程通信模块，基于Netty srcutil：服务工具类 store：消息存储实现相关类 style：checkstyle相关实现 test：测试相关类 to ...

1. 生产者1.1 Tags的使用一个应用尽可能用一个Topic，而消息子类型则可以用tags来标识。tags可以由应用自由设置，只有生产者在发送消息设置了tags，消费方在订阅消息时才可以利用tags通过broker做消息过滤：message.setTags(“TagA”)。 1.2 Keys的使用每个消息在业务层面的唯一标识码要设置到keys字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引（哈希索引,通过对key进行hash计算，索引表存入位置由取模取），应用可以通过topic、key来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证key尽可能唯一，这样可以避免潜在的哈希冲突。 // 订单Id String orderId = "20034568923546"; message.setKeys(orderId); 1.3 日志的打印消息发送成功或者失败要打印消息日志，务必要打印SendResult和key字段。send消息方法只要不抛异常，就代表发送成功。发送成功会有多个状态，在sendResult里定义。以下对每个状态进行说明： SEND_OK 消息 ...

1. 消息发送生产者向消息队列里写入消息，不同的业务场景需要生产者采用不同的写入策略。比如同步发送、 异步发送、Oneway发送、延迟发送、发送事务消息等。 默认使用的是DefaultMQProducer类，发送消息要经过五个步骤：1）设置Producer的GroupName。2）设置InstanceName，当一个Jvm需要启动多个Producer的时候，通过设置不同的 InstanceName来区分，不设置的话系统使用默认名称“DEFAULT”。3）设置发送失败重试次数，当网络出现异常的时候，这个次数影响消息的重复投递次数。想保证不丢消息，可以设置多重试几次。4）设置NameServer地址5）组装消息并发送。 package org.example; import org.apache.rocketmq.client.exception.MQBrokerException; import org.apache.rocketmq.client.exception.MQClientException; import org.apache.rocketmq.client.produ ...

1. 延迟消息定时消息（延迟队列）是指消息发送到broker后，不会立即被消费，等待特定时间投递给真正的topic。 broker有配置项messageDelayLevel，默认值为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”，18个level。可以配置自定义messageDelayLevel。注意，messageDelayLevel是broker的属性，不属于某个topic。发消息时，设置delayLevel等级即可：msg.setDelayLevel(level)。level有以下三种情况： level == 0，消息为非延迟消息 1<=level<=maxLevel，消息延迟特定时间，例如level==1，延迟1s level > maxLevel，则level== maxLevel，例如level==20，延迟2h 定时消息会暂存在名为SCHEDULE_TOPIC_XXXX的topic中，并根据delayTimeLevel存入特定的queue，queueId = delayTime ...

高级功能消息存储分布式队列因为有高可靠性的要求，所以数据要进行持久化存储。 消息生成者发送消息 MQ收到消息，将消息进行持久化，在存储中新增一条记录 返回ACK给生产者 MQ push 消息给对应的消费者，然后等待消费者返回ACK 如果消息消费者在指定时间内成功返回ack，那么MQ认为消息消费成功，在存储中删除消息，即执行第6步；如果MQ在指定时间内没有收到ACK，则认为消息消费失败，会尝试重新push消息,重复执行4、5、6步骤 MQ删除消息 存储介质 关系型数据库DB Apache下开源的另外一款MQ—ActiveMQ（默认采用的KahaDB做消息存储）可选用JDBC的方式来做消息持久化，通过简单的xml配置信息即可实现JDBC消息存储。由于，普通关系型数据库（如Mysql）在单表数据量达到千万级别的情况下，其IO读写性能往往会出现瓶颈。在可靠性方面，该种方案非常依赖DB，如果一旦DB出现故障，则MQ的消息就无法落盘存储会导致线上故障 文件系统 目前业界较为常用的几款产品（RocketMQ/Kafka/RabbitMQ）均采用的是消息刷盘至所部署虚拟机/物理机的文件系统 ...

案例介绍业务分析模拟电商网站购物场景中的【下单】和【支付】业务 下单 用户请求订单系统下单 订单系统通过RPC调用订单服务下单 订单服务调用优惠券服务，扣减优惠券 订单服务调用调用库存服务，校验并扣减库存 订单服务调用用户服务，扣减用户余额 订单服务完成确认订单 支付 用户请求支付系统 支付系统调用第三方支付平台API进行发起支付流程 用户通过第三方支付平台支付成功后，第三方支付平台回调通知支付系统 支付系统调用订单服务修改订单状态 支付系统调用积分服务添加积分 支付系统调用日志服务记录日志 问题分析问题1用户提交订单后，扣减库存成功、扣减优惠券成功、使用余额成功，但是在确认订单操作失败，需要对库存、库存、余额进行回退。 如何保证数据的完整性？ 使用MQ保证在下单失败后系统数据的完整性 问题2用户通过第三方支付平台（支付宝、微信）支付成功后，第三方支付平台要通过回调API异步通知商家支付系统用户支付结果，支付系统根据支付结果修改订单状态、记录支付日志和给用户增加积分。 商家支付系统如何保证在收到第三方支付平台的异步通知时，如何快速给第三方支付凭条做出回应？ 通过MQ进行 ...

MQ介绍为什么要用MQ消息队列是一种“先进先出”的数据结构 其应用场景主要包含以下3个方面 应用解耦 系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。 使用消息队列解耦合，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统回复后，补充处理存在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。 流量削峰 应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。 一般情况，为了保证系统的稳定性，如果系统负载超过阈值，就会阻止用户请求，这会影响用户体验，而如果使用消息队列将请求缓存起来，等待系统处理完毕后通知用户下单完毕，这样总不能下单体验要好。 处于经济考量目的： 业务系统正常时段的QPS如果是100 ...

Mysql的体系结构概览 整个MySQL Server由以下组成 Connection Pool : 连接池组件 Management Services & Utilities : 管理服务和工具组件 SQL Interface : SQL接口组件 Parser : 查询分析器组件 Optimizer : 优化器组件 Caches & Buffers : 缓冲池组件 Pluggable Storage Engines : 存储引擎 File System : 文件系统 1） 连接层 最上层是一些客户端和链接服务，包含本地sock 通信和大多数基于客户端/服务端工具实现的类似于 TCP/IP的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。 2） 服务层 第二层架构主要完成大多数的核心服务功能，如SQL接口，并完成缓存的查询，SQL的分析和优化，部分内置函数的执行。所有跨存储引擎的功能也在这一 ...

集群架构设计架构设计理念在集群架构设计时，主要遵从下面三个维度： 可用性 扩展性 一致性 可用性设计 站点高可用，冗余站点 服务高可用，冗余服务 数据高可用，冗余数据 保证高可用的方法是冗余。但是数据冗余带来的问题是数据一致性问题。实现高可用的方案有以下几种架构模式： 主从模式 简单灵活，能满足多种需求。比较主流的用法，但是写操作高可用需要自行处理。 双主模式 互为主从，有双主双写、双主单写两种方式，建议使用双主单写 扩展性设计扩展性主要围绕着读操作扩展和写操作扩展展开。 如何扩展以提高读性能 加从库 简单易操作，方案成熟。 从库过多会引发主库性能损耗。建议不要作为长期的扩充方案，应该设法用良好的设计避免 持续加从库来缓解读性能问题。 分库分表 可以分为垂直拆分和水平拆分，垂直拆分可以缓解部分压力，水平拆分理论上可以无限扩 展。 如何扩展以提高写性能 分库分表 一致性设计一致性主要考虑集群中各数据库数据同步以及同步延迟问题。可以采用的方案如下： 不使用从库 扩展读性能问题需要单独考虑，否则容易出现系统瓶颈。 增加访问路由层 可以先得 ...

MySQL8其它新特性 1. MySQL8新特性概述MySQL从5.7版本直接跳跃发布了8.0版本，可见这是一个令人兴奋的里程碑版本。MySQL 8版本在功能上做了显著的改进与增强，开发者对MySQL的源代码进行了重构，最突出的一点是多MySQL Optimizer优化器进行了改进。不仅在速度上得到了改善，还为用户带来了更好的性能和更棒的体验。 1.1 MySQL8.0 新增特性1. 更简便的NoSQL支持NoSQL泛指非关系型数据库和数据存储。随着互联网平台的规模飞速发展，传统的关系型数据库已经越来越不能满足需求。从5.6版本开始，MySQL就开始支持简单的NoSQL存储功能。MySQL 8对这一功能做了优化，以更灵活的方式实现NoSQL功能，不再依赖模式（schema）。 2. 更好的索引在查询中，正确地使用索引可以提高查询的效率。MySQL 8中新增了隐藏索引和降序索引。隐藏索引可以用来测试去掉索引对查询性能的影响。在查询中混合存在多列索引时，使用降序索引可以提高查询的性能。 3.更完善的JSON支持MySQL从5.7开始支持原生JSON数据的存储，MySQL 8对这一功能做了优 ...

单行函数1. 函数的理解1.1 什么是函数函数在计算机语言的使用中贯穿始终，函数的作用是什么呢？它可以把我们经常使用的代码封装起来，需要的时候直接调用即可。这样既提高了代码效率，又提高了可维护性。在 SQL 中我们也可以使用函数对检索出来的数据进行函数操作。使用这些函数，可以极大地提高用户对数据库的管理效率。从函数定义的角度出发，我们可以将函数分成内置函数和自定义函数。在 SQL 语言中，同样也包括了内置函数和自定义函数。内置函数是系统内置的通用函数，而自定义函数是我们根据自己的需要编写的，本章及下一章讲解的是 SQL 的内置函数。 1.2 不同DBMS函数的差异我们在使用 SQL 语言的时候，不是直接和这门语言打交道，而是通过它使用不同的数据库软件，即 DBMS。DBMS 之间的差异性很大，远大于同一个语言不同版本之间的差异。实际上，只有很少的函数是被 DBMS 同时支持的。比如，大多数 DBMS 使用（||）或者（+）来做拼接符，而在 MySQL 中的字符串拼接函数为concat()。大部分 DBMS 会有自己特定的函数，这就意味着采用 SQL 函数的代码可移植性是很差的，因此在使 ...