数据库防火墙的性能和高可用性分析

写在前面
欢迎关注点赞收藏️留言
️今日好句分享

“在这个世上，除了极稀少的例外，我们其实只有两种选择：要么是孤独，要么就是庸俗。”

 前言

    数据库防火墙，作为数据库的最后一道防御工事，要想真正发挥防护效果，数据库防火墙必须串联在数据库的前端，可以是物理串联或代理连接（逻辑串联），业务系统巨大的流量将经过数据库防火墙。

    按照这样的部署模式，抛开功能不谈，数据库防火墙想要接入业务需要两个基本前提：可以接受的性能和高可用性，而高可用性是最重要的，必须保障业务的安全性、可用性和连续性。

---

 性能分析

    性能主要考虑两方面的影响：延迟和并发。

延迟

   业务操作从指令发出到结果返回之间消耗的时间。一般来说，绝大部分客户的OLTP（线上交易处理）业务要求秒级响应，这个秒级响应包含了所有的业务处理，包括：客户端的处理（比如浏览器）延迟，业务网络延迟，应用服务器处理延迟，数据库网络延迟，数据库处理延迟等。对于数据库防火墙来说，应用服务器处理延迟和数据库处理延迟之间增加了一个数据库防火墙处理延迟。

   如果数据库防护墙的延迟在合理范围内，不会对业务造成任何影响为合格，当然啦，理想化都不会有影响，但是事实上数据库防火墙的加入肯定会对数据库处理产生影响，其影响等同于网络速度下降。现实中只要这个延迟不影响业务操作，不被察觉到，这个安全防护措施还是很有必要的。

并发

   在现实场景中，随着业务并发程度的上升，响应时间下跌是很常见的事情，并发性会严重影响响应延迟，这就要求数据库防火墙需要在处理高并发量的同时保持延迟时间的稳定。

   从性能的角度看，绝大部分情况下1ms以下的延迟都可以接受，对于高并发的复杂业务或者响应苛刻业务会需要更高的延迟性能，要求在500us以下。

**********************

拓展话题——如何实现高并发

    一方面使用高性能硬件平台、内核优化技术，满足高负载环境下的性能要求。

   另一方面想要实现高性能和可扩缩性，核心技术点有四点：

• 极小化每个SQL操作的处理过程

    众所周知，SQL语法分析非常耗时，需要专门进行优化：基于词法和语法分析，对业务系统的SQL语句进行抽象化处理，形成软解析结果，并对SQL语句进行序列化、标签化，这样就只需要对语法特征不一样的SQL语句进行解析，而应用系统中SQL语法特征不一样的SQL语句是有限的，这样，就能够极大的减少应用系统SQL语句的语法解析量。

• 无锁化设计，支撑高并发下的线性性能

    随着系统并发量的增加，互斥锁会成为主要的性能瓶颈点;无锁化的实现方式是必然，必要时可以通过异步处理来提升吞吐量。

• 低延迟网络处理技术

    随着吞吐量的增加，串联的网络处理开销会成为主要的延迟;推荐采用基于Intel DPDK的透明网卡通讯包处理技术，跳过操作系统内核协议栈的处理，实现低延迟。

• 推荐采用经典的多进程机制

    在关系型数据库领域中，最经典的设计要数Oracle数据库的多进程架构，每个数据库的连接会话对应一个独立的Oracle进程来处理，这样的机制为数据库带来了两个典型优势：

1. 高可扩缩性：随着硬件性能的提升，可以实现接近线性的处理性能提升。
2. 高安全性：一个会话(进程)的处理异常，不影响其他会话(进程)。

**********************

 高可用性

    任何用户在安全和业务保障之间都会优先选择业务保障而暂时放弃安全。由此，对数据库防火墙有一个基本的需求就是：在数据库防火墙出现任何故障，包括软件故障，硬件故障等，仍需要保障业务运行不要被中断和影响。

高可用性的关键技术路线

•  采用多重ByPass，保障业务快速恢复

硬件ByPass：通过网卡的ByPass能力，并结合“看门狗”机制，当发生设备断电、操作系统故障、数据库防火墙核心组件僵死等异常情况时，能够快速的自动开启硬件ByPass，重新打通网络连接，保证业务系统在数据库防火墙发生异常后，在几秒内恢复正常。

软件Bypass：云上环境部署的话，一般是产品自身的设计机制会在故障时，不解析流量，直接放行。代理模式下在后台监听多进程，保证网卡、进程和操作系统的正常工作，保障流量异常的情况下的业务系统连续性。

手动Bypass：在应急情况下绕过网络避免异常阻断，终极大招。

• 采用双机HA网络，保障业务连续性

    支持双机主备部署，适应网络高可用部署模式，并通过网络协议和HA跳线进行主备间探测与切换，采用会话同步、策略同步机制，保障双机之间的一致性。

   作为串联接入的数据库防火墙设备，需要能够无缝的适应这样的高可用环境，能够提供全透明(无IP)的串接方式，就好比一根网线，当这根“网线”出现故障，无法连通时，通讯包会被自动串接到另外一条链路上的数据库防火墙设备，从而无缝的继续业务操作。

---

写在最后的话

    因为我们赋予了数据库防火墙更多的期望，能力越大、责任越大。数据库防火墙必须具备一颗强大的心：低延迟、高吞吐量、高可扩缩性能力。

    性能和高可用的问题太专业了，具体技术实现还是有难度的，目前市场数据库防火墙更多的是在运维侧使用，减低对性能和高可用的需求，由此转向开发更多的运维管理功能，下期告诉你数据库防火墙在运维端如何大放异彩。

 参考资料：

http://t.csdn.cn/XmSB2

http://t.csdn.cn/K50Vm

http://t.csdn.cn/8genq

http://t.csdn.cn/2HRHX

因个人水平确实有限，借鉴了其他人写的一些内容，以上内容分享仅供参考和学习，如有侵权，请联系我删除。