无论您如何选择灾难恢复计划，我们自己的业务系统都必须支持其自身架构的统一。它必须支持数据同步。如果这不兼容，那就特别废话了。 。因此，我计划参加一场双人游戏，第一次从这里开始，当然会涉及分发，而且还有很多技术问题。
结论，你可以直接拖到最后；如果你无法理解，你可以从一开始就看到它。
最近，公共云已经出现了一些重大失误，主要群体和朋友圈已经开始沸腾，但总的来说，声音不超过两个：
单个站点不可靠，必须具备容灾能力。如果发生这种情况，应立即将其删除，因此请返回并构建容灾站点。
鸡蛋不能放在篮子里。简单的云不可靠，必须是阴天。因此，如果是阴天，您必须选择我们的xx云，或者我们可以提供多云xx服务。
我把它放在我的一个讨论小组中。第一个声音是有意识的建构。他很清楚这一点，但想想太简单了。第二种类型的声音基本上是BB，不会移动你的大脑。原因如下。
回到主题，由于第一部分提到主从模式不可靠，那么如何选择呢？并且看到各种各样的技术文章，不是生活或生活，不是在同一个城市，它是不同的，现在它是多云的。这么复杂
我来谈谈我的理解如下：
首先，要清楚这么多名称的含义是什么，然后再看它是否合适。
让我们谈谈相对简单的双重活动（这并不容易，见下文）。实际上，有两个站点同时传输流量。您可以根据用户ID，区域或其他业务属性决定如何共享流量。当网站失败时。当您快速切换到另一个站点（分钟）时，理想情况下，业务基本上是无损或非常小。
这与上面提到的主要和预订设备不同。活动和备用设备的另一个站点不承载任何类型的流量。
在这里，观察最深的，同时交通也该层传输，即流量在统一的网站关闭。所有呼叫都在本地房间完成，或者只有无状态组件（例如应用程序层）处于活动状态。但是，具有数据访问状态和异步消息的组件仍然返回到主站点，并且这两种模式是不同的。
事实上，后者比有源更好/备用如上所述，至少在应用层可以在任何时间使用，但是，当发生故障时，切换数据层是不可缺少的模式。实际上，这需要花费很多时间。与主动和待机模式一样，基本上不可能实践，因为成本太高而数据损坏。 （如果数据层并不复杂，只有几个数据库，这不是一个问题，但在分布式场景，成百上千的实例，成本和成本仍然是非常大的改变）。因此，额外的推荐，如果你想实现有效的双人比赛，你必须确保每个站点独立运行，所有呼叫都通过本地房间和闭环叫，下层可以同步数据。
只是为了达到这个水平，当故障站点不可用，失败的网站上的流量可以从接入层改变到另一个站点，和双活动的效果也可以。
但是，这样做并不意味着我们可以做到这一点。如果您执行类似的架构设计，您将知道有三个关键技术要点：
第一个，在呼叫室的房间。
也就是说，分布式请求不能传送到机房和从机房传送。这是不可接受的。有必要确保当地房间呼叫关闭周期。因此，从分布式服务的路由策略和服务框架，有必要支持这种调用模式。同样，数据访问层和消息组件也支持此功能。
第二，数据的碎片化和一致性。
你为什么要这样做？我们知道系统中数据的准确性，完整性和一致性非常重要。在双重生活场景中，最重要的是数据的一致性。我们不能允许同一记录在同一时间。在更改的情况下，双向同步，如用户事务和支付类型数据，在更改的情况下，我们无法确认哪一方是正确的。
如上所述，这两个站点携带不同的业务在同一时间，这是根据一些商业属性，如用户ID，地理区域等，以分离数据电平，仅部分分配网站内提供固定的用户访问权限。
这保证了单个站点中的同一条数据不会在另一个站点中被修改，并且后续同步可以在一个方向上完成。
因此，这里的关键是数据应该用于碎片。您需要使用中间件分布式数据来设计路由数据接入，在机房读取和写入数据，并以数据的划分，技术门槛和工作量不低。
事实上，如果能够实现这两点，我们常说“单一”架构已经实现。理论上，我们可以选择任何计算机房和区域，并构建系统以提供商业访问。
但实际情况更复杂，因为用户商业系统生成的数据可以被其他系统使用，例如产品库存系统，它涉及消息和异步数据的同步，而数据同步更多这只是一个技术问题，但是一个物理问题，我们将在下面讨论它。
第三是数据同步。
实际上，从同步的角度来看，许多同步工具和开源产品都比较完整，所以这里最大的问题不是技术层面，而是物理层面。
精确度是物理距离延迟的问题。这是一个无法避免的痛苦问题，无论是否生活，或者在同一个城市或不同的地方。
中文
电话咨询
微信咨询
公众号
