作为一名技术人员，文本造诣远低于代码控制，作者不擅长用华丽的藻类表达数据库防火墙的责任，在大多数人看来，它只是一个冷盒子，但作者仍然希望依靠有限的语言能力，用技术人员的思维告诉你这样一个盒子的自我进步。
实现高可用性，解决数据库防火墙最基本的问题“人生”可以说成功不到一半，下一个人生挑战随之而来:高性能和可扩展性。
在这里，有必要介绍数据库防火墙与传统 *** 防火墙的根本区别：
1.深度协议分析和内容分析的复杂性挑战
传统 *** 防火墙：通常只分析 *** 层的包头和部分协议特征，不深入分析通信包，一般不分析应答包。
数据库防火墙：对数据库通信协议的请求包和应答包（双向包）进行深入分析：
1、对于请求包，需要分析出包中的要求SQL语句、参数化语句、参数值、跟踪语句游标。
2、对于应答包，需要分析返回字段信息、结果集、应答信息等。
3、对于SQL句子需要词法和语法分析(下一篇文章将介绍为什么需要语法分析，而不是简单的关键词匹配)。
4、对于参数值和结果集，需要格式转换，并根据策略过滤必要的内容。
显然，通信包的处理工作量差异很大。面对这样的工作强度，我们必须给数据库一个强大的防火墙“心”，对其进行逻辑优化和性能优化可以实现低延迟，保证数据库操作的高吞吐量要求。
二是核心业务数据库的高吞吐量和扩展挑战
与以银行、保险、电信为代表的大型企业、以税务、海关、航空为代表的行业、以快递为代表的新兴领域相比，WEB应用服务器集群，数据库服务器基本上使用少量的高端设备来支持大规模的核心应用程序RAC集群或分布式数据库集群，大多数核心业务场景都是由非常高端的小型机器建造的，通常是数百甚至数百个CPU，几百GB内存，高端磁盘阵列，支持强大的数据库事务吞吐量(TPS)。
在这种情况下，串联数据库防火墙面临“小马拉大车”在这种情况下，高吞吐量和可扩展性的挑战有多严重？以下两个例子充分体现：
首先，介绍数据库防火墙的实际经典案例：
数据库防火墙经典案例 拓扑图
在这个经典案例中，业务系统采用两套RAC节点负载均衡(双活)运行，常规稳定运行，单套RAC节点的性能指标要求如下：
当一路 *** 环境出现故障时，原散在2套RAC节点上的压力将集中在数据库防火墙上，即在异常情况下，单个数据库防火墙面临吞吐量和会话压力的两倍，通信包的延迟仍需保持在50微秒以内。
另一个想说的案例是，到目前为止，数据库防火墙面临着***端性能案例：
数据库防火墙高端案例 拓扑图
在这种情况下，数据库集群的整体性能需求是：
折合到单个DBFirewall考虑到设备故障，设备需要支持的性能指标：
三、高性能和可扩展性解决方案
通过介绍这两个经典案例和高端案例，我相信不用说，我们已经能够感受到数据库防火墙必须有一颗强大的心：低延迟、高吞吐量、高可扩展性。
我们设定了这一目标，下一步就是制定具体的解决方案，核心技术点有四个：
1.极小化每个SQL操作处理过程
众所周知，SQL语法分析非常耗时，需要特别优化：基于词法和语法分析，业务系统SQL抽象处理句子，形成软分析结果SQL语句序列化、标签化，只需对语法特征不同SQL在应用系统中分析句子SQL语法特征不一样的SQL语句有限，可以大大降低应用系统SQL句子的语法分析量。
2.无锁设计支持高并发性的线性能
随着系统并发量的增加，相互排斥锁将成为主要的性能瓶颈；无锁实现是不可避免的，必要时可以通过异步处理来增加吞吐量。
3.低延迟 *** 处理技术
随着吞吐量的增加，串联的 *** 处理开销会成为主要的延迟;推荐采用基于Intel DPDK透明网卡通信包处理技术，跳过操作系统核协议栈处理，实现低延迟。
4.推荐采用经典的多进程机制
在关系数据库领域，最经典的设计是Oracle数据库的多过程架构，每个数据库的连接对应一个独立的会话Oracle该机制为数据库带来了两个典型的优势：
高可扩展性：随着硬件性能的提高，可以提高接近线性的处理性能。
高安全性:会话(过程)处理异常，不影响其他会话(过程)。
安华金和数据库防火墙是基于上述四项核心技术设计开发的成熟数据库防火墙产品，已通过社会保障、金融、运营商等高端行业的验证。
到目前为止，数据库防火墙的自我修养之二——在介绍了高性能和可扩展性后，欢迎用户继续关注数据库防火墙的自我修养系列文章。
名词术语解释
[1]DPDK：全称Data Plane Development Kit，是intel开发的x86芯片上用于高性能 *** 处理的基础库；是数据包转发处理套件；适用于 *** 数据包分析、处理等操作；多核操作可以提高大数据包的转发性能。
版权声明
本文仅代表作者观点，不代表本站立场。
本文系作者授权发表，未经许可，不得转载。
