网站备案自己备案和代理备案,金融网站建设方案ppt,江淮网站开发,易语言用客户端和服务器做网站一、RocketMQ概述 1.1 MQ 概述
MQ#xff0c;Message Queue#xff0c;是一种提供消息队列服务的中间件#xff0c;也成为消息中间件#xff0c;是一套提供了消息生产、存储、消费全过程API的软件系统。消息即数据
1.2 MQ 用途
MQ的用途总结起来可分为以下三点
限流削峰…一、RocketMQ概述 1.1 MQ 概述
MQMessage Queue是一种提供消息队列服务的中间件也成为消息中间件是一套提供了消息生产、存储、消费全过程API的软件系统。消息即数据
1.2 MQ 用途
MQ的用途总结起来可分为以下三点
限流削峰
MQ可以将系统的超量请求暂存其中以便系统后期可以慢慢进行处理从而避免了请求的丢失或系统被压垮
异步解耦
上游系统对下游系统的调用若为同步调用则会大大降低系统的吞吐量与并发度且系统耦合度太高。而异步调用则会解决这些问题。所以两层之间若要实现由同步到异步的转化一般性做法就是在这两层间添加一个MQ层
数据收集
分布式系统会产生海量数据如业务日志、监控数据、用户行为等。针对这些数据流进行实时或批量采集汇总然后对这些数据流进行大数据分析这是当前互联网平台的必备技术。通过MQ完成此类数据收集是最好的选择
1.3 常见 MQ 产品
ActiveMQ
ActiveMQ 是使用Java语言开发一款MQ产品。早期很多公司与项目中都在使用。但现在的社区活跃度已经很低。现在的项目中已经很少使用了
RabbitMQ
RabbitMQ 是使用 ErLang 语言开发的一款MQ产品。其吞吐量较 Kafka 与 RocketMQ 要低且由于其不是Java语言开发所以公司内部对其实现定制化开发难度较大。对于Spring Cloud Netflix其仅支持 RabbitMQ 与 Kafka。吞吐量在5.95w/sCPU资源消耗较高
Kafka
Kafka 是使用Scala / Java语言开发的一款MQ产品。其最大的特点就是高吞吐量常用于大数据领域的实时计算、日志采集等场景。其没有遵循任何常见的MQ协议而是使用自研协议会出现数据丢失功能比较单一。吞吐量高达17.w/s这主要取决于它的队列模式保证了写磁盘的过程是线性IO。此时broker磁盘IO已达瓶颈
RocketMQ
RocketMQ 是使用Java语言开发的一款MQ产品。经过数年阿里双11的考验性能与稳定性非常高。其没有遵循任何常见的MQ协议而是使用自研协议。对于Spring Cloud Alibaba其支持RabbitMQ、Kafka但没有提倡使用 RocketMQ。吞吐量在11.6w/s磁盘IO%util已接近100%。RocketMQ的消息写入内存后即返回ack由单独的线程专门做刷盘的操作所有的消息均是顺序写文件
1.4 MQ 的优缺点
系统可用性减低
系统引入外部依赖增多系统的稳定性就会变差。一旦MQ宕机对业务会产生影响。这就需要考虑如何保证MQ的高可用
系统复杂度提高
引入MQ后系统复杂度会大大提高。以前服务之间可以进行同步的服务调用引入MQ后就会变成异步调用数据的链路就会变得更加复杂。并且还会带来其他一些问题。比如如何保证消费的消息不会丢失不会重复消费消息如何保证消息的顺序性等问题
消息一致性问题
A系统处理完业务通过MQ发送消息给B、C系统进行后续的业务处理。如果B系统处理成功C系统处理失败这事就需要考虑如何保证消息数据处理的一致性
1.5 MQ 常见协议
JMS
JMSJava Messaging ServiceJava消息服务。是Java平台上有关MOMMessage Oriented Middleware面向消息的中间件的技术规范它便于消息系统中的Java应用程序进行消息交换并且通过提供标准的产生、发送、接收消息的接口简化企业应用开发。AcitveMQ是该协议的典型实现
STOMP
STOMPStreaming Text Oriented Message Protocol面向文本流消息协议是一种MOM设计的简单文本协议。STOMP提供一个可互操作的连接格式允许客户端与任意STOMP消息代理Broker进行交互。ActiveMQ是该协议的典型实现RabbitMQ通过插件可以支持该协议
AMQP
AMQPAdvanced Message Queuing Protocol高级消息队列协议是一个提供统一消息服务的应用层标准是应用层协议的一个开放标准是一种MOM设计。基于此协议的客户端与消息中间件可传递消息并不受客户端 / 中间件不同产品不同开发语言等条件限制。RabbitMQ是该协议的典型实现
MQTT
MQTTMessage Queuing Telemetry Transport消息队列遥感测传输是IBM开发的一个即时通讯协议是一种二进制协议主要用于服务器和低低功耗IoT物联网设备间的通信。该协议支持所有平台几乎可以把所有联网物品和外部连接起来被用来当作传感器和制动器的通信协议。RabbitMQ通过插件可以支持该协议
1.6 参考约束和建议
Apache RocketMQ 系统中存在很多自定义参数和资源命名您在使用 Apache RocketMQ 时建议参考如下说明规范系统设置避对某些具体参数设置不合理导致应用出现异常
参数建议范围说明Topic名称字符建议字母az或AZ、数字0~9以及下划线、短划线-和百分号%。 长度建议1~64个字符。 系统保留字符Topic名称不允许使用以下保留字符或含有特殊前缀的字符命名。 保留字符: TBW102 *BenchmarkTest* SELF_TEST_TOPIC *OFFSET_MOVED_EVENT* SCHEDULE_TOPIC_XXXX *RMQ_SYS_TRANS_HALF_TOPIC* RMQ_SYS_TRACE_TOPIC *RMQ_SYS_TRANS_OP_HALF_TOPIC 特殊前缀:* rmq_sys %RETRY% %DLQ% rocketmq-broker-Topic命名应该尽量使用简短、常用的字符避免使用特殊字符。特殊字符会导致系统解析出现异常字符过长可能会导致消息收发被拒绝ConsumerGroup名称字符建议支持字母az或AZ、数字0~9以及下划线、短划线-和百分号%。 长度建议1~64个字符。 系统保留字符ConsumerGroup不允许使用以下保留字符或含有特殊前缀的字符命名。 保留字符: *DEFAULT_CONSUMER* DEFAULT_PRODUCER *TOOLS_CONSUMER* FILTERSRV_CONSUMER *__MONITOR_CONSUMER* CLIENT_INNER_PRODUCER *SELF_TEST_P_GROUP* SELF_TEST_C_GROUP *CID_ONS-HTTP-PROXY* CID_ONSAPI_PERMISSION *CID_ONSAPI_OWNER* CID_ONSAPI_PULL *CID_RMQ_SYS_TRANS* 特殊字符 * CID_RMQ_SYS * CID_HOUSEKEEPING无ACL Credentials字符建议AKAccessKey ID、SKAccessKey Secret和Token仅支持字母az或AZ、数字0~9。 长度建议不超过1024个字符无请求超时时间默认值3000毫秒。 取值范围该参数为客户端本地行为取值范围建议不要超过30000毫秒请求超时时间是客户端本地同步调用的等待时间请根据实际应用设置合理的取值避免线程阻塞时间过长消息大小默认值不超过4 MB。不涉及消息压缩仅计算消息体body的大小。 取值范围建议不超过4 MB消息传输应尽量压缩和控制负载大小避免超大文件传输。若消息大小不满足限制要求可以尝试分割消息或使用OSS存储用消息传输URL消息自定义属性字符限制所有可见字符。 长度建议属性的Key和Value总长度不超过16 KB。 系统保留属性不允许使用以下保留属性作为自定义属性的Key。 保留属性Key无MessageGroup字符限制所有可见字符。 长度建议1~64字节MessageGroup是顺序消息的分组标识。一般设置为需要保证顺序的一组消息标识例如订单ID、用户ID等消息发送重试次数默认值3次。 取值范围无限制消息发送重试是客户端SDK内置的重试策略对应用不可见建议取值不要过大避免阻塞业务线程。 如果消息达到最大重试次数后还未发送成功建议业务侧做好兜底处理保证消息可靠性消息消费重试次数默认值16次消费重试次数应根据实际业务需求设置合理的参数值避免使用重试进行无限触发。重试次数过大容易造成系统压力过量增加事务异常检查间隔默认值60秒事务异常检查间隔指的是半事务消息因系统重启或异常情况导致没有提交生产者客户端会按照该间隔时间进行事务状态回查。 间隔时长不建议设置过短否则频繁的回查调用会影响系统性能半事务消息第一次回查时间默认值取值等于[事务异常检查间隔] * 最大限制不超过1小时无半事务消息最大超时时长默认值4小时。 * 取值范围不支持自定义修改半事务消息因系统重启或异常情况导致没有提交生产者客户端会按照事务异常检查间隔时间进行回查若超过半事务消息超时时长后没有返回结果半事务消息将会被强制回滚。 您可以通过监控该指标避免异常事务PushConsumer本地缓存默认值 *最大缓存数量1024条。 *最大缓存大小64 M。 取值范围支持用户自定义设置无限制消费者类型为PushConsumer时为提高消费者吞吐量和性能客户端会在SDK本地缓存部分消息。缓存的消息的数量和大小应设置在系统内存允许的范围内PushConsumer重试间隔时长默认值 *非顺序性投递间隔时间阶梯变化具体取值请参见PushConsumer消费重试策略。 *顺序性投递3000毫秒无PushConsumer消费并发度默认值20个线程无获取消息最大批次默认值32条消费者从服务端获取消息时一次获取到最大消息条数。建议按照实际业务设置合理的参数值一次获取消息数量过大容易在消费失败时造成大批量消息重复SimpleConsumer最大不可见时间默认值用户必填参数无默认值。 取值范围建议最小10秒最大12小时消费不可见时间指的是消息处理失败后重试间隔的总时长建议设置时取值比实际需要耗费的时间稍微长一些
