腾讯专有云解决方案--部分功能介绍

最新推荐文章于 2024-06-06 09:45:10 发布

原创最新推荐文章于 2024-06-06 09:45:10 发布 · 1k 阅读

0 ·

CC 4.0 BY-SA版权

本文深入解析了腾讯云消息队列CMQ和分布式数据库DCDB的特点与优势。CMQ提供高QPS、消息回溯及一致性算法，支持消息队列与主题模型，而DCDB则具备超高性能、专业可靠性及简单易用性，实现自动水平拆分。

CMQ

简介

腾讯云消息队列（Cloud Message Queue，CMQ）是一种分布式消息队列服务，它能够提供可靠的基于消息的异步通信机制，能够将分布式部署的不同应用（或同一应用的不同组件）之间的收发消息，存储在可靠有效的 CMQ 队列中，防止消息丢失。CMQ 支持多进程同时读写，收发互不干扰，无需各应用或组件始终处于运行状态。

对比RabbitMQ的优势

CMQ-QPS优秀：在保证高可靠前提下，同等物理设备，CMQ 吞吐量优于RabbitMQ的四倍以上。单集群QPS超过10万。
RabbitMQ不支持消息回溯：rabbitMQ不支持消息回溯，CMQ支持按照时间来回溯消息，例如从一天之前的某时某分某秒开始重新消费消息。典型业务场景如consumer做订单分析，但是由于程序逻辑或者依赖的系统发生故障等原因，导致今天消费的消息全部无效，需要重新从昨天零点开始消费，那么以时间为起点的消息重放功能对于业务非常有帮助。
一致性算法对比：CMQ 和 RabbitMQ 都能够使用多台机器进行热备份，提高可用性。CMQ 基于 Raft 算法实现，简单易维护。RabbitMQ 使用自创的GM算法（Guaranteed Multicast），学习难度较高。
RabbitMQ运维难度大：RabbitMQ的开发语言用的是erlang，较小众、学习成本高。

两种模型

消息队列模型(Queue)
point to point，消息生产者生产消息发送到queue中，消息消费者从queue中取出并且消费消息。
消息主题模型(Topic)
发布订阅，消息生产者生产消息发布到Topic，Topic投递到各个订阅者(CMQ支持标签筛选)。 CMQ支持通过 URL、Queue 订阅，目前只允许Topic发送给同一个账户下的Queue。

消息生命周期

Message lifecycle

Component 1 将 Message A 发送到一个队列，该消息在CMQ服务器间提供多份冗余, Message A 是 Active状态。
当 Component 2 准备好处理消息时，就从队列检索消息，然后 Message A 返回，此时 Message A 是 Inactive 状态，仍然停留在队列中，但其他业务不可获取。
Component 2 可从队列删除 Message A，此时 Message A 为 Deleted 状态，消息的最长存活时间由创建队列时指定的 MessageRetentionPeriod 属性值决定，超过此时间后消息状态变成 Expired 并将被回收。如果Component 2 未进行删除，在取出消息隐藏时长(VisibilityTimeout) 后该消息会被再次接受并处理。

CMQ可以支持消息回溯，在消息未被彻底回收，都可以回溯到之前的一个时间点，以消息生产的时间为排序标准。
Message Rewind

CMQ Demo

官网案例: https://cloud.tencent.com/document/product/406/6127
Github:

DCDB

简介

DCDB是部署在腾讯云公有云上的一种支持自动水平拆分的share nothing架构的分布式数据库。分布式数据库即业务获取是完整的逻辑库表，后端却将库表均匀的拆分到多个物理分片节点。目前，DCDB默认部署主备架构且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案，适用于TB或PB级的海量数据库场景。

优点

超高性能：单分片最大性能可达超 24 万 QPS，整个实例性能随着分片数量增加线性扩展。强同步性能与异步同步相当，能让您在数据不丢失的情况下，也拥有较高的性能。
专业可靠：提供完善的数据备份、容灾、一键升级等方案。完善的监控和报警体系，大部分故障都通过自动化程序或腾讯值班同事处理恢复。分布式数据库领域领先功能，如分布式多表 JOIN，小表广播，分布式事务，SQL 透传等。
简单易用：除少量语法与原生 MySQL/PostgreSQL 不同以外，使用起来就像使用单机数据库，分片过程对业务透明且无需干预。兼容 MySQL 协议（支持 Percona、MariaDB 等内核）。支持 WEB 控制台，读写分离能力、专有运维管理指令等。

DCDB简单原理

水平拆分
水平切分是按照某种规则，将一个表的数据分散到多个物理独立的数据库服务器中，这些“独立”的数据库“分片”；多个分片组成一个逻辑完整的数据库实例。
shardkey，建表默认需要设置shardkey，对于shardkey的选择有两点：
1. 主键以及所有唯一索引的一部分
2. 建议选择业务特点和数据库中每张表里实体关系，找到一个与大多数表都相关的实体字段作为shardkey。
数据聚合（合并）

各个set(物理分片)数据会在proxy层进行缓存，然后进行聚合。
在执行 SELECT 语句时，建议您带上 shardkey 字段，否则会导致数据需要全表扫描然后网关才对执行结果进行聚合。全表扫描响应较慢，对性能影响很大。
读写分离
读写分离基本的原理是让主节点 (master) 处理事务性增、改、删操作（INSERT、UPDATE、DELETE），让从节点 (slave) 处理查询操作（SELECT）。

TSF

简介

Tencent Distributed Service Framework，腾讯分布式服务框架。是一个围绕着应用和微服务的 PaaS平台。TSF 提供了 RESTful 调用方式和自研的高性能 RPC 框架，能够构建高可用、高性能的分布式系统。在TSF 控制台上，可以一站式完成应用生命周期的管理，包括创建、部署、启动、停止，也支持扩容、缩容操作。监控服务器资源的磁盘IO、内存、CPU、网络等指标，以监控图标形式展示，精准掌控服务器健康状况。支持设置自定义告警阈值，当指标触发告警条件时，会向您发送及时的告警信息，预防突发情况。

PaaS是Platform-as-a-Service的缩写，意思是平台即服务。把服务器平台作为一种服务提供的商业模式。)

产品优势

TSF advantage

TSF分布式事务

TSF提供基于TCC(try-confirm-cancel)的事务方案。

TCC 模式的事务执行流程：

依次调用从业务系统的 Try 接口
若 Try 阶段成功，则依次调用从业务系统的 Confirm 接口
若在 Try 阶段出现失败，则调用从业务系统的 Cancel 接口，对 Try 接口的操作进行恢复
若在 Confirm 阶段出现失败，则重试，设置重试次数。若重试仍然失败，则需要事后处理
若调用 Cancel 接口失败，也进行重试操作。

如果Try A成功，Try B失败，则会Cancle A。
如果confirm失败，一般是一直重试，重试时间间隔会越来越长。