1 解决方案

一个直截了当的方案是，我们可以利用Redis，MQ中间件的数据缓存，内容分发等功能，作为缓存站和中转站分担数据库压力。

分布式数据库管理系统 将单个逻辑数据库划分到多个物理资源中。
应用程序（通常）不知道数据被拆分到单独的硬件上。

该系统依赖于技术和来自单节点 数据库管理系统 的算法，支持分布式中的事务处理和查询执行环境。

设计分布式数据库管理系统的一个重要目标是容错（即避免单个或一个节点故障导致整个系统瘫痪）。

2 并行和分布式 数据库管理系统 之间的区别。

• 并行集中式数据库：

    • 节点在物理上彼此靠近。
    • 节点通过高速 LAN（快速、可靠的通信结构）连接。
    • 假设节点之间的通信成本很小。因此，人们无需担心
  

关于设计内部协议时节点崩溃或数据包被丢弃。

• 分布式数据库：

    • 节点之间可能相距很远。
    • 节点可能通过公共网络连接，这可能很慢且不可靠。
    • 通信成本和连接问题不容忽视（即节点可能会崩溃，数据包可能会被丢弃）。
  

数据库管理系统的系统体系结构指定 CPU 可以直接访问哪些共享资源。

它影响CPU 如何相互协调，以及它们在数据库中检索和存储对象的位置。

单节点数据库管理系统 使用所谓的共享一切架构。

此单个节点在具有自己的本地内存地址空间和磁盘的本地 CPU 上执行工作线程。

3 数据库共享内存

分布式系统中共享一切体系结构的替代方法是共享内存。

CPU 有权访问通过快速互连到公共存储器地址空间。CPU 也共享同一个磁盘。

实际上，大多数DBMS不使用此体系结构，因为它是在操作系统/内核级别提供的。

它还会导致问题，因为每个进程的内存范围是相同的内存地址空间，可以修改通过多个进程。

每个处理器都有所有内存中数据结构的全局视图。处理器上的每个 DBMS 实例必须“知道”其他实例。

4 数据库共享磁盘

在共享磁盘架构中，所有 CPU 都可以通过互连直接读取和写入单个逻辑磁盘，但每个人都有自己的私人记忆。这种方法在基于云的 DBMS 中更为常见。

数据库管理系统 的执行层可以独立于存储层进行扩展。

添加新的存储节点或执行节点不会影响数据在其他层中的布局或位置。

节点必须在它们之间发送消息以了解其他节点的当前状态。

也就是说，由于内存是本地，如果数据被修改，则在数据片段位于其他 CPU 的主内存。

节点有自己的缓冲池，被视为无状态。节点崩溃不会影响数据库，因为它单独存储在共享磁盘上。

5 数据库不共享任何内容

在无共享环境中，每个节点都有自己的 CPU、内存和磁盘。节点仅通信通过网络相互交流。

在此体系结构中增加容量更加困难，因为 管理系统 必须物理移动数据到新节点。

以确保数据库管理系统 中所有节点的一致性也很困难，因为节点必须在事务状态上相互协调。

然而，好处是没有共享任何东西，数据库管理系统有可能实现更好的性能，并且比其他类型的分布式数据库管理系统体系结构。

分布式数据库管理系统旨在保持数据透明度，这意味着用户不应该被要求知道数据的物理位置，或表的分区或复制方式。

数据如何形成的详细信息存储对应用程序隐藏。

换句话说，在单节点数据库管理系统 上工作的 SQL 查询应该在分布式数据库管理系统上工作相同。

分布式数据库系统必须解决的关键设计问题如下：

• 应用程序如何查找数据？
• 应该如何对分布式数据执行查询？
• 是否应将查询推送到数据的位置？
• 还是应该将数据汇集到一个公共位置以执行查询？
• DBMS 如何确保正确性？

6 小结

即使目前参与开发的项目体量都比较小，数据库性能问题还没有凸显。

但经过压力测试，提前对业务的大体量场景存在的性能障碍有了一定了解，

并且理解数据库管理系统的底层设计思路总是有好处的。