CN107077492A - 可扩展的基于日志的事务管理 - Google Patents

可扩展的基于日志的事务管理 Download PDF

Info

Publication number
CN107077492A
CN107077492A CN201580056687.3A CN201580056687A CN107077492A CN 107077492 A CN107077492 A CN 107077492A CN 201580056687 A CN201580056687 A CN 201580056687A CN 107077492 A CN107077492 A CN 107077492A
Authority
CN
China
Prior art keywords
write
node
record
affairs
dag
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201580056687.3A
Other languages
English (en)
Other versions
CN107077492B (zh
Inventor
A·H·沃姆伦
P·S·珀尔
T·A·拉斯
T·D·科尔
K-K·穆尼斯瓦麦-雷迪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amazon Technologies Inc
Original Assignee
Amazon Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/482,677 external-priority patent/US9323569B2/en
Priority claimed from US14/482,661 external-priority patent/US9519674B2/en
Priority claimed from US14/482,668 external-priority patent/US10303795B2/en
Application filed by Amazon Technologies Inc filed Critical Amazon Technologies Inc
Publication of CN107077492A publication Critical patent/CN107077492A/zh
Application granted granted Critical
Publication of CN107077492B publication Critical patent/CN107077492B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2315—Optimistic concurrency control

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

分区存储组的第一事务管理器基于第一冲突检测操作而存储多分区事务的第一写入的第一有条件提交记录。第二事务管理器基于第二冲突检测操作而存储所述事务的第二写入的第二有条件的提交记录。所述存储组的客户端侧部件确定两种写入均已经被有条件地提交，并且将无条件提交记录存储在提交决定储存库中。写入应用器在将所述第一写入传播至所述第一分区之前检查所述第一有条件的提交记录和所述无条件提交记录。

Description

可扩展的基于日志的事务管理
背景技术
近年来，越来越多的计算应用实施在分布式环境中。给定的分布式应用可例如利用散布在提供商网络的若干数据中心之间的多个物理和/或虚拟服务器，并且可为许多不同国家中的客户服务。随着给定应用中所涉及的服务器的数目增加，和/或随着所述应用网络的复杂性增加，不可避免地更高频率地遭遇各种类型的失效事件(诸如进程或服务器的明显或实际失效、网络消息延时的实质延迟、或服务器对之间的连接性丢失)。分布式应用的设计者因此面临这样的问题：在响应于应用配置状态的变化的同时尝试维持高水平的应用性能(例如，用于应用请求的高吞吐量和低响应时间)。
用于管理状态信息的一些传统技术可涉及锁定所述状态信息来以一致方式实施应用状态变化。遗憾的是，用于应用状态和/或数据的锁定机制自身可随着应用的大小和复杂性增加而常常变成性能瓶颈。其它技术可避免锁定，但是可能必须暂停正常操作以在应用的部件之间传播改变的状态信息。然而，这类“停止一切(stop-the-world)”时段可能成问题，尤其对于用于散布在全世界不同时区中的数百或数千客户所使用的任务关键型工作负载的延时敏感的应用来说。甚至避免锁定和停止一切暂停的一些技术也可在处理极高速率的状态转变时陷入瓶颈。
附图说明
图1示出了根据至少一些实施方案的示例性系统环境，其中建立复制节点的动态DAG(有向非循环图)用于管理应用状态变化。
图2a-图2h共同示出了根据至少一些实施方案的操作的示例性顺序，所述操作可在复制DAG处响应于检测到DAG节点中的一个可能已经失效而被执行。
图3示出了根据至少一些实施方案的可在动态复制DAG处生成的应用状态记录和DAG配置增量消息的示例性部件。
图4示出了根据至少一些实施方案的示例性复制DAG，其成员节点跨提供商网络的多个可用性容器分布。
图5示出了根据至少一些实施方案的示例性配置，其中多个复制DAG的节点可以多租户方式在单个主机处实施。
图6是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于接收到状态转变请求而在复制DAG的接受者节点处执行。
图7是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于接收到已批准的状态转变消息而在复制DAG的中间节点处执行。
图8是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于接收到已批准的状态转变消息而在复制DAG的提交者节点处执行。
图9是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在复制DAG的配置管理器处执行。
图10是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于从配置管理器接收到配置增量消息而在复制DAG的成员节点处执行。
图11a-图11h共同示出了根据至少一些实施方案的操作的示例性序列，所述操作可在协调的暂停程序期间在复制DAG处执行。
图12是示出根据至少一些实施方案的操作的方面的流程图，所述操作在协调的暂停程序期间在状态复制组(诸如复制DAG)的提交者节点处执行。
图13是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在协调的暂停程序期间在状态复制组(诸如复制DAG)的非提交者节点处执行。
图14是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在协调的暂停程序期间在状态复制组(诸如复制DAG)的配置管理器处执行。
图15示出了根据至少一些实施方案的示例性系统环境，所述系统环境包括支持可包括对多个数据存储区的写入的事务的持久性改变日志。
图16示出了根据至少一些实施方案的使用复制DAG的持久性改变日志的示例性实施。
图17示出了根据至少一些实施方案的可由日志记录服务的客户端递交的事务请求描述符的示例性部件元素。
图18示出了根据至少一些实施方案的在基于日志的事务管理器处进行的读取-写入冲突检测的示例。
图19是示出根据至少一些实施方案的可在日志记录服务处执行的控制平面操作的方面的流程图。
图20是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于从客户端接收的事务请求而在日志记录服务处执行。
图21示出了根据至少一些实施方案的可用于实现各自的特殊情况一致性目标的事务请求描述符的示例。
图22示出了根据至少一些实施方案的强制执行与在基于日志的事务管理器处接收的事务请求相关联的重复删除约束的示例。
图23示出了根据至少一些实施方案的强制执行与在基于日志的事务管理器处接收的事务请求相关联的排序约束的示例。
图24示出了根据至少一些实施方案的包括多个逻辑约束描述符的事务请求描述符的示例。
图25是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于指示一个或多个逻辑约束的事务请求而在日志记录服务处执行。
图26示出了根据至少一些实施方案的示例性系统环境，其中可针对各自的日志协调的存储组实施各自的定价策略。
图27示出了根据至少一些实施方案的单数据存储区和跨数据存储区写入操作的示例。
图28示出了根据至少一些实施方案的在确定日志协调的存储组的定价策略时可能考虑到的因素的示例。
图29示出了根据至少一些实施方案的可用于向实施日志协调的存储组的服务的用户指示定价策略选项的示例性的基于web的接口。
图30是示出根据至少一些实施方案的操作的方面的流程图，所述操作可被执行以确定支持日志协调的存储组的服务处的计费金额。
图31示出了根据至少一些实施方案的在存储系统处的事件的示例性序列，其中对事务接受进行的基于读取位置的冲突检测的使用可导致数据不一致性。
图32示出了根据至少一些实施方案的系统环境，其中响应于读取请求而提供的读取描述符包括读取可重复性验证元数据(RRVM)部件。
图33示出了根据至少一些实施方案的读取描述符的示例性组成部件。
图34示出了根据至少一些实施方案的可在读取描述符被提供给存储系统的客户端侧部件之前应用于读取描述符的示例性变换。
图35示出了根据至少一些实施方案的可导致在存储系统的客户端侧部件处生成候选事务提交请求的事件的示例性序列。
图36示出了根据至少一些实施方案的将写入描述符和读取描述符存储在各自日志中的示例性事务管理器。
图37是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在响应于读取请求而提供读取描述符的存储系统处执行。
图38是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在客户端侧部件处生成候选事务请求的存储系统处执行。
图39示出了根据至少一些实施方案的示例性系统环境，其中可针对存储组的不同分区建立各自的基于日志的事务管理器。
图40示出了根据至少一些实施方案的用于存储组的基于性能的事务管理配置的示例。
图41示出了根据至少一些实施方案的示例性配置，其中可针对给定的数据存储区建立多个基于日志的事务管理器。
图42示出了根据至少一些实施方案的示例性配置，其中多分区提交决定储存库与针对存储组的主分区建立的基于日志的事务管理器的日志共位。
图43示出了根据至少一些实施方案的可在支持多分区事务的存储组处生成的提交请求的示例性组成元素。
图44a和图44b示出了根据至少一些实施方案的提交记录的示例性组成元素，所述提交记录可通过基于日志的事务管理器被存储分别用于单分区事务和多分区事务。
图45是示出根据至少一些实施方案的操作的方面的流程图，所述操作可由客户端侧部件和支持多分区事务的存储组的各自分区的基于日志的事务管理器执行。
图46是示出根据至少一些实施方案的操作的方面的流程图，所述操作可由支持多分区事务的存储组的写入应用器执行。
图47是可在至少一些实施方案中使用的示例性计算装置的方框图。
尽管在本文中通列举若干实施方案和说明性附图的方式描述了实施方案，但是本领域中的技术人员将认识到，实施方案不限于所述的实施方案或附图。应当理解，附图和对其进行的详细描述不旨在将实施方案限于所公开的特定形式，而是相反地，意图在于涵盖落入如由随附权利要求书限定的精神和范围内的全部修改、等同物和替代物。本文中所使用的标题仅出于组织目的，并且不意在用于限制本说明或权利要求书的范围。如贯穿本申请所使用，字词“可”是以许可意义而使用(即，意为具有可能性)，而非以强制意义使用(即，意为必须)。类似地，词“包括(include/including/includes)”意为包括但不限于。
具体实施方式
本发明描述了使用组织为图的复制节点管理分布式应用状态以及部署这类图以实施可用于事务管理的日志记录服务的方法和设备的各种实施方案。根据一些实施方案，可使用布置成有向非循环图(DAG)的多个复制节点来实施用于建立容错分布式应用的复制状态机。在一些实施中，特定复制DAG可包括一个或多个接受者节点；一个或多个提交者节点；零个或多个中间节点，每个沿着复制路径定位，所述复制路径包括从接受者节点通向提交者节点的DAG边；以及零个或多个备用节点，其被配置成在节点失效的情况下快速接管其他类型的节点中的一个的责任。复制DAG的接受者节点、中间节点和备用节点在本文中可被统称为“非提交者”节点。“接受者”、“中间”、“提交者”和“备用”可被统称为DAG节点可假定的角色集。在一些实施方案中，接受者节点也可被称为DAG的“头部”节点，并且提交者节点也可被称为“尾部”节点。
一般来说，在至少一些实施方案中，特定复制DAG的每个节点可负责复制至少一个特定应用的状态信息，例如呈写入到本地磁盘或其他类似存储装置的状态转变记录的形式。应用状态信息可沿着从DAG的接受者节点到提交者节点的一组边传播，在本文中被称为复制路径或提交路径。在DAG内传播的每个状态转变消息可包括指示处理对应的状态转变请求(例如，在接受者节点处)的顺序的各自序列号或逻辑时间戳。可在不同实施方案中使用多种技术中的任一种来实施序列号，例如，可使用由接受者节点维持的简单的N位计数器，或可使用由DAG的管理部件(诸如DAG的配置管理器)生成的单调递增的逻辑时间戳值(不一定与日历钟相关)。当特定状态转变记录到达提交者节点时，例如，在已经沿着复制路径保存状态转变记录的足够数目的副本之后，所述转变可被显式或隐式地提交。关于某个时间点的应用的状态在一些实施方案中可被确定为高达选定序列号的所有提交状态转变的结果的逻辑累积。配置管理器可负责通过异步地将配置增量消息传播到DAG节点(如下所述)而管理DAG配置的变化(例如，当节点由于失效而离开DAG，或者加入/重新加入DAG时)。在一些实施方案中，每个复制节点可实施各自的确定性有限状态机，并且配置管理器可实施另一确定性有限状态机。用于管理DAG配置改变的协议在各种实施方案中可被设计成最大化DAG的可用性或“活性”。例如，在至少一些实施方案中，DAG节点可能无需使它们关于DAG配置的视图同步；因此，用于应用状态转变处理的协议即使在沿着复制路径的节点中的一些关于当前DAG配置具有不同于其他节点的视图的情况下，也可正确地工作。因此，在一个简单的示例性方案中，情况可能为，在假定DAG由顺序为节点A、B、C和D组成(即，复制路径为A至B至C至D)的情况下，DAG的一个节点A继续执行其状态转变处理责任，而另一节点D早已因配置增量消息而被通知节点C已经离开DAG，并且因此已经将D的DAG视图更新为包括改变的路径A至B至D。在至少一些实施方案中，配置管理器可能不需要请求DAG节点暂停对状态转变节点的处理，尽管所述节点关于当前DAG配置的视图是可能不同的。因此，在使用本文所述的类型的复制DAG时，可能不需要在一些状态复制技术中可能需要的“停止一切”配置同步时段的类型。
在多数操作条件下，用于传播DAG配置改变信息的技术可最终在各个成员节点处产生DAG配置的聚合的一致视图，同时最小化或消除与节点失效/退出、节点加入或节点角色变化相关联的任何停机时间。对于至少一些实施方案，可利用状态管理协议的正确性的正式数学证明。在至少一些实施方案中，复制DAG的协议在处理假阳性失效检测时可尤其有效。例如，在上述示例中，节点D可能已经被配置管理器通知节点C已经失效，即使节点C实际上尚未失效。因此，在假阳性失效检测之后，在指示C的退出的配置增量消息在A、B和D处被接收之前的时间间隔中，状态转变仍然可由C(以及由其邻居B和D)正确地处理一段时间，从而使得其状态被复制的应用仍然能够继续前进，尽管进行了假阳性失效的检测。在最终被通知其已经从DAG移除之后，C可向配置管理器指示其事实上可用于服务，并且可被允许重新加入DAG(例如，作为备用节点或在沿着已修改的复制路径的某个其他位置中)。
在一些实施方案中，接受者节点可负责从复制DAG的客户端接收应用状态转变请求；确定特定的所请求的转变是否应被接受用于最终提交；存储所接受的状态转变记录的本地副本；以及沿着DAG的复制路径朝向提交者节点将所接受的状态转变记录传输到邻居节点。取决于使用案例，在一些实施方案中，状态转变记录可包括写入有效负载：例如，如果应用状态包括数据库的内容，那么状态转变记录可包括在对应于状态转变的事务期间写入的字节。接受者节点在至少一些实施方案中也可负责确定或生成所接受的状态转变的序列号。中间节点可负责存储所接受的状态转变记录的本地副本，以及将指示所接受的状态转变的消息沿着通往提交者节点的路径传输/转发到下一节点。提交者节点可将其自身关于状态转变记录的副本存储在本地存储装置上，例如，指示记录已经被提交。指示对应的状态转变已经被提交的记录在本文中可被称为“提交记录”，而指示对应的状态转变已经被接受但还不一定被提交的记录可被称为“接受记录”。在一些实施方案中，并且取决于应用的需求，提交者节点可发起提交响应至请求状态转变的客户端的传输(例如，经由接受者节点)。在至少一个实施方案中，提交者节点可通知沿着复制路径的节点中的一些或全部状态转变已经被提交。在一些实施方案中，当在DAG节点处接收到提交指示时，现在提交的状态转变的接受记录可由对应的提交记录替换，或经过修改使得其现在表示提交记录。在其他实施方案中，给定的DAG节点对于相同状态转变可存储接受记录和提交记录两者，例如，具有各自的序列号。在一些实施中，单独的提交记录集和接受记录集可被存储在各个DAG节点处的本地存储装置中，而在其他实施中，对于给定DAG节点处的给定状态转变可一次只存储一种类型的记录(接受或提交)
配置管理器在一些实施方案中可被指定为DAG配置信息的权威性来源，负责接受DAG配置的变化以及将所述变化传播到DAG节点。在至少一些实施方案中，配置管理器自身可被设计成灵活应对失效，例如作为经由共识共同批准DAG配置改变(诸如移除或添加节点)并且在多个配置管理器存储装置处复制DAG配置的容错节点集群。如由名称“配置增量”所暗指，由配置管理器发送到DAG节点的消息可仅包括对特定变化的指示(例如，由节点加入DAG或离开DAG引起的变化，或DAG的现有节点的角色/位置的变化)，并且无需包括DAG配置整体的表示，或无需列出DAG的全部成员关系。因此可预期配置增量消息的给定接收者基于其目前已经接收到的配置增量消息的特定集或序列而构建其自身关于DAG配置的视图。在一些实施中，序列号也可被指派给配置增量消息，例如以使得配置增量消息的接收者能够确定其是否已经丢失任何早先的配置增量消息。由于配置管理器可能不尝试保证不同DAG节点接收配置增量消息的顺序或相对时序，所以在一些实施方案中，DAG配置的当前视图在不同节点处可不同，至少对于如由上述示例指示的一些时段来说是不同的。
根据一个实施方案，DAG节点响应于配置增量消息采取的动作可基于配置改变是否影响接收者的直接邻居而不同。考虑另一示例性方案，其中DAG在时间点T0处包括接受者节点A、中间节点B和提交者节点C，其中初始复制路径为A到B到C。在时间T1处，DAG的配置管理器DCM1觉察到B已经离开DAG，例如由于明显失效或连接性丢失。DCM1可将各自的异步配置增量消息D1和D2分别发送到其余节点A和C，而不请求状态转变请求处理的任何暂停。如果在A于时间T3处接收到D1之前，C在时间T2处接收到D2，那么A可在某个时间间隔(T3-T2)内继续发送发往B的状态转变消息(尽管在N事实上已经失效的情况下，由A发送的消息可能不由B处理)。类似地，如果在C于T3处接收到D2之前，A在T2处接收到D1，那么在C觉察到B离开DAG之前，C可在某段时间(T3-T2)内继续处理其从B接收的当B失效时处在飞行中的消息。当节点A接收到D1时，如果其尚未与C联系，那么节点A可建立与C的连接作为其在代替较旧的复制路径(A到B到C)的新配置的复制路径(A到C)中的新直接后继者。类似地，当C接收到D2时，其可建立与A的连接(如果A尚未联系C)作为其新的直接前驱者，并且至少在一些实施方案中，C可向A递交重新传输可能已经从A传输到B但是尚未到达C的状态转变记录的请求。例如，在重新传输请求内，C可包括其目前已经接收的状态转变记录的最高序列号HSN1，从而使得A能够重新传输序列号高于HSN1的任何状态转变记录。
在至少一些实施方案中，配置管理器可依赖于健康检测机制或服务来指示DAG节点何时已经明显变得不健康，从而导致从DAG配置移除明显不健康的节点。分布式环境中的至少一些健康检测机制可取决于心跳或可能并非始终作出关于节点健康状态的正确决定的其他较低水平的机制。同时，配置管理器在发送其配置增量消息之前可能不是在固定位置无限期地等待确认实际节点失效；而是其可在确定节点失效的可能性高于某个阈值(例如，80％或90％)之后传输配置增量消息，或使用某些其他启发法来触发DAG配置改变和对应的增量消息。如先前所提及，在复制DAG处使用的状态管理协议可例如通过避免“停止一切”的暂停来减轻对假阳性失效“检测”的负面影响。因此，在采用复制DAG时有可能使用比使用其他状态复制技术的情况下将可接受的更快/更便宜的(尽管可能不太可靠)失效检查机制。
在至少一个实施方案中，可针对复制DAG实施协调的暂停技术。在某些条件下，例如，如果检测到涉及多个DAG资源或节点的大规模失效事件，那么配置管理器可引导DAG的幸存节点停止处理其他状态转变，使其应用状态信息彼此同步，将同步化的应用状态信息存储在各自的存储位置处，并且等待重新激活指令。在一些实施中，在本地保存应用状态之后，DAG节点可每个执行干净关闭和重启，并且在重启之后向配置管理器报告以指示其可用于服务。如果在由配置管理器发布暂停命令之前已经失效的节点报告其可用于服务，那么在一些实施方案中，配置管理器可引导这类节点使其应用状态与(例如，被配置管理器)已知关于应用状态为最新的另一节点同步。配置管理器可等待直到足够数目的节点(a)可用于服务以及(b)关于应用状态是最新的；确定(可能为新的)DAG配置；并且通过将指示DAG配置的重新激活消息发送到配置的成员节点来重新激活DAG。这类受控的并协调的暂停/重启策略可允许在大规模失效事件之后进行比一些实施方案中可能以其他方式实现的更快速并且更可靠的应用恢复。协调的暂停方法也可用于除响应于大规模失效之外的目的，例如，用于对来自多个复制节点的应用状态信息进行快速并行备份/拍照。
上文所述的类型的基于DAG的复制状态机在各种实施方案中可用于管理各种不同的应用。在一些实施方案中，可实施日志记录服务，可在所述日志记录服务处经由使用复制DAG而实施的持久性改变日志的实例来注册用于事务管理的一个或多个数据存储区(例如，关系或非关系数据库)。如下文更详细描述，在一些实施方案中，可由这类基于日志的事务管理器来使用乐观的并发控制机制。日志记录服务的客户端可对一个或多个源数据存储区执行读取操作并且确定在给定事务内其中将(例如，基于读取结果)执行写入操作的一个或多个数据存储区位置。包括读取集、写入集、并发控制要求和/或对事务的逻辑约束的表示的事务请求描述符可被递交到日志记录服务的冲突检测器(例如，与对应的复制DAG的接受者节点相关联的冲突检测逻辑)。冲突检测器可使用先前提交的事务的记录连同事务描述符的内容来确定事务请求是否可接受用于提交。如果事务被接受用于提交，那么可在针对日志建立的DAG的某一数量的复制节点处发起对应的提交记录的复制。插入日志的给定副本中的记录可因此每个表示各自的应用状态转变。许多不同逻辑约束在不同实施方案中可被指定，并且由基于日志的事务管理器强制执行，诸如重复删除要求、事务间提交排序要求等。这类基于日志的事务管理机制在一些实施方案中可实现对多项目事务或多数据库事务的支持，其中例如给定事务的写入集包括多个写入位置，即使基础数据存储区可能不原生地支持涉及一个以上写入的事务的原子性。对应于所提交的事务的写入在至少一些实施方案中可被异步地应用于相关数据存储区，例如，事务已经被提交的记录可在对应写入被传播到目标数据存储区之前在某个时间被保存在持久性改变日志中。持久性改变日志在至少一些实施方案中可因此变成应用状态的权威性来源，其中数据存储区在日志已经记录状态变化之后赶上应用状态。
在各种实施方案中，复制DAG也可用于复制的数据库实例，用于管理高吞吐量数据流，和/或用于分布式锁定管理。在一些实施方案中，复制DAG可在提供商网络内使用以管理虚拟化资源(诸如计算实例)的状态变化。在至少一些实施方案中，除了将所提交的写入传播到注册的数据存储区之外(可经由数据存储区的各自读取接口从数据存储区读取写入的结果)，日志记录服务也可定义并实施其自身的单独的访问接口，从而允许感兴趣的客户端直接从持久性日志实例读取针对给定的客户端应用存储的记录的至少一部分。
示例性系统环境
图1示出了根据至少一些实施方案的示例性系统环境，其中建立复制节点的动态DAG(有向非循环图)用于管理应用状态变化。如所示，在系统100中，被建立用于管理应用160的状态转变的复制DAG 140包括具有三个节点的复制路径：接受者节点110、中间节点112和提交者节点114。此外，在所描绘的实施方案中，DAG 140包括备用节点130，所述备用节点可用于在需要的情况下接管其他节点中的任一者的责任。可针对其他复制DAG部署节点的其他组合，例如对于一些应用，可使用一个以上中间节点，对于其他应用，可不使用中间节点，或者可不建立备用节点。DAG 140的配置的改变可由如下文所述的容错DAG配置管理器(DCM)164协调。
在所描绘的实施方案中，接受者节点110可经由一个或多个编程接口诸如API(应用编程接口)接收应用状态转变请求(STR)150。接受者节点110可使用应用相依的规则或逻辑来接受所请求的转变用于最终提交，或可拒绝请求。如果转变被接受，那么可由接受者节点110生成序列号，例如指示该转变相对于其他所接受的转变被接受的顺序。如上文所提及，在一些实施方案中，序列号可包括针对每个所接受的转变递增的计数器，而在其他实施方案中，可使用由配置管理器提供的逻辑时钟或时间戳值。包括对应序列号的应用状态记录(ASR)172A的集合176A可由接受者节点存储在本地持久性存储装置中。在一些实施方案中，应用状态记录可包括转变接受记录和转变提交记录两者(其中提交记录仅在接受者节点被通知对应的转变由提交者节点提交之后才被存储)。在其他实施方案中，沿着复制路径的至少一些节点可仅存储接受记录。在存储指示接受的状态转变记录之后，接受者节点可沿着复制路径将指示批准的状态转变消息(STM)152A传输到其后继者节点，诸如所示配置中的中间节点112。中间节点可将其自身关于对应ASR 172B的副本连同序列号存储在其本地ASR集合176B中。中间节点可沿着当前复制路径将其自身的STM152B传输到其邻居，例如在所描绘的实施方案中传输到提交者节点114。在至少一些实施中，STM 152可包括哪些节点早已存储ASR的副本的指示，例如，消息152B可向提交者节点指示，指示接受的应用状态记录的各自副本早已分别存储在节点110和112处。
响应于在提交者节点处应用状态记录的足够数目的副本已经被存储的确定(其中足以满足要求的副本的确切数目可为应用160的配置参数)，可提交转变。提交者节点的ASR集合176C在所描绘的实施方案中可包括事务提交的记录(与批准相对)；因此，ASR 172C可指示提交而不仅仅是接受。在至少一些实施方案中，提交者节点116可将指示或通知传输到接受者节点和/或中间节点，指示转变被提交。在其他实施方案中，接受者和/或中间节点可将请求递交(例如，周期性地)到提交者节点116以确定哪些转变已经被提交并且可相应地更新它们的ASR集合。对于一些应用，可能不要求显式提交；因此，可不存储提交指示，并且沿着路径的DAG节点中的每个可仅存储指示接受的各自应用状态记录。在所描绘的实施方案中，提交后的STM 154可从提交者节点传输到备用节点130以使得备用节点能够更新其ASR集合176D(例如，通过存储提交ASR 172D)，使得如果并且在备用节点被激活以代替另一DAG节点时，其应用状态信息匹配于提交者节点的应用状态信息。备用节点跟上最新的所提交的应用状态的事实在一些实施方案中可使得配置管理器能够快速激活备用节点用于其他三种类型的角色中的任一种：例如，作为接受者节点、中间节点或提交者节点。
在所描绘的实施方案中，容错DAG配置管理器(DCM)164可负责根据需要将形式为配置增量消息166(例如，消息166A、166B、166C和166D)的DAG配置或成员资格的变化传播到DAG节点。当给定的DAG节点例如由于失效而离开DAG 140时，例如，对应的配置增量消息166可由DCM 164发送到一个或多个幸存节点。类似地，当新的节点加入DAG时(例如，在从失效恢复之后，或为了增加应用160的耐久性水平)，指示加入事件、加入节点在DAG内的位置和/或赋予加入节点的角色(例如，接受者、中间、提交者或备用)的对应配置增量消息可由DCM传输到DAG的一个或多个当前成员节点。配置增量消息166相对于彼此可为异步的，并且可由它们的目标按任何顺序接收，而不影响应用状态的整体复制。DAG的每个节点可负责独立于其他节点可能具有的配置视图174，基于接收到的配置增量消息，来构建其自身关于DAG配置的视图174。因此，例如，由于在各自节点110、112、114和130处接收的不同配置增量消息的相对顺序和/或时序，在一些实施方案中，配置视图174A、174B、174C和174D中的一个或多个可至少对于某个短时间间隔而不同。在至少一些实施方案中，每个DAG节点可将接收的某一数量的配置增量消息的表示或内容存储在各自的本地配置改变储存库中。在所描绘的实施方案中，DCM 164可能不强制执行由DAG节点进行的应用状态处理的停止一切的暂停，例如，其可允许节点继续接收和处理应用状态转变消息，而不管配置增量消息的时序或基础DAG配置改变。下文参考图2a-图2h讨论DAG节点对配置增量消息作出响应的方式的示例。
应注意，尽管图1示出了具有单个线性复制路径或“链”并且每种类型一个节点的DAG，但是在至少一些实施方案中，复制DAG可包括分支路径和/或每个角色具有多个节点。即，若干接受者节点、中间节点、提交者节点和/或备用节点可在同一DAG中共存，并且DAG的复制路径可包括加入节点(其中接收来自多个前驱者节点的转变请求的节点)或分裂节点(从其发送转变请求到多个后继者节点的节点)。如果接受者节点110或提交者节点116拒绝所请求的状态转变(例如，因为接受者节点确定一组应用特定接受准则未得到满足，或者因为在提交者节点接收到所接受的状态转变请求消息时尚未作出所接受的转变的足够数目的副本)，那么在一些实施方案中，请求转变的客户端可被通知转变未被提交。客户端然后可重新尝试转变(例如，通过递交另一状态转变请求)，或者可决定完全放弃请求。在一些实施中，也可允许中间节点中止转变请求。
图2a-图2h示出了根据至少一些实施方案的操作的示例性序列，所述操作可在复制DAG处响应于检测到DAG的节点中的一个可能已经失效而执行。图2a示出了包括三个节点202A、202B和202C的DAG配置的初始状态。在节点202A处接收状态转变请求(STR)150。所接受的状态转变记录在节点202A处复制(在STR的本地批准之后)和在节点202B处复制(在节点202B接收批准的STM 211A之后)，并且在202C处提交(在节点202C接收到批准的STM 211B之后)。DCM 164可接收指示节点202B已经明显失效的健康状态更新250。关于节点202B的状态的健康状态更新在不同实施方案中可从各种来源的任一者接收，例如从其他节点中的一个(202A或202B)接收、或从DAG外部的健康监测服务(例如，在DAG节点被实例化的提供商网络处建立的通用资源健康监测服务)接收。在至少一个实施中，健康状态更新可由DMC 164自身的子部件生成，诸如监测进程，其周期性地发送心跳消息到DAG节点并且在可接受时间窗内没有接收到某一数量的连续心跳消息的响应的情况下确定给定节点处于不健康状态。
在所描绘的实施方案中，DCM 164可基于健康状态更新而决定节点202B应当从DAG移除，以及新的节点202D应当作为节点202C的后继者添加。新节点可例如包括被提升到活动状态作为DAG的新的提交者节点的备用节点。在决定DAG的新配置(即，DAG现在应当包括复制链202A到202C到202D)以及将新配置的表示保存在持久性储存库中之后，DCM 164可将命令241发布到节点202D以加入DAG作为节点202C的后继者。应注意，至少在一些实施方案中，节点(诸如202B)从DAG的移除可能不一定伴随替代节点的直接添加(尤其在所述移除之后保持在线并连接的DAG节点的数目超过其状态被复制的应用所需的节点的最小数目的情况下)；节点202D的添加仅被示为DCM可对节点失效(或至少明显的节点失效)作出响应的方式中的一种。如图2b所示，情况可为节点202B实际上尚未失效(即，关于202B的失效的健康更新是错误的)。在这类假阳性的方案中，状态转变消息可继续从202A朝向202B传输，并且从202B传输到202C，从而允许应用在DCM 164作出移除决定之后的至少某段时间内继续前进。
在至少一些实施方案中，当节点(诸如202B)从DAG移除并且所移除的节点的直接后继者(例如，202C)仍然在DAG中时，先前指派给所移除的节点的角色可被转移到所述直接后继者。因此，在节点202B离开之后，可使可能已经为提交者节点的节点202C成为中间节点，并且新激活的节点202D可被指定为新的提交者节点。如果所移除的节点没有直接后继者(例如，如果节点202C在所描绘的示例中代替节点202B被移除)，那么在一些实施方案中新激活的备用节点可被赋予指派给所移除的节点的角色。在其他实施方案中，角色可能不以这类依序/线性方式转移，例如，配置管理器可决定应该赋予给定节点哪些角色，而无需考虑节点相对于所移除的节点的相对位置。
在所描绘的实施方案中，在决定节点202B应当从DAG移除之后，DCM 164可将各自的异步配置增量消息242A和242B发送到节点202A和202C。如所示，增量消息中的每个可指示，202B已经离开DAG并且202D已经加入。虽然在所描绘的实施方案中配置的两个变化在单个配置增量消息中被指示，但是在其他实施方案中，对于202B的移除和202D的加入可发送单独的配置增量消息。在所描绘的实施方案中，配置增量消息可仅指示DAG配置的变化，并且可能不包括DAG整个配置的表示。STM可继续从节点202A被引导到节点202B，直到节点202A接收到配置增量消息242A或以其他方式觉察到202B已经离开DAG(例如，由于网络连接的终止)为止。在202B实际上尚未失效的情形中，节点202B可继续处理状态转变请求并且朝节点202C发送消息211B，直到其觉察到其已经从DAG移除(例如，在202A或202C停止与202B通信的情况下)。
由于使用异步消息传送机制来发送配置增量消息242，所以所述消息可在不同时间到达它们的目的地。如果在节点202C接收到配置增量消息242B之前，节点202A接收到配置增量消息242A，那么可实现图2d中所描绘的情形(其中DAG至少暂时包含分支)。响应于消息242A，节点202A可将配置改变的指示保存在本地存储装置中并且停止发送任何其他消息到节点202B。此外，节点202A可确定其新的后继者节点是202C，并且可因此建立与节点202C的网络连接并且开始向节点202C发送新的状态转变消息211C。在所描绘的实施方案中，状态转变处理活动可在DAG的各个节点处继续，即使指示202B的移除的消息一路前进到其余节点。在节点202B被假定为已经失效但是事实上保持发挥作用的情形下，例如，甚至在节点202A得知节点202B已经从DAG移除之后，仍然可在节点202B处从节点202A接收一个或多个飞行中的状态转变消息。在接收到这类飞行中的消息之后，节点202B可复制消息中所指示的状态转变信息在本地存储装置中并且尝试将另一类似STM传输到节点202C。如果节点202C尚未得知节点202B的移除(或至少尚未关闭其与节点202B的连接)，那么节点202C可接收并处理来自节点202B的消息，从而允许应用继续前进，即使节点202B已经由配置管理器从DAG配置移除。
如果在节点202A接收到配置增量消息242A之前，节点202C接收到配置增量消息242B，那么可实现图2e中所示的情形。在接收到消息242B之后，节点202C可停止接收从节点202B发送的新消息(例如，在其与节点202B的连接仍然处在服务中的情况下，通过终止所述连接)。在认识到节点202A是其在DAG路径中的新的直接前驱者之后，节点202C可建立与节点202A的连接。在所描绘的实施方案中，节点202C也可确定最高序列号HSN1(在节点202C处早已接收的批准的STM的序列号之中)，并且发送请求260到节点202A以重新传输202C可能已经丢失的任何批准的状态转变消息(即，具有高于HSN1的序列号的任何批准的STM)。此外，节点202C也可建立与其新的后继者节点202D的连接，并且可开始发送随后的批准的STM211D到节点202D。
在节点202A和202C两者均已经被通知DAG配置改变之后，图2f中所示的DAG的新复制路径(即，202A到202C到202D)可用于新传入的状态转变请求。应注意，由于配置增量消息242的时序，情况可能为：在于节点202A处接收到配置增量消息242A之前，节点202A从节点202C得知配置改变。类似地，在一些实施方案中，节点202C可从节点202A(或甚至节点202D)得知新配置。因此，有关新配置的信息可到达DAG的任何给定节点的方式可存在多种，并且至少在一些实施方案中，DAG节点甚至可在配置增量消息已经到达其所有目标接收者之前开始使用新复制路径的部分。
如图2g中所示，在节点202B已经从DAG移除(例如，由于实际失效或由于假阳性失效检测)之后的某个时间点，节点202B可任选地向DCM 164指示其准备用于服务。在实际失效的情况下，例如，节点202B可最终被修复并且重启并且可在发送“可用于服务”消息280之前执行某组恢复操作。在网络连接丢失的情况下，“可用于服务”消息可在重新建立连接之后被发送。在所描绘的实施方案中，作为响应，DCM 164可决定加回节点202B作为DAG的备用节点。因此，如图2h中所示，DCM可将加入命令282发送到节点202B，并且可分别发送一组新的配置增量消息244A、244B和244C到节点202A、202B和202D以通知它们节点202B的添加。应注意，图2a-图2h中所示的操作序列被提供为示例，并且在各种实施方案中，DAG节点和DCM可响应于节点202B的明显失效而执行不同于图2a-图2h中所示的操作序列的操作序列。例如，在一些实施方案中，没有新节点可添加到DAG作为节点202C的后继者。而且，在一些实施方案中，节点202B在其变成可用于服务之后可能不一定重新加入同一DAG；而是，例如，其可被部署到不同的DAG或者可被保持在可配置新DAG的节点池中。
虽然在图2a-图2h中失效检测被示为触发DAG配置改变，但是，一般来说，在各种实施方案中，许多不同考虑因素中的任一者可导致对DAG配置的修改。例如，应用所有者(或DCM)可决定将节点添加到DAG以增强数据耐久性或出于可用性原因。在一些实施方案中，指示新节点的添加的配置增量消息可以类似于上文所述的移除相关传播的异步方式传播到其他DAG节点，而不要求状态转变处理的“停止一切”的暂停。在一些实施方案中，DAG节点可能出于维护相关原因而必须处于脱机状态，例如，为了进行软件升级、为了排除软件错误、或为了硬件修改。在至少一个实施方案中，DAG配置可因如下确定而改变：在一个或多个节点处的工作负载水平(例如，每秒处理的状态转变的数目)已经达到阈值水平，并且应当使用比当前所用的性能更高(或性能更低)的硬件/软件堆叠。在一些实施方案中，DAG配置改变可涉及改变特定DAG节点的位置或角色，而不一定添加或移除节点。例如，配置管理器可将提交者角色切换到先前为中间节点的节点，并且使旧的提交者节点成为新配置中的中间节点。这类角色改变可被实施(并且对应的配置增量消息被传播)，例如出于负载平衡目的，尤其在其中同一主机用于若干不同DAG的节点的多租户环境中。下文更加详细地描述这类多租户环境。
状态转变记录和配置增量消息
图3示出了根据至少一些实施方案的可在动态复制DAG处生成的应用状态记录(ASR)和DAG配置增量消息的示例性部件。如先前所指示，在至少一些实施方案中，每个表示批准的或提交的状态转变的应用状态记录的副本可被存储在沿着DAG的复制路径的若干节点中的每个处，应用状态记录在本文中也可被称为状态转变记录。如所示，应用状态记录320可包括转变的类型302的指示，例如，所请求的状态转变的批准是否被记录，或者批准的状态转变的提交是否被记录。在一些实施方案中，如先前所述，每个DAG节点可存储批准记录和提交记录两者，而在其他实施方案中，可仅存储一种类型的状态转变记录。例如，在一种情形中，批准记录初始可在非提交者节点处被复制，并且批准记录可在事务最终由提交者节点提交之后改变成提交记录。在至少一个实施方案中，单独的转变类型字段302可不包括在ASR中或导致生成ASR的消息中，而是，转变的类型可由DAG节点基于节点对其当前角色和/或从其接收消息的源DAG节点的角色的认知而推断。例如，接收状态转变消息的非提交者节点可推断消息表示批准的状态转变。
在所描绘的实施方案中，状态转变记录320记录可包括转变数据304。转变数据部件304的内容的性质可取决于其状态被管理的应用而不同。在一些情况下，例如，状态转变请求可包括写入有效负载(指示将被写入的某一数量的字节，以及将被写入字节的地址)，并且写入有效负载可包括在转变记录中。对于其他应用，每个状态转变可指示由应用客户端发布的各自命令，并且所述命令的表示可包括在ASR中。ASR 320也可包括对应于状态转变的序列号306(其也可被认为是逻辑时间戳)。序列号可例如在状态转变请求被批准时在接受者节点处生成，或者在状态转变被提交时在提交者节点处生成。在至少一些实施方案中，使用DAG管理的应用的当前状态可通过按增加序列号的顺序应用(在应用的某个初始状态开始)所提交的状态记录的转变数据(例如，写入有效负载、命令等)来确定。在一些实施方案中，转变的复制历史信息308也可包括在ASR中，例如，指示哪些DAG节点早已经针对相同转变存储各自的ASR，和/或那些记录已经被复制的顺序。在一些实施中，这类复制历史信息可例如由提交者节点使用来确认足够数目的节点已经记录了给定的状态转变用于提交。在一些实施方案中，ASR消息可指示接收对应的状态转变请求的接受者节点的身份，但是无需包括关于沿着复制路径的其他节点的信息。在至少一个实施中，可能不要求提交者节点确认在提交批准的状态转变之前，足够数目的节点已经复制了状态转变记录。
在所描绘的实施方案中，DAG配置增量消息370可指示加入或离开配置的一个节点(或多个节点)的标识符352，以及被实施的改变的类型354(例如，加入对离开)。在一些实施中，关于加入(或离开)节点的角色信息356可任选地包括在配置增量消息中。在至少一些实施方案中，正如应用状态序列号与应用状态转变相关联，配置增量消息可包括DAG配置改变序列号358。这类序列号可由配置增量消息的接收者使用来例如确定接收者是否已经丢失任何先前的配置改变。如果一些配置改变已经丢失(例如，由于网络数据包被丢弃)，那么接收者节点可向DCM发送请求以重新传输丢失的配置增量消息。在各种实施方案中，配置改变序列号358可在DCM处被实施为计数器或逻辑时间戳。在DCM包括具有多个节点的集群的一些实施中，由集群管理器维持的全局逻辑时间戳可被用作配置改变序列号358的源。
提供商网络环境中的复制DAG部署
图4示出了根据至少一些实施方案的示例性复制DAG，其成员节点跨提供商网络的多个可用性容器分布。由实体(诸如公司或公共部门组织)建立以将可经由互联网和/或其他网络访问的一个或多个服务(诸如各种类型的多租户和/或单租户基于云的计算或存储服务)提供给一组分布式客户端的网络在本文中可被称为提供商网络。至少一些提供商网络也可被称为“公共云”环境。给定的提供商网络可包括众多数据中心，所述数据中心托管实施、配置和分布由提供商提供的基础设施和服务所需的各种资源池，诸如物理和/或虚拟化计算机服务器、存储装置、联网设备等的集合。在大型提供商网络内，一些数据中心可位于与其他数据中心不同的城市、州或国家中，并且在一些实施方案中，分配给给定应用的资源可分布在若干此类位置之中以实现期望水平的可用性、容错性和性能。
在一些实施方案中，提供商网络可被组织到多个地理区域中，并且每个区域可包括一个或多个可用性容器，所述容器也可被称为“可用性区”。可用性容器继而可包括一个或多个不同的物理处所或数据中心，所述物理处所或数据中心以给定可用性容器中的资源与其他可用性容器中的失效隔绝的方式设计(例如，具有独立的基础设施部件，诸如电源相关的设备、冷却设备和/或物理安全部件)。可能未预期一个可用性容器中的失效导致任何其他可用性容器中的失效；因此，给定物理主机或虚拟化服务器的可用性配置文件意在独立于不同可用性容器中的其他主机或服务器的可用性配置文件。
在一些实施方案中，复制DAG的一个或多个节点可在不同于DAG的其他节点的可用性容器中实例化，如图4中所示。在所描绘的实施方案中，提供商网络402包括三个可用性容器466A、466B和466C，其中每个可用性容器包括某一数量的节点主机410。可用性容器466A的节点主机410A例如包括DAG节点422A、本地持久性存储装置(例如，一个或多个基于磁盘的装置)430A和代理412A，所述代理可用作用于与DAG客户端通信的前端。类似地，可用性容器466B中的节点主机410B包括DAG节点422B、本地持久性存储装置430B和代理412B，并且可用性容器466C中的节点主机410C包括DAG节点422C、本地持久性存储装置430C和代理412C。在所描绘的实施方案中，DAG节点422(和/或代理412)可每个包括一个或多个执行线程，诸如一组一个或多个进程。在所描绘的实施方案中，本地持久性存储装置430可用于沿着复制路径491存储应用状态信息的本地副本(和/或在复制路径491的DAG节点422处接收的DAG配置增量消息内容)。
图4的实施方案中所描绘的DAG的DCM自身包括跨多个可用性容器分布的多个节点。如所示，可使用基于共识的DCM集群490，包括随DCM存储装置475A位于可用性容器466A中的DCM节点472A，以及随DCM存储装置475B位于可用性容器466B中的DCM节点472B。所描绘的DCM因此可至少就不跨可用性容器边界的失效来说被认为是容错的。例如，与由DCM管理的DAG的成员节点相比，这类容错DCM的节点在本文中可被称为“配置节点”。DAG配置的改变(包括例如节点移除、添加或角色改变)可使用DCM节点472之间的基于共识的协议而被批准，并且在对应的配置增量消息被传输到DAG节点422之前，DAG配置的表示可能必须由多个DCM节点存储在持久性存储装置中。用于DCM和/或用于给定的复制DAG的可用性容器的数目在不同实施方案中并且对于不同应用可不同，例如取决于应用的可用性要求或数据耐久性要求。在一些实施方案中，复制DAG可用于管理在提供商网络处实施的其他服务的资源的配置。例如，在一个实施方案中，由虚拟化计算服务使用的计算实例(虚拟机)或实例主机(物理主机)的状态的改变可使用复制DAG来管理。
图5示出了根据至少一些实施方案的示例性配置，其中多个复制DAG的节点可以多租户方式在单个主机处实施。如所示，三个复制DAG 555A、555B和555C的节点分布在四个DAG节点主机510A、510B、510C和510D之间。一般来说，节点主机在其资源容量上可不同，例如，一个主机的计算资源、存储资源、联网资源和/或存储器资源可与其他主机的那些不同。例如，节点主机510B具有可用于DAG信息的两个存储装置530B和530C，节点主机510D具有两个存储装置530E和530F，而节点主机510A和510C具有一个存储装置(分别为530A和530D)。
主机510A包括DAG 555A的接受者节点522A和DAG 555C的中间节点522N。主机510B包括DAG 555A的中间节点522B、DAG555B的提交者节点522K和DAG 555C的中间节点522O。DAG 555A的提交者节点522C和DAG 555C的提交者节点522P可在主机510C处实施。最后，DAG555A的备用节点522C、DAG 555B的接受者节点522J和DAG 555C的接受者节点522M可在主机510D处实例化。因此，一般来说，给定的主机可用于N个不同DAG的节点，并且每个DAG可利用M个不同主机，其中在至少一些实施方案中，M和N可为可配置参数。在至少一些实施方案中，代表各自的应用所有者建立的若干DAG的节点可以多租户方式实施在同一主机上：例如，对于特定应用的所有者可能不明显的是，用于其应用的状态管理的资源也正用于管理其他应用的状态。在一些提供商网络环境中，可实施放置服务，其选择特定主机以用于给定应用的复制DAG的给定节点。在不同实施方案中，节点主机可基于因素的各种组合而选择，诸如其状态被管理的应用的性能要求、候选主机处的可用资源容量、负载平衡需求、定价因素等等。在至少一些实施中，对每个主机实例化多个DAG节点可帮助相对于在仅实例化单个DAG节点的情况下可实现的利用水平而增加主机处的整体资源利用水平。例如，尤其在用于DAG节点的大部分逻辑为单线程的实施方案中，相比于在单租户情形中，在多租户情形中可并行地使用多核心主机的处理器核心中的更多核心，从而增加了主机的平均CPU利用率。
用于实施基于动态DAG的状态复制的方法
如上文所讨论，在一些实施方案中，复制DAG的给定节点可在给定时间点被赋予多个角色中的一个(例如，接受者、中间、提交者或备用)。图6是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于接收到状态转变请求(STR)而在复制DAG的接受者节点处执行。如元素601中所示，接受者节点可例如从状态复制服务的客户端接收包括应用的STR的消息。在不同实施方案中，STR可包括各种元素，部分取决于应用的性质。例如，在如下文更详细描述的一些实施方案中，DAG可用于对引导在一个或多个数据存储区的事务进行乐观并发控制，并且STR可包括可用于检测与先前提交的事务的冲突的诸如读取集和写入集的数据。其状态转变是使用复制DAG来管理的每个应用对所请求的状态转变可具有其自身的接受准则集，并且至少在一些情况下，STR的内容可用于决定转变是应该被接受还是被拒绝。在一些实施中，操作条件也可或替代地用于接受/拒绝所请求的状态转变，例如，如果在接受者节点或在DAG的其他节点处的工作负载水平处在或高于阈值，那么状态转变可被拒绝。如果转变满足接受准则(如元素604中所检测)，那么可针对接受的STR生成新的批准序列号(元素607)，例如，通过递增计数器值或通过获得某个其他单调递增的逻辑时间戳值。指示转变被批准的记录可与序列号一起被存储在本地存储装置中(元素610)。对于一些应用，转变请求可包括将被复制的数据集(诸如写入有效负载)，接受者节点同样可将数据集存储在本地存储装置中。在一个实施中，接受者节点可包括在提供商网络的特定主机处运行的一个或多个进程，并且转变的批准的记录、序列号和转变的数据集可全部被存储在特定主机的持久性的基于磁盘的存储装置处。在一些实施方案中，转变的数据、转变被批准的指示以及序列号可全部被组合成存储在本地存储装置处的单个对象，诸如插入(附加到)日志中的日志条目。在其他实施方案中，转变的数据集可与指示转变的批准的记录分开存储。
在状态转变的记录被安全存储之后，可沿着DAG的复制路径朝向提交者节点将指示批准的状态转变消息传输到邻居节点(元素613)。在一些情况下，取决于DAG的拓扑，可发送多个这类消息，每个消息被发送到沿着复制路径的每个邻居节点。如先前所述，DAG的每个节点可具有其自身关于DAG配置的视图，所述视图在给定时间点处可能不一定与其他节点的视图一致。在所描绘的实施方案中，接受者节点可将其批准的状态转变消息引导到其关于DAG配置的当前视图中所指示的邻居节点，即使该当前视图从DAG的DCM的角度来看(或从一个或多个其他DAG节点的角度来看)碰巧是废弃的或不正确的。在消息被发送之后，可认为状态转变请求的处理在接受者节点处是完成的(元素619)。如果所请求的转变不满足应用的接受准则(如也在元素604中所检测)，那么可拒绝转变(元素616)。在一些实施中，指示拒绝的通知或响应可被提供给请求者。
图7是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于接收到已批准的状态转变消息而在复制DAG的中间节点处执行。在例如从接受者节点或从另一中间节点接收这类消息STM1(元素701)之后，在一些实施方案中，中间节点可确定具有较低序列号的状态转变消息是否丢失(例如，在STM1具有序列号SN1的情况下，具有小于SN1的序列号的一个或多个STM是否尚未被接收)。如果发现了这类丢失的状态转变消息的证据(元素704)，那么在所描绘的实施方案中，中间节点可任选地将对丢失的STM的重新传输请求递交到沿着当前已知复制路径的直接前驱者节点(元素707)。在一些实施中，中间节点可在将对应于STM1的批准状态转变的记录存储在本地存储装置中之前等待接收对其重新传输请求的响应。STM1的批准记录可被存储，例如与批准序列号和与转变相关联的任何数据集(诸如写入有效负载)一起(元素710)。状态转变消息(其在内容上可类似于所接收的消息，或者在内容上与所接收的消息相同)然后可发送到当前已知复制路径上朝向提交者节点的每一邻居节点(元素713)。在状态转变的批准历史包括在状态转变消息内的一些实施中，中间节点可将其(中间节点的)标识符添加到在传出的状态转变消息中所指示的批准者列表。
在一些实施方案中，代替在将STM1的批准记录保存在本地存储装置中之前检查丢失的序列号的是，可采用不同方法。例如，中间节点可在将批准记录存储在本地存储装置中之后和/或在朝向提交者节点传输对应的STM之后检查丢失的序列号。
在一个实施中，保证在给定连接内消息的有序递送的联网协议诸如TCP(传输控制协议)可结合用于在非接受者节点处接收STM的拉模型来使用。在这类实施中，只要中间节点、提交者节点或备用节点维持与其沿着复制路径的直接前驱者的网络连接，便可依赖联网协议来确保不丢失消息。在这类实施中，如果在给定的DAG节点N1处，与直接的前驱者节点P1的连接丢失，那么N1可负责建立与P1的新连接(或在已经接收到指示P1不再是DAG的部分的配置增量消息的情况下，则建立与不同的前驱者节点的连接)，以及请求P1发送具有高于先前最高接收序列号的序列号的任何STM。
图8是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于接收到已批准的状态转变消息而在复制DAG的提交者节点处执行。在例如从中间节点或从接受者节点接收到批准的状态转变消息(元素801)之后，提交者节点可确定状态转变是否满足应用的提交准则。在一些实施方案中，提交者节点可能能够从STM的内容(诸如批准历史字段)确定目前已经被保存的应用状态记录的副本数目，并且在副本数目超过阈值的情况下，可认为转变是可提交的。副本计数阈值可基于应用而不同；例如，在接受者节点处的单个副本对于一些应用可能是足够的。在其他实施方案中，提交者节点也可能在提交转变之前必须考虑其他因素，诸如提交者节点是否早已接收到具有低于当前STM的序列号的序列号的全部STM。在一个实施方案中，例如，在提交当前转变之前，提交者节点可能必须等待直到其接收并处理所有这类先前STM。
如果提交准则(其在应用之间可不同)被满足(如在元素804中所检测)，那么提交者节点可将其对应用状态记录的集合内的提交记录存储在本地存储装置中(元素807)，例如，与序列号和转变数据集(如果有)一起。在一些实施中，提交准则可默认为在接受者节点处早已经被验证的接受准则，即，一旦状态转变已经在接受者节点处被批准，提交者节点便可提交所接收的STM中所指示的状态转变，而不必验证任何另外的条件。在一些实施方案中，STM中所指示的批准序列号的副本可被存储为提交序列号。由于一些批准的转变可能不被提交，所以在至少一个实施方案中，可使用与用于批准不同的一组序列号来用于提交(例如，使得该序列的提交序列号不具有任何间隙)。如果备用节点被配置用于DAG，那么提交后的STM可从提交者节点引导到一个或多个这类备用节点。在至少一些实施方案中，在转变被提交之后，可将提交通知提供给DAG的一个或多个其他节点(元素810)，例如以使得其他节点能够更新其应用状态信息和/或用于将响应传输到状态转变的请求客户端，来指示转变已经被提交。
在丢失的STM不作为与提交准则有关的处理的部分进行处理的一些实施方案中，提交者节点可采用与图7中关于丢失的STM所指示类似的动作。因此，例如，如果提交者节点确定一个或多个STM丢失(其序列号低于所接收的STM的序列号)(元素813)，那么可将对丢失的STM的重新传输请求发送到直接前驱者节点(元素816)以完成对所接收的STM的处理(元素822)。如果提交准则未被满足，那么提交者节点可中止状态转变(元素819)。在一些实施方案中，可将中止通知发送到DAG的一个或多个其他节点，和/或发送到请求状态转变的客户端。在一些实施中，如上文所提及，如果状态转变已经在接受者节点处被批准，那么复制DAG可负责(最终)提交状态转变，即使复制路径的一个或多个节点(包括接受者节点自身)失效。在一些这类实施中，中止状态转变可要求相对重量级的改变，诸如从其他DAG节点移除转变的批准记录(或从恰巧存储批准记录的节点的DAG的实际移除)。如下文关于图11a到图14更详细地描述，先行的协调的DAG暂停技术在一些实施方案中可用于避免STM到达提交者节点而没有将对应的状态转变信息复制在期望数目的DAG节点处的情形。
图9是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在复制DAG的配置管理器(DCM)处执行。如元素901中所示，可由配置管理器检测可能潜在地触发DAG处的配置改变的事件。这类事件可包括接收消息诸如“检测到节点失效”(例如，从DAG节点，或从提供商网络的健康管理部件)或“可用于服务”(例如，从失效之后已经重启的DAG节点)。在一些实施方案中，配置管理器自身可负责监测各种DAG节点的健康状态，并且触发事件可为配置管理器进行的检测：所述节点中的一个尚未以及时方式对某一数量的心跳消息或其他健康检查作出响应。在至少一些实施方案中，DAG节点可负责向DCM报告任何明显的节点失效(例如，当连接意外丢失时，或当在大于阈值的时间段内没有从邻居节点接收到消息时)。在一些实施方案中，DAG节点也可负责向DCM通知可导致DAG配置改变的即将发生的改变(诸如当节点被排程为脱机以进行维护时)。在所描绘的实施方案中，例如，基于可在DCM集群的多个节点之间实施的共识协议，DCM可确定所指示的配置改变(例如，失效节点的移除、或新节点的加入)是否变得有效(元素904)。例如，在一些实施中，由一个DCM节点作出的DAG节点已经失效的确定可在节点从配置移除之前必须在集群的一个或多个其他节点处被确认(例如，通过在其他DCM节点处审查从DAG节点接收的心跳响应)。在其他实施中，关于是否应用可能的配置改变的决定可在不利用基于共识的协议的情况下执行。在一些实施方案中，可确定或生成与DAG配置改变相关联的序列号或逻辑时间戳，例如以包括在发送到DAG的其他节点的配置增量消息中，使得配置改变可在DAG节点处按正确顺序被处理。
无关于配置改变如何被批准，在一些实施方案中，配置改变的表示可能必须在认为改变完成之前在DCM的多个存储位置处被复制(元素907)。在DCM将用作DAG配置信息的权威性来源的实施方案中，将关于配置改变的信息保存在多个位置中可为DCM功能性的重要方面。在至少一些实施中，仅可复制配置的改变(而非例如整个配置)。在配置改变信息已经被保存之后，可标识对应的配置增量消息(指示对配置刚刚实施的改变，不一定是DAG的整个配置)从DCM将发往的一组DAG节点(元素910)。在一些实施方案中，可选择所有DAG成员(潜在地包括作为配置增量消息中所指示的配置改变的部分从DAG移除的节点)作为配置增量消息的目的地。在一个实施方案中，可仅选择被假定为当前DAG成员的节点，例如，配置增量消息在节点被移除或已知节点已经失效的情况下可能不被发送到所述节点。在其他实施方案中，可选择成员的某个子集作为目的地，并且该子集可负责将配置改变传播到其余节点。在成员子集被选择为目的地的实施方案中，DCM可能必须在任何给定时间记载哪些改变已经被传播到哪些成员。在已经标识DAG节点的目的地集合之后，各自的配置增量消息可相对于彼此被异步地发送到节点，并且不需要请求状态转变消息处理或状态转变请求处理的任何暂停(元素913)。在至少一些实施方案中，配置增量消息可包括与配置改变相关联的配置序列号。在一些实施中，复合的配置增量消息可指示两个或更多个改变(例如，失效节点的移除和替换节点的加入)。
图10是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于从配置管理器接收到配置增量消息而在复制DAG的成员节点处执行。在从DCM接收到包括配置改变序列号的这类配置增量消息(元素1001)之后，在所描绘的实施方案中，接收者DAG节点可确定其是否已经丢失任何先前的配置增量消息，例如，通过比较新接收的序列号与先前接收的最高序列号。如果接收者确定一个或多个配置增量消息尚未被接收(元素1004)，那么其可发送配置刷新请求到DCM(元素1007)。这类刷新请求可导致DCM重新发送一个或多个丢失的配置增量消息，例如，或者导致发送指示DAG的整个当前配置的不同类型的消息。
如果没有检测到丢失的配置增量消息(同样在对应于元素1004的操作中)，那么接收者节点可将所接收的配置改变信息存储在本地存储装置中的配置改变储存库中。储存库中所累积的消息可用于更新DAG配置的接收者视图(元素1010)。更新DAG配置的本地视图可包括例如确定将用于未来传出和传入的状态转变消息的一个或多个复制路径的一个或多个DAG节点和/或边。如先前所提及，由于消息递送的异步性质并且因为网络的不同部分可经历不同延迟，所以在一个DAG节点处获得配置增量消息的序列可不同于在另一节点处接收同一组配置增量消息的序列。因此，在给定时间点在两个不同节点处标识的复制路径可彼此不同。在所描绘的实施方案中，如果接收者节点在复制路径上的直接前驱者节点已经改变，或者其直接后继者已经改变，那么接收者节点可采取其他动作。如果直接后继者和直接前驱者节点均不改变，那么在一些实施方案中，对配置增量消息的处理可在将配置改变信息存储在接收者节点的本地存储装置处之后结束(元素1027)。
直接前驱者节点相对于DAG的节点C改变的情形的示例是复制路径的部分从A到B到C向A到C的改变。如果更新的配置涉及接收者的直接前驱者节点的改变，并且尚没有直接从新直接前驱者节点接收到消息(如在元素1013中所检测)，那么接收者节点(在当前示例中为节点C)可建立与新直接前驱者(在当前示例中为节点A)的连接。此外，在至少一些实施方案中，接收者节点(例如，节点C)也可将请求发送到新直接前驱者(例如，节点A)以重新传输序列号高于接收者节点处的最近接收的序列号的STM(元素1017)。如果节点C具有后继者节点，那么节点C可在其等待从节点A接收所请求的重新传输时继续传输任何待决状态转变消息到这类后继者节点。
如果配置增量消息指示接收者的直接后继者节点已经改变，(例如，当节点A接收上文所讨论的相同示例性配置增量消息时，所述消息指示节点B已经离开DAG)，并且尚未从新的直接后继者节点接收到消息(元素1021)，那么接收者节点可建立与新的后继者节点的连接。在上述示例中，节点A可建立与节点C(其新的直接后继者)的连接。状态转变消息可依序传送到新的直接后继者(元素1024)。
复制DAG节点的协调暂停
对于提供商网络运营商，可能引起大量应用的接近同时停机的大规模失效事件呈现重大挑战。其应用受到持续停机影响的客户可能不再相信提供商网络提供关键应用所需的服务水平的能力。虽然大规模失效事件的可能性可通过智能基础设施设计以及通过实施可利用基础设施的高可用性特征的应用架构而降低，但是仍然不可能完全消除大规模失效。在至少一些实施方案中，可因此开发可允许分布式应用从影响多个资源的失效更快速且干净地恢复的技术。在上文所述的类型的复制DAG被用于分布式应用状态管理的一些环境中，协调的暂停协议可用于支持从分布式失效更有效且高效的恢复。在一个实施方案中，例如，响应于对失效情形的检测，DAG的某一数量的节点可由配置管理器引导以停止执行其正常的应用状态转变处理操作(例如，接收状态转变请求消息、存储应用状态信息的本地副本以及沿着其复制路径传输状态转变请求消息)。在暂停其操作之后，在至少一些实施方案中，节点可使其本地应用状态记录与其他DAG节点同步，执行干净关闭以及重启。在节点重启之后，其可向配置管理器回报其可用于服务恢复，并且等待通过配置管理器重新激活DAG。
图11a-图11h共同示出了根据至少一些实施方案的操作的示例性序列，所述操作可在这类协调的暂停程序期间在复制DAG处执行。所示DAG中的每个节点可存储一组各自的提交记录，其中每个提交记录包括(或指示，例如经由指针)对应的提交序列号(CSN)。从节点的角度来看，本地提交记录集可因此表示使用DAG管理的应用的状态。批准的(但尚未提交的)状态转变的记录也可被保持在一些节点或全部节点处，如先前所述。应注意，虽然协调的暂停技术在本文中是在动态复制DAG的背景下进行描述，在所述动态复制DAG中，DCM传输如上文所述的配置增量消息以保持DAG节点关于DAG配置改变而更新，但是在一些实施方案中，类似的方法可用于其他状态复制技术。例如，协调的暂停技术也可用在这样的环境中：其中一组复制节点的配置改变使用以同步化方式更新所有节点的停止一切的重新配置时间间隔而实施，使得复制组仅在已经使所有节点觉察新配置之后才变成可操作的。因此，动态复制DAG可仅表示在不同实施方案中可实施协调的暂停技术的多节点状态复制组(SRG)的一个示例。至少一些这类SRG可具有其自身的类似于先前描述的DCM的配置管理器，并且可具有被指定为提交者节点的一些节点和被指定为非提交者节点的其他节点。
包括五个节点1102A、1102B、1102C、1102D和1102E的复制DAG与DCM 1180一起示于图11a中。在所描绘的示例中，提交者节点1102E包括暂停触发检测器1106，所述暂停触发检测器确定应该发起协调的暂停程序用于DAG。在不同实施方案中，多种不同类型的原因可导致暂停程序的发起。例如，暂停程序可被发起的原因在于：(a)因为某个阈值数目的节点可能已经失效(诸如在节点1102B和1102D处由“X”符号指示的失效)，(b)因为在提交者节点处(或在某个其他节点处)接收配置增量消息的速率超过阈值，(c)因为在某个DAG节点或DCM处丢失网络数据包或连接的比率超过阈值，等等。在所描绘的实施方案中，提交者节点1102E可发送DAG暂停请求1150，所述请求包括提交者节点的提交记录集中所表示的序列号之中的最高序列号。此最高序列号在本文中可被称为最高提交序列号(HCSN)1108，并且可被用作用于在暂停程序的步骤中的一个期间在DAG节点之中使提交记录集同步的参考，如下文所述。在一些实施方案中，可在非提交者节点中的一个处或在DCM 1180自身处作出暂停应当被发起的初始确定，并且特定提交序列号(理想状况下但不一定为HCSN)可被选择为节点应该将其提交记录集更新高达的目标序列号。
响应于接收到暂停请求，DCM 1180可将HCSN保存在持久性存储装置1175中，如图11b中所示。DCM然后可将各自的暂停命令1152发送到至少DAG节点的子集，诸如在所描绘的示例性方案中分别将命令1152A和1152B发送到节点1102A和1102C。在一些实施方案中，DCM1180可根据保存在DCM处的最新DAG配置(包括可能已经失效的节点，诸如1102B和1102D)将暂停命令发送到作为DAG的成员的所有DAG节点。暂停命令可包括HCSN 1108。
在接收到暂停命令之后，DAG节点可停止处理状态转变请求/消息，并且可替代地开始进程来验证其提交记录集包括高达HSCN并且包括对应于HSCN的提交记录的所有提交记录。例如，情况可能为：节点1102A和节点1102C可能尚未被提交者节点1102E通知关于具有小于或等于HCSN的序列号的一个或多个提交状态转变。在这类情形中，如图11c中所示，节点1102A可将提交记录同步请求1172B发送到提交者节点1102E(如由标示为“1a”的箭头所示)，并且节点1102C可将类似的提交记录同步请求1172B发送到节点1102E(如由标示为“1b”的箭头所示)。提交记录同步请求1172可分别包括哪些提交记录在发送请求的节点处丢失的指示，例如，节点1102A可指示其已经具有序列号高达SN1的提交记录，而节点1102C可指示其丢失具有序列号SN2、SN3和SN4的提交记录。丢失的提交记录1174A和1174B然后可通过提交者节点分别发送到节点1102A和1102C，如由标示为“2a”和“2b”的箭头所示。节点1102A和1102C然后可将各自的同步确认1176A和1176B发送到DCM 1180，如由标示为“3a”和“3b”的箭头所示。DCM 1180可将节点1102A和1102C添加到维持在DCM的持久性存储装置1175处的最新节点列表1133(即，已经更新其提交记录集来匹配提交者节点1102E的提交记录集的节点)，如由标示为“4”的箭头所示。
如图11d中所示，在所描绘的实施方案中，DAG的节点可终止执行且自我重启。例如，失效的节点1102B和1102D可重启作为从其失效恢复的部分。作为协调的暂停程序的部分，节点1102A和1102C可在已经使其提交记录集与提交者节点的同步之后将其提交记录集(和/或关于节点操作的另外的元数据)保存在本地存储装置中，并且然后发起受控的重启。在所描绘的实施方案中，节点1102E在其已经发送暂停请求1150之后可等待某一时间间隔(允许提交者节点对至少一些同步请求1172作出响应)，将任何状态元数据保存到本地存储装置，并且然后发起其自身的受控重启作为暂停程序的部分。
在一些实施方案中，在DAG节点1102A-1102E回到联机之后，它们可每个发送各自的“可用于服务”消息到DCM 1180，如图11e中所示，并且等待重新激活指令以恢复它们的应用状态转变处理操作。DCM可能能够辨别(使用其最新的节点列表1133)节点1102B和1102D的提交记录集可能不是最新的，并且可因此发送各自的同步命令1194到节点1102B和1102D，如图11f中所示。在至少一些实施中，同步命令可指示HCSN 1108。响应于同步命令1194，节点1102B和1102D可每个发送其自身的提交记录同步请求1172C和1172D到已知为最新的节点，从而指示哪些提交记录在其各自的提交记录集中丢失。例如，节点1102B可将其同步请求1172C发送到节点1102A，而节点1102D可将其同步请求发送到节点1102E。在一些实施方案中，DCM可指定提交记录同步请求应该发往的目的地节点。在一个实施方案中，所有非提交者DAG节点可能必须使其提交记录集与提交者节点同步。节点1102B和1102D可分别接收其丢失的提交记录1174C和1174D，使得最终所有节点已经使其提交记录集同步高达HCSN。在一些实施中，节点1102B和1102D可将确认发送到DCM1180，从而指示它们的提交记录集已经被更新/同步化。在至少一个实施方案中，DCM关于不在其最新节点列表中的那些节点可起到比上文关于图11f所述的稍微较消极的作用。在这类实施方案中，当失效节点(诸如1102B或1102D)回到联机时，其发送消息到DCM以确定新联机节点是否丢失任何提交记录。DCM可通知节点(例如，仅通过指示HCSN)使节点变成最新需要具有高达HCSN的序列号的提交记录。节点然后可负责使其自身变成最新，以及一旦其已经使其提交记录同步高达HCSN，便向DCM回报。因此，在这类实施方案中，DCM可能不一定发送同步命令1194；而是，新联机节点可采取主动来使其提交记录集同步。
在确认至少阈值数量的节点已经更新了提交记录集之后，DCM1180可确定重启后的DAG的配置。在一些情况下，可重新使用暂停之前处在使用中的相同配置，而在其他实施方案中，可选择不同的配置。例如，情况可能为：要求DAG最少具有四个节点，因此初始可只选择节点1102A-1102E中的四个。如图11g中所示，DCM 1180可发送各自的重新激活消息到选定的节点组(在所描绘的示例中，为所有五个节点)，从而指示DAG的当前配置。DAG节点然后可恢复正常操作，如由图11h所示。在一些实施方案中，未失效的DAG节点中的至少一些(例如，1102A、1102C和1102E)可能不一定自我重启。而是，在这类实施方案中，在使其提交记录集同步之后，这类节点中的一个或多个可简单地推迟其他状态转变处理直到它们从DCM接收到重新激活命令为止。
图12是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在协调的暂停程序期间在SRG(诸如复制DAG)的提交者节点处执行。如在元素1201中所示，提交者节点可确定SRG的协调暂停的触发准则已经被满足。多种不同触发条件可导致协调的暂停，包括例如提交者节点检测到保持响应的SRG节点的数目已经降低到低于阈值，或者SRG的配置改变的发生率超过阈值。在一些情况下，资源工作负载水平或错误率可触发暂停，例如，在网络数据包的丢弃率超过阈值的情况下，或者在连接意外终止的比率处于或高于最大可接受比率的情况下。在一个实施方案中，SRG的非提交者节点、或配置管理器诸如DCM可初始检测到会导致受控暂停的问题，并且可向提交者节点通知所述问题。
在所描绘的实施方案中，在确定将发起受控暂停之后，提交者节点可暂停或停止其对状态转变消息的正常处理/复制，并且将任何未解决的目前为止还未保存的提交记录保存到本地存储装置(元素1204)。提交者节点然后可传输暂停请求(包括HCSN(其提交记录已经由提交者节点存储的转变的序列号之中的最高提交序列号)的指示)到SRG的配置管理器(例如，在复制DAG的情况下为DCM)(元素1207)。HCSN可充当SRG的当前活动节点将使其提交记录集同步高达的目标提交序列号。
在至少一些实施方案中，在其发送暂停请求之后，提交者节点可从其他SRG节点(例如，已经确定其不具有序列号高达HCSN的全组提交记录的节点)接收某一数量的提交记录同步请求(元素1210)。在所描绘的实施方案中，提交者节点对在可配置的时间窗期间接收的任何这类同步请求作出响应。提交者节点然后可任选地执行干净关闭并且重启以及发送可用于服务消息到SRG的配置管理器(元素1213)。在一些实施方案中，可省略干净关闭和重启，并且提交者节点可仅发送可用于服务消息，或者提交者节点可仅推迟其他状态转变相关的处理直到从配置管理器接收到重新激活指令为止。最终，提交者节点可从配置管理器接收重新激活消息，指示DAG的当前暂停后的配置，并且提交者节点然后可根据所指示的配置恢复状态转变相关的处理(元素1216)。在一些实施方案中，情况可能为：在新的暂停后配置中，提交者节点不再被赋予提交者角色；而是，例如，其可被配置为接受者节点、中间节点或备用节点。
图13是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在协调的暂停程序期间在状态复制组(诸如复制DAG)的非提交者节点处执行。在正常操作期间，非提交者节点可在对应转变已经被提交之后的某个时间点将提交记录存储在本地存储装置中；因此，非提交者节点的本地提交记录集可能不一定与提交者节点的本地提交记录集一样最新。如在元素1301中所示，非提交者节点可从配置管理器接收暂停命令，指示HCSN为非提交者节点应该使其本地提交记录集同步所达的目标序列号。
在接收到暂停命令之后，非提交者节点可暂停或停止处理新的状态转变消息。如果具有低于HCSN的序列号的一些提交记录从本地提交记录集丢失，那么非提交者节点可将对丢失记录的提交记录同步请求发送到提交者节点(或发送到由配置管理器指示作为丢失的提交记录的源的不同节点)(元素1304)。如果其提交记录集关于HCSN已经是最新的，那么在暂停程序的这个阶段，非提交者节点可能不需要与其他节点通信。在所描绘的实施方案中，在验证具有高达HCSN的序列号的提交记录被存储在本地存储装置中之后，非提交者节点可将同步确认消息发送到配置管理器(元素1307)。非提交者节点然后可推迟其他应用状态转变处理直到其由配置管理器重新激活为止。任选地，非提交者节点可执行干净关闭和重启，并且在重启之后发送“可用于服务”消息到配置管理器(元素1310)。响应于来自配置管理器的重新激活消息，非提交者节点可更新其关于SRG配置的视图并且恢复应用状态转变处理(元素1313)。在暂停后配置中，不同的角色在一些情况下可由配置管理器赋予非提交者节点，例如，非提交者节点的角色可被改变成提交者节点。
图14是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在协调的暂停程序期间在状态复制组(诸如复制DAG)的配置管理器处执行。如元素1401中所示，配置管理器可从SRG的提交者节点接收暂停请求，指示其提交记录存储在提交者节点处的转变的序列号之中的最高提交序列号((HCSN)。在一些实施方案中，共识协议可在最后作出暂停SRG操作的决定之前用在配置管理器的各种节点之中。配置管理器可将HCSN存储在持久性存储装置中(元素1404)(例如，在配置管理器集群的若干节点处的各自存储装置处)，并且将指示HCSN的暂停命令发送到SRG的一个或多个其他节点(元素1407)。在一些实施方案中，暂停命令可被发送到SRG的所有已知成员，包括被假定已经失效的节点。SRG的接收者节点可每个验证它们的本地提交记录集包含对应于HCSN的提交记录(其在一些情况下可要求接收者节点从提交者节点获得丢失的提交记录，如上文所述)。在验证其提交记录集关于HCSN是最新的之后，暂停命令的接收者可向配置管理器发送指示其提交记录集现在是最新的同步确认。因此，在从SRG节点接收到这类确认之后，配置管理器可将该节点添加到最新节点列表(元素1410)。
在一些实施方案中，配置管理器可等待从SRG节点接收指示它们可用于服务的各自消息。在从节点接收到这类消息之后(例如，在节点已经完成干净关闭和重启之后，或者在节点已经在失效之后回到联机之后)，配置管理器可确定节点是否在最新节点列表中。如果并不知道从其接收“可用于服务”指示的节点关于提交记录是最新的，那么配置管理器可将指示HCSN发送到所述节点(元素1413)，例如，在显式同步命令中或响应于来自节点的隐式或显式查询。使用HCSN作为提交记录将被更新到的目标序列号，节点然后可通过与早已为最新的其他节点通信而更新其本地提交记录集。在一些实施方案中，配置管理器可在同步命令中包括过期节点应当从其获得丢失的提交记录的源的指示。
在配置管理器已经确认所要求的最小数量的SRG节点(a)可用于服务并且(b)关于应用提交状态是最新的之后，配置管理器可完成SRG的初始暂停后配置(元素1416)。配置管理器然后可将指示配置的重新激活消息发送到处于初始配置的适当的节点组(元素1419)。在一些实施方案中，初始配置信息可被提供到节点作为一序列的配置增量消息。
在至少一些实施方案中，选择用于同步的目标序列号(即，SRG的多个节点中的每个将更新其本地提交记录集所高达的序列号)不一定需要是最高提交序列号。例如，情况可能为：在提交者节点处的最高提交序列号是SN1，并且由于因检测到快速上升的大规模失效事件而暂停SRG的操作的迫切需要，SRG配置管理器可能希望允许节点在将其提交记录更新到较小序列号(SN1–k)之后暂停其操作。在一些实施中，SRG的节点可在暂停/重启之前使它们的提交记录同步到某个较低序列号，并且可在暂停之后同步到最高提交序列号，例如，在节点重启和发送“可用于服务”消息到配置管理器之后。如先前所述，在一些实施方案中，暂停程序可由非提交者节点或由配置管理器本身发起。
对多数据存储区事务的基于日志的乐观并发控制
在一些实施方案中，上文所述的类型的复制DAG可用于使用日志记录服务来实施乐观并发控制技术，所述日志记录服务实现对涉及多个独立数据存储区的事务的支持。图15示出了根据至少一些实施方案的示例性系统环境，所述系统环境包括支持可包括对多个数据存储区的写入的事务的持久性改变日志。系统1500示出了可使用日志记录服务实例化的持久性改变日志1510。在所描绘的实施方案中，一个或多个数据存储区1530诸如数据存储区1530A(例如，NoSQL或非关系数据库)和数据存储区1530B(例如，关系数据库)可在日志记录服务处注册用于事务管理。术语“并发控制”、“事务管理”和“更新管理”在本文中可关于由日志记录服务提供的功能性用作同义词。在一些实施方案中，日志记录服务可被认为是可在提供商网络处实施的多个存储服务的一个示例。
在一些实施方案中，客户端1532可例如经由由日志记录服务管理器1501呈现的管理或控制平面编程接口而递交注册请求，所述注册请求指示客户端希望对特定应用使用基于日志的事务管理的数据源集。在一些实施方案中，持久性改变日志1510可响应于这类注册请求而实例化。一般来说，给定的持久性改变日志实例可被创建用于管理一个或多个基础数据存储区的事务，即，在至少一些部署中，基于日志的事务管理可用于单个数据存储区而非同时用于多个数据存储区。如本文所使用，术语“数据存储区”可指代各种各样的持久性或暂时性数据储存库和/或数据消费者中的任一者的实例。例如，一些数据存储区可包括可能不一定为多项目事务提供原生支持的持久性非关系数据库，而其他数据存储区可包括可原生地支持多项目事务的持久性关系数据库。在一些实施方案中，可将提供商网络的网络可访问的存储服务注册为数据存储区中的一个，所述服务使得其用户能够存储任意大小的非结构化数据对象、可经由web服务接口访问。其他类型的数据存储区可包括存储器中数据库、分布式缓存实例、网络可访问的区块存储服务、文件系统服务或物化视图。在至少一个实施方案中，一个或多个数据存储区可包括实施在提供商网络处的排队服务和/或通知服务的部件。消耗由日志记录服务记录的提交写入例如以产生新的数据伪影的实体可表示另一类型的数据存储区，并且在本文中一般可被称为“数据消费者”。这类数据存储区可例如包括预先计算的查询结果管理器(PQRM)(如在数据存储区1530C的情况下)，所述管理器负责生成关于经由日志记录服务管理的指定数据集的指定查询结果(其中所述指定数据集可包括存储在一个或多个不同其他数据存储区处的对象)。在一些实施方案中，快照管理器可表示数据存储区的另一类别，所述快照管理器被配置成生成经由日志记录服务管理的一些或所有提交数据的时间点快照。在不同实施方案中，这类日志快照可被存储用于多种目的，诸如用于备份或用于脱机工作负载分析。术语“数据消费者”在本文中可用于指代诸如PQRM和快照管理器的数据存储区。数据存储区中的至少一些可具有不同于其他数据存储区的读取接口1531，例如，在所描绘的实施方案中，数据存储区1530A的数据存储区(DS)读取接口1531A可包括一组不同于DS读取接口1531B或预先计算的查询接口1531C的API、基于web的接口、命令行工具或定制的GUI(图形用户接口)。
在所描绘的实施方案中，日志记录服务客户端1532可在本地构建事务请求，并且然后递交(或“提供”)事务请求用于由持久性改变日志1510批准和提交。在一个实施中，例如，日志记录服务的客户端侧库可能使得客户端能够通过发布“事务开始”请求的逻辑等同物而发起候选事务。在候选事务内，客户端可对数据存储区1530处的选定对象集执行某一数量的读取，本地(例如，在本地存储器中)执行引导在一个或多个数据存储区处的所提议的写入集。客户端然后可通过发布“事务结束”请求的等同物而递交候选事务。在所描绘的实施方案中，候选事务请求1516可经由日志写入接口1512在与持久性改变日志1510相关联的冲突检测器1505处接收。一般来说，在至少一些实施方案中，给定的事务请求1516可包括分别来自一个或多个数据存储区的一个或多个读取，以及分别引导到一个或多个数据存储区的一个或多个提议的写入，其中被读取的数据存储区集可或不可与被写入的数据存储区集重叠。在一些实施方案中，可使用原生DS读取接口1531来执行读取(尽管如下文所述，在一些情形中，客户端也可经由持久性改变日志1510来执行只读操作)。
在一些实施方案中，给定的事务请求中所指示的至少一些写入可取决于一个或多个读取的结果。例如，所请求的事务可涉及从数据存储区DS1处的位置L1读取一个值V1、从数据存储区DS2处的第二位置L2读取第二值V2、计算函数F(V1,V2)以及将函数的结果存储在某个数据存储区DS3处的位置L3处。在一些基于锁定的并发控制机制中，排他性锁定可必须在L1和L2上获得以确保值V1和V2在L3更新之前不改变。在图15中所示的日志记录服务的乐观并发控制机制中，可能不必获得锁定。而是，在所描绘的实施方案中，冲突检测器1505可至少部分基于事务描述符1516的内容和持久性改变日志1510的提交的事务日志记录集1527而确定所请求的事务中所读取的数据项目集是否自其从其各自的数据存储区读取以来便已经被更新。在至少一些实施方案中，可使用基于序列号的技术来确定这类读取-写入冲突是否存在，如下文更详细描述。如果冲突检测器1505确定在事务期间被读取的数据全部都没有被覆写，那么所请求的事务可被接受用于提交，并且这类被接受用于提交的事务1514可被递交用于在持久性改变日志处复制对应的日志记录。术语“批准”和“接受”在本文中关于未被拒绝的所请求的事务可用作同义词。在所描绘的实施方案中，如果一些读取数据自对应的读取发生以来被更新(或者如果冲突检测器将数据被更新的可能性估计成大于阈值)，那么所请求的事务1516可代替地被拒绝或中止。这种类型的并发控制方法可被认为是乐观的，因为初始地可在读取-写入冲突不可能的乐观假定下作出关于是否继续进行事务的写入集的决定。因此，在读取-写入冲突事实上不频发的情形中，可实现比使用更传统的基于锁定的技术的情况下可能的更高的吞吐量和更少的响应时间。
在所描绘的实施方案中，在事务被接受用于提交的情况下，所提交的事务日志记录的内容可在提交被认为是成功的之前，在与持久性改变日志1510相关联的复制DAG的某一数量的节点处复制(如下文关于图16更详细描述)。在所描绘的实施方案中，如果不创建所需数目的副本，那么可拒绝或中止事务。提交所需的副本数目对于不同的应用或客户端可不同。提交的事务日志记录在本文中也可被称为“提交记录”。在一些实施方案中，当所请求的事务被提交时，请求客户端1532可被通知。在至少一个实施方案中，当事务被拒绝时，客户端1532可被通知，使得例如新的事务请求可被生成并且被递交用于期望的更新。
对于所提交的每个事务，在至少一些实施方案中，可在持久性改变日志1532处生成并存储(例如，作为提交的事务日志记录的副本中的每个的部分)提交序列号(或指示应用的提交状态的某个其他标识符)。这类提交序列号可例如被实施为计数器或逻辑时间戳，如上文关于在复制DAG处用于状态转变的序列号所讨论。例如，在一些实施方案中可由冲突检测器或者在其他实施方案中在持久性改变日志的不同部件(诸如所使用的复制DAG的提交者节点)处确定提交序列号。在所描绘的实施方案中，在给定的事务被提交并且其提交记录被存储在持久性改变日志处之后，事务的写入可被应用于或传播到它们所指向的数据存储区1530中的一个或多个(或者，如在PQRM1530C的情况下，其中写入数据将被消耗)。在一些实施中，写入可以异步方式推动到目标数据存储区1530。因此，在这类实施中，在事务被提交的时间(即，当提交记录的所需数目的副本已经被成功存储时)和所提交的事务的特定写入操作的有效负载到达对应的数据存储区的时间之间可能存在某个延迟。在图15所示的实施方案中，各自的异步写入应用器1517可用于将一些或全部写入传播到相关数据存储区。例如，写入应用器1517A被配置成应用与数据存储区1530A相关的写入1515A，写入应用器1517B推动与数据存储区1530B相关的写入，并且写入应用器1517C推动将在数据存储区1530C处被消耗的写入。在一些实施中，写入应用器可包括持久性改变日志1510的子部件(例如，线程或进程)，而在其他实施中，写入应用器1517可被实施为在持久性改变日志外部的实体。在一些实施方案中，给定的写入应用器1517可负责将写入传播到一个以上数据存储区1530，或者单个数据存储区1530可从多个写入应用器1517接收写入。在至少一个实施中，可使用拉取技术来将写入数据传播到数据存储区，例如，一个或多个数据存储区1530可将写入请求递交到持久性改变日志1510或写入应用器，而不是在写入应用器的发起下被提供写入数据。在于事务期间写入的数据被应用到对应的数据存储区之后，客户端1532可能能够使用数据存储区的各自读取接口而读取更新的数据。在一些实施方案中，写入应用器中的至少一者可能能够执行同步写入(例如，当通过日志记录服务被显式地引导这样做时，或对于应用器所负责的所有写入)。例如，客户端可能希望确保给定事务的至少一个写入(诸如被引导到事务中所涉及的多个数据存储区之中的“主”数据存储区的写入)在客户端被通知事务已经被提交之前已经被应用。在一些实施方案中，将被同步执行的特定写入可在事务请求1516中被指示。
在一些实施方案中，如下文更详细描述，给定的事务请求1516可包括事务的读取集(例如，标识在事务期间读取的数据对象集的信息)、事务的写入集(即，标识将在事务被提交的情况下被更新/写入的数据对象集的信息)、写入有效负载(即，将针对每个写入被存储的数据字节集)、和/或冲突检查分隔符(对应当被检查以接受/拒绝事务的提交事务日志记录子集的指示)的各自指示符。事务请求的这些组成元素中的一些或全部可与事务的提交序列号一起被存储在对应的提交记录内。在至少一个实施方案中，持久性改变日志1510可例如响应于来自数据存储区的查询或来自日志记录服务客户端的查询而提供应用的最新提交状态的标识符1590(诸如目前为止生成的最高提交序列号)。在所描绘的实施方案中，写入应用器可指示对应于它们在数据存储区处应用的写入的提交序列号。因此，在任何给定时间点，客户端1532都可能能够(例如，通过查询数据存储区)确定对应于给定数据存储区1530处的最近应用的写入的提交序列号。
在至少一些实施方案中，在生成事务请求期间(例如，通过日志记录服务的客户端库)，可从在事务期间被访问的数据存储区获得最近应用的提交时间戳，并且这类提交序列号中的一个或多个可在事务请求中被指示为冲突检查分隔符。例如，考虑如下情形：在特定客户端发起包括在数据存储区DS1处的位置L1的读取的事务时，对应于DS1处的最近应用的写入的提交序列号为SN1。还假定在此示例中，事务的读取集仅包括DS1的数据。在这类情形中，SN1可包括在事务请求1516中。冲突检测器可将具有大于SN1的序列号的提交记录标识为将针对所请求的事务进行读取-写入冲突检查的提交记录集。如果所标识的提交记录的任何写入集与所请求的事务的读取集重叠，那么所述事务可被拒绝/中止；否则，在此示例性情形中，所述事务可被批准用于提交。
在所描绘的实施方案中，日志记录服务可暴露一个或多个编程日志读取接口1513(例如，API、网页、命令行实用程序、GUI等)以使得客户端1532能够直接读取日志记录。在其他实施方案中，可能不实施允许直接访问改变日志1510的这类读取API。直接访问指示已经被提交的特定事务的日志记录以及确定事务被提交的顺序的能力可在一些实施方案中使得能够执行新类型的分析，而不是可能仅直接访问数据存储区(由于数据存储区中的至少一些可通常仅允许读取器看见数据对象的最新应用版本，而看不见数据对象的历史)。
图15中所示的乐观并发控制机制可允许支持比在至少一些情形中使用基础数据存储区的并发控制机制已经可能的更复杂类型的原子操作。例如，一些高性能的非关系数据存储区可仅允许单项目事务(即，一次可允许一个写入，但是如果以单批更新递交多个写入，那么可能对一起进行的多个写入不提供原子性/一致性保证)。使用上文所述的基于日志的方法，可相对容易地支持包括对非关系数据存储区(和/或同样其他数据存储区)的多个位置的写入的单个事务。持久性改变日志1510与相关联的冲突检测器1505一起在本文中可被称为基于日志的事务管理器。在一些实施方案中，写入应用器1517也可被认为是事务管理器的子部件。
如上文所提及，在一些实施方案中，持久性改变日志1510可使用先前描述的复制DAG实施。图16示出了根据至少一些实施方案的使用复制DAG 1640的持久性改变日志的示例性实施。在所描绘的实施方案中，由DAG管理的应用状态转变对应于由日志客户端1660所请求的事务，作为包括引导到一组一个或多个数据存储区的读取和写入的应用的部分。应用的状态可被建模为存储在接受者节点1610、中间节点1612、提交者节点1614和备用节点1616处的本地存储装置中的各自的事务记录集1672，其中当前复制路径包括节点1610、1612和1614。在一些实施中，用于批准(即，指示所请求的事务已经被批准用于提交)和提交的单独的事务记录可被存储，而在其他实施方案中，单个事务记录可与指示事务是否已经被提交的字段一起被存储。在所描绘的实施方案中，可存储序列号或逻辑时间戳，作为事务记录中的至少一些的部分，或由所述至少一些事务记录指示。
在所描绘的实施方案中，关于所请求的事务1650是否将被批准用于提交的决定可由实施在接受者节点1610处的冲突检测器作出，但是在其他实施方案中，冲突检测器可在复制DAG外部实施。容错日志配置管理器164可将配置增量消息异步地发送到DAG节点1610、1612、1614和1616，其中每个这类消息指示DAG配置的改变而非DAG的整个配置，并且不需要DAG节点暂停处理由客户端1660递交的传入的事务请求的流。每个DAG节点可独立地处理或聚集被接收的配置增量消息以得到其关于当前DAG配置的各自视图1674(例如，在节点1610处的视图1674A、在节点1612处的视图1674B、在节点1614处的视图1674C以及在节点1616处的视图1674D)。视图1674中的至少一些在给定时间点可不同于其他节点处的视图；因此，在正常操作条件下，不同的DAG节点可能不需要使它们关于DAG配置的视图彼此同步。指示批准的(但是尚未提交的)事务的消息1652A和1652B可沿着复制路径分别从接受者节点1610和中间节点1612传输。在所描绘的实施方案中，提交者节点1614可将指示提交的消息1653传输到接受者节点和中间节点以及到备用节点1616。图16的实施方案中示为复制DAG外部的实体的异步写入应用器1692可将写入从各种提交的事务记录传播到适当的数据存储区或数据消费者。在其他实施方案中，写入应用器可被实施在复制DAG内，例如作为在DAG节点内运行的各自进程。在一些实施中，可通过应用器1692仅读取DAG节点的子集以便将提交的写入传播到其目的地数据源或消费者。在其他实施方案中，如在图16中所示，应用器可从任何DAG节点读取提交的事务记录以推动写入有效负载的内容，如先前所述。
事务请求元素
图17示出了根据至少一些实施方案的可由日志记录服务的客户端1732递交的事务请求描述符1744的示例性部件元素。如所示，在所描绘的实施方案中，事务描述符1744可包括冲突检查分隔符1702、读取集描述符1704、写入集描述符1706、写入有效负载1708和任选的逻辑约束描述符1710。在所示的示例中，日志记录服务客户端1732包括客户端库1756，所述客户端库可用来集合事务请求描述符。在至少一些实施方案中，客户端库可自动地记录分别在数据存储区1730A、1730B和1730C内在事务期间从中读取的读取位置1761A、1761B和1761C，和/或向其写入数据的(在所描绘的示例中数据存储区1730C的)写入位置1771。在一些实施中，客户端库1756也可从每个数据源1730获得其写入最近已经应用在数据存储区的最近事务的对应提交序列号(CSN)。在一个实施方案中，这类CSN可在例如将事务的任何读取发布到对应的数据存储区之前被检索。在另一实施方案中，CSN可恰好在发布在当前事务内被引导到给定的数据存储区1730的第一读取之前从给定的数据存储区1730检索。
在所描绘的实施方案中，冲突检查分隔符1702可从将最近应用的CSN提供为输入的函数导出。例如，在一个实施中，可使用从事务期间读取的所有数据存储区获得的CSN之中的最小序列号。在另一实施中，包括来自每个数据存储区的CSN的向量或阵列可被包括作为事务请求描述符的冲突检查分隔符1702。冲突检查分隔符1702在本文中也可被称为提交的状态标识符(CSI)，因为其表示所请求的事务所依据的一个或多个数据存储区的提交状态。在一些实施方案中，所选的散列函数可应用于读取位置1761A、1761B或1761C中的每个以获得将被包括在读取描述符1704中的散列值集。类似地，所选的散列函数(与用于读取描述符相同的函数、或不同的函数，其取决于实施)可应用于事务的写入的位置以生成写入集描述符1706。在其他实施方案中，可能不使用散列法；而是，例如，可针对读取和写入集条目中的每个使用未散列的位置标识符。写入有效负载1708可包括将针对包括在事务中的写入中的每个写入的数据的表示。任选的逻辑约束1710可包括用于重复检测/消除和/或用于将指定事务排列在其他事务之前或之后的签名，如下文更详细描述。在一些实施方案中，可存储事务请求描述符1744的一些或全部内容作为在持久性改变日志1510处复制的事务状态记录的部分(例如，批准的事务记录和/或提交的事务记录)。
应注意，从其生成读取描述符和写入描述符的读取和写入位置可表示不同的存储粒度，或在不同实施方案中或对于不同数据存储区，甚至表示不同类型的逻辑实体。例如，对于包括由容器名称(例如，表格名称)、用户名称(指示容器的所有者)和某个键集(例如，散列键和范围键)的组合表示特定的数据对象的非关系数据库的数据存储区来说，读取集可依据元组(容器-ID，用户-ID，散列键，范围键)而获得。对于关系数据库，可使用元组(表格-ID，用户-ID，行-ID)或(表格-ID，用户-ID)。
在各种实施方案中，事务管理器可使用事务请求的内容和持久性改变日志来负责标识事务请求中所指示的读取与日志中所指示的写入之间的冲突。对于相对简单的读取操作，基于被读取的位置生成散列值，以及比较该读取位置的散列值与改变日志中所指示的写入的散列值可满足检测冲突的要求。对于一些实施方案中的更复杂的读取请求，使用基于位置的散列值可能并不总是满足要求。例如，考虑以下情形：其中读取请求R1包括查询“从表格T1选择以字母‘G’开头的产品名称”并且原始结果集为“Good-product1”。如果到针对接受而检查其写入W1取决于R1的结果的事务请求的时候，产品名称“Great-product2”被插入表格中，那么这将意味着如果在作出事务接受决定时R1被重新运行，那么R1的结果集将已经改变，即使“Good-product1”数据对象的位置可能还未被修改并且因此可能不被指示日志的写入记录。为了处理关于这类读取查询的读取-写入冲突，或对于涉及值范围的读取查询(例如，“选择价格在$10与$20之间的产品的产品名称集”)，在一些实施方案中，可使用基于逻辑或谓词的读取集描述符。上文所述的基于位置的读取集指示符可因此被认为只是可在各种实施方案中用于读取-写入冲突检测的结果集改变决定元数据的一个示例性类别。
读取-写入冲突检测
图18示出了根据至少一些实施方案的在基于日志的事务管理器处进行的读取-写入冲突检测的示例。在所描绘的示例中，存储在持久性改变日志1810处的事务提交记录(CR)1852被示为按提交序列号从日志顶部到底部递增的顺序布置。最新的或最近提交的事务由CR 1852F表示，其具有提交序列号(CSN)1804F和写入集描述符(WSD)1805F。CR 1852A、1852B、1852C、1852D和1852E中的每个包括对应的CSN 1804(例如，分别为CSN 1804A–1804E)和对应的WSD 1805(例如，WSD 1805A-1805E)。
如所示，事务请求描述符1844包括冲突检查分隔符(或提交状态标识符)1842、读取集描述符1846和写入集描述符1848。(未示出所请求事务的写入有效负载)。可要求基于日志的事务管理系统的冲突检测器来标识将对所请求事务的读取集检查冲突的日志1810的CR集。在所描述的实施方案中，冲突检查分隔符1842指示可由冲突检测器使用来标识将针对读取-写入冲突与所请求事务进行检查的集1809的起始CR的下限CSN，如由标示为“匹配”的箭头所示。在一些实施方案中，集1809可包括以高达最近提交的事务(CR 1852F)的匹配序列号开始的全部CR。如果由CR集1809指示的任何写入与事务请求1844中所指示的任何读取重叠，那么这类读取-写入冲突可导致对所请求事务的拒绝。在不同实施方案中，可使用多种机制来检查是否存在这类重叠。在一个实施方案中，例如，可使用一个或多个基于散列法的计算或探测来确定读取集描述符1846中所表示的读取是否与CR集1809中所指示的写入冲突，从而避免对CR集的依序扫描。在一些实施中，可使用对CR集1809的依序扫描，例如，在CR集中的记录数目低于阈值的情况下。如果CR集1809中所指示的写入均不与所请求事务的任何读取重叠，那么事务可被接受，因为在事务请求的准备期间被读取的任何数据自它们被读取以来均不可能改变。在至少一个实施方案中，事务请求描述符也可指示将针对冲突被检查的事务记录的序列号的上限，例如，冲突检查分隔符可指示CS集1852内的起点和终点两者。
乐观的基于日志的并发控制的方法
图19是示出根据至少一些实施方案的可在日志记录服务处执行的控制平面操作的方面的流程图。所示的管理或配置相关的操作中的至少一些可由诸如图15中所示的日志记录服务管理器1501执行，例如，响应于在日志记录服务处实施的一个或多个管理编程接口的调用而执行。如元素1901中所示，一个或多个数据存储区可经由日志记录服务被注册用于事务管理，所述日志记录服务例如使用上文所述的读取-写入冲突检测方法而实施乐观的并发控制机制。具有各自的不同读取接口的各种类型的数据存储区的事务管理在不同实施方案中可使用基于日志的方法来实施，包括例如关系数据库、非关系数据库、存储器中数据库、提供商网络实施的存储服务、分布式缓存部件、预先计算的查询结果管理器、快照管理器、排队服务、通知服务等等的实例。在一些实施方案中，使用给定的日志实例管理的基础数据存储区中的一些或全部可能不支持由一些传统的关系数据库系统支持的ACID性质(原子性、一致性、隔离和耐久性)中的至少一些。
日志记录服务可标识将用于将被实施用于注册的数据存储区的持久性改变日志的复制DAG节点的一组主机(元素1904)，例如，在实施在提供商网络处的供应服务的帮助下。一个或多个主机也可针对复制DAG的配置管理器被标识，例如，如先前所述，在一些实施中利用基于共识的协议用于实施DAG配置改变的节点集群可使用。复制节点和配置管理器可在所选主机处被实例化。可配置基于日志的事务管理机制的其他部件(元素1907)，包括冲突检测器、一个或多个写入应用器和任选的读取接口管理器用于持久性改变日志。在一些实施方案中，日志的读取接口管理器可负责对直接递交到日志(而非被递交到已注册的数据存储区的读取接口)的读取请求作出响应。在一个示例性实施中，写入应用器可被实例化为订阅事务何时在日志处被提交的通知的各自进程或线程。在一些实施方案中，冲突检测器可包括利用日志的读取接口的模块。冲突管理器的配置可包括例如建立标识读取-写入冲突的顺序对比对应于重复删除或排序的约束检查操作来、提供对客户端的响应方式(例如，关于事务拒绝/提交，客户端是否被通知以及被如何通知)等等。在一些实施方案中，冲突检测器、写入应用器和/或日志读取接口管理器可以多租户方式实施，例如，给定的冲突检测器、写入应用器或读取接口管理器可向已经为其建立各自的日志实例的多个客户端提供其服务。
在持久性改变日志的各种部件已经被配置之后，来自客户端的事务请求流可被启用(元素1910)，例如，通过提供适当的网络地址和/或凭证给客户端。在至少一些实施方案中，在日志记录服务处执行的控制平面操作可包括修整或存档所存储的事务状态记录的部分(元素1914)。在一些这类实施方案中，例如，当用于给定的持久性改变日志的事务记录的存储量跨过阈值时，某一数量的最旧事务记录可被复制到不同的存储设施(诸如提供商网络存储服务，或比用于最近的事务记录集慢的一组存储装置)。在另一实施方案中，可简单地丢弃最旧的事务记录。在至少一个实施方案中，可根据需要执行其他控制平面操作，诸如在持久性改变日志的一个实例和另一实例之间切换，例如，当第一改变日志达到阈值数目的记录时。
图20是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于从客户端接收的事务请求而在日志记录服务处执行。如元素2001中所示，日志记录服务的冲突检测器可接收事务T1的事务请求描述符，例如指示冲突检查分隔符、读取集和写入集，所述写入集包括针已经由日志记录服务建立持久性改变日志所针对的一个或多个数据存储区处的各自位置的一个或多个写入。冲突检查分隔符可指示从其获得事务读取结果的一个或多个源数据存储区的提交状态，并且可因此用作提交的状态标识符(CSI)。在一些环境中，CSI也可被称为“快照序列号”，因为它们可对应于源数据存储区的时间点逻辑快照。存储在持久性改变日志处的事务记录集S1可被标识用于对所请求事务检查潜在冲突(元素2004)，例如，使用冲突检查分隔符和存储在日志中的事务记录的序列号。在一个实施方案中，这类集S1可包括例如具有高于冲突检查分隔符中所指示的序列号的提交序列号的所有事务记录。
如果检测到读取-写入冲突(元素2007)，例如，如果所请求事务的读取集至少部分与集S1的事务中的一个的写入集重叠，那么事务T1可被拒绝或中止(元素2022)。在一些实施方案中，散列函数可用于确定这类重叠是否存在，例如，如果读取集散列到与写入集相同的值，那么可假定冲突已经发生。在一些实施中，可向从其接收事务请求的客户端提供拒绝的指示或通知，使得客户端能够通过生成和递交另一请求描述符而重新尝试事务。如果没有检测到冲突(如也在元素2007中所确定)，那么T1可被接受用于提交(元素2010)。在所描绘的实施方案中，可向持久性存储装置发起对T1的事务记录的复制，例如，在日志的多个复制DAG节点处。在一些实施方案中，当T1被接受用于提交时，接受序列号可被指派给T1，并且可与事务请求描述符元素中的至少一些的内容一起被存储在每个副本中。在至少一个实施方案中，如果事务最终被提交，那么接受序列号可充当提交序列号。
取决于其事务被管理的应用的数据耐久性需求，阈值数量的副本可能必须在事务T1的提交完成之前被存储。如果足够数目的副本被保存(如在元素2013中所确定)，那么提交可被认为是成功的，并且在一些实施方案中可关于提交完成通知请求客户端(元素2014)。如果出于某种原因，可被保存到持久性存储装置的副本数目低于所需阈值(如也在元素2013中所检测)，那么事务可被中止/拒绝(元素2022)。在T1提交之后，在所描绘的实施方案中，T1的写入集中所指示的写入操作可应用于对应的数据存储区或数据消费者，例如，通过异步写入应用器(元素2016)。在一些实施方案中，写入应用器中的至少一个可为同步，例如，客户端可被通知事务仅在这类同步写入应用器完成其更新将被同步应用的事务写入子集之后才被提交。在已经应用更新之后，所更新的数据元素可响应于经由各自的数据存储区的读取接口接收的客户端读取请求而读取(元素2019)。除了由各种注册的数据存储区支持的读取接口之外，在至少一些实施方案中，持久性改变日志自身还可被直接查询事务记录内容，例如，经由日志记录服务的编程查询/读取接口。在一些实施中，经由这类日志记录服务接口引导到日志的读取在一些情况下可能能够比引导到数据存储区的读取更快速地看见写入操作的结果，因为数据存储区可依赖异步应用器来传播已经存在于日志中的写入。在一些实施方案中，可使用同步应用器，一旦事务在日志处被提交，所述应用器便将写入传播到数据存储区。在其他实施方案中，每个应用器可具有可配置时间窗，在所述时间窗内，写入必须被传播到对应的数据存储区或消费者，使得调整事务提交和事务的修改数据在数据存储区处出现之间的最大延迟变成可能。
图21示出了根据至少一些实施方案的可用于实现各自的特殊情况一致性目标的事务请求描述符的示例。在一个实施方案中，日志记录服务的客户端可能希望强制执行“写入后读取”一致性语义，根据所述语义，一旦写入被提交，写入便变成为所有读取器可见。为了确保写入后读取一致性，即，为了确保在数据被提交之后不久，读取始终“看见”数据，客户端可希望递交甚至对只读事务(以及对包含写入的事务)的事务请求。只读事务请求描述符(TRD)2144例如具有空写入集2106A和空写入有效负载2108A，但是具有非空冲突检查分隔符2102A和非空读取集描述符2104A。在接收到这类只读事务请求描述符之后，冲突检测器可检查请求中所指示的读取集与已经以高于冲突检查分隔符中所指示的序列号的序列号提交的写入之间是否存在重叠。如果检测到冲突，那么可拒绝只读事务，因此不允许对可能在生成冲突检查分隔符之后写入已经被提交的位置的读取，即使所请求的事务不包括与那些读取相依的任何写入。
在至少一些实施方案中，只写事务请求在某些情况下可被递交给日志记录服务。对于一些应用，情况可能为：客户端不希望强制执行读取-写入一致性检查，至少在一些时间段期间或对于一些数据存储区。而是，客户端可能希望在这类时间段期间使一些写入被无条件地接受用于提交。因此，具有空读取集2104B和/或空冲突检查分隔符2102B的事务请求描述符2145可连同非空写入集描述符2106B和非空写入有效负载2108B被递交。例如，当数据存储区或对象被初始填充时，或在于某个时间段期间已知仅一个编写器客户端递交请求的情况下，可递交这类只写请求。
如先前所提及，在一些实施方案中，异步写入应用器可用于将提交写入的内容从持久性改变日志传播到各种数据存储区或数据消费者。由于写入传播的异步性质，在一些时间点的情况可能为：提交写入集尚未被传播到它们的预期数据存储区。在至少一个实施方案中，可能使用只写事务来刷新这类未应用的写入。例如，如果特定的写入应用器WA1被配置成具有至给定数据存储区DS1的未解决的不超过N个未应用写入，那么客户端可递交只写事务请求描述符诸如引导到DS1中的特殊写入位置WL1的TRD 2145，其中WL1特别或主要用于刷新未解决的提交写入。在一些情况下，这类TRD可能根本不需要具有任何写入有效负载(例如，写入有效负载2108B可被设置为空)。当接受了这类写入-应用-刷新事务请求时，可将新的待决提交写入添加到日志和未解决请求的WA1队列。随着队列的长度增加，WA1可能必须开始应用队列中的先前提交的写入以满足其不超过N个未应用写入的要求。在一些实施方案中，这类写入-应用-刷新请求可被定期递交，例如，每秒一次，以确保提交的写入不被太长时间地保持为待决。当写入-应用-刷新事务的提交写入到达应用器的队列的头部时，在一些实施中，不需要执行物理写入；而是，例如，应用器可简单地将对应于事务的提交序列号发送到目的地数据存储区作为对最近“应用”的写入的指示符。
对于一些应用，客户端可能希望在至少某些时间段期间强制执行严格的序列化。即，一次可允许仅一个(包含写入的)事务继续进行，而不管事务期间的数据读取与自事务准备被发起以来可能已经被提交的写入之间是否存在任何冲突。在这类方案中，客户端可将严格序列化事务请求描述符2146递交到日志记录服务，其中其读取集描述符2104C指示由应用使用的所有数据集的整个内容。在散列值被用作读取/写入位置的指示符并且与写入集条目进行的逐位比较被用于检测冲突的一个实施中，包括在读取集描述符2402C中的散列值可被设置为一序列“1”(例如，16位散列值为“1111111111111111”)。如果任何包含写入的事务已经以大于这类TRD 2146的冲突检查分隔符2102C的CSN提交，那么可拒绝对应于TRD 2146的事务。因此，由写入集描述符2106C和写入有效负载2108C指示的写入将仅在由描述符指示的冲突检查间隔中还没有提交其他写入的情况下(而不管这类写入的位置)才被提交。
重复删除和排序约束
在一些实施方案中，日志记录服务的客户端可能希望确保重复条目不被写入到一个或多个数据存储区。在一个这类实施方案中，除了执行如上文所述的读取-写入冲突检测之外，日志记录服务还可能必须强制执行事务请求中所指示的重复删除要求。图22示出了根据至少一些实施方案的强制执行与在基于日志的事务管理器处接收的事务请求相关联的重复删除约束的示例。如所示，事务请求描述符2244包括读取-写入冲突检查分隔符2212、读取集描述符2214、写入集描述符2216和逻辑约束分隔符2218。TRD 2244的写入有效负载没有在图22中示出。在所描绘的实施方案中，逻辑约束描述符2218包括指示其表示重复删除约束的LC类型字段2219、重复删除检查分隔符2220和排除签名2222。
在所描绘的实施方案中，为了确定是否接受所请求的事务，日志记录服务可能必须执行两种类型的检查：一种类型用于检测读取-写入冲突，而一种类型用于检测重复。在所描绘的实施方案中，持久性改变日志2210中的提交记录2252可每个包括各自的提交序列号(CSN 2204)、写入集描述符(WSD)2205和重复删除签名(DDS)2206。为了确定读取-写入冲突是否已经发生，日志记录服务可标识CR集2209，始于对应于读取-写入冲突检查分隔符2212的序列号并且结束于最近提交记录2252F，其写入集将针对与所请求事务的读取集描述符2214的重叠进行评估。如果检测到读取-写入冲突(即，如果这类重叠存在)，那么所请求事务可被拒绝，如先前所述。
为了确定所请求的事务的写入是否表示重复，在所描绘的实施方案中另一CR集2259可被标识为始于对应于重复删除检查分隔符2220的序列号并且结束于最近提交记录2252F。对于CR集2259中的每个提交记录，日志记录服务可检查存储在提交记录中的任何重复删除签名是否匹配所请求事务的排除签名2222。如果发现这类匹配，那么可检测到重复，并且在这类情形中即使没有检测到读取-写入冲突，所请求事务也可被拒绝。如果没有检测到重复，并且如果没有检测到读取-写入冲突，那么事务可被接受用于提交。
在至少一些实施方案中，重复删除签名2206可表示由对应的事务以不同于写入集描述符的方式写入的数据项目(例如，通过使用不同散列函数生成的散列值，或通过使用更多位存储的散列值)。写入集的这类不同编码可出于许多原因中的任一个而用于重复删除对读取-写入冲突检测。例如，对于一些应用，相比于客户端关心因假阳性的读取-写入冲突检测而偶尔必须重新递交事务，客户端更关心准确地检测重复。对于这类应用，读取-写入冲突检测中的可接受错误率因此可高于可接受的重复检测错误率。因此，在一些实施中，其输出值采用128或256位的加密强度散列函数可用于重复删除签名，而其输出使用16或32位来存储的较简单的散列函数可用于包括在WSD中的写入签名。在一些情形中，对于所使用的小的数据存储区子集可能要求重复删除，而对于大很多的事务集可能必须检查读取-写入冲突。在这类情况下，在一些实施方案中，可通过使用比重复删除签名小的WDS签名而减少存储和联网资源使用。也可能有利的是，出于其他原因，将读取-写入冲突检测机制与重复删除检测机制逻辑地分开，而非将两者合并，例如，以避免日志记录服务的用户之间的混乱，以能够对重复删除支持单独计费等等。
在其他实施方案中，写入集描述符可用于读取-写入冲突检测和重复删除目的(例如，可不使用单独的排除签名)两者。类似地，在一些实施方案中，相同的序列号值可被用作读取-写入冲突检查分隔符和重复删除检查分隔符，即，针对读取-写入冲突被检查的提交记录集也可针对重复被检查。在至少一个实施方案中，重复删除可被默认执行，例如，使用写入集描述符，而不需要在事务请求描述符中包括逻辑约束描述符。
对于一些应用，客户端可能有兴趣在指定的事务集之间强制执行提交顺序，例如，递交分别对事务T1、T2和T3的三个不同事务请求的客户端可能希望使T1在T2之前提交，并且T3仅在T1和T2两者均已提交之后才提交。在一些实施方案中，可使用第二类型的逻辑约束描述符来强制执行这类提交排序约束。图23示出了根据至少一些实施方案的强制执行与在基于日志的事务管理器处接收的事务请求相关联的排序约束的示例。如所示，事务请求描述符2344包括读取-写入冲突检查分隔符2312、读取集描述符2314、写入集描述符2316和不同于图22的逻辑描述符2218的类型的逻辑约束分隔符2318。TRD 2344的写入有效负载没有在图23中示出。在所描绘的实施方案中，逻辑约束描述符2318包括指示其表示排序约束的LC类型字段2319、排序检查分隔符2220以及分别对应于事务T1和T2的所需排序签名2322A和2322B。逻辑约束描述符2318可包括在TRD2344中以确保所请求事务仅在事务T1和T2两者(由排序签名2322A和2322B所表示)均在先前已经提交的情况下才被提交。
为了确定是否接受所请求的事务，日志记录服务可能再次必须执行图23中所示的示例中的两种类型的检查：一种类型用于检测读取-写入冲突，而一种类型用于确保事务T1和T2已经被提交。在所描绘的实施方案中，持久性改变日志2310中的提交记录2352可每个包括各自的提交序列号(CSN 2304)、写入集描述符(WSD)2305和排序签名2306。为了确定读取-写入冲突是否已经发生，如之前内容，日志记录服务可标识CR集2309，始于对应于读取-写入冲突检查分隔符2312的序列号并且结束于最近提交记录2352F，其写入集将针对与所请求事务的读取集描述符2314的重叠而进行评估。如果检测到读取-写入冲突(即，如果这类重叠存在)，那么所请求事务可被拒绝。
为了确定所请求事务的排序约束是否被满足，在所描绘的实施方案中，另一CR集2359可被标识为始于对应于排序检查分隔符2320的序列号并且结束于最近提交记录2352F。日志记录服务可能必须验证具有匹配所需签名2322A和2322B的排序签名的各自提交记录存在于CR集2359内。如果在CR集2259中没有发现所需签名2322中的至少一个，那么排序约束可能被违反并且所请求事务可能被拒绝，即使没有检测到读取-写入冲突。如果在CR集2359中发现两种排序签名，并且如果没有检测到读取-写入冲突，那么事务可被接受用于提交。
存储在CR 2352内(并且在TRD 2344中)的排序签名在不同实施方案中可使用多种技术生成。在一些实施方案中，它们可由事务的写入集生成；在其他实施方案中，排序签名可至少部分基于其他因素。例如，在一些实施方案中，请求客户端的身份除了可编码在写入签名中之外还可编码在排序签名中，请求事务时的时钟时间可编码在排序签名中，或者可编码对可从其请求事务的位置的指示，等等。在一些实施方案中，可应用如上文关于用于表示排序签名而非写入集签名的不同技术的使用所描述的类似考虑因素。因此，在一些实施方案中，可使用不同的技术来生成排序签名而非用于生成写入集描述符内容，即使排序签名和写入集签名两者均从相同的基础写入位置导出。例如，可使用不同的散列函数或不同的散列值大小。然而，在其他实施方案中，写入集描述符可用于读取-写入冲突检测和排序强制执行目的(例如，可不使用单独的排序签名)两者。类似地，在一些实施方案中，相同的序列号值可被用作读取-写入冲突检查分隔符和排序检查分隔符，即，针对读取-写入冲突被检查的提交记录集也可针对排序被检查。在一些情况下，与写入集无关的任意数字或字符串可被用作排序签名。在至少一个实施方案中，约束描述符可不包括LC类型字段；而是，约束的类型可由约束描述符在事务请求内的位置指示。在一些实施方案中，“所需的”标记可与排序签名相关联，并且“排除的”标记可与重复删除签名相关联，例如，来替代使用LC类型字段。如先前在读取-写入冲突检查分隔符的背景下所提及，在一些实施方案中，CSN上限也可在事务请求描述符内被指定以指示应针对约束检查被检查的提交记录范围，而不是仅指定CSN下限。
在一些实施方案中，可强制执行比图23中所示更复杂的排序约束。例如，取代简单地请求日志记录服务以验证事务T1和T2两者必须在所请求事务的提交之前已经被提交(以任何顺序)，客户端可能能够请求T1必须在T2之前已经被提交。类似地，在一些实施方案中，客户端可能能够请求负排序要求：例如，某个事务集{T1,T2,Tk}应当在所请求事务之前已经按某个指定顺序(或按任何顺序)被提交，并且还有某个另外的事务集{Tp,Ts}不应该已提交。
在图22和图23中，单种类型的逻辑约束在所示的事务请求中被指示。在一些实施方案中，客户端可能希望对各种事务执行若干不同类型的逻辑约束。图24示出了根据至少一些实施方案的包括多个逻辑约束描述符的事务请求描述符的示例。将应用一个排序约束，并且将对由事务描述符2444表示的相同请求事务应用一个重复删除约束。在所描绘的实施方案中，读取和写入集描述符包括被读取或写入的每个数据项目的32位(4字节)散列值。例如，各自的4字节读取散列签名2464A和2464B可表示读取集描述符2404中的两个数据项目位置，并且各自的4字节写入散列签名2465A和2465B可包括在写入集描述符2406中以表示在事务被提交的情况下目标用于写入的两个位置。读取-写入冲突检查分隔符2402将用于选择持久性改变日志中序列号范围的下限，所述持久性改变日志的提交记录将针对所请求事务进行读取-写入冲突检查。
在所描绘的实施方案中，事务请求描述符2444也可包括排序约束描述符2408A和重复删除约束描述符2408B。排序约束描述符2408A可包括约束类型字段2409A、排序检查分隔符2410和对应于其提交必须针对将被接受的所请求事务已经完成的事务的一个或多个所需排序签名(诸如2412A和2412B)。重复删除约束描述符2408B可包括约束类型字段2409B、重复删除检查分隔符2420和重复删除排除签名2422。
如所示，在所描绘的实施方案中，所需排序签名2412A、2412B和重复删除签名2422可分别包括128位(16字节)散列签名2466A、2466B和2467。因此，在所描绘的示例中，逻辑约束签名每个可占据的位是用于读取和写入集签名的每个数据项目所使用的位的四倍之多，相对于针对读取-写入冲突检测执行的比较，此可帮助减少逻辑约束相关的比较的散列碰撞数目。在一些实施方案中，加密散列函数(诸如MD5)可用于排序和/或重复删除签名。在至少一些这类实施方案中，加密散列函数的使用可帮助将评估逻辑约束中的错误机率减小到接近零。虽然基于假阳性的散列碰撞(例如，基于假阳性的读取-写入冲突检测)的低得合理的事务拒绝率可能是可接受的，但是至少一些客户端可能更关心避免因假阳性的散列碰撞(例如，在提交排序的情况下)而对事务的接受，并且加密强度散列函数的使用可帮助避免这类错误的事务接受。在一些实施中，客户端可能能够选择散列函数用于重复检测和/或用于排序目的。在一些实施方案中，相比图24中所示的，不同的散列函数和/或散列值长度可用于重复删除签名、排序签名和/或读取或写入签名，例如，重复删除和排序签名的大小可不同。在至少一些实施方案中，读取的或写入的数据项目的地址可用于读取/写入集签名、重复删除和/或排序签名，例如，而不是使用由地址生成的散列值。在一个实施方案中，重复删除和/或写入签名除了从写入数据的位置导出之外，或者代替其的是，还可从写入有效负载导出。
在一些实施方案中，另外的逻辑约束也可在事务请求描述符中被指定，诸如数据完整性/有效性约束或提交截止期限约束。示例性数据完整性或有效性约束可要求，例如特定值V1可仅存储在数据存储区DS1中，如果不同值V2早已存储在DS1中或某个其他数据存储区中。数据有效性约束可定义将被存储的指定数据类型或数据项目的可接受范围(对存储在指定的数据存储区位置中的值是无条件的或有条件的)。提交约束可指示事务提交将被完成的截止期限，意图在于如果不满足截止期限，则应当放弃或中止事务。
图25是示出根据至少一些实施方案的操作的方面的流程图，所述操作可响应于指示一个或多个逻辑约束的事务请求而在日志记录服务处执行。在所描绘的实施方案中，给定事务的提交要求可包括并发控制要求(例如，未发现上文所述的类型的读取-写入冲突的要求)以及逻辑约束要求。在至少一些实施方案中，对于单个事务，可支持重复删除和排序逻辑约束两者(也可支持其他逻辑约束，但是图25中仅示出关于重复删除和排序的操作)。如元素2501中所示，包括事务T1的一个或多个逻辑约束描述符的事务请求描述符可接收在与日志记录服务的特定持久性改变日志实例相关联的冲突检测器处。对于每个逻辑描述符，在所描绘的实施方案中，对应的检查分隔符可被指定，以用于选择将被分析以确定逻辑约束是被满足还是被违反的提交记录集。也可针对每个逻辑约束指定一个或多个签名的各自集。所请求事务的读取和写入集也可与读取-写入冲突检查分隔符一起被指示。如先前所提及，在一些实施方案中，相同的分隔符可如用于检查读取-写入冲突一样用于一个或多个逻辑约束。而且，在至少一个实施方案中，逻辑约束可能不要求单独的签名；而是，例如，写入集签名可被用作重复删除和/或排序签名。
使用读取-写入冲突检查分隔符，在所描绘的实施方案中，可标识将被分析的第一提交记录集CRS1。这类集可例如包括其序列号位于如下范围中的那些提交记录：始于读取-写入冲突检查分隔符，高达最近存储的提交记录的序列号(或高达事务请求中所指示的不同上限)。如果检测到读取-写入冲突(元素2504)(例如，如果CRS1的任何提交记录的写入集与所请求事务的读取集重叠)，那么可拒绝/中止事务(元素2531)。对读取-写入冲突的检查在本文中也可被称为验证所请求事务满足并发控制要求。在一些实施方案中，可通知从其接收事务请求的客户端，事务已经被中止。
如果没有检测到读取-写入冲突(也在对应于元素2504的操作中)，那么在所描绘的实施方案中可依序检查由对应的描述符指示的逻辑约束中的每个。可检查所述序列中的下一个逻辑约束描述符，并且可基于与约束相关联的检查分隔符而选择新的提交记录集CRS-k用于约束分析(元素2507)。例如，CRS-k可包括具有在始于分隔符并结束于最高记录提交序列号(或高达事务请求中所指示的不同上限)的范围中的序列号的所有提交记录。将被执行的分析可取决于逻辑约束描述符的类型。如果重复删除约束将被检查，以及如果通过比较CDR-k的重复删除签名与所请求的事务而发现重复(元素2510)，那么也可拒绝/中止事务(元素2531)。如果约束为重复删除约束并且没有发现重复(如也在元素2510中所检测)，以及如果仍然有更多的逻辑约束待分析，那么可检查下一个逻辑约束描述符并且可对所述下一个逻辑描述符重复对应于元素2507向前的操作。
如果约束描述符指示排序约束，所述排序约束指示提交事务的一个或多个所需签名，那么可针对排序约束检查CRS-k以确保所需的签名事实上已经被存储用于其提交已经完成的事务。如果没有发现所需事务的提交记录(如在元素2513中所检测)，那么也可中止/拒绝所请求的事务(元素2531)。如果发现所请求事务的提交记录(也在对应于元素2513的操作中)，那么排序约束处理可能完成。如在读取-写入冲突检测的情况下，在至少一些实施方案中，逻辑约束检查也可使用用于比较的散列函数执行，因此避免了扫描提交记录集的开销。如果任何逻辑约束描述符保留(元素2516)，那么继而可对它们进行检查。如果没有保留逻辑约束描述符(如也在元素2516中所检测)，那么可接受事务用于提交。在所描述的实施方案中，例如，在复制DAG的若干节点处，可发起将事务的提交记录保存在持久性存储装置中的程序(元素2519)。如果复制成功(例如，如果提交记录的足够数目的副本被成功地存储在各自的存储装置处)(如元素2522中所检测)，那么事务的提交可被认为完成。如果出于某种原因，没有存储所需数目的副本，那么可仍然拒绝/中止事务(元素2531)。在一些实施方案中，可将事务已经被成功地提交的通知传输到请求客户端(元素2525)。
在一些实施方案中，检查一个以上逻辑约束的操作可替代地被并行执行。在一个实施方案中，读取-写入冲突检查和逻辑约束检查的任何组合可被并行执行。在一些实施方案中，关于所指示的每个逻辑约束的响应可被提供到请求客户端，即使一个或多个约束未被满足。例如，在具有重复删除约束和排序约束的事务请求的情况下，即使重复删除约束未被满足，也可检查排序约束，并且对两种约束的评估结果可被提供到客户端。在一些实施中，客户端可能能够显式地请求将检查给定事务请求的逻辑约束的指定子集或全部。
日志协调的存储组的定价策略
使用如上文所述的基于日志的事务管理器集体管理至少包含写入的事务的一组数据存储区在本文中可被称为日志协调的存储组(LCSG)的成员数据存储区。例如，LCSG可包括多个数据存储区实例，诸如非关系数据库的一个或多个实例、关系数据库的一个或多个实例、提供商网络存储服务的一个或多个存储对象、存储器中数据库实例、实施持久性队列的排队服务、通知服务等。针对数据存储区成员实例化的特定的基于日志的事务管理器也可被认为是LCSG的一部分。在至少一些实施方案中，LCSG可能能够允许用户请求多种跨数据存储区操作。例如，在LCSG处给定事务内执行的单个逻辑写入可最终被转化成(即，可导致)应用在若干不同数据存储区的多个物理更新。如此，可使得相同的基础改变的若干不同视图可经由数据存储区的各自数据访问接口而访问。
考虑以下情形：其中存储系统客户端希望使得相同写入请求的数据有效负载在用于持久性和数据耐久性的数据库系统实例、用于低延时访问写入请求结果的存储器中分布式缓存实例、用于脱机分析的数据仓库服务和用于长期记录保留的存档存储服务处可见。在一个实施方案中，客户端可构建将四个数据存储区中的每个显式地指示为应用数据的给定逻辑改变的目的地的事务。在另一实施方案中，除了支持跨数据存储区事务之外或取代它的是，实例化LCSG的日志记录服务可支持不要求所有不同的写入目标在给定的事务请求内被显式地指定的自动化的跨数据存储区变换。而是，例如，响应于配置请求或在LCSG设置期间，客户端可能能够指示对于引导到数据库实例的任何给定写入，对应的表示将被自动传播到存储器中缓存、数据仓库服务和存档存储服务。在一些实施方案中，可支持一对给定的数据存储区之间两个方向上的变换。例如，如果客户端应用执行直接到数据库实例的写入，那么写入的结果可由日志记录服务以存储器中缓存所预期的适当格式自动添加到存储器中缓存，并且如果客户端应用执行直接到存储器中缓存的不同写入，那么该不同写入的结果可以数据库实例所预期的格式自动传播到数据库实例。
在一些实施方案中，日志记录服务可实施在LCSG处执行的操作的若干不同定价策略，其中的至少一些可以是基于代表客户端执行的操作类型的混合(例如，在时间间隔期间执行了多少跨数据存储区的变换和/或事务，其与涉及对单个数据存储区的写入的许多操作相反)。对于给定计费时段向LCSG客户收取的计费金额可基于如下文所述的多种因素和针对客户或由客户选择的一项或多项定价策略而变化。下文所述的定价策略中的至少一些对于给定客户端可彼此结合使用，例如，分级定价可应用于供应的吞吐量和尽力而为型资源分配模式两者，并且各自的供应的吞吐量定价策略可应用于LCSG的每个数据存储区。
在至少一个实施方案中，包括在给定LCSG内的不同数据存储区的数目、所包括的数据存储区的类型和/或代表客户端执行的跨数据存储区操作(涉及在不同数据存储区处生成初始目标到特定数据存储区的写入的第二表示的操作或事务)的数目可影响计费金额。例如，根据一个定价策略，建立具有八个数据存储区的LCSG可能比建立具有四个数据存储区的LCSG花费得多，假定其他因素诸如整体工作负载水平和/或数据集大小相同。根据其他示例性定价策略，具有支持特定工作负载水平的四个关系数据库实例的LCSG可比包括支持相同的工作负载水平的四个存储器中数据库实例的LCSG花费得多。在一些实施方案中，可根据执行的跨数据存储区操作对客户端计费特定金额。在一个实施方案中，跨数据存储区操作的费用也可基于所涉及的数据存储区的类型而变化，例如初始引导到关系数据库的写入在存储器中数据库处被转化成另外写入的操作花费的金额可不同于初始引导到非关系数据库的写入在存储器中数据库处被转化成另一写入的操作花费的金额。在一些实施方案中，写入传播的方向也可影响操作的价格，例如从数据存储区DS1向DS2的写入的转化花费的金额可与从DS2向DS1的写入的转化花费的金额不同。
在一些实施方案中，可在提供商网络处分配资源(诸如计算服务器、存储装置、网络带宽、存储器等)以供处在若干模式中的一种的LCSG使用。在资源分配的供应吞吐量模式中，日志记录服务的客户端可指示注册为LCSG的成员的特定数据存储区的目标吞吐速率(例如，每秒100个事务)，并且日志记录服务可保留足够资源，使得所请求的吞吐量可为持续的(至少在正常操作条件下，例如，在无失效下)。根据基于供应吞吐量模式的定价策略，客户端可针对目标吞吐速率被计费，即使由客户端递交的实际工作负载恰巧在给定计费时段期间低于目标。在一些实施方案中，不同的供应吞吐量可由客户端针对给定的LCSG的各种数据存储区来请求。根据一些实施方案，供应吞吐量的计费率在一个数据存储区与另一数据存储区之间可不同，例如非关系数据库的100个事务/秒的供应吞吐量的计费率可不同于作为相同LCSG的成员的关系数据库的100个事务/秒的供应吞吐量的计费率。
在至少一些实施方案中，在被称为尽力而为模式的不同资源分配模式下，日志记录服务可能不一定保留或献出对应于客户端的指定目标吞吐量的资源。而是，例如，来自一个或多个共享池的资源可被指派给客户端的LCSG。随着客户端工作负载水平波动，日志记录服务可例如基于共享池中的可用容量而对指派给客户端的资源集作出尽力而为的调整。在至少一些实施方案中，用于尽力而为资源分配模式的定价策略可导致针对相同工作负载水平的计费率不同于供应吞吐量资源分配模式的定价策略。如在供应吞吐量的情况下，在一些实施方案中，不同的计费率可针对尽力而为资源分配应用于不同数据存储区。
根据至少一个实施方案，可实施分级式的基于吞吐量的定价模型。例如，在客户端在0个事务/秒与1000个事务/秒之间进行递交的情况下对计费率B1(例如，每个事务)的收费与对于介于1000个事务/秒与2000个事务/秒之间的事务速率的计费率B2的收费等可以是不同的。在一些实施方案中，类似的基于层级的定价也可应用于带宽使用，例如，对所传送数据的每千兆字节的计费率的收费在所传送的总的千兆字节数目介于0与10GB/天的情况下与所传送的总的千兆字节数目介于10与20GB/天的情况下可以是不同的。在一些实施方案中，计费金额可至少部分基于LCSG客户端关于所用的持久性改变日志和/或关于LCSG的成员数据存储区所需的高可用性水平、数据耐久性、延时而变化。在至少一个实施方案中，LCSG可实施在存储服务处，所述存储服务原生地支持指定的数据存储区类型集，但是也允许添加定制扩展，例如，针对由所述服务原生地支持的数据存储区类型与不原生地提供支持的不同数据存储区类型之间的变换。在一些这类实施方案中，应用于给定扩展的使用的计费率可不同于针对原生支持的数据存储区类型所使用的计费率。
在LCSG的各种数据存储区每个经由每个实施其自身的定价策略的提供商网络的各自服务实施的一个实施中，客户端可针对那些提供商网络服务的使用以及针对LCSG的使用而被单独计费。例如，可根据数据库服务的定价策略计算引导到LCSG的数据库实例的读取的计费金额，而对LCSG事务和跨数据存储区变换操作的计费可根据LCSG定价策略确定。
在至少一个实施方案中，可实施一个或多个编程接口(诸如网页、API等)以使得日志记录服务的客户端能够查看备选的定价策略和/或基于它们的偏好和要求选择特定定价策略。工作负载相关的度量(诸如整体请求的事务和/或读取速率、所执行的跨数据存储区和单个数据存储区操作的数目、所用的网络带宽等)可从针对客户的LCSG分配的资源收集。在至少一些实施方案中，由实施LCSG的日志记录服务的控制平面执行的计费相关工作的部分可包括将工作负载记录分类成指示跨数据存储区操作的子集对指示单个数据存储区操作的不同子集。例如，两种类型的操作的写入记录(单个数据存储区对跨数据存储区)可存储在给定数据存储区处的相同日志中，并且工作负载分析器控制平面部件可能必须检查写入记录的内容以确定写入记录是表示跨数据存储区写入还是单个数据存储区写入。在一个实施中，用于LCSG的提供商网络的一组分布式监测代理可用于度量收集。取决于为LCSG选择的定价策略和所收集的度量，可确定对特定计费时段的计费金额并且向客户端指示所述计费金额。
图26示出了根据至少一些实施方案的示例性系统环境，其中可针对各自的日志协调的存储组(LCSG)实施各自的定价策略。如所示，系统2600包括两个LCSG 2605A和2605B。LCSG 2605A包括两个数据存储区2630A和2630B，而LCSG 2605B包括四个数据存储区2630C、2630D、2630E和2630F。基于日志的事务管理器(LTM)2602A(其包括冲突检测器2615A、持久性改变日志2601A和一组写入应用器2617A)被配置成处理包括由客户端引导到数据存储区2630A和2630B的写入的事务请求。类似地，LTM 2602B(其包括冲突检测器2615B、持久性改变日志2601B和一组写入应用器2617B)被配置成用于管理由客户端引导到数据存储区2630C–2630F的写入。持久性改变日志2601在本文中也可被称为写入日志。
实施LCSG的日志记录服务或存储服务的控制平面2649可包括负责配置和管理任务的多个部件，包括例如管理LCSG成员资格信息、在客户端账户与指派给账户的服务资源之间的映射、记载各种LCSG所使用的定价/计费策略等等。在所描绘的实施方案中，计费管理器2651可负责例如基于针对引向LCSG 2605A和2605B的请求的一个或多个定价策略选项而生成客户端计费金额。在所描绘的实施方案中，可用的定价策略集可被指示给服务的实际或潜在客户，所述服务经由一个或多个编程接口(诸如网页、API、命令行工具或定制GUI)实施LCSG。在至少一些实施方案中，客户也可经由这类编程接口指示应用于其LCSG特定的定价策略，例如在它们将各种数据存储区2630注册为LCSG成员时，或者经由在LCSG被设置之后的某个时间点递交的定价策略改变请求。在所描绘的实施方案中，定价策略2644A已经针对LCSG 2605A被标识，而不同的定价策略2644B已经被选择用于LCSG 2605B。每个定价策略可指示例如在至少指定的计费时段期间将用于各种不同操作类型和/或资源使用单位的计费率。针对给定计费时段对客户收取的计费金额(例如，BA1或BA2)可通过计费管理器2651基于在计费时段期间对它们的LCSG有效的一个或多个定价策略以及基于对计费时段期间所收集的各种度量的分析而确定。
度量收集器2655A可负责监测各种资源，诸如用于数据存储区2630A和/或LTM2602的服务器和装置；以及将对所收集度量的指示提供给计费管理器2651。在LCSG实施在提供商网络内(例如，使用提供商网络的服务，诸如计算服务、存储服务等)的实施方案中，预先存在的度量收集基础设施可用于所述服务中的一些或全部，生成计费金额所需的度量中的至少一些可通过计费管理器从所述服务获得。在一个实施方案中，控制平面2649可包括用于各种定价/计费相关任务的各自部件，例如，成员资格管理器，其负责标识每个LCSG的成员；度量分析器，其用于将所收集的工作负载度量分类成按客户端和/或按操作类型的子组；以及计费生成器，其基于所选的定价策略和工作负载度量为各种客户端产生计费金额。
在应用于LCSG 2605的给定定价策略2644上可考虑多个不同因素，诸如作为LCSG的成员的数据存储区2630的数目和/或类型、操作混合(单个数据存储区写入对跨数据存储区写入)、所用的资源分配模型(例如，供应吞吐量对尽力而为)、所请求的事务速率等等。图27示出了根据至少一些实施方案的单数据存储区和跨数据存储区写入操作的示例。LCSG2705在所描绘的实施方案中包括六个成员数据存储区：NoSQL DB实例2730A、键值存储器中DB 2730B、分布式缓存实例2730C、关系DB实例2730D、存储服务对象2730E和存档服务对象2730F。如所示，给定的LCSG的成员数据存储区可实施非常不同的数据模型(例如，关系对非关系、结构化记录对非结构化数据对象等等)，并且在至少一些实施方案中，不同的读取接口和数据格式可因此在成员数据存储区处使用。
图27中示出了两种类型的写入操作，显式地包括在客户端所请求的事务中的写入，和日志记录服务被配置成自动执行的写入(例如，作为显式请求的写入的结果或副作用)。事务请求2702A指示写入有效负载W1将被引导到NoSQL DB实例2730A，并且也将被引导到存储服务对象2730E。因此，写入有效负载W1的表示W1-A被存储在NoSQL DB实例2730A中，并且相同的写入有效负载的另一表示W1-B被存储在存储服务对象2730E中。类似地，事务请求2702B也包括对有效负载W2的跨数据存储区写入的请求。因此，写入有效负载W2的第一表示W2-A被存储在关系DB实例2730D处，而写入有效负载W2的第二表示W2-B被存储在分布式缓存实例2730C处。事务请求27002C包括单个数据存储区写入。事务请求2702C的写入有效负载W3的表示W3-A因此被存储在NoSQL DB实例2730A处。在至少一些实施方案中，对具有单个数据存储区写入的事务的计费率可与对跨数据存储区写入事务的计费率不同。在至少一些实施中，基线计费率可按事务进行收取，并且另外的计费金额可基于包括在事务中的写入的数目和目的地数据存储区类型而收取。
除了所请求的事务中所显式指示的写入之外，LCSG 2705也可支持从一个成员数据存储区到另一成员数据存储区的数据的自动变换和/或复制。图27中示出了这类跨数据存储区变换的两个示例。在第一示例中，写入有效负载W1的第三表示W1-C从存储服务对象2730E的表示W1-B自动生成并且被存储在键值存储器中数据库2730B中。在第二示例中，使用W2-A作为源，写入有效负载W2的第三表示W2-C被存储在存档服务对象2730F处。在至少一个实施中，各自的写入应用器可针对每对源和目的地数据存储区进行设置，这类自动的跨数据存储区变换操作将在源数据存储区与目的地数据存储区之间被执行。例如，特定写入应用器可被注册为收听器，当写入(诸如W1-B)被应用于存储服务对象2730E时，所述收听器将被通知，使得对应的写入(诸如W1-C)可在键值存储器中数据库2730B处执行。根据LCSG2705的适当的定价策略，在所描绘的实施方案中，各自的计费率可针对自动的跨数据存储区变换的每种类型进行设置。在不同实施方案中，计费率可基于各种因素，诸如特定源和目的地数据存储区类型、将特定写入应用于源数据存储区的时间与将对应的表示应用于目的地数据存储区的时间之间的可接受的延迟等等。因此，例如，计费率BR1可用于在存档存储服务2730F(目的地数据存储区)内生成关系DB实例2730D(源数据存储区)中原始写入的对象的不同表示，而不同的计费率BR2可用于在不同的目的地数据存储区(诸如分布式缓存实例2730C)内生成相同对象的不同表示。对于一对给定的数据存储区，在至少一些实施方案中，跨数据存储区变换操作的方向可影响计费率。
图28示出了根据至少一些实施方案的在确定日志协调的存储组的定价策略时可能考虑到的因素的示例。在一些实施方案中，数据存储区2802的数目和类型可影响定价的若干方面，包括可能要求客户端支付的初始预先费用，以及基于继续使用的费用。例如，为了对具有四个非关系数据库实例的LCSG进行设置，计费金额可不同于用于设置具有非关系数据库、关系数据库、分布式缓存实例和在存档服务处的存档实例中的每个具有一个实例的LCSG的计费金额。LCSG中的数据存储区的数目也可表示相同的基础数据的可能的客户端可访问的视图的数目。
在至少一些实施方案中，工作负载操作类型混合2804可影响计费金额，例如，如上文所讨论，跨数据存储区操作可能具有不同于单个数据存储区操作的费用。在一些实施方案中，客户的工作负载中的读取和写入的混合也可影响计费金额，例如，读取的费用可能一般少于写入的费用。如上文关于图15所述，在至少一些实施方案中，日志读取接口可能使得客户端能够直接向LCSG的持久性日志发布读取，并且使用这类接口的每次读取的费用可能不同于使用数据存储区的接口的每次读取的费用。在对数据存储区的读取由提供商网络的各自服务(即，并非由日志记录服务本身)处理的一些实施中，对使用数据存储区的原生读取接口的读取的计费可与同日志记录服务的使用相关联的计费分开处理。
在一些实施方案中，对LCSG的使用的定价策略可基于资源分配模式2806而不同。在供应吞吐量模式下，日志记录服务可能必须保留或献出资源用于客户端以确保足够容量仍然可用于客户端的指定吞吐量水平。相比之下，为了在尽力而为资源分配模式下履行客户端请求，可使用共享资源，其可能使得日志记录服务资源的平均利用水平能够高于供应吞吐量模式。因此，在至少一些实施方案中，使用供应吞吐量模式时与使用尽力而为模式时，可针对相同实际事务速率向客户端收取不同金额。在一些实施方案中，请求速率层级2808可针对定价策略被定义。根据基于层级的定价，给定事务的计费率可取决于客户端是否每秒发出介于0与1000个之间的事务请求或客户端是否每秒发出介于1000与2000个之间的事务请求而不同。在至少一些实施方案中，客户端的工作负载的网络带宽使用2810可影响定价策略。取决于事务的性质，事务请求的特定数目N1可导致第一客户端的X个千兆字节的通信量，而N1个事务可导致另一客户端的Y个千兆字节的通信量(或在不同时间间隔期间甚至对于第一客户端)。由于由日志记录服务引发的资源使用中的至少一些可与网络带宽成比例地变化，所以日志记录服务的一些定价策略可至少部分基于所测量的带宽使用。在各种实施方案中，由日志记录服务使用的监测基础设施(例如，度量收集器2655A)可使用多种技术来将带宽使用指派给不同客户端，例如，这类指派可基于并入在网络数据包标头内的客户端IP地址、并入在数据包标头或主体内的客户端标识符等等。
在至少一些实施方案中，定价策略可基于延时要求2812、可用性要求2814和/或数据耐久性要求2816而定义和/或选择。例如，一个客户端的应用集可能具有对多数事务将在对应的事务请求被递交的2秒内被接受的要求，并且这类客户端可能愿意支付更高的计费率/事务，只要所递交事务的至少95％在2秒内被接受。基于这类延时百分比度量或平均延时的定价策略因此在这类实施方案中可由日志记录服务支持。不同客户端和/或客户端应用在一些实施方案中可能对日志记录服务具有不同的高可用性要求2814(例如，LCSG的各种部件是否需要联机并且99.99％的时间或99.9999％的时间具有响应性)，此可能影响所选的定价策略。在至少一个实施方案中，对数据耐久性的要求2816(例如，日志记录的最大可接受数据丢失率)也可影响定价。
日志记录服务可原生地支持多个不同的数据存储区类型，诸如在提供商网络处实施的专有数据库或存储服务、流行的开源数据库、缓存服务等。此外，在至少一些实施方案中，日志记录服务可由第三方或客户端扩展。在这类实施方案中，可暴露一组可扩展性接口，允许除日志记录服务的运营商以外的组织或个人添加对基于日志的事务管理的支持用于新数据存储区类型。示例性扩展可能包括未由日志记录服务原生地支持的各种数据存储区的写入应用器，或允许这类数据存储区充当图27中所示的类型的自动化的跨数据存储区变换的源或目的地的数据变换器。在至少一些实施方案中，LCSG的定价策略可将这类扩展的使用考虑在内，例如应用于使用扩展的事务与应用于使用原生支持的数据存储区的事务的收费可不同。
应注意，在各种实施方案中，图27中所示的因素中的若干(或全部)可被组合以标识将针对给定客户用于给定LCSG的特定定价策略。例如，在一些实施方案中，分级定价和/或基于带宽的定价可组合供应吞吐量或尽力而为资源分配模式而应用。类似地，在各种实施方案中，包括在LCSG中的数据存储区的数目和类型可组合工作负载操作混合、吞吐量层级、基于延时的定价等而影响计费金额。
在至少一些实施方案中，日志记录服务的客户端可被赋予从若干选项之中选择定价策略的机会。图29示出了根据至少一些实施方案的可用于向实施日志协调的存储组的服务的用户指示定价策略选项的示例性的基于web的接口。如所示，网页2901包括消息区2904和多个表单字段，所述表单字段可由日志记录服务用户使用来实验不同定价策略部件并且选择最适于用户要求和预算的特定的定价策略元素集。
如在消息区2904中所指示，在所描绘的实施方案中使用LCSG的费用可取决于其事务将使用日志记录服务进行管理的数据存储区的数目和类型。使用元素2907，用户可指示在使用网页2901估计或确定定价的LCSG中将包括多少种不同类型的数据存储区。例如，客户端可选择NoSQL数据库的零个或多个实例、关系数据库的零个或多个实例、存储器中数据库的零个或多个实例、和/或其他类型的数据存储区的零个或多个实例。对于页面2901上所示包括数据存储区计数字段的表单字段中的若干，日志记录服务可指示默认值(诸如NoSQL数据库实例的数目的默认值1)。在一些实施方案中，当用户在各种表单字段中填入值时，网页2901的其他元素中的数据可被即时或接近即时地更新。例如，如果用户将NoSQL数据库实例的数目从1改变到2，那么这类改变对总的月计费金额2925的影响可被实时指示。
在所描绘的实施方案中，使用表单字段2910，用户可指示对资源分配模式的偏好(例如，供应的吞吐量对尽力而为)。在图29的示例性情形中，可将分级定价模型用于单个数据存储区请求和跨数据存储区请求两者。对于每个数据存储区类型，写入的预期请求速率(例如，以写入/秒表示)可使用表单字段2913指示。跨数据存储区写入的预期请求速率(给定源数据存储区类型与给定目的地数据存储区类型之间)可使用表单字段2916指示。其他源和目的地对之间的跨数据存储区变换的预期请求速率可同样被指示，例如，通过点击字段2916中所示的链接以及指示源、目的地和速率。对于一个或多个字段诸如写入请求速率的字段，网页2901可提供具有离散的选项集的下拉式菜单(例如，使得防止用户指示对应条目的未被支持的值，诸如负请求速率)。在所描绘的实施方案中，用户也可使用元素2919指定带宽使用层级。对延时、数据耐久性和/或可用性的定制偏好可通过点击元素2922中所指示的链接而提供，并且这类偏好也可影响定价。基于用户输入的值对每月计费金额的估计可提供在网页2901的元素2925中。应注意，网页2901只是可用于允许日志记录服务的客户端在定价策略选项之中进行选择的编程接口的一个示例。在其他实施方案中，可使用多种其他方法，诸如具有定义的性能特性(例如，“小”对“中”对“大”LCSG)和定价策略的数据存储区的预定义包的使用。在其他实施方案中，可使用采用其他方法来定价的网页，诸如基于预算的模型，其中用户首先指示预算并且然后被引向可被支持用于这类预算的特定数据存储区组合、工作负载混合等等。在一些实施方案中，被指示为影响LCSG定价的因素可不同于图29中所示的因素。在各种实施方案中除了网页之外，还可使用API、定制定价GUI或其他编程接口。
图30是示出根据至少一些实施方案的操作的方面的流程图，所述操作可被执行以确定支持日志协调的存储组(LCSG)的服务处的计费金额。如元素3001中所示，代表客户端，服务可确定或标识多个数据存储区(诸如关系数据库、非关系数据库、存储器中数据库、分布式缓存环境、存储服务对象集合、文件系统等的实例)，所述数据存储区被指定为特定的日志协调的存储组的成员。在一些实施方案中，成员资格信息可在数据存储区被注册时(例如，当LCSG在客户端的请求下被设置时)在服务的控制平面部件处获得。在其他实施方案中，可向LCSG成员资格信息(其可随成员被添加或丢弃而随时间改变)的储存库进行咨询(例如，每个计费时段至少一次)，以确定当前成员资格。读取可经由其各自的读取接口而引导到数据存储区，而写入可至少部分基于写入记录日志的内容而被LCSG的事务管理器接受或拒绝。
如元素3004中所示，可将对影响LCSG使用的计费金额的多个定价策略选项或因素的指示提供给客户端。在至少一些实施方案中，客户端可使用类似于图29中所示的编程接口来指示给定的LCSG的潜在的数据存储区组合，并且服务可响应于客户端的输入来显示定价策略选项。定价策略选项可包括。在不同实施方案中，各种各样的因素可在确定定价时起到作用，包括例如作为LCSG的成员的数据存储区的数目和类型的某个组合、操作类型的混合(例如，单个数据存储区写入对多数据存储区写入)、资源分配模式(例如，供应吞吐量对尽力而为)、分级式或绝对的性能水平(例如，对于吞吐量或延时)、带宽使用、数据耐久性、可用性等等。
可从客户端接收这样的指示：对于至少某个时间段，特定定价策略(例如，至少部分基于客户端关于数据存储区选择、不同操作类型诸如跨数据存储区写入的预期工作负载水平等等所提供的输入而导出的策略)将用于客户端的LCSG(元素3007)。在所述时间段期间，有关定价策略的各种度量可被收集并且被提供例如到服务的计费/定价控制平面部件。可收集工作负载相关的度量，包括各种类型的客户端请求的数目和速率(以及与客户端请求相关联的响应时间或延时)，以及收集资源相关的度量，诸如由客户端使用的网络带宽。在一些实施方案中，控制平面部件可负责将工作负载记录(和/或资源使用度量)分类成表示不同操作类别的子组，诸如跨数据存储区对单个数据存储区写入(元素3010)。在所描绘的实施方案中，基于所收集的度量和为客户端选择或由客户端选择的定价策略，可确定所述时间段内的计费金额(元素3013)并且向所述客户端指示所述计费金额(元素3016)。在至少一个实施方案中，客户端可使用服务的编程接口来在未来计费时段内改变计费策略。
读取可重复性验证的描述符
如先前所提及，对于简单的读取操作的一些类型，基于日志的事务管理器可能能够仅基于读取位置(即，关于在事务期间从其读取数据的地址的信息)检测与随后的写入的冲突。然而，对于更复杂的读取，此纯粹基于位置的冲突检测可能不足以满足要求。图31示出了根据至少一些实施方案的在存储系统处的事件的示例性序列，其中对事务接受进行的基于读取位置的冲突检测的使用可导致数据不一致性。时间线3199示出了从日志记录服务的客户端角度来看的事件E1、E2、E3、E4和E5的序列，其中较早事件在左边，并且较晚的事件在右边。在E1之前，数据存储区3110包括具有至少三个记录的“雇员”表格。每个记录具有各自的位置(由具有前缀“L”的标签指示，诸如“Lc”)，并且包括雇员名字字段和工资字段。在所描绘的示例中，雇员“Andy”的工资为$X，并且雇员“Ann”的工资为$Y。事件E1对应于客户端对检索名字始于“A”的雇员的记录内容的读取请求R1进行的递交(例如，在类SQL的伪码中，可递交“从雇员名字始于“A”的雇员中选择*”的请求)。事件E2包括来自数据存储区的响应，其中R1的结果集包括雇员“Andy”和“Ann”的记录。所述两个记录的地址/位置Lc和Lk以及指示最近提交的写入(在读取之前)何时被应用于数据存储区3110的逻辑时间戳LTS1也被返回到客户端。
客户端然后基于R1的结果集执行对名字始于“A”的雇员的平均工资(“A_工资”)的计算(事件E3)。根据由客户端接收的结果集，A_工资被设置成$X和$Y的平均值(即，($X+$Y)/2)。同时，在对应于(LTS1+Δ1)的某个时间，新雇员“Art”(工资为$J)的记录通过写入应用器插入到雇员表格中的位置Ln处。在没有觉察到插入的情况下，客户端准备事务请求TR1，所述事务请求包括如由客户端计算的A_工资的写入。TR1还指示读取位置Lc和Lk(例如，使用两个位置的各自散列签名)和将逻辑时间戳LTS1指示为冲突检查分隔符。TR1在对应于逻辑时间戳(LTS1+Δ1+Δ2)的时间处在指派给数据存储区3110的基于日志的事务管理器(LTM)处被检查(事件E4)。作为冲突检测的部分，基于日志的事务管理器检查读取集位置Lc和Lk是否自LTS1以来已经被写入，以及未发现任何这类写入。因此，在提交逻辑时间戳为(LTS1+Δ1+Δ2)，A_工资的值不一致/不正确的情况下，所请求事务被接受用于提交(事件E5)。(假定所示事件的示例性序列，A_工资的值本应当已经被设置成($X+$Y+$J)/3，而非($X+$Y)/2，并且因此可被认为是不一致或不正确的。)应注意，差异并不是由LTM造成的错误的结果，而是以下事实的结果：对于一些类型的读取，基于地址的读取-写入冲突检测并不是总是能够用于验证读取可重复性(即，检查在读取被重新发布的情况下读取的结果集将不会改变)。
为了处理图31中所示的类型的问题，将被包括在事务请求中的读取描述符可能需要包括比位置指示符(诸如基于地址的散列签名)更复杂的元数据。例如，对于一些类型的读取，元数据可包括对用于读取的查询谓词的至少一部分(例如，类SQL查询的“where子句”)或甚至读取请求的整个文本的编码。在一些情况下，可在元数据中指示可被调用来确定读取的结果集是否已经改变的函数(或函数指针)。在一些实施方案中，可被评估以确定读取结果是否已经改变的表达可被提供为RRVM。术语“读取可重复性验证元数据”(RRVM)在本文中可用于指代信息：其可用于确定对应的读取请求在重新递交的情况下是否将具有与读取请求的先前递交相同的结果集：即，给定的读取请求是否表示在读取请求的原始递交之后的某个时间点处的“可重复读取”。
图32示出了根据至少一些实施方案的系统环境，其中响应于读取请求而提供的读取描述符包括RRVM部件。如所示，系统3200包括存储服务的异构存储组3201，其中所述存储组包括成员数据存储区3230A和3230B。每个数据存储区3230可表示各自的编程读取接口，诸如数据存储区3230A的读取接口3227A和数据存储区3230B的读取接口3227B。所述两个数据存储区不仅在读取接口方面而且在基础数据模型方面也不同(例如，一个数据存储区包括关系数据库的实例，而另一个数据存储区可表示非关系数据库的实例)。在一些实施方案中，数据存储区3230可能已经在特定客户端(诸如代表它数据存储区在提供商网络处被实例化的客户端)的请求下被注册为存储组3201的成员。每个数据存储区可包括多个各自的数据对象(例如，记录、文件、可经由web服务接口访问的非结构化数据对象、缓存条目等等，其取决于数据源的性质)，诸如数据存储区3230A的对象3210A–3210F和数据存储区3230B的对象3210M–3210Q。此外，每个数据存储区可存储一个或多个状态转变指示符3225，诸如对应于数据存储区处执行的各种写入操作的逻辑时间戳。例如，在数据存储区3230A的情况下，如果三个不同写入W1-A、W2-A和W3-A是以该顺序完成或应用，那么写入W3-A完成之后至少一个STI 3225A可对应于与W3-A相关联的逻辑时间戳。类似地，在数据存储区3230B处，在写入W1-B和W2-B按该顺序完成之后至少一个STI 3225B将表示对应于W2-B的逻辑时间戳。
在所描绘的实施方案中，存储组3201的各种成员数据存储区3230可每个被配置成根据共同的读取描述符格式3298生成读取描述符。响应于经由读取接口3227A在数据存储区3230A处接收的读取请求R1-A，例如，包括STI 3246A和RRVM 3244A的读取描述符3242A可被提供到存储服务的客户端侧部件3235。如上文所述，RRVM可用于在生成原始R1-A结果集3240A之后的某个时间点确定(预测具有某种高概率)结果集R1-A是否已经改变。在至少一些实施方案中，客户端侧部件3235可包括存储服务的前端请求处理者节点，所述节点从终端用户3266接收终端用户读取请求(和/或写入请求)并且将对应的内部请求引导到适当的后端数据存储区3230。在另一实施方案中，客户端侧部件3235可包括由存储服务提供的库的部件，所述部件可安装在客户端拥有的计算装置处并在所述计算装置处执行，例如，所述装置在实施异构存储组3201的提供商网络外部，或在所述提供商网络内。一般来说，位于实施异构存储组的提供商网络内或所述提供商网络外、能够使用本文所述的编程接口用于读取请求和/或提交请求的任何进程或装置可充当客户端侧部件。类似地，响应于经由读取接口3227B引导到数据存储区3230B的读取请求R1-B，除了R1-B结果集3240B之外，读取描述符3242B也可被提供到客户端侧部件。读取描述符3242B可包括RRVM 3244B，其可用于验证R1-B是否为可重复读取；以及在生成R1-B的原始结果集3240B时对应于数据存储区3230B的状态的STI。应注意，至少在一些实施方案中，包括RRVM 3244的读取描述符3242可响应于读取请求而提供，其独立于对应读取是否将用于事务请求(例如，写入是否取决于读取请求的结果集)。类似地，在至少一些实施方案中，包括RRVM的读取描述符可被提供，而独立于对数据存储区的写入是否直接由客户端侧部件执行，或写入是否经由上文所述的类型的基于日志的事务管理器协调和/或经由上文所述的类型的写入应用器传播。至少在一些实施方案中，对于简单的读取(例如，“从表格T1选择*，其中记录_id＝RID1”)，读取对象的地址或读取对象的标识符的编码(例如，散列签名)可足以验证读取可重复性。因此，甚至在基于谓词或基于查询子句的元数据被生成用于测试更复杂的读取的可重复性的实施方案中，一些RRVM也可包括基于位置的指示符。在至少一个实施方案中，指示所提供的RRVM的类型的字段可包括在读取描述符中，例如，RRVM是“单个位置散列签名”还是“复杂的查询编码”。
在至少一些实施方案中，数据存储区可以若干不同粒度存储关于状态转变的信息，并且一个以上状态转变指示符可包括在读取描述符中。图33示出了根据至少一些实施方案的读取描述符的示例性组成部件。在所描绘的实施方案中，示例性数据存储区3330包括多个表格3310，诸如表格3310A和3310B。每个表格包括多个数据记录，每个数据记录具有各自的记录标识符或RID(其可充当记录的位置指示符)3318和各自的记录修改时间戳(RMT)3320，所述时间戳指示应用于记录的最新更新或写入。因此，例如，表格3310A包括具有RID 3318A、3318B和3318C的记录，而表格3310B包括具有RID3318K、3318L和3318M的记录。每个记录可包括未示出的其他数据列或属性。在至少一些实施方案中，RMT 3320可表示逻辑时间戳(而非基于壁钟的时间戳)，例如依据生成单调递增的时间戳值的数据存储区可访问的逻辑时钟的输出值而表达。当记录被插入表格3310中时，在所描绘的实施方案中，其RMT可被设置成对应于插入的逻辑时间戳值；随后，如果相同记录被更新，那么RMT可被更新以指示更新的逻辑时间戳。在一些实施方案中，逻辑时钟可负责提供一序列单调递增的时间戳值(其可能不对应于壁钟时间值)。在一个实施中，对于每个存储组，可标识逻辑时间戳的单个源(例如，与组的事务管理器相关联的时钟)。在其他实施方案中，不同的数据存储区可使用不同的逻辑时钟。
在所描绘的实施方案中，除了记录层次修改时间信息之外，表格层次修改时间信息也可被维持，形式为表格修改时间戳(TMT)，诸如表格3310A的TMT 3316A和表格3310B的TMT 3316B。在所描绘的实施方案中，表格3310的TMT可指示该表格的记录的RMT之中的最近RMT。因此，对于表格3310，如果在给定时间点，具有RID3318C的记录是表格内的最近写入的记录，那么TMT 3316A也可包含与RMT 3320C相同的逻辑时间戳值。类似地，在甚至更高的粒度下，数据存储区修改时间戳(DMT)3308可被设置成表格的TMT之中的最近TMT值，其指示存储在数据存储区3330处的任何记录之中的最近改变。
在图33中所示的实施方案中，引导到数据存储区3310内的给定记录的读取的读取描述符可指示层次结构中所有三个层次的修改逻辑时间戳——记录层次(例如，指示修改被读取的记录的最后时间)、表格层次和数据存储区层次。如所示，响应于结果集包括表格3310A的记录3318B的读取请求R1，所生成的读取描述符RD1可包括RMT3320B、TMT 3316A和DMT 3308(除了读取可重复性验证元数据(RRVM)3340A之外)。类似地，响应于结果集包括表格3310B的记录3318M的读取请求R2，读取描述符RD2可包括RMT 3320M、TMT 3316B、DMT3308和不同的RRVM 3340B。如果读取的结果集包括若干不同记录，那么可在一些实施中包括那些记录的最少量的RMT，而在其他实施方案中，所有记录的RMT可包括在读取描述符中。类似地，如果给定读取请求的结果包括来自一个以上表格的记录，那么表格的TMT之中的最小TMT在一些实施方案中可在读取描述符中被指示，而在其他实施方案中，可包括含有所有表格的TMT的向量。在不同实施中以及对于不同类型的数据存储区，可使用状态转变记录的其他层次结构。例如，在数据存储区表格被划分成分区的实施方案中，分区修改时间戳可包括在读取描述符中(例如，除了TMT之外，或取代TMT)。在一些实施方案中，对于实施文件系统的数据存储区，对文件、目录和文件系统的写入的逻辑时间戳可被用作状态转变指示符的层次结构。在一些实施方案中，读取描述符中包括状态转变指示符的层次结构(取代仅仅是单个值，诸如DMT)可能使得基于日志的事务管理器能够作出不同保守水平的并发控制决定。例如，在一种保守方法中，事务管理器可标识自DMT以来已经被引导到数据存储区的任何记录的任何写入作为冲突写入，而在不太保守的方法中，可仅认为已经被引导到自其RMT以来读取的特定记录的写入作为冲突。
如图32中所指示，在至少一些实施方案中，读取描述符可由存储组的数据存储区提供到系统的客户端侧部件。在一些这类实施方案中，读取描述符可并入在客户端侧部件处生成的事务提交请求内，并且出于并发控制目的由事务管理器检查。在至少一些实施方案中，出于多种原因，尽管读取描述符可能必须通过事务管理器解译，但是日志记录服务或提供商网络的运营商可能不希望读取描述符的内部细节被递交读取和写入请求的终端用户看见。例如，服务运营商可能希望保留改变读取描述符的格式或内容的能力，这在终端用户已经变得习惯于预期固定大小的终端用户可读取的读取描述符的情况下可能比较难进行。因此，在一些实施方案中，读取描述符的内容可在它们被传输给客户端侧部件之前经历一个或多个变换。图34示出了根据至少一些实施方案的可在读取描述符被提供给存储系统的客户端侧部件之前应用于读取描述符的示例性变换。在所描绘的实施方案中，存储层次结构的三个层次(数据存储区、表格和记录)的各自修改逻辑时间戳包括在所生成的读取描述符中。如所示，未修改的或预变换状态中的读取描述符3401可包括N1+N2+N3+N4个字节，其中N1个字节用于原始的DMT 3408，N2个字节用于原始的TMT 3416，N3个字节用于原始的RMT 3420，以及N4个字节用于RRVM 3440。
在第一变换中，在所描绘的实施方案中，多个(N5)字节可被添加到读取描述符作为“填充”。在一些实施方案中，可将不同数目的字节添加到在相同数据存储区生成的不同读取描述符，例如，使用随机数字生成器来从某个选定的填充大小范围内选择填充字节的数目。在一些实施方案中，填充字节也可用随机选择的数据填充。这类随机生成的填充元素可帮助确保终端用户不假定所有读取描述符将具有相同大小。
除了填充变换之外，在一些实施方案中，读取描述符也可或替代地被编码或被混淆，使得其元素在不被解码的情况下不再可解译或可理解。因此，例如，填充的读取描述符3451可在传输到客户端侧部件之前被加密或编码成混淆的读取描述符3458。在所描绘的实施方案中，存储服务的服务器侧部件(诸如读取描述符可能必须被解码所在的事务管理器)可能具有必要的元数据(例如，解密凭证、或对将用于解码读取描述符的函数或方法的指示)，但是可能无法使终端用户访问撤销混淆所需的信息。可在各种实施方案中执行两种变换(填充和混淆)的不同序列，例如，在一些实施方案中，读取描述符元素的原始版本可在填充字节被添加之前，首先被编码。在一些实施方案中，可仅使用填充或仅使用混淆。在至少一些实施方案中，也可在读取描述符被传输到客户端侧部件之前应用其他变换，例如，可压缩描述符。
无状态的独立于数据存储区的事务
图35示出了根据至少一些实施方案的导致对来自存储系统的客户端侧部件的候选事务提交请求的递交的操作的示例性序列。客户端侧部件可例如包括在存储服务的前端请求处理者处运行的进程，或可安装在客户端拥有的计算装置处的存储服务提供商库的部件。BEGIN_TRANSACTION请求可例如在客户端侧部件时间线3599上的时间t1，从终端用户接收在客户端侧部件处。在一些实施方案中，客户端侧部件可响应于BEGIN_TRANSACTION请求分配或保留存储器缓冲区3535以准备候选事务请求。在其他实施方案中，存储器缓冲区3535可随着事务的不同读取和/或写入完成而被动态地分配。
在时间线3599上的时间t2处，读取请求R1可经由无状态协议从客户端侧部件引导到异构存储组3575的数据存储区DS1(例如，响应于在服务前端请求处理者或库部件处接收的终端用户读取请求)。在所描绘的实施方案中，异构存储组3575可包括成员数据存储区DS1、DS2、DS3和DS4，其中每个数据存储区可能已经被注册为存储组的成员，其写入操作将经由基于日志的事务管理器(LTM)进行管理。可也要求存储组3575的成员响应于读取请求而生成并传输读取描述符(例如，包括状态转变指示符和上文所述的类型的RRVM的描述符)。在一些实施方案中，存储组的至少一些成员可实施不同的数据模型(例如，关系对非关系、结构化对非结构化记录)，其具有对应的读取接口和记录/对象存储格式。如先前所提及，多个不同类别的数据存储区可包括在存储组中，包括例如关系数据库、非关系数据库、存储器中数据库、分布式缓存、可经由由提供商网络服务实施的web服务接口访问的存储对象的集合、在提供商网络处实施的排队服务或在提供商网络处实施的通知服务的实例。用于读取请求R1的协议可为无状态的，因为在所描绘的实施方案中，在对应于R1的结果集3510A和读取描述符3512A被传输到客户端侧部件之后，DS1可能不保留有关客户端侧部件的任何会话元数据。在不同实施方案中，各种无状态的应用层协议中的任一者可用于读取请求和响应，诸如根据REST(代表性状态传输)架构的各种HTTP(超文本传输协议)变体中的任一者。结果集3510A和读取描述符3512A可存储在存储器缓冲区3535中。
在时间线3599的时间t3处，事务范围内的第二读取请求R2可例如响应于终端用户的另一读取请求而经由无状态协议递交到存储组3575的第二数据存储区DS2。再者，在将结果集3510B和读取描述符3512B提供给客户端侧部件之后，数据存储区DS2可能不保留关于R2或客户端侧部件的任何会话状态元数据。在所描绘的实施方案中，存储组3575的成员数据存储区中没有一个可觉察到以下事实：事务已经在客户端侧部件处开始；对于数据存储区，每个读取请求可简单地表现为与任何其他读取或写入均无关的独立请求。
在时间t4处，其有效负载3520A取决于R2的结果集并且最终应用于数据存储区DS3的写入W1(如果所准备的候选事务最终被提交)可在本地执行，例如，在所描绘的实施方案中，到客户端侧缓冲区3535内的存储器的一部分。W1的写入描述符3522A(指示W1所引向的目标地址)也可在缓冲区中创建。例如，在一些实施中，目标地址的散列签名可被用作写入描述符3522A。在时间t5处，其有效负载3520B取决于R1的结果集并且引向DS4的写入W2可类似地在客户端侧部件的本地存储器中执行。在所描绘的实施方案中，W2的第二写入描述符3522B也可在客户端侧部件的存储器缓冲区3535中准备。
在时间t6处，可从终端用户接收COMMIT_TRANSACTION请求。因此，读取描述符3512A和3512B、写入描述符3522A和3522B以及写入有效负载3520A和3520B都可被包装到候选事务提交请求3524中以递交到存储组3575的LTM。LTM的冲突检测器3566可基于对读取描述符的分析和LTM的提交记录日志的选定子集(其中所述子集是至少部分基于读取描述符而选择)的内容而确定接受还是拒绝候选事务。如果检测到读取-写入冲突(例如，由于使用包括在读取描述符中的一个中的RRVM进行的确定)：R1或R2是不可重复的，因为随后的写入已经改变了在读取请求被重新递交的情况下将被返回的结果集，那么可拒绝候选事务。在这类情形中，在所描绘的实施方案中，客户端侧部件可重新尝试读取R1和R2，从而获得新的结果集和读取描述符，并且生成新的候选事务提交请求以递交给LTM。这类重新尝试可在尝试中的一次成功之前，或在终端用户(代表它事务被请求)被通知事务失效之前，被尝试某阈值次数。
在所描绘的实施方案中，如果冲突检测器3566接受提交请求3524，那么W1和W2的写入描述符以及有效负载可被存储在LTM的日志中。在至少一些实施方案中，写入描述符可被认为是提交请求中所包括的读取描述符的逻辑“对偶”，因为为了检测冲突，由先前存储的写入描述符所指示的写入可能必须针对与由读取描述符指示的读取的潜在重叠或实际重叠而被检查。因此，在高层次下，在给定实施中在写入描述符中对写入的指示方式可能必须与在读取描述符中对读取的指示方式逻辑地兼容。LTM的写入应用器3568可关于接受决定同步或异步地将写入W1和W2应用于它们的目标数据存储区DS3和DS4。在一些实施方案中，写入应用器也可利用无状态协议，并且目标数据存储区DS3和DS4可能不必存储关于写入应用器或关于由写入应用器发布的写入请求的任何会话相关的元数据。
因此，在图35中所示的实施方案中，多个写入(诸如W1和W2)可被提交作为客户端侧部件处准备的原子性事务的部分，而无需在所涉及的数据存储区处生成或存储任何事务相关的元数据。在一些实施方案中，可实施这类客户端侧多写入事务，即使基础数据存储区可能不原生地支持多写入事务，和/或即使基础数据存储区可能仅支持无状态的读取和写入操作。即，事务原子性和一致性可被提供给异构存储组的用户，即使成员数据存储区不保留给定读取发生的时间与写入发生的时间(其取决于给定读取的结果)之间的会话信息(或事务状态信息)。
如先前所述，基于日志的事务管理器可将对应于所提交写入的写入描述符(诸如3522A和3522B)存储在持久性改变日志(诸如使用上文所述的复制DAG实施的日志)中。在一些实施方案中，读取描述符的内容也可通过事务管理器保存，即使所提交的事务的读取描述符对于作出未来提交决定可能是不需要的。图36示出了根据至少一些实施方案的将写入描述符和读取描述符存储在各自日志中的示例性事务管理器。如所示，基于日志的事务管理器3602使用两个单独的持久性日志：写入描述符日志3610和读取描述符日志3620。在其他实施方案中，两种类型的描述符可被存储在共享的持久性日志中。读取描述符日志3610的内容可用于检查读取-写入冲突作为先前所述的乐观并发控制方法的部分，和/或用于也如先前所述的逻辑约束管理。读取描述符日志3620可用于例如工作负载分析，例如来确定跨异构存储组的不同部分的读取分布。在一些实施方案中，可保留被提交的和被拒绝的事务两者的读取描述符用于工作负载分析目的。也可分析被拒绝的事务的读取描述符以标识事务拒绝的原因，例如，以确定是否应采取任何行动(诸如将被足够频繁地读取并且被足够频繁地更新以引起许多事务拒绝的特定数据对象分区)来降低事务拒绝的频率。
图37是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在响应于读取请求而提供读取描述符的存储系统处执行。如在元素3701中所示，可建立包括多个数据存储区的异构存储组HSG1。不同的数据模型和/或读取接口可由组的成员数据存储区支持，例如，组可包括关系数据库、非关系数据库、存储器中数据库、分布式缓存实例、文件存储区或文件系统、包括可经由web服务接口访问非结构化数据对象的存储服务等等中的一个或多个实例。实施HSG1的服务的客户端可向组注册(添加)数据存储区或以编程方式从组移除数据存储区。在至少一些实施方案中，可要求组HSG1的所有成员数据存储区响应于具有根据由服务所指示的共同读取描述符格式的读取描述符(除读取结果集之外)的读取请求。
可接收引导到HSG1的数据存储区DS1的特定读取请求R1(元素3704)。R1可包括对用于确定其结果集的过滤准则的指示。过滤准则的性质可取决于目标数据存储区的类型而不同。例如，如果R1是支持SQL(结构化查询语言)或类SQL接口的数据库，那么过滤准则可被表达为SQL选择子句。如果DS1是呈现web服务接口的存储服务，那么过滤准则可被表达为一个或多个URL(通用资源定位符)。对于键值数据存储区，过滤准则可包括一组独特键，所述键继而对应于数据存储区内的特定记录位置/地址。读取请求的结果集可与表示DS1的先前提交的状态的数据存储区DS1的一个或多个状态转变指示符(STI)一起被标识(元素3707)。在一些实施方案中，STI可包括对应于提交写入向数据存储区的应用的逻辑时间戳，使得提交写入的结果在生成结果集时是可见的。在一个实施中，例如，STI可包括以下各者中的一者或多者：数据存储区层次修改逻辑时间戳、表格层次修改逻辑时间戳或记录层次修改逻辑时间戳(例如，图33中所示的DMT、TMT和RMT)。在一些实施方案中，取代逻辑时间戳，或除了逻辑时间戳之外，可使用基于壁钟的时间戳。
可生成对应于R1的读取描述符RD1(元素3710)。读取描述符可包括例如STI和至少某个读取可重复性验证元数据(RRVM)。可使用RRVM例如以确定R1是否为可重复读取，即，在第一次获得结果集之后的某个时间点，在R1被重新发布的情况下，R1的结果集是否将保持不变。RRVM的格式和内容在不同实施方案中可不同，例如，基于将被确定可重复性的读取的类型、所涉及的数据存储区的性质等等。在一些实施方案中，例如，RRVM可包括对从其获得R1结果集的对象的位置的编码，诸如至少一个这类位置的散列签名。对于具有更复杂的过滤/选择准则的读取，诸如类似于图31背景下讨论的读取的一个或多个范围查询，对查询谓词或选择子句的编码可包括在RRVM中。在一些实施方案中，可被评估以确定R1的结果是否已经改变的表达(或可被执行的函数)可在RRVM中被指示。在一个实施中，整个读取请求R1可包括在RRVM中，例如，呈编码或压缩格式。在可生成若干种不同类型的RRVM的一些实施方案中(例如，基于地址的签名对查询谓词编码对函数)，RRVM的类型可由读取描述符RD1内的字段指示。RD1可被传输到HSG1的客户端侧部件(例如，实施HSG1的服务的前端请求处理者节点，或服务的库部件)。在一些实施方案中，RD1可用在客户端侧部件处用于构建事务提交请求，或用于诸如工作负载分析等的其他目的。
图38是示出根据至少一些实施方案的操作的方面的流程图，所述操作可在客户端侧部件处生成候选的事务提交请求的存储系统处执行。客户端侧部件可包括例如在存储服务的前端请求处理者节点处运行或在由存储服务提供给客户的库内的一个或多个进程。如元素3801中所示，候选事务将被准备的指示可从终端用户接收在异构存储组HSG1的客户端侧部件处，诸如经由服务的应用编程接口(API)接收的BEGIN_TRANSACTION请求。在一些实施中，BEGIN_TRANSACTION请求和COMMIT_TRANSACTION请求(或END_TRANSACTION请求)之间在客户端侧部件处执行的操作集可被认为是在事务范围内，例如，从以下意义来看：在间隔内发布的读取的可重复性可能必须在事务的写入被提交之前被验证。
一个或多个读取请求可通过客户端侧部件引导到事务范围内存储组HSG1的数据存储区，例如，响应于由终端用户作出的读取API调用。在所描绘的实施方案中，可使用无状态协议执行读取中的至少一些，即可能不要求读取所引向的数据存储区维持客户端会话信息，或保留关于读取请求的任何其他持久性元数据。例如，数据存储区可能没有指示读取结果将用于写入操作或事务的信息。对应于每个这类读取请求，结果集和读取描述符可由目标数据存储区提供(元素3804)。给定的读取描述符可包括指示截至获得结果集时数据存储区的提交状态(或数据存储区的子集的提交状态，诸如数据库实例情况下的表格或记录)的一个或多个状态转变指示符(STI)。此外，读取描述符也可包含读取可重复性验证元数据(RRVM)的至少一个元素，例如，以下信息：诸如对读取查询或谓词的编码、函数、或表示读取目标位置的散列签名，其可用于检查在读取被重新递交的情况下读取结果是否已经改变。读取结果集和读取描述符可存储在可由客户端侧部件访问的存储器缓冲区中(元素3807)，例如，存储在前端请求处理者节点处或在客户端拥有的计算装置处的本地存储器中。
可使用本地存储器执行其写入有效负载可能取决于读取结果集中的至少一个的一个或多个写入，例如，写入有效负载可存储在由客户端侧部件可写入的缓冲区中。在至少一个实施方案中，由于事务范围内的写入而最终将向其写入的在HSG1的数据存储区处的目标位置也可取决于读取结果集。在一些实施方案中，写入描述符(例如，基于写入的目标HSG1位置的散列签名)也可被存储用于客户端侧存储器缓冲区中的写入中的至少一些(元素3810)。应注意，在一些实施方案中，可能不需要写入描述符，例如，写入有效负载可包括对写入位置的指示，并且位置指示可足以满足读取-写入冲突检测的要求。在本地执行事务的所有读取和写入之后，事务的本地操作已经完成的指示(诸如COMMIT_TRANSACTION或END_TRANSACTION请求)可接收在客户端侧部件处(元素3813)。
在所描绘的实施方案中，可在客户端侧部件处生成对候选事务的提交请求，所述提交请求包括读取描述符、写入有效负载和写入描述符(元素3816)。应注意，在一些实施方案中，包括在事务范围内的一个或多个写入可能不一定取决于事务中所指示的读取结果。在其中例如先前描述的类型的逻辑约束(例如，重复删除约束或提交排序约束)将在候选事务被接受用于提交之前被检查的一些实施方案中，另外的数据签名可被生成用于逻辑约束并且被并入到提交请求中。提交请求可被传输到负责为HSG1作出提交决定的事务管理器(元素3819)，诸如基于日志的事务管理器，其被配置成使用上文所述的类型的乐观的并发控制机制。关于是提交还是拒绝候选事务的决定可在事务管理器处作出(元素3822)，例如，使用读取描述符和日志的所选子集来标识如先前所述的读取-写入冲突。如果作出接受候选事务的决定(例如，如果根据所使用的并发控制协议没有检测到读取-写入冲突)，那么可将新的提交记录添加到事务管理器的日志。在至少一些实施方案中，可使用如先前所述的复制有向非循环图(DAG)实施日志。
使用多个基于日志的事务管理器以实现可扩展性
在一些实施方案中，单个基于日志的事务管理器(LTM)可能无法应付针对包括上文所述的类型的一个或多个数据存储区的存储组请求事务的速率。例如，在至少一些实施中，随着所请求提交或事务的速率增加，可用于将提交记录插入持久性日志(例如，在实施用于持久性日志的复制DAG的给定节点的主机处)中的CPU资源可能变成瓶颈。在一些情况下，除了CPU之外或取代CPU，用于日志记录和/或往返于日志的网络路径的存储装置可能变成瓶颈。任何单个这类瓶颈或这类瓶颈的组合可导致可由给定的LTM支持的事务吞吐量的上限。部署更快的单个服务器、更快的存储装置或更快的网络部件以通过给定的LTM支持增加的吞吐量可最终变得不切实际，例如，出于成本原因、可用性原因、和/或简单地由于甚至最快速的可用部件也无法处理某些工作负载。
因此，在至少一些实施方案中，将使用乐观的基于日志的并发控制的存储组的一个或多个数据存储区的数据可被逻辑地划分成分区，其中各自的LTM被指派给不同分区以进行分区层次冲突检测。例如，在具有一组表格T1、T2、T3、T4和T5的数据库的情况下，一个LTM可被指派给包括T1、T2和T3的分区，并且不同的LTM可被指派给包括T4和T5的分区。每个这类LTM可能能够关于其自身持久性日志执行本地冲突检查，用于一个特定分区的提交记录被存储在所述持久性日志中。其读取和写入均被引导到单个分区的事务的提交决定可以类似于先前所述的方式由单个LTM处理。然而，一些事务可涉及来自多个分区的读取(和/或对多个分区的写入)。这类事务在本文中可被称为多分区事务。在支持多分区事务的实施方案中，客户端侧部件(诸如实施基于日志的事务管理的存储服务的前端请求处理者处的进程、或由用于安装在客户端拥有的装置处的这类服务提供的库的部件)可能必须与被指派来检测所涉及的分区的本地冲突的各自LTM一起，参与提交如下文所述的多分区事务。
考虑简单的示例性多分区事务MPT1，其包括(a)对存储组的分区P1的写入W1，其中W1取决于引导到P1的较早读取R1的结果；以及(b)对分区P2的写入W2，其中W2取决于引导到P2的较早读取R2的结果。在本示例中，基于日志的事务管理器LTM1和LTM2被指定来分别关于P1和P2检测读取-写入冲突。在一个实施方案中，提交请求CR1(其包括W1的写入描述符和R1的读取描述符RD1)可由客户端侧部件CSC1发送到LTM1。在至少一些实施方案中，读取描述符RD1可包括早先例如关于图32到图38讨论的那些类型的读取可重复性验证元数据和状态转变指示符。使用RD1和LTM1的所提交写入日志，LTM1可确定CR1是否具有本地可检测的冲突，即，可使用可用在LTM1处的信息标识的冲突。如果LTM1使用其日志和RD1没有发现冲突，那么LTM1可将CR1指定为可有条件地提交，并且将有条件的提交记录插入LTM1日志中。客户端侧部件CSC1可被通知W1已经被指定为可有条件地提交。对于MPT1的第二写入W2，CSC1可类似地将第二提交请求CR2发送到LTM2。如果LTM2向CSC1通知W2也可本地提交(例如，有条件的提交记录已经被存储用于W2于LTM2日志中)，那么CSC1可确定MPT1是可全局或无条件地提交。CSC1然后可将用于MPTR1的无条件提交记录插入多分区提交决定储存库(MCDR)中，例如，在其指针存储在对应于CR1和CR2的有条件的提交记录内的位置处。被指派以将所提交的写入传播到P1的写入应用器WA1可检查响应于CR1生成的提交记录，指示W1被发现是可有条件地提交的。在确定W1被有条件地提交之后，WA1可在MCDR中搜索对应的无条件提交记录。在一些实施方案中，如果发现这类无条件的提交记录(例如，在如下文所述的超时时段内)，那么W1可被传播到P1。类似地，被指定以将写入传播到P2的写入应用器(WA1或不同的写入应用器WA2)可检查对应于CR2和W2的有条件的提交记录，查找MPT1的无条件提交记录，并且将W2传播到P2。在至少一些实施方案中，如果一个或多个写入应用器没有发现无条件提交记录，那么可放弃写入(例如，W1和W2均不可被传播到其各自的目的地分区)。
图39示出了根据至少一些实施方案的示例性系统环境，其中可针对存储组的不同分区建立各自的基于日志的事务管理器(LTM)。如所示，在系统3900中，分区的存储组3902可包括三个逻辑分区(LP)：LP 3910A、3910B和3910C。一般来说，包括早先描述的类型的一个或多个数据存储区(例如，关系数据库实例、非关系数据库实例、存储服务对象、存储器中数据库实例、分布式缓存实例、文件系统等)的存储组在各种实施方案中可被逻辑地细分成任何期望数目的分区，这取决于各种因素，诸如如下文所述的存储组的目标性能要求。在一些实施方案中，逻辑分区也可被存储在各自的物理存储装置中，例如，分区P1中的表格T1可存储在磁盘D1上、分区P2中的表格T2可存储在不同的磁盘D2上等等，但是可能不要求逻辑分区的这类物理分离。在所描绘的示例中每个逻辑分区具有所配置的对应LTM和对应写入应用器(WA)，但是在至少一些实施方案中可能并不要求LTM与WA之间的这类1:1映射。在系统3900中，LP 3910A具有具持久性日志3918A的LTM 3915A，LP 3910B具有具持久性日志3918B的LTM 3915B，并且LP 3910C具有具持久性日志3918C的LTM 3915C。在一些实施方案中，持久性日志3918每个可使用类似于早先描述的复制DAG的复制DAG实施。WA 3920A被配置成检查日志3918A中的提交记录并且将其中所指示的至少一些写入传播到LP 3910A；类似地，WA 3920B被配置成检查日志3918B的提交记录并且传播至少一些写入到LP 3910B，并且WA 3920C被配置成检查日志3918C的提交记录并且传播至少一些写入到LP 3910C。
如由箭头1a和1b所指示，存储组3902的客户端侧部件3930可将多分区事务MPT1的各自的提交请求C-Req1和C-Req2分别递交到LTM 3915A和LTM 3915C。C-Req1可包括取决于引导到LP 3910A的早先读取R1的至少一个写入W1，而C-Req2可包括取决于引导到LP 3910C的早先读取R2的至少一个写入W2。使用(a)包括在提交请求中的读取描述符和(b)日志3918A和3918C，LTM 3915A和3915C可分别确定写入W1和W2是否是可有条件地提交的(例如，是否可使用各自的本地日志和各自的读取描述符检测到与写入的任何读取-写入冲突)。在所描绘的实施方案中多分区事务的写入诸如W1或W2可被认为可通过给定LTM有条件地(而非无条件地)提交，因为LTM可能不具有足够的信息来作出关于整体提交多分区事务的决定，事实上，在至少一些实施中，LTM可能甚至觉察不到多分区事务的其他写入。如果使用本地可用的信息没有检测到冲突，那么例如对应于C-Req1的有条件的提交记录Cond-C-Rec1可由LTM3910A存储在日志3918B中，并且对应于C-Req2的有条件的提交记录Cond-C-Rec2可由LTM 3910C存储在日志3918C中。此外，在至少一些实施方案中，指示所请求的写入被有条件地提交的各自响应可由LTM 3915A和3915B中的每个提供到客户端侧部件3930。因此，如由箭头2a所指示，响应C-Resp1可由LTM 3915A提供到客户端侧部件3930，并且响应C-Resp1可由LTM 3915B提供，如由箭头2b所指示。应注意，在至少一些实施中，提交请求C-Req1和C-Req2可并行发送，并且类似地，对提交请求的处理也可被并行执行。在至少一些实施方案中，可按任何顺序或并行发送多分区事务的不同提交请求，可由各自的LTM按任何顺序或并行地存储对应的有条件的提交记录，并且可由客户端侧部件按任何顺序或并行地接收对提交请求的响应。
在所描绘的示例中，响应于确认写入W1和W2均为可有条件地提交，客户端侧部件3930可将无条件的提交记录Uncond-C-Rec存储在多分区提交决定储存库(MCDR)3940A中(箭头3)。一般来说，在至少一些实施方案中，客户端侧部件可在验证给定的多分区事务(诸如MPT1)的全部写入已经被指定为可有条件地提交之后，存储这类无条件提交记录。在所描绘的示例中，已经针对存储组3902建立了两个MCDR 3940A和3940B。一般来说，在各种实施方案中可建立任何期望数目的MCDR，例如，基于如下文讨论的多分区事务请求的预期或目标吞吐量。在建立多个MCDR的实施方案中，关于哪个MCDR将用于给定的无条件提交记录的决定可基于各种因素作出，例如，基于事务中所涉及的特定分区，基于由客户端侧部件实施的负载平衡准则等等。在至少一些实施方案中，对将存储无条件提交记录的位置的指示可包括在由客户端侧部件发送到LTM的提交请求中，并且也可包括在存储在日志3918中的有条件提交记录中。在一些实施中，MCDR可被实施为持久性日志的实例(例如，类似于日志3918)。
在有条件的提交记录Cond-C-Rec1已经存储在日志3918A中之后的某个时间点，写入应用器3920A可检查记录(如由箭头4a所示)。在一些情况下，这类检查可为同步的(例如，有条件的提交记录一被写入到日志3918，其马上可由负责将所提交的写入推动到存储组的数据存储区的写入应用器读取)，而在其他情况下，写入应用器可关于有条件的提交决定异步地检查提交记录。在检查Cond-C-Rec1之后，WA 3920A可确定提交是有条件的，并且因此可尝试找到对应的无条件提交记录。在至少一些实施方案中，对无条件提交记录Uncond-C-Rec的位置的指示可包括在有条件的提交记录Cond-C-Rec1中。在其他实施方案中，写入应用器可从其他源得知无条件提交记录的位置，例如，通过在数据库中查找多分区事务的标识符。如由箭头5a所指示，在所描绘的实施方案中，WA 3920A可将Uncond-C-Rec定位在MCDR3940A中，并且由此确认有条件的提交记录Cond-C-Rec1中所指示的写入实际上将应用于其目标目的地。如由箭头6a所指示，写入W1可因此被传播到分区LP 3910A。在所描绘的实施方案中，写入应用器3920C可执行类似于WA 3920A的程序，例如，其可同步或异步地检查有条件的提交记录Cond-C-Rec2(箭头4b)，确定预期将存储对应的无条件提交记录的位置，并且查找Uncond-C-Rec(箭头5b)。在确认W2是其一部分的多分区事务已经被无条件地提交之后，WA 3920C可因此将W2传播到其预期的目的地LP 3910C。
如下文更详细描述，在至少一些实施方案中，可实施超时机制使得如果WA 3920无法确认无条件提交记录Uncond-C-Rec已经在某个时间间隔内被写入，那么一个或多个对应写入(诸如W1或W2)的传播可被放弃。在一些实施方案中，如果LTM 3915确实发现使多分区事务的写入表现为不可提交的冲突，那么客户端侧部件3930可将无条件中止记录而非无条件提交记录存储在MCDR 3940A中。考虑如下情形：LTM 3915A将W1指定为可有条件地提交，而LTM 3915B基于冲突将W2指定为不可提交的。在后一情形中，如果并且当WA3920A尝试找到W1是其一部分的多分区事务的无条件提交记录时，其可能替代地发现多分区事务已经被放弃/中止，并且可因此放弃对写入W1的传播。在至少一些实施方案中，如果作出放弃/中止多分区事务的决定，那么可修改(例如，以指示中止)或移除日志3918中的有条件的提交记录。类似地，在一些实施方案中，如果作出无条件地提交多分区事务的决定，那么可修改日志3918中的对应有条件的提交记录以指示父多部分事务被无条件地提交。在这类实施方案中，由于可基于日志3918的内容进行提交决定的冲突检测操作中的至少一些，所以解决提交的条件性的模糊性可有助于作出随后的提交决定。
在不同实施方案中，有关LTM、WA和MCDR将包括在存储组的配置中的数目的决定可基于各种因素。图40示出了根据至少一些实施方案的用于存储组的基于性能的事务管理配置的示例。如所示，分布式存储服务配置管理器4080可接收两个存储组的各自配置请求4050A和4050B。配置请求4050A可指示客户端的目标事务吞吐率或TPS(事务/秒)4005A为10000并且目标写入延时4010A为50毫秒(例如，写入请求与对目标数据存储区的对应写入的传播之间的延迟平均不超过50毫秒)。也可提供客户端存储组的数据存储区的列表4020A(例如，数据存储区DS1和DS2)，指示例如所包括的数据存储区的类型、存储区的最大大小等。类似地，配置请求4050B可指示客户端的数据存储区列表4020B(例如，数据存储区DS3、DS4、DS5)、目标TPS 4005B(例如，20000)和目标写入延时4010B(例如，200毫秒)。
至少部分基于配置请求的内容，配置管理器4080(其可为分布式存储服务的管理/控制平面的部件)可生成每个请求4050的候选事务管理配置。在所描绘的示例中，响应于配置请求4050A生成的事务管理配置4060A可包括两个LTM 4025A和4025B、四个写入应用器4027A-4027D和一个MCDR 4029A。在一些实施方案中，所提出的事务管理配置的LTM的数目可对应于客户端的存储组的所建议的或所推荐的分区(例如，一个LTM可被设置用于每个逻辑分区)。在这类实施方案中，如果客户端批准所提出的分区，那么客户端或存储服务可确定适当的分区计划。在其他实施方案中，可要求客户端将它们的存储组分区，例如至少部分基于客户端的目标TPS，并且提供分区计划作为配置请求的部分给配置管理器。
在图40的所描绘的示例中，针对给定配置选择的LTM的数目与目标TPS成比例。因此，对于请求4050A中所指示的10000TPS目标，在配置4060A中建议两个LTM；并且对于请求4050B中所指示的20000TPS目标，推荐四个LTM(4025K–4025N)。所推荐的写入应用器的数目是基于目标写入延时，其中对于较小的目标延时推荐较多的应用器。因此，对于50毫秒的目标写入延时，四个写入应用器包括在配置4060A中，而对于请求4050B中所指示的200毫秒的写入延时，仅两个写入应用器4027K和4027L包括在配置4060B中。在不同实施方案中，也可基于各种因素诸如目标TPS、多分区事务的目标部分等等而选择MCDR的数目。在所示示例中，对于请求4050A中所指示的参数，推荐两个MCDR 4029K和4029L。
在不同实施方案中，包括在配置请求4050中的参数类型，以及参数与事务管理配置4060的所推荐部件计数之间的关系可与图40中所示的那些不同。例如，在一些实施方案中，客户端也可能必须在其配置请求中指示多分区事务对单分区事务的目标比率，并且这类比率可由配置管理器使用来确定MCDR的所推荐数目。在至少一些实施方案中，在配置管理器将所推荐的配置提供到客户端之后，客户端可能必须在配置管理器部署/实例化LTM、WA和/或MCDR之前批准所述推荐。在一些实施方案中，随着工作负载改变，可动态地调整针对存储组设置的MCDR、LTM和/或WA的数目，例如，不需要暂停事务处理。
在至少一些实施中，给定的数据存储区可被划分成用于基于日志的事务管理的若干逻辑分区；即，LTM可被建立成处理单个数据存储区子集的冲突检测和有条件提交决定。图41示出了根据至少一些实施方案的示例性配置，其中可针对给定的数据存储区建立多个基于日志的事务管理器。如所示，在所描绘的情形中，存储组4102可包括数据存储区4110A(其可例如包括非关系数据库的实例)、4110B(例如，存储器中数据库的实例)和4110C(例如，向非结构化对象呈现web服务接口的存储服务的对象集)。
在所描绘的实施方案中，存储组4102已经被划分成六个逻辑分区(LP)4120A–4120F。数据存储区4110A包括LP 4120A和4120B，数据存储区4110B包括LP 4120C，并且数据存储区4120C包括LP4120D、4120E和4120F。每个逻辑分区4120具有所建立的对应LTM4125，例如，LP 4120A具有LTM 4125A，LP 4120B具有LTM 4125B等等。针对给定的数据存储区实例化的逻辑分区和/或LTM的数目在至少一些实施中可能不一定与数据存储区中所预期的数据量成比例，但是预期的数据集大小可为在确定分区数目时的因素。在各种实施方案中，其他因素也可用于确定分区，诸如各种类型的事务(例如，单分区、多分区或跨数据存储区事务)的预期速率、数据存储区和/或用于LTM 4125的服务器的原生性能能力(例如，可如何快速地将写入应用于LTM日志)、数据存储区的可用性或数据耐久性目标、客户端预算目标、相对于不同数据存储区的定价策略差异等等。
在至少一些实施方案中，若干LTM 4125可能必须合作以便实施某些类型的事务。例如，考虑如下情形：LP 4120A包括表格T1，并且LP 4120B包括另一表格T2。多分区事务的提交请求CR1由客户端侧部件引导到LTM 4125A。CR1指示引导到T1的读取R1的读取描述符，并且包括基于R1结果的两个写入：引导到T1的写入W1，和引导到T2的写入W2。在这类情形中，如果LTM 4125A基于其本地日志和R1的读取描述符未发现任何冲突，那么W1和W2两者均可被指定为可提交的。然而，W2被引导到不同于包括T1的分区的分区。在这类情形中，在至少一些实施方案中，各自的有条件的提交记录可被写入在LTM 4120A和LTM 4120B两者的日志中(例如，由于从LTM 4120A发送到LTM 4120B的请求)。在一些实施方案中，类似合作可在针对存储组的不同数据存储区建立的LTM之间实施，例如，如果W2被引导到LP 4120D，那么LTM 4120A可将对包括W2的有条件的提交的请求发送到LTM 4120D。
如先前所提及，在一些实施中，可使用类似于由LTM使用的持久性日志实施多分区提交决定储存库(MCDR)。因此，在一个这类实施中，可使用类似于图1所示的复制DAG实施给定的MCDR，正如可使用复制DAG来实施由LTM使用的日志一样。图42示出了根据至少一些实施方案的示例性配置，其中多分区提交决定储存库与针对存储组的主分区建立的基于日志的事务管理器的日志共位。在所描绘的实施方案中，存储组4202已经被细分成主逻辑分区4210A和非主逻辑分区4210B和4210C。在不同实施方案中，将所述分区中的一个指派为主或主要分区可基于例如存储在分区中的数据的相对重要性(代表其建立存储组4202的客户端的角度来看)、目标性能、其内容包括在分区中的数据存储区的可用性或数据耐久性目标、和/或其他因素。
在所描绘的实施方案中，各自的LTM 4215可针对逻辑分区4210中的每个进行配置。在所描绘的实施方案中，已经被实例化用于主LP 4210A的LTM 4215A可被指定为主LTM，而其余的LTM(诸如4215B和4215C)可被指定为非主LTM。在至少一个实施中，主LTM4215A可使用相比于部署用于非主LTM的服务器具有更大计算、存储、存储器和/或联网容量的一个或多个服务器而实施，但是可能并不要求资源容量的这类不对称性。在所描绘的实施方案中，主LTM的日志4218A可与用于存储组4202的MCDR 4240共位(例如，共享用于计算、联网、存储和/或存储器的相同服务器资源)。MCDR 4240和/或日志4218A可每个被实施为各自的多个复制DAG节点，在一些实施方案中，所述节点中的一些共位。例如，复制DAG RD1的节点N1、N2、N3和N4可用于日志4218A，不同复制DAG的节点Nk、Nl、Nm和Nn可用于MCDR 4240，其中N1与Nk共同定位在给定的服务器上，N2与N1共同定位在不同的服务器上等等。在至少一些实施方案中，用于MCDR 4240的复制DAG的节点的数目不需要与用于主LTM的日志4218A的复制DAG的节点数目相同。在一个实施方案中，相同的复制DAG可用于日志4218A和MCDR 4240的记录。应注意，在一些实施方案中，将所述LTM中的一个指定为主LTM可能不一定伴随该LTM与MCDR共享资源。在另一实施方案中，一个以上LTM日志可与存储组的各自MCDR共位。
图43示出了根据至少一些实施方案的可在支持多分区事务的存储组处生成的提交请求的示例性组成元素。如所示，提交请求4344可包括对事务类型4302的指示(例如，其提交被请求的一个或多个写入是单分区事务还是多分区事务的部分)。在一些实施中，取代事务类型4302的是，提交类型可在提交请求中被指示，例如，其中“有条件的”提交类型被指示用于多分区事务的写入，并且“无条件的”提交类型被指示用于单分区事务的写入。提交请求可包括一个或多个读取描述符4304，所述读取描述符指示由一个或多个写入描述符4306表示的写入所依据的读取。在一些实施方案中，读取描述符可包括RRVM(读取可重复性验证元数据)和/或一个或多个状态转变指示符，所述状态转变指示符表示读取所引向的分区的提交状态、类似于(在分区层次上)RRVM和先前所述的状态转变指示符。
写入描述符4306(其可类似于先前在图17-图25的背景下所讨论的写入集描述符)可包括例如对提交请求的写入所引向的位置的指示。一个或多个写入有效负载4308可指示将被写入到写入描述符中所指示的地址的数据或内容。在一些实施方案中，逻辑约束诸如先前参考描述的重复删除约束和/或提交排序约束可经由各自的逻辑约束描述符4310(其可类似于参考图22-图25讨论的逻辑约束描述符)指示。逻辑约束在一些这类实施方案中可以分区层次指示，并且在其他实施方案中可以存储组层次指示。如果逻辑约束以存储组层次指示，那么接收提交请求4344的LTM在一些实施方案中可能必须与其他LTM合作以确保约束已经在有条件地(或无条件地)提交所请求的写入之前被满足。
在图43中所描绘的实施方案中，MCDR信息4312可包括在提交请求中用于多分区事务。MCDR信息可包括例如可用于访问预期被创建为对应于提交请求的无条件提交记录(或中止记录)的标识符、键或地址。表示多分区事务的独特标识符或键在一些实施方案中例如可用于在散列表或类似结构中查找无条件/提交记录。MCDR信息4312可包括在存储在LTM日志处的有条件的提交记录中，例如，使得写入应用器能够确定无条件的提交/中止记录的位置。
在一些实施方案中，提交超时值4314可在提交请求4344中被指示。提交超时值可指示已经检查多分区事务MT1的有条件的提交记录CCR1的写入应用器WA1，在放弃对CCR1的写入的传播之前，需要等待对应于MT1的无条件提交记录UCR被写入到MCDR的最大时间量。因此，提交超时值可提供解决中止或失效的客户端侧部件的问题的方式，否则在一些实施中该问题可潜在地导致关于多分区事务的遭遇(提交或中止)的不确定性。在至少一些实施方案中，MCDR可实施提供单调递增的逻辑时间戳值的逻辑时钟，并且超时值可被表达为这类时钟的未来逻辑时间戳值。例如，在一个情形中，准备提交请求4344的客户端侧部件可从MCDR逻辑时钟读取当前的逻辑时间戳值LTS1，并且将某个所选偏移(例如，1000)添加到LTS1以获得超时值。超时值(LTS1+1000)可存储在由接收提交请求4344的LTM生成的有条件的提交记录中。在一些实施方案中，负责传播该提交请求中所指示的写入的写入应用器可定期地检查以查看无条件的提交记录(或无条件的中止记录)是否存在于适当的MCDR中。写入应用器在其未能找到无条件提交/中止记录的情况下，从MCDR的逻辑时钟获得当前的逻辑时间戳。如果在本示例中当前的时间戳超过超时值LTS1+1000，那么写入应用器额可放弃对有条件的提交记录的写入的传播/应用。应注意，在一些实施方案中，并非图43中所示的全部部件均可并入提交请求内，并且在其他实施方案中，可包括图43中未示出的其他部件。MCDR信息4312和提交超时值4314可被认为是可包括在提交请求记录4344中的多分区事务元数据的示例。
在一些实施方案中，单分区事务可表示在存储组处处理的总工作负载的显著部分(或甚至大部分)，并且所提交的单分区事务的写入可由写入应用器传播到分区而不咨询MCDR。单分区事务的写入所依据的读取以及写入自身可被引导到不超过一个分区，因此可能仅需要单个LTM来执行对这类事务的冲突检测。在一些这类实施方案中，针对单分区事务的存储在LTM日志中的信息类型可能不同于针对多分区事务存储的信息类型。图44a和图44b示出了根据至少一些实施方案的提交记录的示例性组成元素，所述提交记录可通过基于日志的事务管理器被存储分别用于单分区事务和多分区事务。如图44a中所示，单分区事务的提交请求4431可由客户端侧部件4430递交到指定用于该分区的LTM 4402。LTM 4402的冲突检测器4402可使用包括在提交请求4431中的一个或多个读取描述符，与持久性日志4442中的先前存储的提交记录的选定集一起，来确定提交请求4431中所指示的读取是否与随后的所提交写入冲突。如果没有检测到冲突，那么可将对应于提交请求4431的提交记录4444A添加到日志4442。由于请求4431是用于单分区事务，所以可能不需要另外的协调(例如，与在多分区事务情况下由客户端侧部件所执行的协调类似的协调)来将提交指定为无条件的。因此，在至少一些实施方案中，例如，使用如所示的类型字段4452A，提交记录4444A可指示提交是无条件的。用于单分区提交请求的提交记录4444A也可包括写入信息4462A，包括例如对一个或多个写入有效负载的指示和写入在分区内所引导到的位置。
响应于对多分区事务的写入的提交请求4432，如图44b中所示，冲突检测器4440可执行与针对单分区事务的提交请求所执行相同的本地冲突检测的类型(例如，基于请求4432的读取描述符和日志4442中的先前存储的提交记录的选定集)。然而，在本地没有检测到冲突的情况下，在所描绘的实施方案中，存储在日志4442中的新提交记录4444B在若干方面可不同于提交记录4444A。字段4452B中所指示的提交类型例如可被设置成有条件的而非设置成无条件的。除了提交类型字段和写入信息4462B之外，在一些实施方案中，MCDR查找信息4456也包括在提交请求中。MCDR查找信息(其可至少部分基于提交请求4432的内容)可允许写入应用器确定预期将对应于有条件的提交记录4444B的无条件提交/中止记录定位在何处。取决于实施，不同类型的条目可包括在MCDR查找信息4456中，例如，无条件提交记录的地址或标识符在一个实施中可被提供，或者可用于查找地址的键可被提供，或者可被调用以获得地址的函数可被提供。在至少一些实施方案中，提交超时4458可包括在有条件的提交记录4444B中，指示例如无条件提交/中止记录应当在MCDR内可用的最迟时间，使得在超时已截止之后没有发现这类无条件提交/中止记录的情况下，有条件的提交记录4444B的写入可能不必被传播到它们的目标分区。如先前所提及，在至少一些实施方案中，可依据预期将从MCDR的逻辑时钟获得的逻辑时间戳值而表达这类超时值4458。MCDR查找信息和提交超时4458可被认为是存储在有条件的提交记录4444B中的多分区事务元数据的示例，例如供写入应用器消耗。
在一些实施方案中，用于单分区的提交记录或多分区提交记录的内容可不同于图44a和图44b中所示的内容。例如，在一个实施方案中，取代提交类型字段的是，提交记录可包括事务类型字段(例如，单分区或多分区)，并且写入应用器可基于事务类型字段内容而确定对于给定的提交记录是否需要对MCDR内容进行检查。在一些实施中，可能不需要MCDR查找信息4456，例如，可使用允许写入应用器使用写入描述符的内容来确定何处可发现有条件的提交的无条件记录的协议。在一个实施方案中，超时值可在提交记录中未被指示，而是，例如，写入应用器可在其首次读取提交记录时设置其自身的超时，并且在该超时截止时决定放弃写入传播。
图45是示出根据至少一些实施方案的操作的方面的流程图，所述操作可由客户端侧部件和支持多分区事务的存储组的各自分区的基于日志的事务管理器执行。如元素4502中所示，存储组的客户端侧部件CSC1可将多分区事务MPT1的写入W1的提交请求CR1递交到与存储组的分区P1相关联的第一基于日志的事务管理器LTM1。例如，在事务取决于引导到存储组的一个以上分区的读取的情况下，所述事务可由CSC1指定为多分区，并且因此针对整个事务的提交决定可能要求一个以上LTM作出各个提交决定(例如，将被执行的各自R-W冲突检测)。在图45中所示的简化情形中，MPT1可包括两个写入W1和W2。在所描绘的实施方案中，写入W1可取决于读取R1(被引导到分区P1)的结果，读取R1的读取描述符RD1包括在CR1中。LTM1可例如使用其持久性日志L1和RD1执行冲突检测，以确定W1是否关于可由LTM1本地可检测的读取-写入冲突类型而可提交。如果没有发现冲突(如在元素4506中所确定)，那么可将新的有条件的提交记录CCR1存储在L1中，指示W1已经被指定为可由LTM1有条件地或本地提交(元素4510)。在一些实施方案中，CCR1也可包括提交超时值和/或对MCDR的指示，如果/当发现MPT1为可无条件提交时预期将在所述MCDR处写入无条件提交记录。LTM1可例如响应于CR1，向CSC1通知已经发现W1为可有条件地提交以及CCR1已经被写入L1。在所描绘的实施方案中，如果W1并非可本地提交，例如，如果在对应于元素4506的操作中通过LTM1检测到一个或多个冲突，那么CCR1将不被存储在L1中，并且CSC1可被通知W1已经被拒绝(元素4518)。
在所描绘的实施方案中，CSC1也可将对应于不同写入W2的提交请求CR2递交到负责对不同分区P2进行冲突检测的基于日志的事务管理器LTM2(元素4504)。CR2也可包括其自身的读取描述符集，所述集指示W2所依据的读取。LTM2可使用LTM2的日志L2和CR2的读取描述符来执行其关于W2的自身冲突检测，以确定W2是否为可提交的。如果没有发现将阻止LTM2对W2的接受的冲突(元素4508)，那么可将W2的有条件的提交记录CCR2存储在LTM2的日志L2中(元素4512)。在所描绘的实施方案中，CCR2也可包括提交超时值(例如，存储在CCR1中的相同值，或由LTM2确定的不同值)和对预期W2的无条件提交记录的MCDR位置的指示。可例如作为由LTM2生成的对CR2的响应，CSC1可被通知W2已经被指定为可有条件地或本地提交以及CCR2已经被写入L2(元素4516)。如果W2并非可本地提交的，例如，如果在对应于元素4508的操作中通过LTM2检测到一个或多个冲突，那么CCR2将不被存储在L2中，并且CSC1可被通知W2已经被拒绝(元素4520)。
在所描绘的实施方案中，如果CSC1确定W1和W2两者均被有条件地提交(元素4528)，例如，基于LTM1和LTM2两者都已经将各自的有条件的提交记录CCR1和CCR2写入到它们各自的日志的确定，CSC1可生成MPT1的无条件提交记录并将其存储在MCDR中(元素4531)。如果W1和W2中的一者或两者被拒绝作为不可提交(如也在元素4528中所检测)，例如，如果CSC1确定有条件的提交记录CCR1或CCR2中的至少一个没有被写入，那么CSC1可能不将MPT1的无条件提交记录存储在MCDR中。在一些实施方案中，替代地，中止记录可任选地存储在MCDR中(元素4534)，例如，在本将已经被写入无条件提交记录将两个写入指定为可提交的相同位置中。应注意，一般来说，虽然关于MPT1仅讨论了两个写入，但是多分区事务可包括任何期望数目的写入，并且在至少一些实施方案中，CSC可确保在存储无条件提交记录之前所有写入已经被指定为可由其各自的LTM进行本地提交。在一些情形中，给定的多分区事务的若干不同写入(例如，Wx、Wy和Wz)可被引导到单个分区(例如，LP1)。在一些实施中，对给定分区的若干这类写入可包括在单个提交请求中，例如，指示Wx、Wy和Wz的一个提交请求可由CSC1发送到LTM1。在其他实施中，每个写入请求可使用单独提交请求进行处理。.在一些实施方案中，取代等待被通知有关所请求的写入是否被有条件地提交，CSC可发挥更积极的作用来确定写入的状态，例如，CSC可直接读取LTM日志(例如，使用类似于图15中所示的接口1513的日志读取接口)，或可向LTM查询以确定提交请求的结果。
在至少一个实施方案中，客户端侧部件可将单分区事务处理为多分区事务的特殊情况，例如，在确定单分区事务的写入已经被接受用于由LTM提交时，单分区事务的无条件提交记录也可被存储在用于单分区事务和多分区事务的提交决定储存库(CDR)中。在这类实施方案中，CDR可由写入应用器针对单分区事务以及针对多分区事务被检查。在其他实施方案中，提交决定储存库可仅用于多分区事务。
图46是示出根据至少一些实施方案的操作的方面的流程图，所述操作可由支持多分区事务的存储组的写入应用器执行。如在元素4601中所示，被配置成将改变应用于存储组的一个或多个分区的写入应用器WA1可检查存储在与存储组的分区P1相关联的基于日志的事务管理器LTM1的持久性日志中的提交记录CRec1。如果CRec1指示对应的提交是有条件的(如在元素4604中所检测)，那么WA1可推断CRec1中所指示的写入是多分区事务的部分并且必须在写入被传播到其目标目的地之前找到无条件提交记录。因此，如在元素4610中所指示，WA1可确定(a)MCDR内预期将存储对应于CRec1的无条件提交记录UCR1的位置；以及(b)提交超时值TO1，其指示UCR1应当出现以使多分区事务不被放弃的最迟时间。
WA1可检查UCR1是否已经存储在MCDR中(元素4614)。如果UCR1已经被存储，那么在所描绘的实施方案中，WA1可将CRec1中所指示的写入传播或应用于其目的地(元素4626)。如果UCR1不存在于MCDR中(如也在元素4614中所检测)，那么WA1可检查(a)由TO1指示的超时是否已经截止或(b)对应于CRec1的中止记录已经存储在MCDR中(元素4617)。在超时以MCDR的逻辑时钟的逻辑时间戳单位表示的实施中，例如，WA1可向MCDR递交对当前逻辑时间戳的查询以确定超时是否已经截止。如果WA1确定超时已经截止或对应于CRec1的多分区事务已经被显式中止，那么写入传播和/或对CRec1的其他处理可被WA1放弃，即CRec1的写入无需应用于其目的地位置(元素4620)。如果超时尚未截止并且未发现中止记录(如也在元素4617中所检测)，那么WA1可在重新检查MCDR以查看对应于CRec1的无条件提交记录是否已经被写入之前(元素4614)，等待指定的或可调谐的MCDR检查间隔(元素4623)。在所描绘的实施方案中，可根据元素4614向前按间隔对MCDR进行检查直到三个事件中的一个发生：(a)发现对应于CRec1的无条件提交记录UCR1，(b)发现对应于CRec1的中止记录，或(c)超时截止。如果(a)发生，那么可传播CRec1的写入(元素4626)；否则可最终放弃写入。在一些实施中，如果放弃对写入的传播，那么可修改提交记录CRec1或从LTM1的日志移除提交记录CRec1以指示放弃(例如，响应于来自WA1的请求由WA1或由LTM1进行)。
在图46中所描绘的实施方案中，如果CRec1指示其提交是无条件的(例如，如果CRec1中所指示的写入是单分区事务而非多分区事务的部分)，如也在元素4604中所检测，那么写入可由WA1传播到它们的预期目的地(元素4626)而无需对MCDR进行任何检查。在其他实施方案中，如上文所提及，可以统一方式处理单分区和多分区事务两者，因为无条件提交记录可存储在用于两种类型的事务的提交决定储存库中，并且写入应用器可能必须验证在传播每种类型的事务的写入之前，这类无条件的提交记录已经被写入。
应注意，在各种实施方案中，除了图6、图7、图8、图9、图10、图12、图13、图14、图19、图20、图25、图30、图37、图38、图45和图46的流程图中所示的操作之外的操作可用于实施上文所述的技术中的至少一些。以流程图示出的操作中的一些可不在一些实施方案中被实施，可按不同顺序实施，或可并行而非依序执行。
使用案例
使用复制DAG管理应用状态变化的上文所述的技术可用于各种实施方案中，所述技术包括使用读取描述符和客户端侧事务准备进行的基于日志的事务管理。随着越来越多的组织将其计算迁移到提供商网络环境，已经开发了具有各自的一致性语义和各自接口的更多种分布式存储应用。一些大的应用可跨多个数据存储区实例，并且复制DAG和基于日志的事务管理技术可表示分布式存储应用管理的统一的、灵活的、可扩展的并且高度可用的方法。复制DAG节点在应用状态转变上取得进展的能力(即使DAG配置的各自视图可能至少暂时有分歧)可减小或消除处理应用请求时使用不太动态的复制技术的情况下可能出现的“停止一切”暂停中的至少一些。基于日志的事务管理可能不仅允许跨数据存储区事务(以及可能不支持原子性多写入事务的数据存储区的多项目事务)，而且可促进诸如自动化查询响应生成、快照生成等特征。跨多个数据存储区执行数据分析的全新方式可使用日志记录服务的自身读取接口而实现。可实施阐明这类新类型的跨数据存储区操作的成本的定价策略，从而使得用户能够被通知对它们的数据变换要求作出的预算决定。可使用上文所述的方法针对非常高的吞吐量应用扩大乐观的基于日志的事务管理，其中基于日志的事务管理器被设置用于给定存储组的各自分区，并且任何给定的多分区事务的提交通过与多个这类事务管理器互动的客户端侧部件进行协调。
在一些提供商网络环境中，经由复制DAG进行的基于日志的事务管理可用于存储实施在提供商网络处的另一网络可访问的服务(诸如，虚拟化计算服务、存储服务或数据库服务)的控制-平面配置信息。在这类情形中，使用日志管理的事务可表示网络可访问的服务(诸如虚拟计算服务情况下的计算实例或虚拟化主机)的各种资源的配置的改变。
说明性计算机系统
在至少一些实施方案中，实施本文中所述的一项或多项技术(包括实施复制DAG的各个部件、用于事务管理的日志服务、或异构存储系统(包括客户端侧部件诸如前端请求处理者以及多分区提交决定储存库)的技术)的一部分或全部的服务器可包括通用计算机系统，所述通用计算机系统包括一个或多个计算机可访问的介质或被配置成访问一个或多个计算机可访问的介质。图47示出了这类通用计算装置9000。在所示实施方案中，计算装置9000包括经由输入/输出(I/O)接口9030耦合到系统存储器9020(其可包括非易失性和易失性存储器模块两者)的一个或多个处理器9010。计算装置9000还包括耦合到I/O接口9030的网络接口9040。
在各种实施方案中，计算装置9000可为包括一个处理器9010的单处理器系统、或包括若干处理器9010(例如，两个、四个、八个或另一合适数目)的多处理器系统。处理器9010可为能够执行指令的任何合适的处理器。例如，在各种实施方案中，处理器9010可为通用或嵌入式处理器，其实施多种指令集架构(ISA)中的任一种，诸如x86、PowerPC、SPARC或MIPS ISA或任何其他合适的ISA。在多处理器系统中，每个处理器9010一般但不一定可实施相同ISA。在一些实施中，取代常规处理器或除了常规处理器之外，可使用图形处理单元(GPU)。
系统存储器9020可被配置成存储可由处理器9010访问的指令和数据。在至少一些实施方案中，系统存储器9020可包括易失性和非易失性部分两者；在其他实施方案中，可仅使用易失性存储器。在各种实施方案中，系统存储器9020的易失性部分可使用任何合适的存储器技术实施，诸如静态随机存取存储器(SRAM)、同步动态RAM或任何其他类型的存储器。对于系统存储器的非易失性部分(例如，其可包括一个或多个NVDIMM)，在一些实施方案中可使用基于闪存的存储器装置，包括NAND闪存装置。在至少一些实施方案中，系统存储器的非易失性部分可包括电源，诸如超电容器或其他电源存储装置(例如，电池)。在各种实施方案中，基于忆阻器的电阻性随机存取存储器(ReRAM)、三维NAND技术、铁电RAM、磁阻RAM(MRAM)或各种类型的相变存储器(PCM)中的任一者可至少用于系统存储器的非易失性部分。在所示实施方案中，实施一个或多个期望函数的程序指令和数据，诸如上文所述的那些方法、技术和数据，被示为作为代码9025和数据9026存储在系统存储器9020内。
在一个实施方案中，I/O接口9030可被配置成协调处理器9010、系统存储器9020和装置中的任何外围装置(包括网络接口9040或诸如各种类型的持久性和/或易失性存储装置等其他外围接口)之间的I/O通信量。在一些实施方案中，I/O接口9030可执行任何必要协议、时序或其他数据变换以将来自一个部件(例如，系统存储器9020)的数据信号转换成适于由另一部件(例如，处理器9010)使用的格式。在一些实施方案中，I/O接口9030可包括对通过各种类型的外围总线附接的装置的支持，例如，诸如外围部件互连(PCI)总线标准或通用串行总线(USB)标准的变体。在一些实施方案中，I/O接口9030的功能可被分离成两个或更多个单独部件，例如，诸如北桥和南桥。而且，在一些实施方案中，I/O接口9030的一些或全部功能性(诸如至系统存储器9020的接口)可被直接并入到处理器9010中。
网络接口9040可被配置成允许数据在计算装置9000与附接到一个网络或多个网络9050的其他装置9060(例如，诸如图1到图46中所示的其他计算机系统或装置)之间交换。在各种实施方案中，网络接口9040可支持经由任何合适的有线或无线通用数据网络(例如，诸如以太网络的类型)的通信。此外，网络接口9040可支持经由电信/电话网络(诸如模拟语音网络或数字光纤通信网络)、经由存储区域网络(诸如光纤通道SAN)或经由任何其他合适类型的网络和/或协议的通信。
在一些实施方案中，系统存储器9020可为计算机可访问的介质的一个实施方案，所述计算机可访问的介质被配置成存储上文针对图1到图46所描述用于实施对应的方法和设备的实施方案的程序指令和数据。然而，在其他实施方案中，可在不同类型的计算机可访问的介质上接收、发送或存储程序指令和/或数据。一般来说，计算机可访问的介质可包括非暂时存储介质或存储器介质诸如磁或光介质，例如经由I/O接口9030耦合到计算装置9000的磁盘或DVD/CD。非暂时性计算机可访问的存储介质也可包括任何易失性或非易失性介质诸如RAM(例如，SDRAM、DDR SDRAM、RDRAM、SRAM等)、ROM等，所述介质可包括在计算装置9000的一些实施方案中作为系统存储器9020或另一类型的存储器。此外，计算机可访问的介质可包括经由通信介质诸如网络和/或无线链路(诸如可经由网络接口9040实施)传送的传输介质或信号诸如电、电磁或数字信号。诸如图47中所示的多个计算装置的部分或全部可用于实施各种实施方案中的所述功能；例如，在多种不同装置和服务器上运行的软件部件可合作来提供功能性。在一些实施方案中，所述功能性的部分除使用通用计算机系统来实施或取代使用通用计算机系统来实施的是，可使用存储装置、网络装置或专用计算机系统来实施。如文本中所使用，术语“计算装置”指代至少所有这些类型的装置，并且不限于这些类型的装置。
前述内容可鉴于以下另外的条款而进行更好的理解：
1.一种系统，其包括：
一个或多个计算装置，其被配置成：
在第一基于日志的事务管理器(LTM)处从存储组的客户端侧部件接收对第一多分区事务的第一写入的第一提交请求，其中所述第一写入取决于所述第一提交请求中所指示的第一读取的结果，其中所述第一读取被引导到所述存储组的第一分区；
在第二LTM处从所述客户端侧部件接收对所述第一多分区事务的第二写入的第二提交请求，其中所述第二写入取决于所述第二提交请求中所指示的第二读取的结果，其中所述第二读取被引导到所述存储组的第二分区；
将对应于所述第一写入的第一有条件的提交记录存储在所述第一LTM的第一持久性日志内，指示所述第一写入关于所述第一读取与记录在所述第一持久性日志中的第一写入子集之间的读取-写入冲突是可提交的，其中所述第一有条件的提交记录包括关于所述第一多分区事务的元数据；
将对应于所述第二写入的第二有条件的提交记录存储在所述第二LTM的第二持久性日志内，指示所述第二写入关于所述第二读取与记录在所述第二持久性日志中的第二写入子集之间的读取-写入冲突是可提交的，其中所述第二有条件的提交记录包括关于所述第一多分区事务的所述元数据；
响应于确定(a)所述第一有条件的提交记录已经被存储和(b)所述第二有条件的提交记录已经被存储，通过所述客户端侧部件将对应于所述第一多分区事务的第一无条件提交记录存储在多分区提交决定储存库(MCDR)中；以及
响应于(a)对包括在所述第一有条件的提交记录中的关于所述第一多分区事务的所述元数据的检查和(b)对所述第一无条件提交记录的检查，通过与所述存储组的特定分区相关联的第一写入应用器将所述第一写入传播到所述特定分区。
2.根据条款1所述的系统，其中所述一个或多个计算装置还被配置成：
在所述第一LTM处接收对不同多分区事务的第三写入的第三提交请求，其中所述第三写入被引导到所述第一分区，并且其中所述第三提交请求包括所述不同多分区事务的超时的表示；
将对应于所述第三写入的第三有条件的提交记录存储在所述第一持久性日志内，指示所述第三写入关于读取-写入冲突是可提交的；
在所述超时截止之后，检测对应于所述不同多分区事务的第二无条件提交记录尚未存储在所述MCDR中；以及
确定将不实施所述第三写入到所述第一分区的传播。
3.根据条款1所述的系统，其中所述第一提交请求包括对所述MCDR的指示，并且其中关于所述第一多分区事务的所述元数据包括对所述MCDR的所述指示。
4.根据条款1所述的系统，其中所述一个或多个计算装置还被配置成：
在所述第一提交请求之前，接收被引导到所述存储组的一种或多种类型的操作的目标性能水平的指示；以及
至少部分基于所述目标性能水平的所述指示确定以下各者中的一者或多者：(a)将针对所述存储组建立的LTM的数目，(b)将针对所述存储组建立的MCDR的数目或(c)将针对所述存储组建立的写入应用器的数目。
5.根据条款1所述的系统，其中所述第一分区被指定为所述存储组的主分区，其中所述第一持久性日志至少包括第一服务器的一个或多个存储装置的第一部分，并且其中所述MCDR至少包括所述第一服务器的所述一个或多个存储装置的第二部分。
6.一种方法，其包括：
通过一个或多个计算装置执行：
将对应于第一多分区事务的第一写入的第一有条件的提交记录存储在存储组的第一基于日志的事务管理器(LTM)的第一持久性日志内，指示所述第一写入已经至少部分基于由所述第一LTM执行的第一冲突检测分析而被指定为可提交的；
将对应于所述第一多分区事务的第二写入的第二有条件的提交记录存储在所述存储组的第二LTM的第二持久性日志内，指示所述第二写入已经至少部分基于由所述第二LTM执行的第二冲突检测分析而被指定为可提交的；
响应于检测到所述第一和第二写入已经被指定为可提交的，存储对应于所述第一多分区事务的第一无条件提交记录；以及
响应于(a)对所述第一有条件的提交记录的检查和(b)对所述第一无条件提交记录的检查，通过第一写入应用器将所述第一写入传播到所述存储组的特定分区。
7.根据条款6所述的方法，其还包括通过所述一个或多个计算装置执行：
在所述第一LTM处接收对不同多分区事务的不同写入的提交请求，其中所述不同写入被引导到所述第一分区，并且其中所述提交请求包括所述不同多分区事务的超时的表示；
将对应于所述不同写入的第三有条件的提交记录存储在所述第一持久性日志内，指示所述不同写入可至少部分基于由所述第一LTM执行的第三冲突检测分析而提交；
在所述超时截止之后，检测到对应于所述不同多分区事务的第二无条件提交记录尚未存储在多分区提交决定储存库(MCDR)中；以及
确定将不实施所述不同写入到所述第一分区的传播。
8.根据条款7所述的方法，其中所述MCDR具有提供单调递增的逻辑时间戳值的相关联逻辑时钟，并且其中所述超时包括预期将从所述逻辑时钟获得的特定未来逻辑时间戳值。
9.根据权利要求6所述的方法，其中响应于对所述第一写入的第一提交请求而存储所述第一有条件的提交记录，并且其中响应于对所述第二写入的第二提交请求而存储所述第二有条件的提交请求，所述方法还包括通过所述一个或多个计算装置执行：
在所述第一LTM处接收对第二多分区事务的第三写入的第三提交请求，其中所述第三写入取决于引导到所述第一分区的第三读取的结果；
在所述第二LTM处接收对所述第二多分区事务的第四写入的第四提交请求，其中所述第四写入取决于引导到所述第二分区的第四读取的结果；
将对应于所述第三写入的第三有条件的提交记录存储在所述第一持久性日志内，指示所述第三写入可至少部分基于由所述第一LTM执行的第三冲突检测分析而提交；
至少部分基于由所述第二LTM检测的特定冲突而确定所述第四提交请求已经被所述第二LTM拒绝；以及
响应于所述第四提交请求已经被拒绝的所述指示而放弃对所述第三写入的传播。
10.根据条款6所述的方法，其中响应于在所述第一LTM处从所述存储组的客户端侧部件接收的第一提交请求而存储所述第一有条件的提交记录，其中所述存储所述第一无条件提交记录由所述客户端侧部件执行。
11.根据条款10所述的方法，其中所述第一提交请求包括对存储所述第一无条件提交记录的MCDR的指示。
12.根据条款10所述的方法，其中所述第一提交请求包括对第一读取的指示，其中所述第一写入取决于所述第一读取的结果，并且其中对所述第一读取的所述指示由所述第一LTM使用来执行所述第一冲突检测分析。
13.根据条款6所述的方法，其还包括通过所述一个或多个计算装置执行：
接收引导到所述存储组的一种或多种类型的操作的目标性能水平的指示；以及
至少部分基于所述目标性能水平的所述指示确定以下各者中的一者或多者：(a)将针对所述存储组建立的LTM的数目，(b)将针对所述存储组建立的多分区提交决定储存库的数目或(c)将针对所述存储组建立的写入应用器的数目。
14.根据条款6所述的方法，其中所述第一分区被指定为所述存储组的主分区，其中所述第一持久性日志至少包括第一服务器的一个或多个存储装置的第一部分，并且其中所述第一无条件提交记录存储在所述一个或多个存储装置的特定存储装置处。
15.根据条款6所述的方法，其中所述第一无条件提交记录存储在多分区提交决定储存库(MCDR)中，所述决定储存库包括复制有向非循环图的多个节点，所述多个节点包括第一节点和第二节点，并且其中所述存储所述第一无条件提交记录包括将所述第一无条件提交记录的各自副本存储在所述第一节点和所述第二节点处。
16.一种非暂时计算机可访问的存储介质，其存储程序指令，所述程序指令在于一个或多个处理器上执行时实施存储组的客户端侧部件，其中所述客户端侧部件被配置成：
将对第一多分区事务的第一写入的第一提交请求传输到存储组的第一基于日志的事务管理器(LTM)，其中所述第一提交请求包括对所述第一写入所依据的第一读取的指示，其中所述第一读取被引导到所述存储组的第一分区；
将对第一多分区事务的第二写入的第二提交请求传输到所述存储组的第二基于日志的事务管理器(LTM)，其中所述第二提交请求包括对所述第二写入所依据的第二读取的指示，其中所述第二读取被引导到所述存储组的第二分区；
响应于确定(a)所述第一写入已经被指定为可由所述第一LTM至少部分基于第一提交分析而提交以及(b)所述第二写入已经被指定为可由所述第二LTM至少部分基于第二提交分析而提交，而将对应于所述第一多分区事务的第一无条件提交记录存储在选定位置处。
17.根据条款16所述的非暂时计算机可访问的存储介质，其中所述第一提交请求包括以下各者中的一者或多者：(a)对所述选定位置的指示，或(b)用于所述第一多分区事务的提交超时。
18.根据条款16所述的非暂时计算机可访问的存储介质，其中所述客户端侧部件还被配置成：
响应于不同多分区事务的至少一个写入已经被指定为不可由所述第一LTM提交的确定，将对应于所述不同多分区事务的中止记录存储在不同的选定位置处。
19.一种非暂时计算机可访问的存储介质，其存储程序指令，所述程序指令在于一个或多个处理器上执行时实施存储组的写入应用器，其中所述写入应用器被配置成：
确定通过所述存储组的基于日志的事务管理器存储在持久性日志内的特定记录表示被引导到所述存储组的第一分区的第一写入的有条件的提交；
标识被指定为存储多分区事务的无条件提交记录的提交决定储存库，所述多分区事务包括引导到第一分区的一个或多个写入；以及
响应于所述提交决定储存库包括第一多分区事务的无条件提交记录的确定，所述第一多分区事务包括所述第一写入，将所述第一写入传播到所述存储组的所述第一分区。
20.根据条款19所述的非暂时计算机可访问的存储介质，其中所述写入应用器被配置成：
确定存储在所述持久性日志内的第二记录表示被引导到所述第一分区的第二写入的有条件的提交，其中所述第二写入是第二多分区事务的部分；
标识与所述第二多分区事务相关联的提交超时；以及
至少部分基于对应于所述第二多分区事务的无条件提交记录在所述超时截止之前尚未被写入到所述提交决定储存库的检测，放弃所述第二写入到所述第一分区的传播。
21.根据条款19所述的非暂时计算机可访问的存储介质，其中所述写入应用器被配置成：
确定存储在所述持久性日志内的第二记录表示被引导到所述第一分区的第二写入的无条件提交；以及
将所述第二写入传播至所述第一分区而无需检查所述提交决定储存库。
此外，前述内容可鉴于以下另外的条款而进行更好的理解：
1.一种系统，其包括：
一个或多个计算装置，其被配置成：
在包括多个数据存储区的异构存储组的客户端侧部件处接收对应于一个或多个读取的各自读取描述符，所述多个数据存储区包括第一数据存储区和第二数据存储区，所述读取描述符包括对应于引导到所述第一数据存储区的第一读取的第一读取描述符，其中所述第一读取描述符包括对已经被应用在所述第一数据存储区处的状态转变的指示，并且其中，根据无状态协议，在所述第一读取描述符被提供到所述客户端侧部件之后，所述第一数据存储区不维持关于所述客户端侧部件的会话元数据；
将一个或多个写入的各自写入描述符存储在所述客户端侧部件可访问的一个或多个缓冲区中，所述写入描述符包括引导到所述异构存储组的特定数据存储区的第一写入的第一写入描述符，其中所述第一写入的有效负载是至少部分基于所述第一读取的结果，并且其中所述第一写入描述符指示将在所述特定数据存储区处修改的对象；
在所述客户端侧部件处生成对包括所述一个或多个写入的候选事务的提交请求，其中所述提交请求至少包括所述第一读取描述符和所述第一写入描述符；
将所述提交请求从所述客户端侧部件传输到事务管理器；
在所述事务管理器处，至少部分基于根据并发控制协议对所述第一读取描述符的分析，确定所述候选事务被接受用于提交；以及
发起对所述第一写入描述符中所指示的所述对象的修改。
2.根据条款1所述的系统，其中所述客户端侧部件包括在实施在提供商网络处的存储服务的请求处理者节点处执行的进程。
3.根据条款1所述的系统，其中所述第一读取描述符包括用于至少所述第一读取的读取可重复性验证元数据。
4.根据条款1所述的系统，其中所述提交请求包括对应于引导到所述第二数据存储区的第二读取的第二读取描述符，其中所述一个或多个写入的至少一个写入的有效负载是至少部分基于所述第二读取的结果。
5.根据条款1所述的系统，其中所述一个或多个写入包括引导到不同于所述特定数据存储区的数据存储区的第二写入。
6.一种方法，其包括：
通过一个或多个计算装置执行：
在包括一个或多个数据存储区的存储组的客户端侧部件处接收对应于一个或多个读取的各自读取描述符，所述数据存储区包括第一数据存储区，所述读取描述符包括对应于引导到所述第一数据存储区的第一读取的第一读取描述符，其中所述第一读取描述符包括对已经应用在所述第一数据存储区处的状态转变的指示；
在所述客户端侧部件处生成一个或多个写入的各自写入描述符，所述写入描述符包括引导到所述一个或多个数据存储区的特定数据存储区的第一写入的第一写入描述符，其中所述第一写入的有效负载是至少部分基于所述第一读取的结果，并且其中所述第一写入描述符指示将在所述特定数据存储区处修改的对象；
将对包括一个或多个写入的候选事务的提交请求从所述客户端侧部件传输到事务管理器，所述写入包括所述第一写入，其中所述提交请求至少包括所述第一读取描述符和所述第一写入描述符；
在所述事务管理器处，至少部分基于对所述第一读取描述符的分析，确定所述候选事务将被接受用于提交。
7.根据条款6所述的方法，其中根据无状态协议，在所述第一读取描述符被提供到所述客户端侧部件之后，所述第一数据存储区不维持关于所述第一读取的会话元数据。
8.根据条款6所述的方法，其还包括通过所述一个或多个计算装置执行：
将指示所述候选事务已经被接受用于提交的事务记录存储在所述事务管理器的耐久日志中；
其中所述候选事务将被接受用于提交的所述确定是至少部分基于对存储在所述耐久日志中的一个或多个其他事务记录的分析。
9.根据条款8所述的方法，其中使用复制图的多个节点实施所述耐久日志。
10.根据条款6所述的方法，其中所述候选事务将被接受用于提交的所述确定包括验证所述第一读取的结果集自所述读取描述符生成以来尚未被修改。
11.根据条款6所述的方法，其中对所述特定状态转变的所述指示包括逻辑时间戳。
12.根据条款6所述的方法，其中所述第一读取描述符包括用于至少所述第一读取的读取可重复性验证元数据。
13.根据条款6所述的方法，其中所述一个或多个数据存储区包括第二数据存储区，其中所述第一数据存储区实施第一数据模型并且所述第二数据存储区实施不同的数据模型，其中所述提交请求包括对应于引导到所述第二数据存储区的第二读取的第二读取描述符，其中所述一个或多个写入的至少一个写入的有效负载是至少部分基于所述第二读取的结果。
14.根据条款12所述的方法，其中所述第一数据存储区包括以下各者中的一者：非关系数据库系统、关系数据库系统、实施允许访问非结构化数据对象的web服务接口的存储服务、存储器中数据库、分布式缓存的实例、排队服务的部件、或通知服务的部件。
15.根据条款6所述的方法，其中所述第一数据存储区不支持包括一个以上写入的事务的原子性。
16.一种非暂时计算机可访问的存储介质，其存储程序指令，所述程序指令在于一个或多个处理器上执行时：
在包括一个或多个数据存储区的存储组的客户端侧部件处接收对应于一个或多个读取的各自读取描述符，所述数据存储区包括第一数据存储区，所述读取描述符包括对应于引导到所述第一数据存储区的第一读取的第一读取描述符，其中所述第一读取描述符包括对已经应用在所述第一数据存储区处的状态转变的指示；
在所述客户端侧部件处生成一个或多个写入的各自写入描述符，所述写入描述符包括引导到所述一个或多个数据存储区的特定数据存储区的第一写入的第一写入描述符，其中所述第一写入的有效负载是至少部分基于所述第一读取的结果，并且其中所述第一写入描述符指示将在所述特定数据存储区处修改的对象；以及
将对包括一个或多个写入的候选事务的提交请求从所述客户端侧部件传输到事务管理器，所述写入包括所述第一写入，其中所述提交请求至少包括所述第一读取描述符和所述第一写入描述符。
17.根据条款16所述的非暂时计算机可访问的存储介质，其中根据无状态协议，所述第一数据存储区不维持关于所述第一读取的会话元数据。
18.根据条款16所述的非暂时计算机可访问的存储介质，其中所述第一读取描述符包括用于至少所述第一读取的读取可重复性验证元数据。
19.根据条款16所述的非暂时计算机可访问的存储介质，其中所述一个或多个数据存储区包括第二数据存储区，其中所述第一数据存储区实施第一数据模型并且所述第二数据存储区实施不同的数据模型，其中所述提交请求包括对应于引导到所述第二数据存储区的第二读取的第二读取描述符，其中所述一个或多个写入的至少一个写入的有效负载是至少部分基于所述第二读取的结果。
20.根据条款16所述的非暂时计算机可访问的存储介质，其中所述第一数据存储区不支持包括一个以上写入的事务的原子性。
此外，前述内容可鉴于以下另外的条款而进行更好的理解：
1.一种系统，其包括：
一个或多个计算装置，其被配置成：
接收引导到异构存储组的多个数据存储区的第一数据存储区的第一读取请求，其中所述第一读取请求包括将用于标识第一结果集的第一过滤准则；
确定特定状态转变的指示符，其中所述特定状态转变包括在标识所述第一结果集之前应用于所述第一数据存储区的一个或多个修改；
使用所述第一过滤准则标识所述第一结果集；
生成读取描述符，所述读取描述符包括(a)所述特定状态转变的所述指示符和(b)可用于确定所述第一读取请求是否表示可重复读取的读取可重复性验证元数据(RRVM)；
将所述第一结果集和所述读取描述符的表示传输到所述异构存储组的客户端侧部件；以及
至少部分基于对所述读取描述符的分析，确定在所述第一读取请求之后引导到所述异构存储组的特定数据存储区的写入请求满足接受准则。
2.根据条款1所述的系统，其中所述RRVM包括所述第一过滤准则的表示。
3.根据条款1所述的系统，其中所述RRVM是至少部分基于包括在所述第一结果集中的数据对象的地址。
4.根据条款1所述的系统，其中所述读取描述符的所述表示包括所述读取描述符的混淆版本。
5.一种方法，其包括：
通过一个或多个计算装置执行：
接收引导到第一数据存储区的第一读取请求；
确定特定状态转变的指示符，其中所述特定状态转变包括在标识所述第一读取请求的第一结果集之前应用于所述第一数据存储区的一个或多个修改；
生成读取描述符，所述读取描述符包括(a)所述特定状态转变的所述指示符和(b)可用于确定所述第一读取请求是否表示可重复读取的读取可重复性验证元数据(RRVM)；以及
响应于所述第一读取请求，将至少所述读取描述符的表示和所述第一结果集传输到特定目的地。
6.根据条款5所述的方法，其中所述RRVM包括所述读取请求中所指示的选择准则的表示。
7.根据条款5所述的方法，其中所述RRVM包括将被调用来确定所述第一读取请求的重复是否将导致不同于所述第一结果集的结果集的函数的表示。
8.根据条款5所述的方法，其中所述RRVM是至少部分基于包括在所述第一结果集中的数据对象的地址。
9.根据条款5所述的方法，其中所述RRVM包括应用于包括在所述第一结果集中的数据对象的所述地址的所选散列函数的输出。
10.根据条款5所述的方法，其中所述特定状态转变的所述指示包括逻辑时间戳。
11.根据条款5所述的方法，其中所述读取描述符包括对第一结果集的数据对象的最后修改时间的指示。
12.根据条款5所述的方法，其中所述读取描述符包括对所述第一数据存储区的表格的最后修改时间的指示，其中所述表格包括所述第一结果集的一个或多个数据对象。
13.根据条款5所述的方法，其中对所述读取描述符的所述表示包括所述读取描述符的混淆版本。
14.根据条款5所述的方法，其还包括通过所述一个或多个计算装置执行：
确定将被并入所述读取描述符的所述表示中的填充字节的数目，其中所述确定包括使用随机数字计算；以及
在所述传输所述表示之前，将填充字节的所述数目并入在所述读取描述符的所述表示内。
15.一种非暂时计算机可访问的存储介质，其存储程序指令，所述程序指令在于一个或多个处理器上执行时：
响应于引导在存储组的第一数据存储区处的读取请求，确定对应于在生成所述读取请求的第一结果集之前已经应用在所述第一数据存储区处的修改的特定状态转变的指示符；
生成读取描述符，所述读取描述符包括(a)所述特定状态转变的指示和(b)可用于确定所述第一读取请求是否表示可重复读取的读取可重复性验证元数据(RRVM)；以及
发起所述读取描述符和所述第一结果集到所述存储组的客户端侧部件的传输。
16.根据条款15所述的非暂时计算机可访问的存储介质，其中所述RRVM包括所述读取请求中所指示的选择准则的表示。
17.根据条款15所述的非暂时计算机可访问的存储介质，其中所述RRVM包括将被调用来确定所述读取请求的重复是否将导致不同于所述第一结果集的结果集的函数的表示。
18.根据条款15所述的非暂时计算机可访问的存储介质，其中所述RRVM是至少部分基于包括在所述第一结果集中的数据对象的地址。
19.根据条款15所述的非暂时计算机可访问的存储介质，其中所述特定状态转变的所述指示包括逻辑时间戳。
结论
各种实施方案还可包括在计算机可访问的介质上接收、发送或存储根据前文描述实施的指令和/或数据。一般来说，计算机可访问的介质可包括存储介质或存储器介质诸如磁或光介质(例如磁盘或DVD/CD-ROM)、易失性或非易失性介质诸如RAM(例如，SDRAM、DDR、RDRAM、SRAM等)、ROM等，以及经由通信介质(诸如网络和/或无线链路)传送的传输介质或信号诸如电、电磁或数字信号。
如图中所示和本文所述的各种方法表示方法的示例性实施方案。方法可在软件、硬件或它们的组合中实施。可改变方法的顺序，并且各种元素可被添加、重新排序、组合、省略、修改等。
如获益于本公开的本领域中的技术人员将明白，可作出各种修改和改变。希望包含全部这类修改和改变，并且因此上文描述将被视为说明性意义而非限制性意义。

Claims (15)

1.一种系统，其包括：
一个或多个计算装置，其被配置成：
在第一基于日志的事务管理器(LTM)处从存储组的客户端侧部件接收对第一多分区事务的第一写入的第一提交请求，其中所述第一写入取决于所述第一提交请求中所指示的第一读取的结果，其中所述第一读取被引导到所述存储组的第一分区；
在第二LTM处从所述客户端侧部件接收对所述第一多分区事务的第二写入的第二提交请求，其中所述第二写入取决于所述第二提交请求中所指示的第二读取的结果，其中所述第二读取被引导到所述存储组的第二分区；
将对应于所述第一写入的第一有条件的提交记录存储在所述第一LTM的第一持久性日志内，指示所述第一写入关于所述第一读取与记录在所述第一持久性日志中的第一写入子集之间的读取-写入冲突是可提交的，其中所述第一有条件的提交记录包括关于所述第一多分区事务的元数据；
将对应于所述第二写入的第二有条件的提交记录存储在所述第二LTM的第二持久性日志内，指示所述第二写入关于所述第二读取与记录在所述第二持久性日志中的第二写入子集之间的读取-写入冲突是可提交的，其中所述第二有条件的提交记录包括关于所述第一多分区事务的所述元数据；
响应于确定(a)所述第一有条件的提交记录已经被存储和(b)所述第二有条件的提交记录已经被存储，通过所述客户端侧部件将对应于所述第一多分区事务的第一无条件提交记录存储在多分区提交决定储存库(MCDR)中；以及
响应于(a)对包括在所述第一有条件的提交记录中的关于所述第一多分区事务的所述元数据的检查和(b)对所述第一无条件提交记录的检查，通过与所述存储组的特定分区相关联的第一写入应用器将所述第一写入传播到所述特定分区。
2.根据权利要求1所述的系统，其中所述一个或多个计算装置还被配置成：
在所述第一LTM处接收对不同多分区事务的第三写入的第三提交请求，其中所述第三写入被引导到所述第一分区，并且其中所述第三提交请求包括所述不同多分区事务的超时的表示；
将对应于所述第三写入的第三有条件的提交记录存储在所述第一持久性日志内，指示所述第三写入关于读取-写入冲突是可提交的；
在所述超时截止之后，检测对应于所述不同多分区事务的第二无条件提交记录尚未存储在所述MCDR中；以及
确定将不实施所述第三写入到所述第一分区的传播。
3.根据权利要求1所述的系统，其中所述第一提交请求包括对所述MCDR的指示，并且其中关于所述第一多分区事务的所述元数据包括对所述MCDR的所述指示。
4.根据权利要求1所述的系统，其中所述一个或多个计算装置还被配置成：
在所述第一提交请求之前，接收被引导到所述存储组的一种或多种类型的操作的目标性能水平的指示；以及
至少部分基于所述目标性能水平的所述指示确定以下各者中的一者或多者：(a)将针对所述存储组建立的LTM的数目，(b)将针对所述存储组建立的MCDR的数目或(c)将针对所述存储组建立的写入应用器的数目。
5.根据权利要求1所述的系统，其中所述第一分区被指定为所述存储组的主分区，其中所述第一持久性日志至少包括第一服务器的一个或多个存储装置的第一部分，并且其中所述MCDR至少包括所述第一服务器的所述一个或多个存储装置的第二部分。
6.一种方法，其包括：
通过一个或多个计算装置执行：
将对应于第一多分区事务的第一写入的第一有条件的提交记录存储在存储组的第一基于日志的事务管理器(LTM)的第一持久性日志内，指示所述第一写入已经至少部分基于由所述第一LTM执行的第一冲突检测分析而被指定为可提交的；
将对应于所述第一多分区事务的第二写入的第二有条件的提交记录存储在所述存储组的第二LTM的第二持久性日志内，指示所述第二写入已经至少部分基于由所述第二LTM执行的第二冲突检测分析而被指定为可提交的；
响应于检测到所述第一和第二写入已经被指定为可提交的，存储对应于所述第一多分区事务的第一无条件提交记录；以及
响应于(a)对所述第一有条件的提交记录的检查和(b)对所述第一无条件提交记录的检查，通过第一写入应用器将所述第一写入传播到所述存储组的特定分区。
7.根据权利要求6所述的方法，其还包括通过所述一个或多个计算装置执行：
在所述第一LTM处接收对不同多分区事务的不同写入的提交请求，其中所述不同写入被引导到所述第一分区，并且其中所述提交请求包括所述不同多分区事务的超时的表示；
将对应于所述不同写入的第三有条件的提交记录存储在所述第一持久性日志内，指示所述不同写入可至少部分基于由所述第一LTM执行的第三冲突检测分析而提交；
在所述超时截止之后，检测到对应于所述不同多分区事务的第二无条件提交记录尚未存储在多分区提交决定储存库(MCDR)中；以及
确定将不实施所述不同写入到所述第一分区的传播。
8.根据权利要求7所述的方法，其中所述MCDR具有提供单调递增的逻辑时间戳值的相关联逻辑时钟，并且其中所述超时包括预期将从所述逻辑时钟获得的特定未来逻辑时间戳值。
9.根据权利要求6所述的方法，其中响应于对所述第一写入的第一提交请求而存储所述第一有条件的提交记录，并且其中响应于对所述第二写入的第二提交请求而存储所述第二有条件的提交请求，所述方法还包括通过所述一个或多个计算装置执行：
在所述第一LTM处接收对第二多分区事务的第三写入的第三提交请求，其中所述第三写入取决于引导到所述第一分区的第三读取的结果；
在所述第二LTM处接收对所述第二多分区事务的第四写入的第四提交请求，其中所述第四写入取决于引导到所述第二分区的第四读取的结果；
将对应于所述第三写入的第三有条件的提交记录存储在所述第一持久性日志内，指示所述第三写入可至少部分基于由所述第一LTM执行的第三冲突检测分析而提交；
至少部分基于由所述第二LTM检测的特定冲突而确定所述第四提交请求已经被所述第二LTM拒绝；以及
响应于所述第四提交请求已经被拒绝的所述指示而放弃对所述第三写入的传播。
10.根据权利要求6所述的方法，其中响应于在所述第一LTM处从所述存储组的客户端侧部件接收的第一提交请求而存储所述第一有条件的提交记录，其中所述存储所述第一无条件提交记录由所述客户端侧部件执行。
11.根据权利要求10所述的方法，其中所述第一提交请求包括第一读取的指示，其中所述第一写入取决于所述第一读取的结果，并且其中所述第一读取的所述指示供所述第一LTM使用来执行所述第一冲突检测分析。
12.根据权利要求6所述的方法，其还包括通过所述一个或多个计算装置执行：
接收引导到所述存储组的一种或多种类型的操作的目标性能水平的指示；以及
至少部分基于所述目标性能水平的所述指示确定以下各者中的一者或多者：(a)将针对所述存储组建立的LTM的数目，(b)将针对所述存储组建立的多分区提交决定储存库的数目或(c)将针对所述存储组建立的写入应用器的数目。
13.根据权利要求6所述的方法，其中所述第一分区被指定为所述存储组的主分区，其中所述第一持久性日志至少包括第一服务器的一个或多个存储装置的第一部分，并且其中所述第一无条件提交记录存储在所述一个或多个存储装置的特定存储装置处。
14.根据权利要求6所述的方法，其中所述第一无条件提交记录存储在多分区提交决定储存库(MCDR)中，所述决定储存库包括复制有向非循环图的多个节点，所述多个节点包括第一节点和第二节点，并且其中所述存储所述第一无条件提交记录包括将所述第一无条件提交记录的各自副本存储在所述第一节点和所述第二节点处。
15.一种系统，其包括：
一个或多个处理器；以及
一个或多个存储器，其存储程序指令，所述程序指令在于所述一个或多个处理器上执行时实施存储组的客户端侧部件，其中所述客户端侧部件被配置成：
将对第一多分区事务的第一写入的第一提交请求传输到存储组的第一基于日志的事务管理器(LTM)，其中所述第一提交请求包括对所述第一写入所依据的第一读取的指示，其中所述第一读取被引导到所述存储组的第一分区；
将对第一多分区事务的第二写入的第二提交请求传输到所述存储组的第二基于日志的事务管理器(LTM)，其中所述第二提交请求包括对所述第二写入所依据的第二读取的指示，其中所述第二读取被引导到所述存储组的第二分区；
响应于确定(a)所述第一写入已经被指定为可由所述第一LTM至少部分基于第一提交分析而提交以及(b)所述第二写入已经被指定为可由所述第二LTM至少部分基于第二提交分析而提交，而将对应于所述第一多分区事务的第一无条件提交记录存储在选定位置处。
CN201580056687.3A 2014-09-10 2015-09-10 可扩展的基于日志的事务管理 Active CN107077492B (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US14/482,677 2014-09-10
US14/482,661 2014-09-10
US14/482,668 2014-09-10
US14/482,677 US9323569B2 (en) 2014-09-10 2014-09-10 Scalable log-based transaction management
US14/482,661 US9519674B2 (en) 2014-09-10 2014-09-10 Stateless datastore-independent transactions
US14/482,668 US10303795B2 (en) 2014-09-10 2014-09-10 Read descriptors at heterogeneous storage systems
PCT/US2015/049470 WO2016040666A1 (en) 2014-09-10 2015-09-10 Scalable log-based transaction management

Publications (2)

Publication Number Publication Date
CN107077492A true CN107077492A (zh) 2017-08-18
CN107077492B CN107077492B (zh) 2020-09-08

Family

ID=54207747

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201580056687.3A Active CN107077492B (zh) 2014-09-10 2015-09-10 可扩展的基于日志的事务管理

Country Status (5)

Country Link
EP (1) EP3191984B1 (zh)
JP (2) JP6346376B2 (zh)
CN (1) CN107077492B (zh)
CA (2) CA3040213C (zh)
WO (1) WO2016040666A1 (zh)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107544758A (zh) * 2017-08-29 2018-01-05 新华三云计算技术有限公司 集群的磁盘心跳检测方法和装置
CN108932286A (zh) * 2018-05-23 2018-12-04 阿里巴巴集团控股有限公司 一种数据存储方法、数据查询方法及装置
CN109450670A (zh) * 2018-10-19 2019-03-08 杭州东方通信软件技术有限公司 一种人工智能模式下的指令冲突判断方法及其系统
CN109656700A (zh) * 2018-12-17 2019-04-19 广州市玄武无线科技股份有限公司 多租户下分布式链路跟踪方法、系统、设备以及存储介质
CN110058958A (zh) * 2018-01-18 2019-07-26 伊姆西Ip控股有限责任公司 用于管理数据备份的方法、设备和计算机程序产品
CN110121712A (zh) * 2017-12-05 2019-08-13 华为技术有限公司 一种日志管理方法、服务器和数据库系统
CN110147369A (zh) * 2017-10-26 2019-08-20 Sap欧洲公司 多重租赁数据库系统中的数据分离和写入重新定向
CN110457305A (zh) * 2019-08-13 2019-11-15 腾讯科技（深圳）有限公司 数据去重方法、装置、设备及介质
CN111930692A (zh) * 2020-05-28 2020-11-13 武汉达梦数据库有限公司 一种基于日志解析同步的事务合并执行方法及装置
CN111930693A (zh) * 2020-05-28 2020-11-13 武汉达梦数据库有限公司 一种基于日志解析同步的事务合并执行方法及装置
CN112068986A (zh) * 2019-06-10 2020-12-11 伊姆西Ip控股有限责任公司 用于管理备份任务的方法、设备和计算机程序产品
US20240103981A1 (en) * 2022-09-28 2024-03-28 Hitachi, Ltd. Automatic copy configuration

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017181430A1 (zh) * 2016-04-22 2017-10-26 华为技术有限公司 分布式系统的数据库复制方法及装置
CN109725989B (zh) * 2017-10-31 2020-07-31 阿里巴巴集团控股有限公司 一种任务执行的方法及装置
US11823178B2 (en) 2017-11-17 2023-11-21 International Business Machines Corporation Optimization of high volume transaction performance on a blockchain
CN111489490B (zh) * 2019-01-28 2022-05-06 菜鸟智能物流控股有限公司 物流对象容器发生异常事件的处理方法、装置及对象容器
CN111831337B (zh) 2019-04-19 2022-11-29 安徽寒武纪信息科技有限公司 数据同步方法及装置以及相关产品
CN111782267B (zh) * 2019-04-04 2022-12-09 安徽寒武纪信息科技有限公司 数据处理方法及装置以及相关产品
CN111857828B (zh) * 2019-04-25 2023-03-14 安徽寒武纪信息科技有限公司 处理器操作方法及装置以及相关产品
CN111857829A (zh) * 2019-04-25 2020-10-30 安徽寒武纪信息科技有限公司 处理器操作方法及装置以及相关产品
CN111782577B (zh) 2019-04-04 2023-03-24 安徽寒武纪信息科技有限公司 数据处理装置及方法以及相关产品
EP3828698B1 (en) * 2019-04-04 2022-07-20 Cambricon Technologies Corporation Limited Data processing method and apparatus, and related product
JP7227538B2 (ja) * 2019-07-25 2023-02-22 日本電信電話株式会社 選定装置、選定方法、およびプログラム
CN113807507A (zh) * 2020-06-16 2021-12-17 安徽寒武纪信息科技有限公司 数据处理方法及装置以及相关产品
CN112948206B (zh) * 2021-02-22 2024-05-31 上海宽带技术及应用工程研究中心 基于云计算的时序日志管理系统及包含该系统的电子设备
US20240062192A1 (en) * 2022-08-18 2024-02-22 DefinQ, Inc. Single step staking for smart contracts and other blockchain transactions

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110314148A1 (en) * 2005-11-12 2011-12-22 LogRhythm Inc. Log collection, structuring and processing
CN102419764A (zh) * 2010-10-20 2012-04-18 微软公司 带有多版本化的数据库系统的分布式事务管理
US20120166407A1 (en) * 2010-12-28 2012-06-28 Juchang Lee Distributed Transaction Management Using Two-Phase Commit Optimization

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04199339A (ja) * 1990-11-29 1992-07-20 Hitachi Ltd 分散処理システムの分散トランザクションファイル制御方法
JPH06243072A (ja) * 1993-02-17 1994-09-02 Hitachi Ltd 分散処理システムの分散トランザクションコミット制御方式
JPH08235043A (ja) * 1995-02-28 1996-09-13 N T T Data Tsushin Kk 協調型分散システム
JP3094888B2 (ja) * 1996-01-26 2000-10-03 三菱電機株式会社 採番機構、データ整合性確認機構、トランザクション再実行機構及び分散トランザクション処理システム
JP5088734B2 (ja) * 2007-11-22 2012-12-05 インターナショナル・ビジネス・マシーンズ・コーポレーション 耐障害性トランザクション処理システム及び処理方法
JP2011076487A (ja) * 2009-09-30 2011-04-14 Oki Networks Co Ltd 計算機、及びデータベース管理プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110314148A1 (en) * 2005-11-12 2011-12-22 LogRhythm Inc. Log collection, structuring and processing
CN102419764A (zh) * 2010-10-20 2012-04-18 微软公司 带有多版本化的数据库系统的分布式事务管理
US20120166407A1 (en) * 2010-12-28 2012-06-28 Juchang Lee Distributed Transaction Management Using Two-Phase Commit Optimization

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OZGUR ULUSOY: "Processing real-time transactions in a replicated database system", 《DISTRIBUTED AND PARALLEL DATABASES》 *

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107544758B (zh) * 2017-08-29 2020-07-10 新华三云计算技术有限公司 集群的磁盘心跳检测方法和装置
CN107544758A (zh) * 2017-08-29 2018-01-05 新华三云计算技术有限公司 集群的磁盘心跳检测方法和装置
CN110147369A (zh) * 2017-10-26 2019-08-20 Sap欧洲公司 多重租赁数据库系统中的数据分离和写入重新定向
CN110147369B (zh) * 2017-10-26 2023-09-12 Sap欧洲公司 多重租赁数据库系统中的数据分离和写入重新定向
CN110121712B (zh) * 2017-12-05 2022-04-05 华为技术有限公司 一种日志管理方法、服务器和数据库系统
CN110121712A (zh) * 2017-12-05 2019-08-13 华为技术有限公司 一种日志管理方法、服务器和数据库系统
CN110058958A (zh) * 2018-01-18 2019-07-26 伊姆西Ip控股有限责任公司 用于管理数据备份的方法、设备和计算机程序产品
CN108932286B (zh) * 2018-05-23 2022-04-22 北京奥星贝斯科技有限公司 一种数据查询方法及装置
CN108932286A (zh) * 2018-05-23 2018-12-04 阿里巴巴集团控股有限公司 一种数据存储方法、数据查询方法及装置
CN109450670B (zh) * 2018-10-19 2022-04-01 杭州东方通信软件技术有限公司 一种人工智能模式下的指令冲突判断方法及其系统
CN109450670A (zh) * 2018-10-19 2019-03-08 杭州东方通信软件技术有限公司 一种人工智能模式下的指令冲突判断方法及其系统
CN109656700A (zh) * 2018-12-17 2019-04-19 广州市玄武无线科技股份有限公司 多租户下分布式链路跟踪方法、系统、设备以及存储介质
CN112068986A (zh) * 2019-06-10 2020-12-11 伊姆西Ip控股有限责任公司 用于管理备份任务的方法、设备和计算机程序产品
CN112068986B (zh) * 2019-06-10 2024-04-12 伊姆西Ip控股有限责任公司 用于管理备份任务的方法、设备和计算机程序产品
CN110457305A (zh) * 2019-08-13 2019-11-15 腾讯科技（深圳）有限公司 数据去重方法、装置、设备及介质
CN111930692A (zh) * 2020-05-28 2020-11-13 武汉达梦数据库有限公司 一种基于日志解析同步的事务合并执行方法及装置
CN111930693A (zh) * 2020-05-28 2020-11-13 武汉达梦数据库有限公司 一种基于日志解析同步的事务合并执行方法及装置
CN111930693B (zh) * 2020-05-28 2024-02-06 武汉达梦数据库股份有限公司 一种基于日志解析同步的事务合并执行方法及装置
US20240103981A1 (en) * 2022-09-28 2024-03-28 Hitachi, Ltd. Automatic copy configuration

Also Published As

Publication number Publication date
CA3040213A1 (en) 2016-03-17
CN107077492B (zh) 2020-09-08
WO2016040666A1 (en) 2016-03-17
CA2960988A1 (en) 2016-03-17
CA3040213C (en) 2020-09-08
CA2960988C (en) 2019-06-04
JP2017531256A (ja) 2017-10-19
EP3191984B1 (en) 2021-03-10
JP6677759B2 (ja) 2020-04-08
JP2018163671A (ja) 2018-10-18
JP6346376B2 (ja) 2018-06-20
EP3191984A1 (en) 2017-07-19

Similar Documents

Publication Publication Date Title
CN107077492A (zh) 可扩展的基于日志的事务管理
CN106462449B (zh) 具有多项目事务支持的多数据库日志
CN107148617A (zh) 日志协调存储组的自动配置
US11397709B2 (en) Automated configuration of log-coordinated storage groups
CN106233264B (zh) 使用可变条带大小的文件存储装置
CN106255967B (zh) 分布式存储系统中的命名空间管理
US10373247B2 (en) Lifecycle transitions in log-coordinated data stores
US20180047002A1 (en) Cross-data-store operations in log-coordinated storage systems
CN105706086B (zh) 用于获取、存储和消费大规模数据流的管理服务
US9323569B2 (en) Scalable log-based transaction management
US9519674B2 (en) Stateless datastore-independent transactions
US9852204B2 (en) Read-only operations processing in a paxos replication system
US10303795B2 (en) Read descriptors at heterogeneous storage systems
CN106462601A (zh) 针对多盘区操作的原子写入
CN103930875B (zh) 用于加速业务数据处理的软件虚拟机
CN106462544A (zh) 分布式存储系统中的会话管理
CN106462545A (zh) 可缩放文件存储服务
Dubey On Consistent and Efficient Graph Data Management

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant