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。

消息生命周期

1. Component 1 将 Message A 发送到一个队列，该消息在CMQ服务器间提供多份冗余, Message A 是 Active状态。

2. 当 Component 2 准备好处理消息时，就从队列检索消息，然后 Message A 返回，此时 Message A 是 Inactive 状态，仍然停留在队列中，但其他业务不可获取。

3. Component 2 可从队列删除 Message A，此时 Message A 为 Deleted 状态，消息的最长存活时间由创建队列时指定的 MessageRetentionPeriod 属性值决定，超过此时间后消息状态变成 Expired 并将被回收。 如果Component 2 未进行删除，在取出消息隐藏时长(VisibilityTimeout) 后该消息会被再次接受并处理。

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

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简单原理

1. 水平拆分
   水平切分是按照某种规则，将一个表的数据分散到多个物理独立的数据库服务器中，这些“独立”的数据库“分片”；多个分片组成一个逻辑完整的数据库实例。
   

   shardkey，建表默认需要设置shardkey，对于shardkey的选择有两点：

   1. 主键以及所有唯一索引的一部分
   2. 建议选择业务特点和数据库中每张表里实体关系，找到一个与大多数表都相关的实体字段作为shardkey。

2. 数据聚合（合并）
   

   各个set(物理分片)数据会在proxy层进行缓存，然后进行聚合。
   在执行 SELECT 语句时，建议您带上 shardkey 字段，否则会导致数据需要全表扫描然后网关才对执行结果进行聚合。全表扫描响应较慢，对性能影响很大。

3. 读写分离
   读写分离 基本的原理是让主节点 (master) 处理事务性增、改、删操作（INSERT、UPDATE、DELETE），让从节点 (slave) 处理查询操作（SELECT）。
   

TSF

简介

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

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

产品优势

TSF分布式事务

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

TCC 模式的事务执行流程：

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

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

TSF Demo

官网案例: https://cloud.tencent.com/document/product/649/16619