腾讯云 TDSQL 审计原理揭秘-优快云博客

作者简介：孙勇福，腾讯云高级工程师，负责腾讯云 TDSQL 产品研发，毕业至今一直从事数据存储系统运维和研发工作，在数据库领域以及 NoSQL 领域具有丰富的运维和开发经验。

开源数据库往往不具备商业数据库一样的高端能力，但是却因简单易用，无需 license 费用等深得大家喜欢，但在云服务时代，打造一款同时具备了开源数据库的性价比和商业数据库的安全性的数据库，几乎是所有使用者心中的梦想。腾讯云数据库 TDSQL 基于这样的考虑，实现了云化的审计能力，下面就让我们一起来看看具体的技术细节。

产品架构

各模块特点

1) proxy

三个无差别 proxy Ip，保证一个或者两个 proxy 故障时，剩余 proxy Ip 正常工作用户无感知。
旁路信息进入 kafka 时，对数据进行压缩上传同时 kafka 必须半数节点响应成功后才算正确上传。
每个用户实例都有自己单独的 proxy，在数据上传是不同实例消息并发上传到 kafak 的 topic,保证每个用户信息及时进入审计消息队列。

2) Kafka

Kafka 是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：
以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上数据也能保证常数时间的访问性能
高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条消息的传输
支持 Kafka Server 间的消息分区，及分布式消费，同时保证每个 partition 内的消息顺序传输
同时支持离线数据处理和实时数据处理

Kafka解析

Terminology

Broker：Kafka 集群包含一个或多个服务器，这种服务器被称为 broker
Topic：每条发布到 Kafka 集群的消息都有一个类别，这个类别被称为 topic。（物理上不同 topic 的消息分开存储，逻辑上一个 topic 的消息虽然保存于一个或多个 broker 上但用户只需指定消息的 topic 即可生产或消费数据而不必关心数据存于何处）
Partition：parition 是物理上的概念，每个 topic 包含一个或多个 partition，创建topic 时可指定parition数量。每个 partition 对应于一个文件夹，该文件夹下存储该 partition 的数据和索引文件
Producer：负责发布消息到 Kafka broker
Consumer：消费消息。每个 consumer 属于一个特定的 consumer group（可为每个 consumer 指定 group name，若不指定 group name 则属于默认的group）。使用 consumer high level API 时，同一 topic 的一条消息只能被同一个 consumer group 内的一个 consumer 消费，但多个 consumer group 可同时消费这一消息。

Kafka框架

如上图所示，一个典型的 kafka 集群中包含若干 producer（可以是 web 前端产生的 page view，或者是服务器日志，系统 CPU、memory 等），若干 broker（Kafka 支持水平扩展，一般 broker 数量越多，集群吞吐率越高），若干 consumer group，以及一个 Zookeeper 集群。Kafka 通过 Zookeeper 管理集群配置，选举 leader，以及在 consumer group 发生变化时进行rebalance。producer 使用 push 模式将消息发布到 broker，consumer使用 pull 模式从 broker 订阅并消费消息。

3) audit-server

audit-server 是分布式服务，采用一致性 hash 算法进行路由
多协程并发处理模式保证 kafka 数据秒级别消费

一致性 hash

在分布式集群中，对于机器的添加和删除已经故障机器自动脱离集群不影响服务是分布式集群的最基本的功能。本次审计服务采用一致性 hash 完成这种基本功能。

具体描述如下：按照常用的 hash 算法来将对应的 key 哈希到一个具有 2^32 次方个桶的空间中，即 0~(2^32)-1 的数字空间中，也就是将 object1，object2, object3, object4 四个（假设有四个实例对象）实例对象通过 hash 散列到 hash 环上。如图（来自于网络）

同时将三个服务节点（假设三个服务节点），通过 hash 也散列到 hash 环上。如图（来自于网络），通过找出距离自己最近的 node 节点，即可找到服务节点。

在服务节点添加删除或故障时实例对象都会自动的调整找到距离自己最近的服务节点进行审计服务。

同时，在引入 audit-server 路由时，我们发现 node 服务节点分布越均匀，每个服务节点的负载也就越均匀。这里引用了虚拟节点来解决这一问题。

审计策略

独立规则加载协程：在规则加载时，不影响审计规则功能区性能
优先级：策略支持用户自定义优先级，在策略匹配时，优先匹配到优先级较高的策略。
规则设置丰富: 支持规则=, !=，>, >=, <, <= 以及正则匹配。
权限：支持二次认证，保证数据安全性。

多并发协程

协程，不需要抢占式调度，可以有效提高线程的任务并发性，而避免多线程的缺点（go 原生支持）

故障优化

耦合关系：保证一个子系统发生故障时，不会影响其他系统的正常运行。
审计服务故障时保障数据不丢：消息消费时会动态的记录匹配到规则的或者超过一定阈值消息的 offset，保证服务被分配到其他节点或者故障服务修复启动时都会从正确的位置消费消息。
数据旁路 kafka 数据不丢：在数据传入到kafka是必须保证半数以上的节点响应此消息时，才进行下面的数据传输。
告警及时感知：kafka 或者 MongoDB 不可用时会秒级别感知，发送告警信息给系统负责人，及时恢复服务。
自动扩容：匹配规则消息存储采用腾讯云 MongoDB，通过后台打通，在存储空间不够时支持自动扩容。
数据顺序性：每个消息在旁路时都会被打上一个时间戳同时消息也是按顺序进入消息队列，在数据读取时按照时间戳顺序读取。

腾讯云MongoDB

腾讯云 MongoDB 特点

设计服务数据存储采用，腾讯云自有的 MongoDB 服务，该产品具备以下特点：

云存储服务，是腾讯云平台提供的面向互联网应用的数据存储服务。
提供了高性能、高可靠、易用、便捷的 MongoDB 集群服务，每一个实例都是至少一主一从的副本集或者包含多个副本集的分片集群。
整合了备份、扩容等功能，尽可能的保证用户数据安全以及动态伸缩能力

当然，为了用户的安全考虑，我们所有的数据，都是需要用户主动开启审计的前提下，才会记录流水数据，并对数据进行过滤和存储。

使用云数据库 MongoDB 服务的好处：

安全：提供在线的至少两份数据存储，确保线上数据安全。同时通过备份机制保存多天的备份数据以便于在灾难情况进行数据恢复。
高性能：集中安装专用高性能存储服务器（高内存全 SSD 机型）来支持海量访问。省心：提供 7×24 小时的专业服务，扩容和迁移对用户透明且不影响服务。提供全面监控，可随时掌控 MongoDB 服务质量。