分布式系统概念和设计
分布式事务
访问多个服务器管理的对象的事务称为分布式事务。
当一个分布式事务结束时，事务的原子特性要求所有参与事务的服务器必须全部提交或全部放弃。
实现：
- 其中一个服务器承担了协调者的角色，保证在所有的服务器上获得一样的结果。
- 协调者的动作取决于协议：二阶段提交协议，该协议允许服务器之间通信，可以就提交和放弃共同做出决定。
平面和嵌套分布式事务
分布式事务的协调者
- 执行了分布式事务请求的服务器需要相互通信，以确保在事务提交时能够协调他们之间的动作。
- 创建某一分布式事务的协调者称为该分布式事务的协调者，作用于在分布式事务结束时负责提交或放弃事务。
- 分布式事务访问的每个服务器都是该事务的参与方，每个服务器提供一个我们称为参与者的对象。
- 每个事务参与者负责跟踪所有参与分布式事务的可恢复对象。
- 这些参与者配合协调者共同执行提交协议的决定。
- 在事务的执行过程中，协调者在列表中记录所有对参与者的引用，每个参与者都记录一个对协调者的引用。
- 协调者将参与者记录到分布式事务的参与者的列表中。
- 协调者知道此事务的每个参与者，每个参与者也知道协调者。
- 在事务的提交过程中，参与者和协调者都能收集到必要的信息。
原子提交协议
二阶段提交协议
出发点是任何一个参与者都能提交或放弃事务它那部分事务。
根据事务的原子特性，如果一个事务放弃提交事务，那么整个分布式事务全部放弃。
- 第一个阶段是每个参与者投票决定事务是提交还是放弃。
- 一个参与者决定提交事务之后就不再允许其放弃事务。
- 在一个参与者决定投票决定提交事务时，必须能够保证自己的提交协议能够正确执行，即使其他事务出现故障，
- 一个参与者能够最终提交事务，说明参与者属于事务的准备好的状态。
- 为了保证事务能够提交，每个参与者必须将事务中发生的所有改变的对象和状态保存到持久存储器中。
提交协议的故障模型
二阶段提交协议是一种达成共识的协议。
在异步系统中，如果一个进程崩溃是不可能达成共识
二阶提交协议达成共识的原因是因为，崩溃进程被新进程替代，新进程的状态通过持久存储器的数据进行设置，从而进行响应。
分布式事务的并发和控制
锁
分布式事务中，某个对象的锁总是在同一个服务器中，授权这些锁的是本地锁管理器决定的。
本地锁管理器决定是满足锁的需求还是让其等待。
当时本地事务为提交或放弃之前，本地锁管理器不能释放任何锁。
分布式死锁的问题。
分布式锁是一种用于保证分布式系统并发访问的一致性和可靠性的机制。在设计和实现分布式锁时，需要考虑以下几个方面：
- 锁管理：分布式锁需要能够管理锁的获取、释放等操作，以保证并发性和可靠性。通常可以使用类似于互斥锁的机制来实现分布式锁。
- 节点管理：分布式锁需要能够管理分布式环境下的节点，以保证节点的可用性和容错性。通常可以使用类似于ZooKeeper的分布式协调服务来实现节点管理。
- 通信协议：分布式锁需要能够使用可靠的通信协议进行节点之间的通信，以保证数据的一致性和正确性。通常可以使用类似于TCP的可靠传输协议来实现通信协议。
在实现分布式锁时，可以采用以下几种方式：
- 基于数据库的锁机制：可以使用数据库的锁机制来实现分布式锁，例如行锁、表锁等。这种方式相对简单，但是会影响并发性能。
- 基于分布式协调服务的机制：可以使用分布式协调服务来实现分布式锁，例如基于ZooKeeper的分布式锁机制。这种方式可以保证分布式锁的一致性和可靠性，但是会增加系统的复杂度和开销。
- 基于Redis的机制：可以使用Redis的分布式锁机制来实现分布式锁。这种方式可以保证分布式锁的一致性和可靠性，同时具有较高的性能和可扩展性。
在选择分布式锁的实现方式时，需要根据实际情况综合考虑各种因素，例如系统的复杂度、并发性能、可靠性等。同时，在实现分布式锁时，需要考虑锁的粒度、锁的超时时间、锁的重试机制等问题，以保证分布式锁的正确性和可靠性。
分布式时间戳排序并发控制
- 分布式事务中，协调者必须保证每个事务附上全局唯一的时间戳
- 全局唯一时间戳由事务访问的第一个协调者发送给客户。
- 若服务器上的一个对象执行了事务中的一个操作，那么事务时间戳被传给该服务器上的协调者
- 分布式事务中的所有服务器共同保证事务的串行等价性质。
- 如果一个事务U访问的服务器对象版本在事务T访问后提交，而在另一个服务器上T和U又访问了另外的服务器对象，也必须按照相同次序提交对象。
- 为了保证所有服务器上的相同排序，协调者必须就时间戳顺序达成一致
- 时间戳比较，首先比较本地时间，然后比较服务器id,二元组数据结构
分布式系统中，时间戳排序并发控制（Timestamp Ordering Concurrency Control，TOCC）是一种用于保证并发事务的一致性和隔离性的机制。TOCC的基本思想是使用全局时间戳来对事务进行排序，从而保证事务之间的执行顺序，从而保证事务的一致性和隔离性。
TOCC的实现可以分为两个阶段：
- 事务提交阶段：在事务提交时，需要为每个事务分配一个全局时间戳，该时间戳可以使用递增序列号、时钟同步等方式生成。同时，需要将事务的操作序列和时间戳一起提交到协调节点进行处理。
- 事务处理阶段：在协调节点中，需要对事务进行时间戳排序，从而保证事务的执行顺序。同时，需要对并发访问的数据进行加锁，以保证事务的隔离性。在事务处理完成后，需要将事务的结果和时间戳一起返回给客户端。
TOCC的优点是可以保证事务的一致性和隔离性，同时可以支持高并发访问。但是，TOCC的缺点是需要进行时间戳排序和加锁等操作，会影响系统的性能和可扩展性。
在实现TOCC时，需要考虑以下几个方面：
- 时间戳生成方式：需要选择合适的时间戳生成方式，以保证时间戳的唯一性和递增性。
- 时间戳排序算法：需要选择合适的时间戳排序算法，以保证时间戳的正确排序。
- 锁管理：需要对并发访问的数据进行加锁，以保证事务的隔离性和正确性。
- 容错机制：需要考虑分布式环境下的容错机制，以保证系统的可用性和可靠性。
乐观并发控制
- 每个事务提交之前必须首先进行验证。
- 事务在验证开始时被贴上一个事务序号，事务的串行化是根据这些事务的序号的顺序实现的。
- 分布式事务的验证由一组服务器共同完成，每个服务器验证自己对象的事务。
在分布式系统中，乐观并发控制（Optimistic Concurrency Control，OCC）是一种用于保证并发事务的一致性和隔离性的机制。OCC的基本思想是假设事务之间不存在冲突，即所有事务都可以并发执行。在事务提交时，需要对事务进行版本控制，以保证事务的一致性和隔离性。
OCC的实现可以分为两个阶段：
- 事务执行阶段：在事务执行时，需要为每个事务记录一个版本号，该版本号可以使用递增序列号、时间戳等方式生成。同时，需要对事务执行过程中访问的数据进行标记，以记录事务执行的版本号。
- 事务提交阶段：在事务提交时，需要检查事务访问的数据是否被其他事务修改，如果没有被修改，则提交事务。如果被修改，则需要回滚事务并重新执行。
OCC的优点是可以支持高并发访问，同时不需要进行加锁等操作，可以提高系统的性能和可扩展性。但是，OCC的缺点是需要进行版本控制和冲突检测等操作，会增加系统的复杂度和开销。
在实现OCC时，需要考虑以下几个方面：
- 版本控制方式：需要选择合适的版本控制方式，以保证版本号的唯一性和递增性。
- 冲突检测方式：需要选择合适的冲突检测方式，以保证事务的一致性和隔离性。
- 容错机制：需要考虑分布式环境下的容错机制，以保证系统的可用性和可靠性。
在选择OCC的实现方式时，需要根据实际情况综合考虑各种因素，例如系统的复杂度、并发性能、可靠性等。同时，在实现OCC时，需要考虑版本控制方式、冲突检测方式、容错机制等问题，以保证OCC的正确性和可靠性。
分布式死锁
分布式系统中，死锁是一种常见的问题。当多个进程或线程在分布式系统中互相等待对方释放锁资源时，就会发生死锁。分布式死锁的发生是由于分布式系统中存在多个独立的资源管理器，而这些资源管理器又相互依赖，从而导致了死锁的发生。
分布式死锁的解决方法可以分为以下几种：
- 超时机制：在分布式系统中，可以使用超时机制来解决死锁问题。当一个事务等待其他事务释放锁资源的时间超过一定的阈值时，就认为发生了死锁，并回滚事务。
- 死锁检测：在分布式系统中，可以使用死锁检测机制来解决死锁问题。死锁检测机制可以通过检查系统中的资源分配情况来判断是否发生了死锁，并采取相应的措施来解除死锁。
- 锁粒度控制：在分布式系统中，可以通过控制锁粒度来减少死锁的发生。例如，可以将锁粒度从表级别降低到行级别，从而减少死锁的概率。
- 资源分配策略：在分布式系统中，可以通过优化资源分配策略来减少死锁的发生。例如，可以采用资源预留策略，即在事务执行前就预留好所需的资源，从而避免死锁的发生。
分布式事务恢复
- 事务的原子性要求事务访问的对象能够反映出所有已经提交事务的作用，而取消所有未完成或者放弃的事务的作用
- 持久性：被要求对象被永久的存储在可靠存储器上并且一直可用，如果客户提交事务确认，所有对象的更新都会被保存到持久存储器
- 故障原子性要求：即使服务器故障，事物的作用也是原子性。
- 事务的恢复功能就是保证服务器对象的持久性和并提供故障原子性服务。
- 恢复管理器：
- 对于已经提交的事务，将对象保存到持久存储器
- 服务器崩溃后恢复服务器上的对象
- 重新组织恢复文件以提高恢复操作的性能
- 回收存储空间
日志
- 日志技术上，恢复文件包含了该服务器上执行的所有操作的历史
- 操作历史由对象值，操作事务状态和意图列表组成
- 事务中的次序反映了服务器上事务准备好，已提交或放弃的次序
- 在服务器正常操作过程中，每次事务准备提交，提交，放弃，恢复管理器都会被调用。
- 恢复文件的添加是原子性质的，即写入的总是完整的。
- 如果服务器崩溃，最后一次写入可能不完整。
- 为了提高效率可能几次缓存在一个提交恢复写入动作里。
- 另一个就是顺序写磁盘技术比随机写的效率高
- 所有未提交的事务在崩溃后将根据日志内容全部放弃。
分布式系统中，事务恢复是一种重要的机制，用于保证事务的一致性和可靠性。分布式事务恢复通常包括以下几个步骤：
- 故障检测：在分布式系统中，需要监测系统中的故障情况，例如节点故障、网络故障等。当发生故障时，需要及时检测并进行相应的处理。
- 日志记录：在分布式系统中，需要对事务执行过程中的操作进行日志记录。日志记录可以用于恢复事务执行过程中的数据和状态。
- 事务回滚：当发生故障时，需要对未完成的事务进行回滚操作。回滚操作可以通过撤销事务的操作来恢复数据和状态。
- 事务重放：在故障恢复过程中，需要对已经提交的事务进行重放操作，以保证数据和状态的一致性和可靠性。
在实现分布式事务恢复时，需要考虑以下几个方面：
- 日志记录方式：需要选择合适的日志记录方式，以保证数据和状态的可靠性和一致性。
- 回滚机制：需要设计合适的回滚机制，以保证事务的一致性和可靠性。
- 重放策略：需要选择合适的重放策略，以保证数据和状态的一致性和可靠性。
- 容错机制：需要考虑分布式环境下的容错机制，以保证系统的可用性和可靠性。
在实现分布式系统时，需要考虑事务恢复机制，并采取相应的措施来保证系统的稳定性和可靠性。同时，需要进行事务恢复测试和调试，以保证系统的正确性和可靠性。