二.分布式锁的实现

　　FS只是负责数据存储，对数据的使用不进行任何承诺，所以必须提供锁功能来进行数据访问的保护，当然也可以提供给其它模块或用户程序进行系统/用户资源的保护。当用户程序不遵守自己的锁协议时可能会造成意外，但FS绝不会去介入数据的管理。

　　锁所占用的资源包括一个锁名、一个用于确认是否可以对锁进行操作的认证字和当前拥有锁的主机ID列表。对锁的实现不区分共享锁(读锁)还是互斥锁(写锁)，由用户程序自己定义锁协议来自行解决资源访问的权限问题。

　　锁的存活时间只有5秒，如果没有持续的Lock动作则5s后自动释放。当发生锁**时(即同名锁本机已分配又从网络收到其它发布的同名锁但认证字不同)就会先释放锁，如果是本机加的锁则还会执行一个强制锁**(向网络发布该锁)后并通知客户程序。

　　三.数据日志的实现

　　当需要同步数据文件、备份数据文件时，都需要冻结对数据文件的写操作，所以针对此期间的数据修改(增、删、改、改名)都需要建立一个数据日志，将数据修改操作保存下来，等数据文件同步、备份操作完成后再将数据日志导入。要考虑到在执行数据日志导入的同时如果还有数据写操作发生该如何处理。由于时间仓促，本系统暂时使用了多份数据日志的方案而没有使用管道。

　　数据日志本质上就是一个文件，其中的格式按TLV(类型/长度/值)方式进行定义即可。

　　四.事务的实现

　　有了锁也有了数据日志，所以很容易就实现了事务(Transaction)处理的功能。其本质就是把对数据的访问接口封装起来，读操作直接进行而数据修改操作则保存到事务处理的数据日志中，当最终Commit时再一次性的把所有数据修改变现。当然在Commit之前用户也可以随时Cancel掉本事务。

　　事务处理中最关键的是锁协议的定义。读锁(共享锁)使用1作为锁的认证字，而写锁(互斥锁)则使用2--int.maxvalue之间的一个随机数作为认证字。同时约定，通过事务进行的所有操作都必须拥有相应的锁，也就是说即便是只通过事务读也必须为其申请读锁才能够读取到数据。当然锁操作是被封装到事务处理的实现中，用户程序只需要定义需要访问的数据并指出其权限即可。

　　用户在使用事务处理时必须先定义需要访问的数据，然后要显式的启动事务才能进行数据访问。事务启动后就会开始逐个对需要访问的数据进行加锁，如果加锁不成功则事务会等待2s后再次进行尝试，如果加锁成功也会每2s执行一次Lock动作以维持锁，所以事务处理必须显式终结(调用Commit/Cancel)。用户程序必须等待事务指示可用后才能进行数据操作否则所有操作无效。

　　为了避免死锁，加锁不成功或锁**时都会将已申请到的锁全部释放掉。

　　事务处理顺便还实现了一个事务的Rollback功能，但由于敬惜人工智能系统平台所实现的事务处理工作在客户端，所以事务的Rollback功能其实没有多少意义，除非最终决定将所有的数据访问全部通过事务来实现，但这样做的代价过大，毕竟这是分布式系统而不是单机，事务处理的开销太大而且效率不高。

　　由于本分布式存储系统的专用性，所以这里的事务处理不具备通常意义上的事务处理所具备的完整性保证，这主要是因为平台数据的离散化特征决定的，平台所存储的数据不像关系数据库中的数据那样具有高度的函数依赖和数值依赖特征，所以本系统将数据完整性的维护责任交给了客户方。