Aerospike 5.2版本采用了新型运算法则，用于传输修改后的bin值，该算法可确保在大多数情况下，仅给用户发送精确更改后的bin。（在Aerospike的数据模型中，Set相当于关系型数据库的“表”，而Bin相当于“列”。）如图1所示，当Aerospike集群使用XDR来进行相互连接时，它们可在脑裂模式下运行，在该模式下，两个系统都允许应用程序进行读写操作。此时，如果同时更新多个集群记录中同一bin的副本，就可能导致数据出现永久性不同步的现象。
（图1：Active XDR为永久脑裂模式）
在图2的示例中，写入操作b0和b1的时间相距较远，以至于跨集群的异步复制在下一次写入操作之前就已经完成。但是，如果写入操作b11和b12的相距足够近，就会导致这些操作可进行复制，并在网络上交换了对应的值，那么该bin值在两个群集上将无法同步。这种不同步的情况会一直持续，直到同样的bin在后续进行更新，以恢复同步。大部分依赖数据库的应用程序都不希望出现此类不可预测的问题。
（图2：出现不同步的bin值）
在Aerospike 5.5版本中，我们通过组合的方式来引入bin的融合，该组合可防止并发的更新导致bin出现无限期的不同步现象。为了提供bin值的融合功能，Aerospike会使用基于最后更新时间(LUT)和源id (src-id)组合的冲突检测和解决策略，来标明所发生更新的位置。
Bin的融合可以使用“LWW（最后写入获胜）”模型。该计划的关键组成部分包括：
Bin的每次更新都会生成时间戳（LUT），并将时间戳存储在元数据记录中。
对“bin、时间戳、以及元数据”的更改均是通过XDR链接传送的。
Aerospike 5.5版本通过将存储在该记录本地副本的时间戳值与远程副本中已更新的时间戳值进行比较，再通过使用LWW策略来确定是否覆盖当前数据或保持某个当前存储数据。存储为时间戳的时钟时间是决策的基础；所有集群都将解析为相同的值，从而在所有位置均使相同的值来解决问题。
需要注意的是，由于XDR复制的异步特性，并发写入的调和工作可能不会发生在后续的bin值的读取或写入操作之前。因此，应用程序可能会从最近的写入中读取值，并在调和期间将该值进行覆盖。此外，修复的过程也是异步的，并且无需依赖应用程序的读取或写入来进行操作。只要XDR链接正常运行，就可以保证在有限的时间内进行故障修复。
为bin的更新方案启用融合功能（例如图3）后，值b12已经胜出b11，并且新值b12可以相当快的在两个集群之间进行融合。此过程增强了用户体验的可预测性，因为在融合操作进行之后，读取返回至任何副本的bin值将变得相同。当XDR链路启动后，融合操作将发生在接近两个集群之间的网络延迟间隔内。需要注意的是，网络延迟可能在几毫秒至几百毫秒之间，具体时间取决于集群中不同XDR链接的位置距离。
（图3：冲突检测和解决方案示例）
需要注意的是，即使源集群和目标集群的节点位置相距较远，他们的时钟时间依然是融合算法的基础。假设在同一bin的更新中，参与更新的多个节点之间的时钟偏移是稳定的（即，不同节点中的时钟以相同的速率向前移动，并时刻保持相同间隔）。在这种情况下，系统可以容忍时钟偏移的情况。但是，这种偏移也意味着发生冲突时，在对帐过程中，由落后的节点进行的写入操作会出现数据丢失。此外，这部分集群也将拒绝客户端的写入记录操作。
部署XDR bin的融合，需要引入三个新的配置参数：
ship-bin-luts：必须在XDR源节点上启用此选项以实现bin的融合。当启用后，XDR将发送该bin值的上次更新时间（LUT）。在尝试解决网格冲突时，这些LUT值是较为必要的。
flict-resolve-writes：必须在XDR目标节点上启用此选项以实现值的融合。当启用后，可以存储该bin值的上次更新时间。
src-id：允许的值的范围为1-255。为了实现bin的融合，此参数需要满足该范围值数。并且需要在XDR中选择一个唯一值，用于打破可能与上次更新时间有关的bin值的联系。
关于Aerospike
Aerospike 克服了看似不可能消除的数据瓶颈，以可以降低基础架构复杂性、减少传统 NoSQL 数据库成本的功能优势，在与其他数据库的竞争中获得了众多公司的认可。Aerospike 使客户能够立即打击欺诈行为，它大大增加了购物车的大小，部署了全球数字支付网络，为数百万客户提供了即时的一对一个性化服务。
点击阅读全文，获取更多信息
