什么是BDR

BDR使用 PostgreSQL的逻辑解码功能 来实现低开销的逻辑复制解决方案，大多数用户将希望使用物理复制或者WAL归档来实现冗余，高可用性，备份和PITR，而逻辑复制非常适合于数据集成，数据移动和数据聚合，横向扩展和分布式多主部署。

什么场景适合使用BDR

一般来说，如果某一批数据在某一个数据库节点上进行修改，则比较适合使用DBR。
      具体举例说明:我们假设有一个维护房产资源信息的系统，目前支持三个城市：北京，上海，广州，那么在上海区域登录系统修改上海房源信息的可能性比较大，北京的用户通常也是修改的北京的房源，每个用户都是操作格式区域的数据。
而且 大多数情况是数据在哪里被创建，就在哪里被改变。从市场运营的的角度来看，两个不同区域的用户，在同一时间修改不同区域的 同一条数据 这种情况几乎是不会出现。 除此之外，如果业务场景基本都是Insert操作，很少有update和delete操作，也很适合使用BDR，因为插入式不太可能引起冲突的.
    然而也有一些不好的场景，如果强一致性是业务的模板，比如 秒杀，抢红包，这种情况下，BDR就不是一个很好的选择，应该通过应用程序解决相关的问题。
     BDR可以有效地写数据，但是他无法提升写入的性能，BDR本身需要现在的当前服务器节点写入完成以后才能进行其他服务节点的同步， 如果你需要找一个提升服务写入性能的方案，那么PL/Proxy可能是一个更好的选择。

BDR和基于触发器的复制之间的区别

PostgreSQL有许多基于触发器的逻辑复制解决方案，包括 Londiste， Slony-I和 Bucardo。它们已经成熟，使用广泛并且功能强大，并且像BDR一样，它们具有逻辑复制的优点和缺点。

所有基于触发器的复制解决方案都有固有的写放大功能，其中对数据库的每次写都会对复制日志表产生相应的写。
    原始写入和对复制日志的写入都记录在WAL以及堆中，因此每次写入实际上发生四次。通过读取和处理用于复制数据的WAL以复制BDR可以避免这种写放大，因此对BDR复制的数据库的写入仅被写入两次-就像PostgreSQL上的其他持久写入一样。
     此外基于触发器的复制还需要在发送和/或接收端进行外部守护进程。BDR在PostgreSQL本身内部运行其管理过程，因此没有单独的复制过程需要管理。

BDR数据设计过程的问题，解决冲突

BDR是一种松散耦合的无共享多主设备设计，这些趋向于使所有节点对于外部客户端而言似乎都是同一虚拟数据库的一部分，并具有跨节点锁定，事务隔离等功能。

• 使用BDR的应用程序可以自由地写入任何节点，只要它们谨慎地防止或处理冲突即可。
• 如果节点出现故障或出现网络问题，则无需复杂地选举新的主服务器。无需等待故障转移。每个节点始终是一个主节点，并且始终可以直接写入。
• 该应用程序可以在地理上分布，以便该应用程序与数据和用户接近，以获得更好的性能和可用性。可以在本地满足读取要求。
• 应用程序可以容忍分区：即使应用程序与某些或所有其他节点失去通信，应用程序也可以保持正常运行，然后在恢复连接时自动重新同步。

由于BDR是异步复制的，因此并非所有节点在任何给定时刻都具有相同的数据视图。在单个节点上，可以确保已提交的事务的更改对于新启动的事务立即可见。
   在BDR中情况并非如此-如果您提交的事务更改了一个节点上的行，则进行SELECT另一节点上的该行，您可能仍然会获得旧值。此外 锁定操作不会复制到其他节点。如果将行或表锁定在一个节点中，则其他节点不知道将其锁定在其他位置。
     由于异步复制和缺少全局锁定，因此如果两个事务都在单个节点上运行，则不同节点上的事务可能会执行无法执行的操作。这些被称为冲突，BDR可以使用简单的last-update-wins策略或使用用户定义的冲突处理程序来解决冲突。
     BDR提供了一些工具来帮助简化应用程序设计，比如分布式序列。每个节点不是被赋为一个值而一系列值，然后，这些值可以被使用，直到下一个系列值被分配