cap理论:
Consistency 一致性:“all nodes see the same data at the same time”,即所有节点在同一时间的数据完全一致。
Availability 可用性:“Reads and writes always succeed”,即服务在正常响应时间内一直可用。
Partition Tolerance分区容错性:the system continues to operate despite arbitrary message loss or failure of part of the system,即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务。
一 CRAQ论文
文章:Object Storage on CRAQ
1 CR(Chain Replication)
图:读操作必须由尾节点处理,写操作从头节点开始向下进行
所有读取请求都到达并在尾部处理。写请求到达链的头部,并向下传播到链的尾部。 当尾节点提交写操作时,会向客户端发送一个答复。 CR(Chain Replication)文件描述了尾部直接向客户端发送消息; 因为我们使用TCP,所以我们的实现实际上让头部在接收到来自尾部的确认后做出响应,因为它已经与客户机建立了网络连接。 此确认传播如图中的虚线所示。2 针对于大量读的优化CRAQ(Chain Replication with Apportioned Queries):
对数据进行dirty,clear标记。一个节点可以存储一个对象的多个版本,每个版本都包括一个单调递增的版本号和一个附加属性用来标记该版本是干净的还是脏的。所有版本最初都标记为干净。当节点收到一个对象的新版本时,如果该节点不是尾部,就将该对象标记为dirty,如果到了尾节点,就标记为clean并将此版本提交,然后尾节点通过链通知其他节点提交。
图:clear状态下的链
每个节点都处于clear状态,存储一个对象的相同副本,读请求可以访问任意节点返回相同的值。图:对脏对象的读取可以由任何节点接收,但是当对象为dirty时,需要向尾节点请求clear版本,尾节点返回对象版本号,脏节点返回对应版本的对象。
二 Amazon Aurora数据库内核:
crash-safe:因为redo log,InnoDB能保证数据库发生异常重启,之前提交的记录不会丢失。
redo log日志:在InnoDB引擎特有的日志,属于物理日志。循环写的。
binlog日志:在Server层中,是逻辑日志。追加写的。
索引:
InnoDB索引使用B+树索引模型,根据叶子结点的内容,分为主键索引和非主键索引。 主键索引的叶子节点存的是整行数据,InnoDB中,主键索引也被称为聚簇索引(clustered index) 非主键索引的叶子节点内容是主键的值,非主键索引也称为二级索引(secondary index) 基于非主键查询需要多扫描一棵主键索引树,所以应用中应该尽量使用主键索引。
最左前缀原则:即最左优先,在检索数据时从联合索引的最左边开始匹配(基于InnoDB引擎中索引是B+树的特性)
索引的复用能力:联合索引因为可以支持最左前缀,所以当已经有了 (a,b)这个联合索引后,一般就不需要单独在 a 上建立索引了。因此,第一原则是,如果通过调整顺序,可以少维护一个索引,那么这个顺序往往就是需要优先考虑采用的。索引的复用能力。因为可以支持最左前缀,所以当已经有了 (a,b)这个联合索引后,一般就不需要单独在 a 上建立索引了。因此,第一原则是,如果通过调整顺序,可以少维护一个索引,那么这个顺序往往就是需要优先考虑采用的。